ISPConfig Update (3.0.3.3 » 3.0.4.3) Mail, vhost und DB Probleme

[vertex]

ISPConfig Update von Version 3.0.3.3 auf 3.0.4.3

Server auf Basis: The Perfect Server – Debian Squeeze (Debian 6.0) With BIND & Courier [ISPConfig 3]

Pakete aktuellste Version (apt-get upgrade von heute morgen).

----------

Nach dem Update von ISPConfig konnten keine eMails mehr gesendet oder empfangen werden. (Temporary authentication failure.)

Habe dann das Backup mit der aktuellen Konfiguration abgeglichen.

U. A. gibt es Unterschiede in der "/etc/courier/authmysqlrc" betreffend "MYSQL_LOGIN_FIELD". Zuvor stand dort "email" als Wert - jetzt "login". Diese Änderung wurde durch das Update auch in anderen Configdateien vorgenommen.

Habe also die Tabelle mail_user geprüft: Dort existiert kein Feld "login" - lediglich "email".

Ich habe das Problem vorerst gelöst, indem ich das Feld "login" neu angelegt und die Inhalte des Feldes "email" dorthin kopiert habe. Ist jetzt redundant.

Als nächstes habe ich in ISPConfig einen neuen Account angelegt um zu prüfen welches Feld jetzt benutzt wird. Zu meiner Überraschung: Beide!? Wie jetzt?

Ich kann mir ja erklären wofür man beide Felder haben möchte - wenn Login Benutzername von der eMail-Adresse abweichen soll - aber dann bräuchte ich in der ISPConfig Maske doch ein entsprechendes Feld?

----------

Nächste Probleme:
- die vhosts funktionieren nicht mehr (alles geht auf default)
- Server IP Adressen können bei Domains nicht mehr ausgewählt werden
- Server IP Adressen können nicht mehr verwaltet werden (Fehler: Unknown column 'client_id' in 'field list')

Mal sehn ob das alles war. Ich tendiere langsam dazu das Backup wieder einzuspielen - dieses "Update" scheint ja mehr Arbeit zu verursachen als eine Neuinstallation - und das bei einer Standardinstallation ohne irgendwelche großen Sonderkonfigurationen.

Wird der Updatelog irgendwo gespeichert, sodass ich dort nach Fehlern suchen kann? Mir scheint als hätte mindestens das Update der ISPConfig Datenbank nicht geklappt.

Hab ich irgendeinen ganz entscheidenden Punkt beim Update vergessen? Bei einer Standardkonfiguration sollte man doch nicht mehr machen müssen als ispconfig_update.sh mit Standardparametern durchzuführen??


/edit:

Musste zurück auf Version 3.0.3.3 - kann das Produktivsystem nicht so lange abgeschaltet lassen. Werde wohl einen Clon herstellen und an diesem herumexperimentieren müssen.

Gibt es irgendwo manuelle Updateinstruktionen? Beim automatischen Update wird die Datenbank scheints einfach übergangen und nichts läuft mehr

Kann es sein, dass der Standardname der Datenbank fest im Updatescript steht oder etwas ähnlich dummes?? Wenn das bei allen klappt, nur bei mir nicht, kann es ja nur eine dieser wenigen, vom Standard abweichenden Optionen sein. Wir haben Aliase für Squirrelmail (wie am Ende des Installtutorials beschrieben) und eben einen anderen Datenbanknamen. Der Rest ist eigentlich standard.

 

[Till]

Erstmal vorab, ich hab schon jede Menge Debian squeeze systeme von 3.0.3.3 aof 3.0.4.3 aktualisiert, immer problemlos. Es muss also an etwas spezifischen auf Eirem System liegen.

Ich vermute etwas mit den Datenbankberechtigungen nicht stimmt. Ein gern gemachter Fehler ist dass ein anderer User angegeben wird wenn der ISPConfig Installer nach dem root User fragt und wenn der andere User dann nicht vollständige root Permissions hat, dann kann das Update nicht vollständig durch laufen. Einde andere Möglichkeit ist dass Du das mysql root Passwort geändert hast ohne es auch in /usr/local/ispconfig/server/lib/mysql_clientdb.conf zu ändern.

Dee Datenbankname speilt keine Rolle. Falls Du aber Befehlszeichen die von der Shell interpretiert werden in Deinem mySQL root Passwort verwendest, dann kann dies durchaus Probleme machen.

 

[vertex]

Guter Gedanke! Das war's allerdings leider noch nicht.

/usr/local/ispconfig/server/lib/mysql_clientdb.conf

Geprüft, dort stehen die korrekten root Zugangsdaten - geändert hat sich nichts und das Passwort ist alphanumerisch ohne Sonderzeichen.

Bei dem Schritt "Reconfigure Services? (yes,no) [yes]:" des Updatescripts war ich unsicher, da mir nicht klar war welche Services alle betroffen sein sollen. Habe dann aber der Standardauswahl vertraut und bestätigt, da sowieso ziemlich alles standardmässig nach "The Perfect Server" Instruktionen konfiguriert wurde.

Wählst du dort eventuell "nein"?

Andere Unterschiede zwischen unseren Systemen? Eventuell Dovecot statt Courier?


Kann man den Output des Updatescripts irgendwie abrufen oder beim nächsten Versuch speichern? "command > file" fällt mir spontan ein - doch dann hab ich glaub ich keine Interaktionsmöglichkeiten mehr. Muss mal nach Modifiern suchen.. aber evtl wird's ja sowieso irgendwo gelogged?

 

[Till]

Die Standardauswahl zu wählen war richtig und ist auch notwendig, wenn Du nein gewählt hättest dann wären die Konfiguartionsdateien nicht an die neue Datenbankstruktur angepasst worden.

Kann man den Output des Updatescripts irgendwie abrufen oder beim nächsten Versuch speichern? "command > file" fällt mir spontan ein - doch dann hab ich glaub ich keine Interaktionsmöglichkeiten mehr. Muss mal nach Modifiern suchen.. aber evtl wird's ja sowieso irgendwo gelogged?

Der steht bereits im install.log in /var/log/ispconfig/

 

[vertex]

Ach, so einfach ist das

Dort hab ich zwar keine install.log, aber ein Verzeichnis höher hab ich eine ispconfig_install.log gefunden. Mal sehn...

Gleich als erster Eintrag:

Do 29. Mär 10:37:05 CEST 2012 - [ISPConfig] - /tmp/ispconfig3_install/install/lib/update.lib.php, Line 38: WARNING: could not read in ispconfig3.sql

Leider ist /tmp/ispconfig3_install/ schon weg (hat wohl das Setup aufgeräumt)...

Liegt vielleicht das heruntergeladene Archiv noch irgendwo rum?

 

[Till]

Du findest ein Backup der SQL Datei im Backup Verzeichnis dass Du beim Update angegeben hast, wahrscheinlich /var/backups oder /var/backup/. Außer Du hast beim Update angegeben dass Du kein Backup erstellen möchtest.

 

[vertex]

Der macht ein Backup des Installationspaketes? Prima, wird am nächsten Arbeitstag geprüft - also mor*gähn*

Dank zwischendurch für die andauernde Hilfestellung

 

[Till]

Der macht ein Backup des Installationspaketes? Prima, wird am nächsten Arbeitstag geprüft - also mor*gähn*

Nein, ein Backup der Installation vor dem Update inkl. der DB und anahnd des dort liegenden SQL Dumps kannst Du nachsehen warum es fehlschlägt. Möglicherweise hast Du irgendwelche Datenbakfelder selbst in der DB eingefügt? Das Installationspaket kannst Du Dir doch jederzeit runter laden von ispconfig.de.

 

[vertex]

Ne, ich hab garnichts geändert an der Datenbank.

Ok, die zwei Stellen an der mein "could not read in ispconfig3.sql" Fehler kommt stecken in der update.lib.php ganz am Anfang:

//** load the pre update sql script do perform modifications on the database before the database is dumped
    if(is_file(ISPC_INSTALL_ROOT."/install/sql/pre_update.sql")) {
        if($conf['mysql']['admin_password'] == '') {
            caselog("mysql --default-character-set=".$conf['mysql']['charset']." -h '".$conf['mysql']['host']."' -u '".$conf['mysql']['admin_user']."' '".$conf['mysql']['database']."' < '".ISPC_INSTALL_ROOT."/install/sql/pre_update.sql' &> /dev/null", __FILE__, __LINE__, 'read in ispconfig3.sql', 'could not read in ispconfig3.sql');
        } else {
            caselog("mysql --default-character-set=".$conf['mysql']['charset']." -h '".$conf['mysql']['host']."' -u '".$conf['mysql']['admin_user']."' -p'".$conf['mysql']['admin_password']."' '".$conf['mysql']['database']."' < '".ISPC_INSTALL_ROOT."/install/sql/pre_update.sql' &> /dev/null", __FILE__, __LINE__, 'read in ispconfig3.sql', 'could not read in ispconfig3.sql');
        }
    }

Ok, also nicht ispconfig3.sql

An der Stelle werden eigentlich nur die $conf Variable und ISPC_INSTALL_ROOT Konstante gebraucht. Das SQL Script macht nichts was irgendwie Feldabhängig wär - nur "DROP TABLE IF EXISTS"..

/usr/local/bin/ispconfig_update.sh
calls
/usr/local/ispconfig/server/scripts/ispconfig_update.php
calls
/usr/local/ispconfig/server/scripts/update_from_tgz.sh
calls
/tmp/ispconfig3_install/install/update.php

update.php definiert die ISPC_INSTALL_ROOT erst in Zeile 65, bindet die update.lib.php aber schon in Zeile 54 ein. Aber wäre die Konstante nicht definiert, dürfte er ja die Bedingung is_file() nicht erfüllen.

Ich bin da nicht tief genug drin um das schnell nachvollziehen zu können. Ich belass es erstmal bei "geht halt nicht" - muss wieder zur Projektarbeit.

Zum Server: Ist ein Strato V-Server.. ziemlich neue Installation. Ausser Debian Installation mit ISPConfig 3.0.3.3 nach Perfect Server Manual (inkl Squirrelmail + JailKit) und regelmässigen Debian Updates ist da nichts passiert oder gebastelt worden. Evtl funktioniert ja ein späteres Update - ansonsten muss es warten bis ich meinen privaten Server (gleiches Setup, bis auf Dovecot statt Courier) aktualisiere.. da hab ich dann auch mehr Zeit mir die Programmierung vom Update anzusehen. Zur Not Installpakete von 3.0.3.3 und 3.0.4.7 vergleichen und alles per Hand umbauen.

Till, danke nochmal für deinen Einsatz. Kann den Zeitaufwand nur leider nicht mehr rechtfertigen und noch einen Serverausfall durch Updateversuch kann ich auch nicht riskieren. Kommt auf die "Wenn Zeit dafür ist.." Todo - und die wird leider so gut wie nie abgearbeitet...

 

[Till]

Mögliche andere Ursachen sind eine volle Festplatte, gecrashte mysql Tabellen (mal mit phpmyadmin checken) oder aber Zeichensequenzen die von der bash interpretiert werden im mysql root passwort, sowas wie hochkommata oder $.

Updates von 3.0.3.3 auf 3.0.4.3 hab ich jede Menge für Kunden installiert, das lief immer problemlos. Muss also etwas spezifisches an Deinem Setup sein was den Fehler hervorruft.

 

[vertex]

volle Festplatte: Wie gesagt, frisches System, viel Platz
gecrashte mysql Tabellen: Werde ich prüfen..
Zeichensequenzen im mysql root passwort: Geprüft, keine drin.

Ja, irgendwas muss ja anders sein - allerdings ist nichts "spezielles" dazugekommen. Wir haben das System ja extra so aufgesetzt, dass es so standardkonform ist, dass wir problemlose Updates fahren können.

Eventuell gabs auch ein temporäres Problem - beschädigter Download oder sowas.

Heute abend werd ich mal meinen privaten Server prüfen - der kam später, evtl ist da schon 3.0.4.7 drauf. Falls nicht mache ich dort mal ein Update. Falls das klappt kann ich dessen System mit dem des Problemservers abgleichen.

 

[vertex]

So, ist zwar schon ne Weile her, aber es gibt noch etwas neues.

Ich hab mich jetzt endlich getraut auf meinem privaten Server das Update auf 3.0.4.3 zu wagen. Der einzige Unterschied zu den Firmenservern ist, dass der private Server mit Dovecot statt Courier läuft. Ansonsten identische Setups.

Das Problem beim Einstellen der IP Adressen hatte ich diesmal nicht. ISPConfig läuft nach dem Update ganz prima. Allerdings waren alle Domains nicht mehr erreichbar, exakt dem Problem entsprechend wie hier beschrieben: http://www.howtoforge.de/forum/installation-und-konfiguration-12/update-3-0-3-2-alle-webs-weg-3957/

Ich habe also die Einstellungen mit Name VirtualHost vorgenommen, gewartet, wieder aktiviert, lange gewartet (rund eine Stunde)... trotzdem keine Besserung - Domains weiterhin unerreichbar.

Es folgen zwei weitere Nachrichten, da der folgende Log + Nachrichtenteil das Limit von 10.000 Zeichen sprengt.

 

[vertex]

"service apache2 restart" lieferte mir dann nochmal die gleichen Meldungen, wie ich sie schon am Ende des ISPConfig Update Scripts bekommen hatte und zusätzlich ein schönes, rotes "failed":

myAwesomeColoredHostname / # service apache2 restart
Restarting web server: apache2[Tue Jun 05 20:18:06 2012] [warn] The  Alias directive in /etc/apache2/sites-enabled/010-ispconfig.conf at line  51 will probably never match because it overlaps an earlier Alias.
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost 123.45.67.89:443 overlaps  with VirtualHost 123.45.67.89:443, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost 123.45.67.89:80 overlaps  with VirtualHost 123.45.67.89:80, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost  [IPv6 gekürzt]:443 overlaps with VirtualHost  [IPv6 gekürzt]:443, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost  [IPv6 gekürzt]:80 overlaps with VirtualHost  [IPv6 gekürzt]:80, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost 123.45.67.89:443 overlaps  with VirtualHost 123.45.67.89:443, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost 123.45.67.89:80 overlaps  with VirtualHost 123.45.67.89:80, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost  [IPv6 gekürzt]:443 overlaps with VirtualHost  [IPv6 gekürzt]:443, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost  [IPv6 gekürzt]:80 overlaps with VirtualHost  [IPv6 gekürzt]:80, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost 123.45.67.89:443 overlaps  with VirtualHost 123.45.67.89:443, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost 123.45.67.89:80 overlaps  with VirtualHost 123.45.67.89:80, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost  [IPv6 gekürzt]:443 overlaps with VirtualHost  [IPv6 gekürzt]:443, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost  [IPv6 gekürzt]:80 overlaps with VirtualHost  [IPv6 gekürzt]:80, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost 123.45.67.89:443 overlaps  with VirtualHost 123.45.67.89:443, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost 123.45.67.89:80 overlaps  with VirtualHost 123.45.67.89:80, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost  [IPv6 gekürzt]:443 overlaps with VirtualHost  [IPv6 gekürzt]:443, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost  [IPv6 gekürzt]:80 overlaps with VirtualHost  [IPv6 gekürzt]:80, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost 123.45.67.89:443 overlaps  with VirtualHost 123.45.67.89:443, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost 123.45.67.89:80 overlaps  with VirtualHost 123.45.67.89:80, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost  [IPv6 gekürzt]:443 overlaps with VirtualHost  [IPv6 gekürzt]:443, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost  [IPv6 gekürzt]:80 overlaps with VirtualHost  [IPv6 gekürzt]:80, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost 123.45.67.89:443 overlaps  with VirtualHost 123.45.67.89:443, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:06 2012] [warn] VirtualHost 123.45.67.89:80 overlaps  with VirtualHost 123.45.67.89:80, the first has precedence, perhaps you  need a NameVirtualHost directive
 ... waiting [Tue Jun 05 20:18:07 2012] [warn] The Alias directive in  /etc/apache2/sites-enabled/010-ispconfig.conf at line 51 will probably  never match because it overlaps an earlier Alias.
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost  [IPv6 gekürzt]:443 overlaps with VirtualHost  [IPv6 gekürzt]:443, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost  [IPv6 gekürzt]:80 overlaps with VirtualHost  [IPv6 gekürzt]:80, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost 123.45.67.89:443 overlaps  with VirtualHost 123.45.67.89:443, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost 123.45.67.89:80 overlaps  with VirtualHost 123.45.67.89:80, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost  [IPv6 gekürzt]:443 overlaps with VirtualHost  [IPv6 gekürzt]:443, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost  [IPv6 gekürzt]:80 overlaps with VirtualHost  [IPv6 gekürzt]:80, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost 123.45.67.89:443 overlaps  with VirtualHost 123.45.67.89:443, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost 123.45.67.89:80 overlaps  with VirtualHost 123.45.67.89:80, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost  [IPv6 gekürzt]:443 overlaps with VirtualHost  [IPv6 gekürzt]:443, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost  [IPv6 gekürzt]:80 overlaps with VirtualHost  [IPv6 gekürzt]:80, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost 123.45.67.89:443 overlaps  with VirtualHost 123.45.67.89:443, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost 123.45.67.89:80 overlaps  with VirtualHost 123.45.67.89:80, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost  [IPv6 gekürzt]:443 overlaps with VirtualHost  [IPv6 gekürzt]:443, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost  [IPv6 gekürzt]:80 overlaps with VirtualHost  [IPv6 gekürzt]:80, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost 123.45.67.89:443 overlaps  with VirtualHost 123.45.67.89:443, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost 123.45.67.89:80 overlaps  with VirtualHost 123.45.67.89:80, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost  [IPv6 gekürzt]:443 overlaps with VirtualHost  [IPv6 gekürzt]:443, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost  [IPv6 gekürzt]:80 overlaps with VirtualHost  [IPv6 gekürzt]:80, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost 123.45.67.89:443 overlaps  with VirtualHost 123.45.67.89:443, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost 123.45.67.89:80 overlaps  with VirtualHost 123.45.67.89:80, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost  [IPv6 gekürzt]:443 overlaps with VirtualHost  [IPv6 gekürzt]:443, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost  [IPv6 gekürzt]:80 overlaps with VirtualHost  [IPv6 gekürzt]:80, the first has precedence,  perhaps you need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost 123.45.67.89:443 overlaps  with VirtualHost 123.45.67.89:443, the first has precedence, perhaps you  need a NameVirtualHost directive
[Tue Jun 05 20:18:07 2012] [warn] VirtualHost 123.45.67.89:80 overlaps  with VirtualHost 123.45.67.89:80, the first has precedence, perhaps you  need a NameVirtualHost directive
(98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
Action 'start' failed.
The Apache error log may have more information.
 failed!

Es folgt eine weitere Nachricht.

 

[vertex]

Als nächstes habe ich den Loglevel via ISPConfig auf "Debug" konfiguriert und /usr/local/ispconfig/server/server.sh ausgeführt, wie hier beschrieben: Jobqueue backed up - Page 2 - HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

Ausgabe:

myAwesomeColoredHostname /usr/local/ispconfig/server # /usr/local/ispconfig/server/server.sh
05.06.2012-18:43 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
05.06.2012-18:43 - DEBUG - Found 4 changes, starting update process.
05.06.2012-18:43 - DEBUG - Calling function 'update' from plugin 'apps_vhost_plugin' raised by event 'server_update'.
05.06.2012-18:43 - DEBUG - Calling function 'update' from plugin 'network_settings_plugin' raised by event 'server_update'.
05.06.2012-18:43 - DEBUG - Network configuration disabled in server settings.
05.06.2012-18:43 - DEBUG - Calling function 'update' from plugin 'postfix_server_plugin' raised by event 'server_update'.
05.06.2012-18:43 - DEBUG - Processed datalog_id 98
05.06.2012-18:43 - DEBUG - Calling function 'update' from plugin 'apps_vhost_plugin' raised by event 'server_update'.
05.06.2012-18:43 - DEBUG - Calling function 'update' from plugin 'network_settings_plugin' raised by event 'server_update'.
05.06.2012-18:43 - DEBUG - Network configuration disabled in server settings.
05.06.2012-18:43 - DEBUG - Calling function 'update' from plugin 'postfix_server_plugin' raised by event 'server_update'.
05.06.2012-18:43 - DEBUG - Processed datalog_id 99
05.06.2012-18:43 - DEBUG - Calling function 'update' from plugin 'apps_vhost_plugin' raised by event 'server_update'.
05.06.2012-18:43 - DEBUG - Calling function 'update' from plugin 'network_settings_plugin' raised by event 'server_update'.
05.06.2012-18:43 - DEBUG - Network configuration disabled in server settings.
05.06.2012-18:43 - DEBUG - Calling function 'update' from plugin 'postfix_server_plugin' raised by event 'server_update'.
05.06.2012-18:43 - DEBUG - Processed datalog_id 100
05.06.2012-18:43 - DEBUG - Calling function 'update' from plugin 'apps_vhost_plugin' raised by event 'server_update'.
05.06.2012-18:43 - DEBUG - Calling function 'update' from plugin 'network_settings_plugin' raised by event 'server_update'.
05.06.2012-18:43 - DEBUG - Network configuration disabled in server settings.
05.06.2012-18:43 - DEBUG - Calling function 'update' from plugin 'postfix_server_plugin' raised by event 'server_update'.
05.06.2012-18:43 - DEBUG - Processed datalog_id 101
05.06.2012-18:43 - DEBUG - Calling function 'restartHttpd' from module 'web_module'.
[Tue Jun 05 20:43:47 2012] [warn] The Alias directive in /etc/apache2/sites-enabled/010-ispconfig.conf at line 49 will probably never match because it overlaps an earlier Alias.
[Tue Jun 05 20:43:47 2012] [warn] NameVirtualHost 123.45.67.89:80 has no VirtualHosts
[Tue Jun 05 20:43:47 2012] [warn] NameVirtualHost 123.45.67.89:443 has no VirtualHosts
[Tue Jun 05 20:43:47 2012] [warn] NameVirtualHost 1234:567:890a:bcde:f012:3456:7890:abcd:80 has no VirtualHosts
[Tue Jun 05 20:43:47 2012] [warn] NameVirtualHost 1234:567:890a:bcde:f012:3456:7890:abcd:443 has no VirtualHosts
[Tue Jun 05 20:43:48 2012] [warn] The Alias directive in /etc/apache2/sites-enabled/010-ispconfig.conf at line 49 will probably never match because it overlaps an earlier Alias.
[Tue Jun 05 20:43:48 2012] [warn] NameVirtualHost 123.45.67.89:80 has no VirtualHosts
[Tue Jun 05 20:43:48 2012] [warn] NameVirtualHost 123.45.67.89:443 has no VirtualHosts
[Tue Jun 05 20:43:48 2012] [warn] NameVirtualHost 1234:567:890a:bcde:f012:3456:7890:abcd:80 has no VirtualHosts
[Tue Jun 05 20:43:48 2012] [warn] NameVirtualHost 1234:567:890a:bcde:f012:3456:7890:abcd:443 has no VirtualHosts
05.06.2012-18:43 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
finished.

Der Witz ist: Wie man leicht erkennt, stehen dort wesentlich weniger Warnungen. Noch lustiger ist, dass danach jetzt wieder alle Domains wieder sauber ansprechen.

Ob das jetzt die eine Sekunde war, welche ich nicht lange genug "gewartet" habe, oder ob es das ausführen der server.sh war (was ist das eigentlich für ein Script? Und wo wir schon dabei sind: Wo finde ich die Job Cue? (Kein Typo, ich mag "Queue" nur nicht tippen)) kann ich nicht sagen.

Werde jetzt erstmal losstiefeln und schauen wieso da immernoch 4 Warnungen wegen "has no VirtualHosts" kommen. Ausserdem muss ich mal nachschauen was das für eine Aliasdirektive ist...

Puh.. habe fertig. Dank dir Till für deine ganze Unterstützung, welche ich diesmal zwar aus anderen Threads gekratzt habe, wo aber dennoch immer dein Name dran stand

/e Post Scriptum:
Mir ist beim Vergleich der gemachten SQL Dumps der ISPConfig DB (vor und nach Backup) noch aufgefallen, dass es keinerlei Datenbankstrukturänderungen durch das Update gab. Seltsam.. evtl hatte ich auf dem privaten Server doch schon eine etwas neuere Version von ISPConfig als in der Firma *grübel*

/e2 Post Post Scriptum:
Zeile 49 der /etc/apache2/sites-enabled/010-ispconfig.conf

Alias /awstats-icon "/usr/share/awstats/icon"

...und gefunden:

lrwxrwxrwx 1 root root 43 Jun  5 20:05 000-ispconfig.conf -> /etc/apache2/sites-available/ispconfig.conf
lrwxrwxrwx 1 root root 43 Feb  6 21:35 010-ispconfig.conf -> /etc/apache2/sites-available/ispconfig.conf

Tja, die war wohl doppelt gesymlinked. Die 000 fliegt raus - die Zahlen sind extra so gewählt um die Priorität festzulegen. Oder spricht etwas dagegen? Jetzt gibt's beim Apache Restart jedenfalls keine Warnungen mehr

 

[woehrl]

Update 3.0.5.3 auf 3.0.5.4 - Gleiches Problem

Beim Update auf die neueste Version entstand auf unserem Server wieder dieses Problem.
Die NameVirtualHosts in der /etc/apache2/sites-available/ispconfig.conf waren weg, obwohl unter System-Server IP Adressen noch immer alle IP-Adressen eingetragen waren und die Option NameVirtualHosts aktiviert war.
Wäre es möglich, nach dem Update dieses File korrekt neu erstellen zu lassen?

Viele Grüße,
F W

 

[Till]

Ich habe es gerade mal auf 3 Kundensystemen gecheckt die ich heute von 3.0.5.3 auf 3.0.5.4 aktualisiert habe. Die Datei wurde auf allen korrekt erstellt und enthält alle unter System > Server IP gelistetetn Adressen.

Welche Linux Distribution wird auf dem Server eingesetzt?

Hast Du vielleicht in conf-custom eine eigene Version der Datei als template abgelegt die nicht mit aktuellen Versionen kompatibel ist?

 

[woehrl]

Hallo Till,

vielen Dank für Deine Nachricht. Wir haben den Server nach der folgenden Anleitung 10/2013 neu aufgesetzt:
The Perfect Server - Debian Wheezy (Apache2, BIND, Dovecot, ISPConfig 3) | HowtoForge - Linux Howtos and Tutorials

Keine eigenen Templates, etc. Mir wäre grad nichts bekannt, was ich an der apache-config von Hand gepfriemelt hätte.

Als Fehlerbehebung hab ich lediglich die Haken "NameVirtualHost" bei allen IPs einmal entfernen und wieder setzen müssen. (Hatte zwischendurch auf die Queue-Verarbeitung gewartet)

Viele Grüße,
Florian

 

[Till]

Das ist das setup das auch auf 2 der 3 Kundenserver eingesetzt wird die ich gecheckt habe. Ziegt er denn als aktuelle version 3.0.5.4 an (unter Hilfe)?

 

[woehrl]

Jup, alles ok, in Titel und Hilfe steht 3.0.5.4. Ich häng Dir das Log vom Update mittels ispconfig_update.sh an.

 

[woehrl]

Hallo Till,

beim Update auf 3.0.5.4p4 gabs wieder Ärger mit den Virtual Hosts, nur diesmal fehlten sie nicht, sie waren jetzt offenbar irgendwo doppelt konfiguriert:

[Mon Oct 27 14:37:20 2014] [warn] VirtualHost x.x.x.x:80 overlaps with VirtualHost x.x.x.x:80, the first has precedence, perhaps you need a NameVirtualHost directive
...

Ich musste wieder mal den Haken bei "NameVirtualHost" bei allen IPs einmal entfernen und später wieder setzen. Bis dahin landeten alle Zugriffe bei einem einzigen unserer Kunden. Die anderen waren nicht amused.

Viele Grüße,
Florian