Upgrade ispCP von 1.0.0 RC6 OMEGA auf RC7 - bugfixing

Nachdem ich gestern Abend auf einem meiner Server mit Debian 5.0 Lenny diverse Updates gefahren hatte, rang ich mich dann auch noch dazu durch, das dort verwendete ISP-Interface ispCP upzudaten. Die vorherige Version hatte einige Bugs und bei mir funktionierten das Rootkit-Erkennungstool chkrootkit und der ftp-Server proftpd nicht. Diese Probleme hoffte ich mit dem Update gleich noch bequem miterledigen zu können. Doch es kam wie so oft anders und insgesamt saß ich jetzt über 6h dadran, alles wieder zum Laufen zu bekommen. Im folgenden eine soeben noch mal überarbeitete Doku/Mitschrift dazu:

Nach dem Erstellen eines kompletten Backups arbeitete ich die für ispCP übliche HowTo zum Upgrade ab. Die Domains selbst liefen anschließend und auch ein Login in das Frontend war möglich. Auch das Logfile des chkrootkit ließ sich jetzt anzeigen. Dafür findet ispCP das Log des neuen zusätzlichen Tools rkhunter (rootkithunter) nicht, obwohl es dort liegt, wo es hingehört und auch erwartet wird: /var/log/rkhunter.log. Zusätzlich zu dieser eher unwichtigen Kleinigkeit gab es auch noch unerwartet schwierige neue Probleme. Der proftpd verweigerte weiterhin seinen Dienst und die Konfiguration der einzigen auf dem Server verwendeten Subdomain ging verloren.

proftpd mit ispCP

Um den proftpd wieder zum Laufen zu bekommen, geht man der Fehlermeldung (Fatal: unknown configuration directive ‘SQLAuthTypes’ on line 164 of ‘/etc/proftpd/proftpd.conf’) entsprechend in die Datei /etc/proftpd/proftpd.conf und entfernt die Auskommentierung vom SQLBackend direkt über der fehlerhaft gemeldeten Zeile, da die verwendete proftpd-Variante unter Debian Lenny inzw. bei v1.3.1 angekommen ist. Da ein erneuter Startversuch wieder nicht klappt, hilft ein Blick in den oberen Bereich der conf-Datei. Dort muss die Direktive Include /etc/proftpd/modules.conf verfügbar gemacht werden und in der entsprechenden Datei /etc/proftpd/modules.conf muss das Kommentarzeichen aus den Zeilen LoadModule mod_sql.c und LoadModule mod_sql_mysql.c entfernt werden. Bei einem anschließenden Restart des proftpd wird die Fehlermeldung Fatal: Include: error including ‘/etc/proftpd/ispcp/*’: Das Argument ist ungültig on line 214 of ‘/etc/proftpd/proftpd.conf’ ausgegeben. Da das ispcp-Unterverzeichnis nicht (mehr?) existiert und vermutlich lediglich ein Relikt aus älteren Versionen ist, genügt es, diese Zeile zu entfernen. Damit läuft der proftpd so wie gewünscht.

Bug bei Subdomains in ispCP 1.0.0 RC7 beseitigen

Bei einem Vergleich der relevanten Datei /etc/apache2/sites-available/ispcp.conf mit einer Backup-Version von vor dem Upgrade fällt sofort auf, dass in der neuen Version die Konfiguration der Subdomain fehlt. In der ispCP-GUI wird die in der DB gespeicherte Subdomain jedoch weiterhin angezeigt. Da in der conf-Datei jedoch auch andere Änderungen bzw. Aktualisierungen vorgenommen wurden, empfiehlt es sich, die Subdomain via Frontend zu löschen und anschließend neu anzulegen. Falls man noch kein Backup hat, erstellt man sich dieses mittels:
# cp -R /var/www/virtual/meinedomain.de/meinesub/ /var/www/virtual/meinedomain.de/meinesub2/
Der Versuch, die Subdomain im Frontend zu löschen schlug anschließend fehl. Um nicht alle notwendigen Stellen im Dateisystem und in der DB suchen zu müssen, die auf diese Subdomain verweisen, entschied ich mich, doch die fehlenden Zeilen aus der alten Version der Datei in die neue zu kopieren. Hierzu müssen alle Zeilen von
# httpd [meinesub.meinedomain.de] sub entry BEGIN.
bis
# httpd [meinesub.meinedomain.de] sub entry END.
kopiert werden und zwar vor die leere Subdomain-Definition
# httpd [{SUB_NAME}] sub entry BEGIN.
# httpd [{SUB_NAME}] sub entry END.

und somit auch vor die eigentliche Domain-Definition (dmn entry). Auch damit lief nichts und bei einem genaueren Vergleich der alten conf mit der neuen fielen diverse Unterschiede in den Definitionen auch innerhalb der (Sub-)Domains auf, weshalb ich mich dafür entschied, doch wieder die Zeilen zu entfernen und alle anderen Hinweise auf die Subdomain zu suchen und zu löschen. Beim Versuch, mich in phpMyAdmin einzuloggen, scheiterte ich daran, dass mein admin-Passwort nicht mehr funktionierte. Ein Blick in den MySQL-Server via
# mysql -u root -p
mysql> SELECT USER();

ergab, dass außer dem root-User keine weiteren User vorhanden sind - da muss also auch etwas verloren gegangen sein. Um einen neuen admin-User anzulegen, verwendet man z.B. einen der folgenden Befehle:
mysql> GRANT ALL PRIVILEGES ON *.* TO admin@localhost IDENTIFIED BY 'meinPsw' WITH GRANT OPTION;
mysql> CREATE USER admin@localhost IDENTIFIED BY PASSWORD 'meinPsw' ;

In beiden Fällen bekam ich als Ergebnis Query OK, 0 rows affected - also wurde der User - warum auch immer - nicht hinzugefügt. An der Stelle probierte ich noch ewig weiter, bekam es aber nicht hin. Mittels der Befehlszeilen
mysql> USE ispcp;
mysql> SELECT * FROM subdomain;

erhielt ich dann wenigstens schon mal eine genaue Beschreibung des Problems. Im Feld subdomain_status stand für die Subdomain folgender Eintrag drin:
store_file() | ERROR: Can't open file |/etc/proftpd/ispcp/meinesub.meinedomain.de.conf| for writing: Datei oder Verzeichnis nicht gefunden
Das ist auch kein Wunder, denn seit dem RC7 liegt diese Datei unter /etc/ispcp/proftpd/working/meinesub.meinedomain.de.conf und kann somit an der alten Stelle nicht gefunden werden. Legt man als Test eine weitere Subdomain an, so bekommt man für diese eine entsprechende Fehlermeldung. Offensichtlich ist also das ispCP-Script zum Anlegen von Subdomains im RC7 bugy. Theoretisch könnte man bei funktionierendem Script Probleme beheben, indem man die Tabellen-Spalte status auf change setzt und während dem vorübergehendem Anhalten des ispcp-daemon die Datei /var/www/ispcp/engine/ispcp-rqst-mngr ausführt (lt. ispCP-HowTo). Da dies in diesem Fall jedoch allein nicht weiterhelfen würde, bin ich noch auf folgenden WorkAround gekommen:
# ln -s -n -d /etc/ispcp/proftpd/working/ /etc/proftpd/ispcp
Nachdem der Link erstellt wurde, sind folgende Befehle abzusetzen:
# /etc/init.d/ispcp-deamon stop
# mysql -u root -p
mysql> UPDATE `subdomain` SET `subdomain_status` = 'change' WHERE 1;
mysql> quit;
# /var/www/ispcp/engine/ispcp-rqst-mngr
# /etc/init.d/ispcp-deamon start

Nachdem so ein Regenerate-Request ausgelöst wurde, steht im Status-Feld der Subdomain auch das gewünschte ok. Beim Testen mit einer weiteren Subdomain trat dann beim Löschen ein erneuter Fehler auf: scheinbar wird fälschlicher Weise 2x versucht, die Datei zu löschen, der 2. Versuch klappt nicht mehr und dafür erhält man wieder einen Fehler in der DB, den man dort direkt löschen muss. Aber immerhin funktionieren die Subdomains erstmal wieder und die Probleme dieser Version werden dann hoffentlich bald mit der finalen Version behoben.

Bleibt für mich nur noch die Frage, wie ich jetzt wieder an meinen phpMyAdmin-Zugang herankomme. Auch wenn ich den extrem selten brauche, so wäre es doch schon sehr angenehm, diesen wieder zur Verfügung zu haben.

6 Reaktionen zu “Upgrade ispCP von 1.0.0 RC6 OMEGA auf RC7 - bugfixing”

  1. admin

    Ach ja: da das Löschen der Subdomains nicht klappt, muss man auch die Unterverzeichnisse innerhalb der Domain (/var/www/virtual/…) manuell löschen.

  2. admin

    Ich habe mich noch mal schlau gemacht, was mein Login-Problem bei phpMyAdmin angeht. ispCP legt zwar einige Accs während der Installation an, diese sind jedoch nicht zum Login gedacht. Der pma-User dient einzig und allein internen phpMyAdmin-Anzeigen und der ispCP-ftp-SQL-Acc ist der echte Systemnutzer, über den der proftpd die virtuellen ispCP-User ins Dateisystem lässt. Der von mir vermisste admin-User hingegen scheint nie angelegt worden zu sein. Statt dessen meldet man sich bei einer ispCP-Installation mit dem MySQL-root am phpMyAdmin an. Dies jedoch klappt bei mir nicht. Woran dies liegt und wie ich das hinbekomme, darum werde ich mich ein ander mal kümmern …

    Der Fehler bei den Subdomains besteht übrigens nicht bei RC7-Neuinstallationen. Scheinbar liegt der Fehler nur irgendwo im Updatescript, welches wo auch immer den Pfad nicht richtig anpasst.

    Leider scheint im RC7 auch weiterhin das altbekannte Problem mit den 500er Fehlern bei ispCP zu bestehen. Zwar sind die Fehler selten, aber eben immer noch zu sehen - ich hatte gerade eben nämlich grad wieder einen davon.

  3. admin

    Wie schon weiter oben erwähnt, hat ispCP gerne mal Schwierigkeiten mit den log-Files der beiden Rootkit-Erkennungstools. Diese waren wohl auch beide schon in früheren ispCP-RC-Versionen ausgewertet worden, klappten bei mir aber wenn dann immer nur vorübergehend.

    Anpassungen für rkhunter und chkrootkit

    Der Grund ist schnell gefunden: die icpCP-GUI hat keine Zugriffsrechte auf die Logfiles, da diese (scheinbar nicht immer?) nur mit den Dateirechten 600 angelegt werden. Aktualisiert werden die Logs alle 12h durch zwei entsprechende Aufrufe in der Datei /etc/cron.d/ispcp - dort eingetragene cron-Jobs werden nicht per crontab -l ausgegeben. Da man auf diese Weise die Dateirechte der Logs schlecht ändern kann, liegt eine andere Lösung auf der Hand: die Auslagerung des Aufrufs inklusive der Änderung der Dateirechte in einer separaten Datei. Hierzu legte ich mit den Zugriffsrechten 700 die Datei /root/rk_tools.sh an:
    #!/bin/bash
    /usr/bin/rkhunter --cronjob --createlogfile /var/log/rkhunter.log >/dev/null 2>&1
    /usr/sbin/chkrootkit &> /var/log/chkrootkit.log
    chmod +r /var/log/chkrootkit.org
    chmod +r /var/log/rkhunter.log

    In der Datei /etc/cron.d/ispcp löscht man einen der Rootkit-Tool-Einträge und ändert den anderen auf die Datei /root/rk_tools.sh. Von jetzt an funktioniert auch die Logfileanzeige innerhalb von ispCP.

  4. admin

    Das Problem mit der nicht möglichen Anmeldung an phpMyAdmin hat sich inzwischen von allein gelöst. Nach einem Update von MySQL war es wohl der Neustart des mysqld, der weitergeholfen hatte. Merkwürdig daran ist, dass während der Installation mysqld bereits neu gestartet wurde und dies eigentlich auch nicht für derart einfache Dinge nötig sein sollte.

    Leider funktioniert awstats noch immer nicht, wie mir erst später auffiel. Hintergrund ist, dass im RC7 einiges geändert wurde und in der Version vom 12.12.2008 noch einige Fehler existierten - vor allem für Updates von älteren Versionen. In den aktuellsten Daily Snapshots soll awstats vernünftig nutzbar sein. Die Anmeldung erfolgt für per ispCP zugelassenen Usern und mit Anmeldedaten aus der MySQL-DB. In der von mir installierten Version fehlen in der ispCP-GUI noch die notwendigen Menüs für die awstats-User. Das muss dann wohl ein späteres Update beheben.

  5. Internetagentur

    Hmmm … ich selber habe keine Probleme damit auch nicht mit den Logfiles. Ich benutze ISPCP gerade erst zum ersten mal und finde es sogar jetzt schon besser als Confixx oder Plesk.

  6. admin

    Wenn Du es zum ersten mal benutzt, hast Du sicherlich bisher auch kein Update gemacht. Bei den Updates geht oft was schief - die Scripte dafür sind leider noch im alpha-Stadium. Ansonsten ist icpCP eine super-Software, die mit Sicherheit in 1-2 Jahren auch komplexe Aufgaben beherrschen wird, die bisher nur von den richtig teuren ISP-Lösungen geboten werden.

Einen Kommentar schreiben