Der Fehler trat dann auf, wenn man unter "Serververwaltung" -> "Mail" -> "Postfix" im Feld "Servername" einen manuellen Namen eingestellt hatte und diesen mit LiveConfig r4552-r4555 auf den Standard-Namen zurückgesetzt hatte.
Zurückgesetzt habe ich zwar nichts, aber ja, es war hier etwas anderes hinterlegt.
ZitatDanke auch für die schnellen Rückmeldungen und die Unterstützung bei der Fehlersuche.
Danke für's beheben! 
Lässt sich schon sagen wann - auch zeitlich - der Bug auftritt und ob er OS-abhängig ist?
Wir betreiben einen LiveConfig Business-Verbund mit getrennten Nameservern.
Der Fehler trat unabhängig von LiveCOnfig-Events auf: die Business-Installation habe ich um 12:39 UTC aktualisiert, die DNS-EInträge wurden um 14:50 Uhr UTC gelöscht.
Hallo,
der Fehler trat hier auch auf - identisches Verhalten (gelöschter MX auf allen Zonen)
Betraf allerdings nur Domains mit "internem" MX (eigene externe DNS-Records blieben erhalten).
Logs, soweit vorhanden, folgen per Mail.
Problematisch war allerdings auch, dass einfach nur ein Wechsel auf "extern" und zurück auf "intern" nicht reichte: BIND hat die Zone noch einige Sekunden (~60-90s?) aktiv, so dass der Wechsel auf intern nicht erkannt wurde.
Erst das Abwarten des kompletten Reload und das danach folgende "addZone" war von Erfolg gekrönt.
JUCHU!
*10z*
Liest hier überhaupt noch jemand richtig mit?
vs
Die Kritik ist fair, keine persönlichen Bereiche wurden angesprochen!!!!!
q.e.d.
Das ist eine Serververwaltung wo mehrheitlich schon vorhandene Programme angesteuert wird(Apache, Postfix und co).
Weil manche Features in der Form, in der LiveConfig die integriert, noch gar nicht existieren: für den Message-Quota-Dienst sind bisher nur Integrationen über Milter oder Policy-Services (CBPolicyd!) vorhanden. Die "üblichen Verdächtigen" bei HowTos gehen aber nicht auf Quota-Einschränkungen bei sendmail (mail()-Funktion) ein. Also hinsetzen und selber in Postfix rausbekommen, wie das am besten läuft, so dass der Kunde auch eine saubere Rückmeldung bekommt.
ZitatIch muss dazu sagen das ich immernoch zufrieden bin, ich schaue mir regelmässig die Konkurrenz an aber unübersichtliche Blackboxen wie Plesk oder OS Frickeleien wie ISPConfig sind auch nicht der Weisheit letzter Schluß.
Sehe ich genauso.
ZitatSolange bis das irgendwie mal komplett passt werde ich halt einige Sachen selber implementieren müssen. Was schade ist denn ich habe mehr als genug anderes zu tun.
Dito.
Wenn die Kommunikation der(s) Entwickler(s) eben so dürftig ist, dann passieren solche sachen eben, die sich ganz schnell in eine Negative Richtung drehen.
Und wie genau verbesserst du dadurch die Motivation im Entwickler-Team, die Probleme schneller zu lösen?
Nun, die Meldung deutet auf ein DAtenbankproblem hin, was sagt
show full processlist;
Bei einer SQLite-Datei nicht möglich.
Rate dazu, eventuell doppelt laufende Prozesse zu prüfen.
Eine Umstellung auf mySQL schadet auch nicht.
Empfehlung:
RewriteEngine on
RewriteRule ^(\.)\.html $1.phpHTML-Dateien von PHP parsen lassen ist dezent suboptimal, Stichwort "User darf HTML-Dateien hochladen".
It might be possible to use one ID within different users.
No, there's a unique constraint on Let's Encrypt Login Keys.
Meine Frage:
Anscheinend hat die Löschung des Cronjob über die LiveConfig-Oberfläche nicht richtig geklappt - wo kann ich nachschauen, ob da noch etwas rumliegt, was gelöscht werden muss - die /etc/cron* habe ich durch, da ist nichts drin?
crontab. ("-e -u xxx")
Berechtigungen des LC-Benutzers prüfen.
Dort ist das ganze auch dokumentiert und stimmt mit dem was kk geschrieben hat überein: Klick
*sign*
Chroots erzeugen mehr Aufwand und größere Probleme, als sie letztendlich nützen.
Zumal, wie Herr Keppler schon schrieb, man über PHP/Python/CGI sowieso genau das auch ausführen kann, was man über SSH machen könnte.
"Einsperren" mag über open_basedir und den safe_mode mit PHP 5.x noch funktionieren, wird mit PHP7 aber schwer und mit Python gar unmöglich.
Ganz abgesehen davon, dass open_basedir von PHP zwar einen Call von fopen() oder file_get_contents() verifiziert. Den identischen Aufruf von "system('cat ...');" hingegen nicht.
Warum also den Benutzer bei SSH künstlich einschränken und den Aufwand bei der Pflege erhöhen, gleichzeitig aber die Webserver-Umgebung weiterhin "offen" lassen?
Ok das Fazit ist also: PHP kompilieren und alles ist gut!
Oder die richtigen Pakete verwenden.
Wie macht ihr das denn mit den Modulen? Ihr habt doch sicherlich nicht nur ein Ordner für die Module, für alle PHP-Versionen oder?
Jede PHP-Version hat ein eigenes Scan-Dir und somit eigene Module etc, alles getrennt.
Welche RPM hast du denn da genau runtergeladen? Das sieht nämlich nicht danach aus, dass du die Daten so verwendest, wie das vom RPM vorgesehen ist/war.
Ne, ich habe nur die RPM's entpackt .. Aber das sollte ja auch funktionieren ;D
Nö, sollte es nicht.
Die PHP-Versionen wurden offenbar so compiliert, dass sie in /etc/php.d noch nach zusätzlichen ini-Dateien suchen.
Also diesen Ordner aufräumen und alle Extensions (warum man das auch immer will) direkt in LiveConfig verwalten, wodurch die Anweisungen mit in die Kunden-php.ini aufgenommen werden.
Der Reseller Bug den ich vor Monaten schon bemängelt habe, ist immer noch offen, sowas ist ein absolute no-go einfach wenn der Reseller nutzen kann soviel er will die Funktion ist völlig nutzlos so.
Wir haben unseren Resellern schlichtweg dedizierte Maschinen hingestellt. Erspart viele andere Probleme.
Aber ja, das ist schon länger offen.
ZitatDas LC immer noch das Olle FastCGI nutzt und warum nicht endlich mal auf php-fpm => Wenn du schon mit Kleinigkeiten wie Docroot ändern kommst
Docroot ändern ist Webserver-unabhängig, PHP-FPM hingegen nur für Nginx. Dort gibt es übrigens auch Probleme (APC-Cache ist global für alle Pools!).
ZitatMan darf auch nicht vergessen das ISPC nichts kostet im gegensatz zu LC wo ich gewisse dinge auch erwarte wenn es Gebühren Kostet.
Korrekt.
ZitatUmzüge mit LC auf andere Server sind grausam, ich/wir haben das nun 3 mal gemacht und jedes mal lief was anderes schief
Dann macht ihr die Umzüge anders als wir.
Rsync des gesamten Servers - anschließend Anpassung der Netzwerk-Konfiguration sowie der IPs etc. in LiveConfig. Läuft.
Zitatsowas ist mir bei Plesk nicht einmal passiert.
Die letzten Umzüge, die ich mit dem Plesk-Migrations-Tool (Backup/Restore) gemacht habe, liefen alles andere als "problemlos". Ist aber auch ein Weilchen her.
Letztendlich: Plesk gibt es nicht erst seit gestern. Hat mit Parallels/Ingram/Odin/Yippie-Yeah GmbH aber auch etwas mehr Kapital und damit auch Manpower zur Verfügung.
Wenn dir Plesk besser gefällt - bitte, es hindert dich keiner, nur noch das einzusetzen.
Ich habe mit Plesk meine Probleme und daher weiterhin die Hoffnung, dass die bestehenden Probleme gelöst werden. Ein produktiver Einsatz von LiveConfig ist problemlos möglich. Das Setup geht deutlich schneller als Plesk oder ISPConfig, preislich empfinde ich es auch attraktiver.
Und zum Thema "SSL so schön einfach": die Nachteile bei der Umsetzung habe ich oben schon skizziert.
Ich bin gespannt, wie die Dialog-Box dazu bei LC ausfallen wird.
Also wenn der wechsel LC => Plesk oder ISPConfig 3 so ohne weiteres möglich wäre, würden wir das sofort machen.
Andersrum aber genausowenig.
ZitatSupport bei LC ist mehr schlecht als recht.Update kommen kaum noch in den letzten Monaten
Oh?
"Preview-Version: 2.3.0 (r4541) (03.04.2017)"
ZitatIch hab es schon mal gesagt, an unseren Kunden würde ich LC derzeit nicht mehr empfehlen
Sowohl Plesk als auch ISPConfig haben - in meinen Augen - massive konzeptuelle Probleme: beide Lösungen wurden um das Objekt "Domain" als Kern-Komponente, statt um "Vertrag"/"Kunde", aufgebaut.
Das heißt:
- Alias-Domains sind bei beiden nur stiefmütterlich behandelt worden. Diese sind aber relevant, wenn mehrere Domains auf das gleiche CMS / den gleichen Ordner zeigen sollen (WP-Netzwerk, Multishop, ...)
- ISPConfig hat sich IMHO selbst ins Abseits geschossen, da Subdomains noch suboptimaler gelöst sind. mod_rewrite-Gefriemel, wenn das Docroot geändert werden soll, empfinde ich nicht als elegant (auch für den Kunden nicht)
- SSL-Zertifikate sind gerade bei Alias-Domains schwierig: ISPConfig erlaubt für Alias-Domains gar keine (eigenen) SSL-Zertifikate. Mit der neue Let's Encrypt-Integration wird ein MUltiDomain-Zertifikat beantragt, was gerade bei WP-Netzwerk suboptimal ist. Ich will persönlich keinem Dritten verraten müssen, welche Domains sonst noch so auf dem Shop liegen. Plesk kann das inzwischen besser, ja.
Somit stellt sich (mir!) die Frage, ob zurück zu ISPConfig oder Plesk, gar nicht erst: "Änderung DocRoot", "mehrere Domains in einem Account" und "unabhängige SSL-Zertifikate" sind drei Eigenheiten von LiveConfig, die die anderen beiden Panels nicht (in der Form wie LC) bieten.
- Port 80 kann nicht durch Nginx belegt werden, weil vermutlich Apache schon darauf läuft. "netstat -tulpen" kann das bestätigen.
- LiveConfig ersetzt Dateien, ja. Die sollten dann auch nicht mehr geändert werden
- LiveCOnfig verwendet PHP-FCGI für Nginx, nicht PHP-FPM.
Das ist jetzt aber nichts, was sich nicht auch durch Suche im Forum/Google rausfinden hätte lassen können.
Offenbar läuft der dazugehörige FastCGI-Prozess (nginx-php-fcgi) nicht oder öffnet nicht diesen Socket.
