• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

VHCS nach upgrade auf lenny - wie debugge ich?

kleinerdrache

New Member
Hallo!

Ich habe vhcs schon einige Zeit im Einsatz, habe einen Server aber jetzt auf lenny upgegradet (apt-get dist-upgrade) und jetzt haben ein paar scripte probleme. Das Problem wurde bekannt weil 'Domain wird angelegt' bzw. 'Subdomain wird angelegt' nicht mehr verschwindet. Meine Diagnosen bisher:

In der Datenbank sind die Domains und Subdomains auf Status 'toadd' und ändern sich nicht. ein vhcs2-rqst-mngr lauf (nach stoppen des daemons) schießt die CPU auf 100% usage, so dass der server fast nicht mehr zu benutzen ist, (http requests, bzw. neue ssh logins sind dann nur schwer möglich), ich kann aber sofern ich bereits vorher ein zweites ssh offen habe in top nachsehen und erkennen dass die scripten vhcs2-dmn-mngr und vhcs2-sub-mngr dieses Problem verursachen, wobei ich aber nicht in der Lage bin herauszufinden wie. (Vermutlich eine Loop in der die Scripten hängen bleiben.)

Hat jemand eine Idee wie ich nun weiter vorgehen kann um dieses Problem zu lösen?

Danke,
Martin
 
Wäre schön

Ja, ich habe das gesehen und auch schon mal runter geladen, allerdings sehe ich da ein Problem: In der Anleitung zu VHCS -> ispCP wird zuerst mal gestestet ob die aktuelle Installation auch ordnungsgemäß ist, mittels Status der Domains auf 'change' zu setzen, dann vhcs2-rqst-mngr starten und sehen obs klappt. Und da hab ich hier mein Problem. :(

Ansonsten hätte ich das schon erledigt.

Denkst du ich sollte das einfach mal ignorieren und dennoch auf ispCP umsteigen, oder handle ich mir da jetzt Probleme ein, die ich vorher noch lösen sollte?

lg,
Martin
 
Ich wäre mit Upgrades jetzt erstmal vorsichtig, net dass es beim Upgrade noch mehr zerschießt. Ich würde vorher erst wieder alles zum Laufen bringen und dann nen Backup machen und anschließend Upgraden.
Centy hat neulich schonmal nen Upgrade von VHCS auf Lenny gemacht, soweit ich das noch in Erinnerung, vielleicht gibts da ja nützliche Tipps. ;)
 
Zeigt dir der Systemdebugger keine Fehlermeldungen an wenn du als Hauptadmin nach siehst?

Ansonsten schalt doch mal in der vhcs2-lib.php den Debugging Modus an dann legt VHCS brav gescheite Logdateien an die einem weiter helfen.
 
Nein, leider zeit der Debugger keine Fehler an. Das debug in vhcs-lib.php (vhcs2-lib.php finde ich hier nicht (version VHCS® Pro v2.4.7.1) gesetzt hilft nicht, aber das habe ich vermutet, denn die Scripten die da hängen sind auch in Perl nicht in PHP geschrieben.

lg,
Martin
 
Geht da noch mehr?

Also damit bekomme ich guten Output, aber noch immer etwas unspezifisch:
Code:
debian31m:/var/www/vhcs2/engine# ./vhcs2-rqst-mngr 
DEBUG: push_el() sub_name: get_conf(), msg: Starting...
DEBUG: push_el() sub_name: get_file(), msg: Starting...
DEBUG: push_el() sub_name: get_file(), msg: Ending...
DEBUG: push_el() sub_name: setup_main_vars(), msg: Starting...
DEBUG: push_el() sub_name: decrypt_db_password(), msg: Starting...
DEBUG: push_el() sub_name: decrypt_db_password(), msg: Ending...
DEBUG: push_el() sub_name: setup_main_vars(), msg: Ending...
DEBUG: push_el() sub_name: get_conf(), msg: Ending...
DEBUG: push_el() sub_name: mngr_start_up(), msg: Starting...
DEBUG: push_el() sub_name: lock_system(), msg: Starting...
DEBUG: push_el() sub_name: sys_command(), msg: Starting...
DEBUG: push_el() sub_name: sys_command('/bin/touch /tmp/vhcs2.lock'), msg: Ending...
DEBUG: push_el() sub_name: lock_system(), msg: Ending...
DEBUG: push_el() sub_name: del_file(), msg: Starting...
DEBUG: push_el() sub_name: del_file(), msg: Ending...
DEBUG: push_el() sub_name: get_conf(), msg: Starting...
DEBUG: push_el() sub_name: get_file(), msg: Starting...
DEBUG: push_el() sub_name: get_file(), msg: Ending...
DEBUG: push_el() sub_name: setup_main_vars(), msg: Starting...
DEBUG: push_el() sub_name: decrypt_db_password(), msg: Starting...
DEBUG: push_el() sub_name: decrypt_db_password(), msg: Ending...
DEBUG: push_el() sub_name: setup_main_vars(), msg: Ending...
DEBUG: push_el() sub_name: get_conf(), msg: Ending...
DEBUG: push_el() sub_name: doSQL(), msg: Starting...
DEBUG: push_el() sub_name: doSQL(), msg: Ending...
DEBUG: push_el() sub_name: mngr_start_up(), msg: Ending...
DEBUG: push_el() sub_name: mngr_engine(), msg: Starting...
DEBUG: push_el() sub_name: doSQL(), msg: Starting...
DEBUG: push_el() sub_name: doSQL(), msg: Ending...
DEBUG: push_el() sub_name: doSQL(), msg: Starting...
DEBUG: push_el() sub_name: doSQL(), msg: Ending...
DEBUG: push_el() sub_name: mngr_engine(), msg: processing 21, salzburg, toadd.
DEBUG: push_el() sub_name: sys_command(), msg: Starting...
hier drücke ich Strg+C nach etwa einer Minute, dann gehts weiter:
Code:
DEBUG: push_el() sub_name: sys_command('/var/www/vhcs2/engine/vhcs2-sub-mngr 21 1>/var/log/vhcs2/vhcs2-sub-mngr.stdout 2>/var/log/vhcs2/vhcs2-sub-mngr.stderr'), msg: Ending...
(die stdout datei ist leer.) Der rest scheint nicht mehr relevant zu sein....

Irgendwelche Ideen?

lg,
Martin
 
Last edited by a moderator:
Wenn ich die Files lese bevor ich Strg+C drücke ist da tatsächlich nützlicher output drin, so wie mir scheint:

---einiges vorher---
Code:
DEBUG: push_el() sub_name: get_tag(), msg: Starting...
DEBUG: push_el() sub_name: get_tag(), msg: ERROR: '{DMN_NAME}' eq '{DMN_NAME}', missing '{DMN_NAME}' in src !
DEBUG: push_el() sub_name: repl_var(), msg: Ending...
DEBUG: push_el() sub_name: repl_var(), msg: Starting...
DEBUG: push_el() sub_name: repl_tag(), msg: Starting...
DEBUG: push_el() sub_name: get_tag(), msg: Starting...
DEBUG: push_el() sub_name: get_tag(), msg: ERROR: '{DMN_IP}' eq '{DMN_IP}', missing '{DMN_IP}' in src !
DEBUG: push_el() sub_name: repl_var(), msg: Ending...
DEBUG: push_el() sub_name: repl_var(), msg: Starting...
DEBUG: push_el() sub_name: repl_tag(), msg: Starting...
DEBUG: push_el() sub_name: get_tag(), msg: Starting...
DEBUG: push_el() sub_name: get_tag(), msg: Ending...
DEBUG: push_el() sub_name: repl_tag(), msg: Ending...
DEBUG: push_el() sub_name: repl_tag(), msg: Starting...
DEBUG: push_el() sub_name: get_tag(), msg: Starting...
DEBUG: push_el() sub_name: get_tag(), msg: ERROR: '{SUB_NAME}' eq '{SUB_NAME}', missing '{SUB_NAME}' in src !
DEBUG: push_el() sub_name: repl_var(), msg: Ending...
DEBUG: push_el() sub_name: repl_var(), msg: Starting...
DEBUG: push_el() sub_name: repl_tag(), msg: Starting...
---einiges nachher---

Diese Meldungen wiederholen sich ständig, daher also die hohe CPU last. :(

Doch wie behebt man das?

lg,
Martin
 
Last edited by a moderator:
Da stimmen wohl die Templates nicht mehr. Oder es hat deine Mysql Datenbank zerlegt denn da kommen werden keine Variablen mehr übergeben. Schau mal nach ob in den Datenbanken die neuen Domains angelegt werden.
 
Wie meinst du das mit der Datenbank? Auch Domains werden nicht angelegt, der Eintrag in die Datenbank also die Domain mit status 'toadd' funktioniert. Die letzte hat auch aus irgend einem grund nach langem laufen auch einträge in die vhcs.conf (apache2 virtualhost geschichte) gemacht, die waren korrekt. Allerdings musste ich die unterverzeichnisse selber anlegen nur /var/www/virtual/neuedomain.com wurde (mit falschen rechten) erzeugt. Ich habe das dann händisch gemacht und auf ok gesetzt, allerdings scheint das nicht zufriedenstellend zu funktionieren.

Soll ich die Templates durch schauen? Worauf muss ich da achten?

lg,
Martin
 
Nur so mal zum Verständnis...

Du hast ein Upgrade auf Debian Lenny gemacht, soweit klar. Von Welcher Version denn? Debian Etch, Sarge, oder was?

Ich frage nur, weil mal abgesehen von der Änderung in der Datei /etc/apt/sources-list ggf. eine Deinstallation und Neuinstallation des ein oder anderen Paketes und der abhängigen Paketen notwendig sein könnte, weil dies evt. vom Paketmanager leider nicht so aufgelöst wird, wie man es sich vorgestellt hat. So z.B. beim gleichzeitigen Umstieg von PHP4 auf PHP5 und MYSQL4 auf MYSQL5.

Es könnte aber auch eine der anderen notwendigen Libs sein. Bei Etch auf Lenny wäre mal ein Vergleich der Pakete sinnvoll:

VHCS auf Etch benötigt z.B. folgende Pakete:
Code:
ssh
postfix
proftpd-mysql
courier-authdaemon
courier-base
courier-imap-ssl
courier-imap
courier-maildrop
courier-pop
courier-pop-ssl
libberkeleydb-perl
libcrypt-blowfish-perl
libcrypt-cbc-perl
libcrypt-passwdmd5-perl
libdate-calc-perl
libdate-manip-perl
libdbd-mysql-perl
libdbi-perl
libio-stringy-perl
libmail-sendmail-perl
libmailtools-perl
libmd5-perl
libmime-perl
libnet-dns-perl
libnet-netmask-perl
libnet-smtp-server-perl
libperl5.8
libsnmp-session-perl
libterm-readkey-perl
libtimedate-perl
perl
perl-base
perl-modules
bind9
diff
gzip
iptables
libmcrypt4
mysql-client-5.0
mysql-common
mysql-server-5.0
patch
php5
php5-mcrypt
php5-mysql
php-pear
procmail
tar
original-awk
libterm-readpassword-perl
libsasl2-modules
libsasl2
sasl2-bin
apache2
apache2.2-common
apache2-mpm-prefork
libapache2-mod-php5
bzip2
php5-gd
g++
make
Vergleiche dies mal mit den verfügbaren Paketen von Debian Lenny. Vielleicht fehlt eines oder man muss ein alternatives Paket verwenden.

VHCS kann über solche Probleme stolpern, d.h. der apache macht zwar seinen Job, jedoch fällt die VHCS-Engine offensichtlich auf die Nase.

Die letzten Meldungen deuten wie Centy schon schrieb auf ein Problem mit den Templates bzw. der Datenbank-Einträge für den bind hin. Überprüfe den Pfad /etc/vhcs/bind/
Hier gibt es ein Verzeichnis working
Neben den jeweiligen *.db Einträge für die domains gibt es die named.conf aus denen die conf für den bind jeweils generiert werden. Check mal die Dateien durch, ob diese die erforderliche Tag-Paarung (jeweils BEGIN und END) haben oder gar leer (bei neuen domains) sind.

Geh mal mit
Code:
mysql -p
in mysql und arbeite mit vhcs2
Code:
use vhcs2;
Dann lass Dir die Inhalte einiger Datenbank anzeigen:
Code:
select * from domain;
select * from sudomain;
select * from domain_aliasses;
Sind alle angelegten Domains auch enthalten?

Last but not least, schau mal die Dateien im Unterverzeichnis backup an. Von welchem Datum sind diese denn? ggfs. könnte man diese nutzen, um VHCS wieder auf die Beine zu helfen.
 
Last edited by a moderator:
Ja, ursprünglich wars glaub ich ein sarge, hatte in der sources-list mal 'stable' drinnen, jetzt 'lenny'.

Die Pakete die ich habe habe ich jetzt lt. deiner Liste abgearbeitet, da wurden nur ssl pakete nachinstalliert, der Rest war ok, mit der Ausnahme, dass teilweise neuere Pakete (perl5.10 anstatt 5.8) installiert sind.

Den Meldungen zu den Templates bin ich nachgegangen, fand eine leere datei in /etc/vhcs/bind/working, welche ich entfernen konnte, was das problem aber nicht behob. (Die datei scheint ein relikt zu sein, die domain war längst entfernt und kommt auch in named.conf nicht vor.

Die .db files und die named.conf datei scheinen alle gut auszusehen, mir fehlt hier nichts, die BEGIN und END sind da, soweit ich das sehen kann.

Die Tabellen in der Datenbank: Alle mit Status 'ok' sind vorhanden. Eine domain habe ich auf 'change' und eine andere auf 'toadd' gesetzt. vhcs2-rqst-manager will die 'change' domain zuerst bearbeiten, dann die subdomains und dann die neue domain. Alles scheint fehl zu schlagen. Die 'change' domain scheint aber bei bind/working ordentlich erstellt worden zu sein, sieht aus wie alle anderen domains und ist in named.conf includiert.

Auch umgekehrt, scheint alles zu stimmen, also keine Datei in working die nicht in der DB vorkommt (ausgenommen 'toadd') (Subdomains nur überflogen.)

Das backup selber scheint nicht ungewöhnlich zu sein, scheint zu stimmen.

Was mich aber noch stutzig macht, auch der Datei /var/log/vhcs2/vhcs2-dmn-mngr.stderr:
Code:
Name "main::db" used only once: possible typo at /var/www/vhcs2/engine/vhcs2-dmn-mngr line 779.

Dies kommt vom subdomain script nicht.

Und dann scheint noch jemand einen alias zu erzeugt haben, der mit www. beginnt, also 'www.domainname.com' anstatt 'domainname.com', wodurch jetzt auch eine www.domainname.com.db datei in /etc/vhcs2/bind/working entstanden ist, allen anderen dateien fehlt das www. -> allerdings ist die auch richtig in named.conf eingefügt, sollte also für das vhcs script keine bedeutung haben.

Helfen uns die gewonnenen Erkenntnisse weiter? Wie kann ich nun weiter vorgehen?

lg,
Martin
 
OK, also ein Upgrade von Sarge auf Lenny.

Nun, wann wurde via VHCS das letzte Mal etwas geändert bzw. hinzugefügt? Ich meine damit, wann das letzte Mal eine Domain, Subdomain oder email-Konto hinzugefügt oder geändert wurde.

Für die Ursachenforschung ist das insofern von Bedeutung, da der vhcs2-rqst-manager eben nur dann aktiv wird. Es wäre also möglich, dass sich ein Problem schon viel früher eingeschlichen hat und nur deshalb jetzt auffällt, weil man nun neben der Umstellung auch noch domains, subdomain, domaialiases, emailkonten, etc. hinzufügt oder ändert.

Hier läge das Problem nicht in der Umstellung, sondern an VHCS2 an sich. Prüfe das mal bitte. Was die Datenbank anbetrifft, so gibt es einige Macken, die zum Versagen von VHCS2 führen können. So z.B, das "Quota", sofern man das überhaupt so bezeichnen darf.
Code:
select * from quotalimits;
select * from server_traffic;
Sofern Du über eine Sicherung der Datenbank verfügst, kannst Du ja mal hier die Einträge löschen.
das ganze geht mit phpmyadmin vieleicht etwas komfortabler.
 
Also ich habe die Zeiten des Updates leider nicht mehr im Kopf und kriege daher schwer raus, ob das Problem mit dem upgrade zusammenhängt oder nicht. Aber rein vom Gefühl her würde ich sagen, dass es unabhängig ist.

Ich habe probiert:

Code:
delete from quotalimits;
delete from server_traffic;

und dann ein neues vhcs2-rqst-mngr, aber das Problem hat sich dadurch leider nicht verändert.

Vom Log her deutet das sehr auf probleme mit bind zusammen, da ich bind gar nicht brauche habe ich auch zwischendurch ausprobiert, dns von vhcs weg zu schalten, (FAQ) aber das hatte auch keinen Erfolg gebracht.

Was kann ich sonst noch ausprobieren?

lg,
Martin
 
Nun, es liegt nicht am bind selbst, sondern nach den logs ganz klar an vhcs bzw. dessen Generierung der Konfigurationsdateien: Nachfolgend mal der Aufbau im Verzeichnis /etc/vhcs2/bind/working am Beispiel example.com und IP 192.168.0.1:
Die Datei named.conf:
Code:
// bind Data BEGIN.

// dmn [example.com] cfg entry BEGIN.
zone "example.com" { 
	type master; 
	file "/var/cache/bind/example.com.db"; 
};
// dmn [example.com] cfg entry END.

// dmn [{DMN_NAME}] cfg entry BEGIN.
// dmn [{DMN_NAME}] cfg entry END.

// bind Data END.
Dann noch die domain mit der subdomain filepile in example.com.db:
Code:
$TTL 86400
@	IN	SOA	ns.example.com. root.example.com. (
; dmn [example.com] timestamp entry BEGIN.
			 1193133205	
; dmn [example.com] timestamp entry END.
			 8H	
			 2H	
			 4W	
			 1D )	
		 IN 	 NS 	 ns.example.com.
		 IN 	 MX 	 10 mail.example.com.
                 
example.com.	A	192.168.0.1
ns		IN	A	192.168.0.1
mail		IN	A	192.168.0.1
www		CNAME	example.com.
ftp		CNAME	example.com.
; sub [filepile.example.com] entry BEGIN.
filepile.example.com.		 IN	A	192.168.0.1
www.filepile.example.com.		 IN	A	192.168.0.1
ftp.filepile.example.com.		 IN	A	192.168.0.1
; sub [filepile.example.com] entry END.

; sub [{SUB_NAME}] entry BEGIN.
; sub [{SUB_NAME}] entry END.

Entscheidend sind hier weniger die Einträge für sich, als vielmehr die Kommentarzeilen, die von VHCS genutzt werden.

Auch ist wichtig die Einträge in der Datenbank, hier Tabellen domain und domain_aliasses dahin gehend zu vergleichen, ob für alle hier hinterlegten Einträge auch Konfigurationsdateien bzw. Einträge bestehen. Es mag hier ein oder mehrere Datenbankeinträge drin sein, für den es keine Entsprechung in den generierten Konfigurationsdateien gibt. Es kann also sein, dass einer dieser Einträge das Problem bei der Generierung verursacht. So sind die Dateien in working zwar alle OK, aber die Generierung neuer schlägt fehl. Wenn Du Sicherungen hast, kannst ja hier selektiv den ein oder anderen möglichen Eintrag mal löschen.

Eine andere Sache ist ein defektes template:

Sollten ggfs. die templates beschädigt sein, so lade vhcs2 hier (Datei vhcs2-2.4.7.1.tar.bz2) runter und entnehme aus configs/bind/parts die Templates für bind bzw. vergleiche diese mit denen (/etc/vhcs2/bind/working) auf Deinem Server.
 
Ich habe die Templates, bzw. alle files unter /etc/vhcs2/bind/working und /etc/vhcs2/bind/parts genau angesehen, und kann hier keine Fehler entdecken. Habe wirklich sehr gut recherchiert und genau geschaut, mit datenbank verglichen etc. und kann hier den fehler nicht finden. Seltsam das ganze. Was könnte ich noch probieren?

lg,
Martin
 
VHCS2 Datenbank exportieren, Server plätten, VHCS neuinstallieren, Datenbank einspielen alles auf Change und neu machen.
 
Ok, ich glaube da bleibt keine andere Lösung. Allerdings hab ich den Jargon von 'plätten' nicht verstanden. Hoffentlich heißt das nicht neu aufsetzen oder so, das ist schon ein stabiles system bis auf den fehler.

lg,
Martin
 
Ja komplett neu aufsetzen. Anders bekommst du das VHCS nicht mehr richtig bereinigt. Evtl. solltest du das vorher mal in ner VM testen ob es richtig funktionieren würde mit einem DB Dump nicht dass die DB selber auch kaputt ist.
 
Back
Top