Hab daran garnicht gedacht das der Reseller für seine Kunden diese Einstellung ja seperat nochmal abändern kann..
hm, eigentlich wäre es schöner und sinnvoller, wenn der Reseller den Präfix nicht ändern kann, höchstens weiteres anhängen kann...
Hab daran garnicht gedacht das der Reseller für seine Kunden diese Einstellung ja seperat nochmal abändern kann..
hm, eigentlich wäre es schöner und sinnvoller, wenn der Reseller den Präfix nicht ändern kann, höchstens weiteres anhängen kann...
bitte auch den Changelog 3350->3353 ergänzen
... und das Handbuch fehlt natürlich noch
das sollte ausreichen, vielleicht noch ein reboot des openvz-containers.
vollständig weiß ich es nicht mehr, aber ich sehe hier bei einem OpenVZ-LC-Container keine weiteren Settings in dieser Richtung.
prüfen kann man dann mit "repquota -g -a"
kann es sein das man mit Version 1.8, statt den Bug zu beheben, den Reiter: Angebote -> Eigenschaften -> PHP-Einstellungen jetzt ganz entfernt hat?
ja, das scheint so zu sein
das war zwar schon bei 1.7.x der Fall, dennoch:
wenn man in der Serververwaltung von Postfix auf das "i" neben DNS-Whitelists klickt, kommt nur "undefined"
[*]Verwaltung eigener DNS-Einträge (A/AAAA/CNAME/MX/TXT/SRV)
na dann ist das endlich mal erledigt und man kann mit wichtigerem fortfahren
[*]vereinfachte Integration eigener Einstellungen in Postfix-Konfiguration (postfix.LOCALCONFIG - wird derzeit noch in die Doku aufgenommen)
auch sonst ist ja leider zu LCDEFAULTS noch nichts in der Doku, wäre wünschenswert da nachzubessern
Zuletzt steht es ja jedem Anwender selbst frei, wann/ob er LiveConfig aktualisiert.
gleich mal apt pinning auf 1.7.* eingerichtet
oder benennen Sie die Konfigurationsdatei um (z.B. in "awstats.conf.disabled").
das behebt das Problem.
manchmal hängt sich postgrey übrigens so auf, dass nur "kill -9 PID-von-postgrey" hilft, kein normaler neustart/start
Klingt, als läuft auf dem Empfänger-Server Postgrey nicht.
Evtl. wurde es manuell beendet oder mangels genug Arbeitsspeicher durch den oom_killer?
ps aux | grep postgrey
und bei Debian z.B.:
/etc/init.d/postgrey start
Arnolds Ausführungen klingen sehr vernünftig
Danke für die Umsetzung.
ich glaube dazu gab es schon 2 Themen, bitte kein drittes anfangen:
http://www.liveconfig.com/de/f…tellungen-error_reporting
http://www.liveconfig.com/de/forum/threads/1560-PHP-Schwerwiegende-Bugs-innerhalb-von-Configs-in-speziellen-Fällen
Auf jeden Fall müssen wir die Init-Scripte (liveconfig/lcclient/lcsam/...) für systemd "fit machen".
Bitte unbedingt mit Berücksichtigung, dass nicht jeder auf Debian8 systemd nutzen wird
da muss kk+Team ran (die den Bug auch schon länger kennen).
Dazu gibt es sogar schon länger zwei praktisch gleiche Tickets im öffentlichen Redmine-Bugtracker:
https://www.liveconfig.com/dev/issues/111
https://www.liveconfig.com/dev/issues/139
"Zielversion 1.7.0" hat nicht ganz geklappt, obwohl es wirklich ein Bug ist und kein Feature...
LiveConfig unterstützt MariaDB bereits
Gut zu wissen! das reicht uns zumindest, v.a. aufgrund der angesprochenen User-Verwirrungs-Problematik ist es evtl. sogar besser, dass es dem Kunden als MySQL-DB dargestellt wird.
Da fällt mir ein:
Testen Sie bald/schon auch mit Debian 8 Jessie?
Da wird sich ja nichts großes mehr ändern, es wäre sehr gut, wenn diese neue Debian-Version ab dem 1. Release-Tag dann voll unterstützt würde, sodass man ab diesem Stichtag (voraussichtlich Anfang 2015) keine neuen Wheezy-Systeme mehr aufsetzen muss
Die Frage ist immer, wie repräsentativ eine Umfrage im Forum ist. Wenn ich z.B. mit einem Kunden spreche, der >50 LiveConfig-Server betreibt, dann hat der natürlich mehr Stimmen als fünf Kunden im Forum.
so sollte es sein, ja
EDIT:
da fiel mir durch nachzählen gerade erst auf, wieviele Lizenzen das hier schon sind :-O
wenn ich mir den Kommentar erlauben darf:
es erstaunt mich, wie viele die DNS-Server nicht vom Hosting trennen und auf die sehr ausgereiften Verwaltungsoberflächen etablierter Domain-Registrare verzichten...
Die Angabe von Release-Daten oder Angaben wie "voraussichtlich nächste Woche" ist nicht hilfreich, wenn sie so falsch bleiben wie in der Vergangenheit. Natürlich kann unerwartetes dazwischen kommen, aber dann plant man dieses Risiko entweder mit ein und nennt einen späteren Termin oder aber sagt gar nichts zu Terminen bzw. Terminplanung.
Die Komplexität der Releases könnte auch verringert werden, siehe unten.
Ähm, jede Software befindet sich in der Entwicklung denn Stillstand == TOT.
Ab einem gewissen Punkt muss man aber diese nunmal einsetzen können und der Shop suggeriert mir das es soweit ist
Und auf die Implementierung drängen tut man nur wenn es schon Jahrelang angekündigt ist und sich drauf verlassen hat das das kommt. Das es stellenweise Jahrelang auf sich warten lässt ist kein Idealzustand.
Da schließe ich mich an.
Immerhin scheint 1.8.0 einige unserer Probleme und Anforderungen zu lösen - hoffen wir nur, dass nicht mehrere neue Bugs hinzukommen, deren Behebung dann wieder eine Weile dauert.
Aus unserer Kundensicht wäre weiterhin zu befürworten, den Fokus noch stärker auf Bugfixing zu legen, Bugfix-Releases von Feature-Releases zu trennen und neue Funktionen in kleineren Häppchen zu releasen.
PS: ach ja, mit IE6/7 ist LiveConfig nun leider nicht mehr verwendbar. Minimum ist nun IE8 (mit dem testen wir das zumindest als "Minimal-Standard" durch).
Wird dem Nutzer anhand des UserAgent dann direkt eine entsprechende Meldung angezeigt und der Login verweigert oder kommt es zu einer Vielzahl von Problemen?