# ISPConfig erstellt fehlerhafte .vhost mit Nicht-DE-Domain



## speedy8 (22. Okt. 2016)

Hallo,

nachdem ich dieses Posting erst fehlerhaft im Englischen Forum erstellt hatte hier noch einmal der 2. Versuch.

Ich habe hier ein kleines Problem. Und zwar hatte ich bislang eine example.net - Domain als Alias-Domain laufen. Die wurde bislang auch korrekt weitergeleitet auf eine bestehende andere Domain.
Heute wollte ich nun für diese "example.net" - Domain eine eigene Webseite anlegen.

Zunächst habe ich die alte Alias-Domain gelöscht und eine eigenständige Domain namens "example.net" erstellt.

Durch ISPConfig3.1 (auf einem Debian 7)  wurde korrekt ein Verzeichnis

/var/www/clients/client1/web95

mit allen dazugehörigen Unterordnern angelegt.

Wenn ich die Domain aufrufe, erscheint jedoch nicht die Default-Seite für durch ISPConfig angelegte Seiten, sondern eine Apache-Standard-Seite. Das hat mich gewundert, so dass ich unter
/etc/apache2/sites-available
nachgeschaut habe, was der ISPConfig dort angelegt hat. Bei Durchsicht der bisherigen Domain, auf die die Alias weitergeleitet hat, wurden die Einträge der Alias-Domain korrekt entfernt. Aber für die neue Domain befinden sich jetzt 2 Dateien im Verzeichnis, nämlich
1.:    example.net.vhost
und
2.:    example.net.vhost.err

In der ersteren Datei befindet sich so gut wie kein Inhalt, bis auf

```
# Apache did not start after modifying this vhost file.
# Please check file /etc/apache2/sites-available/example.net.vhost.err for syntax errors.
```
In der zweiten Datei ist dann der korrekte Inhalt einer vhost-Datei enthalten.

Was mache ich hier falsch? Sollte ich den Inhalt der 2. Datei in die erste Datei kopieren?

Ok, das habe ich nach Anraten von Till einmal gemacht ... und ... ein Restart von Apache bringt mir die Meldung


```
apache2: bad user name web95
Action 'configtest' failed.
The Apache error log may have more information.
failed!
```
Das scheint mit meiner weiteren Feststellung zu korrespondieren, dass mir nämlich aufgefallen ist, dass durch ISPConfig die Datei-Rechte bzw. Benutzer-Rechte nicht mehr wie bisher vergeben werden. Bislang war es so, dass die Dateien im Webseiten-Verzeichnis dem Benutzer=webXY und der Gruppe=clientXY gehörten. In meinem Beispiel müssten die Dateien web95:client1 gehören ... tun sie aber nicht!
Die bei der oben benannten Seite erstellten Ordner gehören root:client[XY].
Warum wurde das geändert? Oder ist das nur eine Fehlfunktion?

Und wie kann ich mich hier weitere an die Lösung heranarbeiten?
Vielen Dank für hilfreiche Tip(p)s.
Mfg
Alexander


----------



## Till (24. Okt. 2016)

Das Problem ist hier adss der User nicht angelegt werden konnt. chau doch mal ob es die Gruppe "sshusers" in /etc/group gibt. Wenn nicht, lege sie an.


----------



## speedy8 (24. Okt. 2016)

Hallo,
nein, das kann nicht das Problem sein. Denn in der /etc/group gibt es folgenden Eintrag:

```
sshusers:x:5002:
```
ein Hinzufügen mittels

```
addgroup –system sshusers
```
war insoweit nicht möglich. Was kann ich denn als weiteres testen?

MfG


----------



## Till (25. Okt. 2016)

Benutz den Debugmode und lege damit eine neue website an und schau Dir dabei an warum er keinen user auf deinem system anlegen kann.


----------



## speedy8 (25. Okt. 2016)

Hallo,

habe im DEBUG-Mode gerade einmal eine neue Webseite angelegt. Hier nun der Output im /var/log/ispconfig/ispconfig.log


```
25.10.2016-22:59 - DEBUG - Found 1 changes, starting update process.
25.10.2016-22:59 - DEBUG - Calling function 'ssl' from plugin 'apache2_plugin' raised by event 'web_domain_insert'.
25.10.2016-22:59 - DEBUG - Calling function 'insert' from plugin 'apache2_plugin' raised by event 'web_domain_insert'.
25.10.2016-22:59 - DEBUG - Adding the user: web96
25.10.2016-22:59 - DEBUG - chown failed: /var/www/clients/client1/web96/private : web96
25.10.2016-22:59 - DEBUG - Creating symlink: ln -s /var/www/clients/client1/web96/ /var/www/testdomain.de
25.10.2016-22:59 - DEBUG - Creating symlink: ln -s /var/www/clients/client1/web96/ /var/www/clients/client1/testdomain.de
25.10.2016-22:59 - DEBUG - exec: chown -R web96:client1 /var/www/clients/client1/web96/web
25.10.2016-22:59 - DEBUG - exec: chown web96:client1 /var/www/clients/client1/web96/web
25.10.2016-22:59 - DEBUG - exec: usermod --groups sshusers web96 2>/dev/null
25.10.2016-22:59 - DEBUG - chown failed: /var/www/clients/client1/web96/cgi-bin : web96
25.10.2016-22:59 - DEBUG - chown failed: /var/www/clients/client1/web96/tmp : web96
25.10.2016-22:59 - DEBUG - chown failed: /var/www/clients/client1/web96/web : web96
25.10.2016-22:59 - DEBUG - chown failed: /var/www/clients/client1/web96/web/error : web96
25.10.2016-22:59 - DEBUG - chown failed: /var/www/clients/client1/web96/web/stats : web96
25.10.2016-22:59 - DEBUG - chown failed: /var/www/clients/client1/web96/webdav : web96
25.10.2016-22:59 - DEBUG - chown failed: /var/www/clients/client1/web96/private : web96
```
Ich kann hier leider nicht erkennen, warum die CHOWN-Kommandos nicht klappen.
Der Nutzer ist nicht als Nutzer im System eingetragen, die client-Gruppe gibt es aber. Somit sind die Verzeichnisse vorliegend mit den Rechten root:client1 versehen.

Oder seht ihr aus dem DEBUG noch mehr als ich?

Viele Grüße


----------



## florian030 (26. Okt. 2016)

chown und useradd sind auf Deinem Server aber schon vorhanden?


----------



## speedy8 (29. Okt. 2016)

ja, natürlich! Über Chown hatte ich im Eingangstext ja schon geschrieben, adduser habe ich eben noch einmal getestet. Ich kann es aber gar nicht genau sagen, ob es auf dem Debian7-Server mit ISPConfig 3.0x schon korrekt funktioniert hat, da ich seither keine neue Domain erstellt hatte. System hatte ich vorher aber anstandslos auf einem Debian6 am Laufen, wo auch korrekt die Datei- und Verzeichnisrechte gesetzt wurden.

Was könnte ich denn nun noch unternehmen? Habe aktuell bereits das ISPConfig 3.1.1 am Start.

Vielen Dank!


----------



## Till (30. Okt. 2016)

Und Du hast für php cli nicht funktionen wie exec oder so in der php.ini deaktviert?


----------



## speedy8 (2. Nov. 2016)

ok, heute habe ich wieder einmal etwas Zeit auf dem Server zu schauen. 

In der /etc/php5/apache2/php.ini sind folgende Sachen ausgeschlossen


```
disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,
```
Aber das meintest Du sicherlich nicht, oder?

In der Datei /etc/php5/cli/php.ini hingegen ist hinter "disable_functions" nichts aufgelistet.

In der Datei /etc/php5/cgi/php.ini sind hingegen wieder alle oben aufgelisteten Dinge ausgeschlossen.
Soll ich die alle rauslöschen? Wäre das nötig? Und wäre das auf der anderen Seite ein Sicherheitsproblem? Denn die Einstellungen scheinen Standardmäßig mit der Neuinstallation von Debian7 mitgekommen zu sein, da ich mir nicht bewußt bin, diese Eintragungen vorgenommen zu haben.

Mfg


----------



## speedy8 (2. Nov. 2016)

so, ich habe eben einmal in den oben benannten 2 Dateien die Zeile "disable_functions" auskommentiert und mit einem "/etc/init.d/apache restart" den Webserver neu gestartet. 
Nach erneutem Anlegen einer neuen Webseite kann ich leider noch immer keine Änderung feststellen! Oder habe ich an der falschen Stelle geschaut?

MFg


----------



## Till (4. Nov. 2016)

Zitat von speedy8:


> /etc/php5/cli/php.ini


Wenn nichts in der php.ini steht dann kann es das von mir angesprochene Problem nicht sein. Den webXX User und die clientXX Gruppe dieses webs gibt es aber in passwd und group Datei? Wenn nicht, dann müssen wir weiter suchen arum der Linux useradd Befehl bei Dir nicht mehr geht.


----------



## speedy8 (4. Nov. 2016)

Hallo,


Zitat von Till:


> ... Den webXX User und die clientXX Gruppe dieses webs gibt es aber in passwd und group Datei? ...


nun, wie im Eingangspost schon geschrieben wurde der User selbst nicht angelegt. Die ClientGruppe gab's ja schon. Aber ich denke, wenn ich jetzt sogar noch einen neuen Kunden erstellen würde, dass auch die neue Gruppe nicht angelegt würde. Handisch kann ich i.Ü. die Befehler "useradd" und "groupadd" aufrufen, natürlich nur su-Rechten.

Hast Du noch eine Idee? Dass ich noch ein Debian7 nutze kann ja nicht das Problem sein.

Mfg


----------



## Till (7. Nov. 2016)

Zitat von speedy8:


> Hast Du noch eine Idee? Dass ich noch ein Debian7 nutze kann ja nicht das Problem sein.


nein. am Debian 7 liegt es nciht. Prüfe mal die group und passd / shadow datei mit den befehlen:

pwck

und

grpck

auf Inkonsistenzen.


----------



## speedy8 (9. Nov. 2016)

Hallo Till,

danke, vielen Dank! Das war die Lösung. Da ist wohl beim Server-Transfer seinerzeit irgendwas in Schieflage gekommen sein, was sich sonst nicht bemerkbar gemacht hat außer halt jetzt beim Neuanlegen von Webseiten.

bei "pwck" hat er mir (nach Anzeige aller nicht existierenden USER) folgende Fehlermeldung ausgegeben

```
invalid password file entry
delete line ''?
```
was ich entsprechend mit "yes" bestätigt habe.

bei "grpck" brachte er die Meldung, dass es einen Duplikat-Eintrag gab und zudem in der Datei /etc/gshadow diverse Einträge fehlten, die er nach Bestätigung mit "yes" automatisch hinzugefügt hat.

Und siehe da, jetzt klappts mit auch mit ISPConfig!

Vielen Dank nochmal für den Tip. Diese Befehle sind mir in meiner Linux-Zeit bislang noch nie über den Weg gelaufen. Man lernt doch immer etwas dazu.

Mfg
Alexander


----------



## saschabe (3. März 2017)

Hi,
ich muss den Thread leider mal auskramen. Ich habe selbiges Problem mit den erstellen neuer Websites.
Hier mal die apache2 error.log

```
[Fri Mar 03 18:18:09.785383 2017] [:error] [pid 21653] python_init: Python version mismatch, expected '2.7.5+', found '2.7.9'.
[Fri Mar 03 18:18:09.785487 2017] [:error] [pid 21653] python_init: Python executable found '/usr/bin/python'.
[Fri Mar 03 18:18:09.785494 2017] [:error] [pid 21653] python_init: Python path being used '/usr/lib/python2.7/:/usr/lib/python2.7/plat-x86_64-linux-gnu:/usr/lib/python2.7/lib-tk:/usr/lib/python2.7/lib-old:/usr/lib/python2.7/lib-dynload$
[Fri Mar 03 18:18:09.785514 2017] [:notice] [pid 21653] mod_python: Creating 8 session mutexes based on 150 max processes and 0 max threads.
[Fri Mar 03 18:18:09.785519 2017] [:notice] [pid 21653] mod_python: using mutex_directory /tmp
[Fri Mar 03 18:18:09.797183 2017] [ssl:warn] [pid 21653] AH01906: server.example.com:8080:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Mar 03 18:18:09.797201 2017] [ssl:warn] [pid 21653] AH01909: server.example.com:8080:0 server certificate does NOT include an ID which matches the server name
[Fri Mar 03 18:18:09.797240 2017] [ssl:error] [pid 21653] AH02217: ssl_stapling_init_cert: can't retrieve issuer certificate! [subject: O=SERVER,L=Berlin,ST=SH,C=DE / issuer: O=SERVER,L=Berlin,ST=SH,C=DE / serial: D7DA924CBFD540FB / notbefore$
[Fri Mar 03 18:18:09.797244 2017] [ssl:error] [pid 21653] AH02567: Unable to configure certificate server.example.com:0 for stapling
[Fri Mar 03 18:18:09.802887 2017] [mpm_prefork:notice] [pid 21653] AH00163: Apache/2.4.10 (Debian) mod_fastcgi/mod_fastcgi-SNAP-0910052141 mod_fcgid/2.3.9 Phusion_Passenger/4.0.53 mod_python/3.3.1 Python/2.7.9 OpenSSL/1.0.2j configured $
[Fri Mar 03 18:18:09.802910 2017] [core:notice] [pid 21653] AH00094: Command line: '/usr/sbin/apache2'
[Fri Mar 03 18:21:40.861069 2017] [fcgid:warn] [pid 21681] [client 84.186.106.23:59694] mod_fcgid: stderr: PHP Warning:  mysqli_connect(): Headers and client library minor version mismatch. Headers:50553 Library:50630 in /usr/local/ispc$
[Fri Mar 03 18:21:40.861127 2017] [fcgid:warn] [pid 21681] [client 84.186.106.23:59694] mod_fcgid: stderr: PHP Warning:  mysqli_connect(): Headers and client library minor version mismatch. Headers:50553 Library:50630 in /usr/local/ispc$
[Fri Mar 03 18:31:56.740755 2017] [mpm_prefork:notice] [pid 21653] AH00171: Graceful restart requested, doing restart
[Fri Mar 03 18:31:56.913879 2017] [auth_digest:notice] [pid 21653] AH01757: generating secret for digest authentication ...
[Fri Mar 03 18:31:56.914876 2017] [:notice] [pid 25824] FastCGI: process manager initialized (pid 25824)
[ 2017-03-03 18:31:56.9216 25826/7f1a22f1b740 agents/Watchdog/Main.cpp:538 ]: Options: { 'analytics_log_user' => 'nobody', 'default_group' => 'nogroup', 'default_python' => 'python', 'default_ruby' => '/usr/bin/ruby', 'default_user' => $
[ 2017-03-03 18:31:56.9277 25829/7f5e308cf740 agents/HelperAgent/Main.cpp:650 ]: PassengerHelperAgent online, listening at unix:/tmp/passenger.1.0.21653/generation-1/request
[ 2017-03-03 18:31:56.9375 25834/7fd75e151780 agents/LoggingAgent/Main.cpp:321 ]: PassengerLoggingAgent online, listening at unix:/tmp/passenger.1.0.21653/generation-1/logging
[ 2017-03-03 18:31:56.9376 25826/7f1a22f1b740 agents/Watchdog/Main.cpp:728 ]: All Phusion Passenger agents started!
[Fri Mar 03 18:31:56.981718 2017] [:error] [pid 21653] python_init: Python version mismatch, expected '2.7.5+', found '2.7.9'.
[Fri Mar 03 18:31:56.981962 2017] [:error] [pid 21653] python_init: Python executable found '/usr/bin/python'.
[Fri Mar 03 18:31:56.981984 2017] [:error] [pid 21653] python_init: Python path being used '/usr/lib/python2.7/:/usr/lib/python2.7/plat-x86_64-linux-gnu:/usr/lib/python2.7/lib-tk:/usr/lib/python2.7/lib-old:/usr/lib/python2.7/lib-dynload$
[Fri Mar 03 18:31:56.982018 2017] [:notice] [pid 21653] mod_python: Creating 8 session mutexes based on 150 max processes and 0 max threads.
```
DEBUG nach Seitenerstellung:

```
03.03.2017-18:41 - DEBUG - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'.
03.03.2017-18:41 - DEBUG - Found 1 changes, starting update process.
03.03.2017-18:41 - DEBUG - Calling function 'ssl' from plugin 'apache2_plugin' raised by event 'web_domain_insert'.
03.03.2017-18:41 - DEBUG - Calling function 'insert' from plugin 'apache2_plugin' raised by event 'web_domain_insert'.
03.03.2017-18:41 - DEBUG - Adding the user: web24
03.03.2017-18:41 - DEBUG - Creating symlink: ln -s /var/www/clients/client0/web24/ /var/www/example.com
03.03.2017-18:41 - DEBUG - Creating symlink: ln -s /var/www/clients/client0/web24/ /var/www/clients/client0/example.com
03.03.2017-18:41 - DEBUG - exec: chown -R web24:client0 /var/www/clients/client0/web24/web
03.03.2017-18:41 - DEBUG - exec: chown web24:client0 /var/www/clients/client0/web24/web
03.03.2017-18:41 - DEBUG - exec: usermod --groups sshusers web24 2>/dev/null
03.03.2017-18:41 - DEBUG - Creating fastcgi starter script directory: /var/www/php-fcgi-scripts/web24/
03.03.2017-18:41 - DEBUG - Creating fastcgi starter script: /var/www/php-fcgi-scripts/web24/.php-fcgi-starter
03.03.2017-18:41 - DEBUG - Writing the vhost file: /etc/apache2/sites-available/example.com.vhost
03.03.2017-18:41 - DEBUG - Creating symlink: /etc/apache2/sites-enabled/100-example.com.vhost->/etc/apache2/sites-available/example.com.vhost
03.03.2017-18:41 - DEBUG - Apache status is: running
03.03.2017-18:41 - DEBUG - Calling function 'restartHttpd' from module 'web_module'.
03.03.2017-18:41 - DEBUG - Restarting httpd: systemctl restart apache2.service
03.03.2017-18:41 - DEBUG - Apache restart return value is: 1
03.03.2017-18:41 - DEBUG - Apache online status after restart is: down
03.03.2017-18:41 - WARNING - Apache did not restart after the configuration change for website example.com. Reverting the configuration. Saved non-working config as /etc/apache2/sites-available/example.com.vhost.err
03.03.2017-18:41 - WARNING - Reason for Apache restart failure: Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xe" for details.
03.03.2017-18:41 - DEBUG - Calling function 'restartHttpd' from module 'web_module'.
03.03.2017-18:41 - DEBUG - Restarting httpd: systemctl restart apache2.service
03.03.2017-18:41 - DEBUG - Processed datalog_id 254
03.03.2017-18:41 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
finished.
PHP Warning:  mysqli_connect(): Headers and client library minor version mismatch. Headers:50553 Library:50630 in /usr/local/ispconfig/server/lib/classes/db_mysql.inc.php on line 79
```
Habe bereits geprüft, ob exec deaktivier ist. Ist es nicht.
Gruppe sshusers ist vorhanden und die web Benutzer werden da auch eingetragen.
Ausgabe pwck:

```
user 'lp': directory '/var/spool/lpd' does not exist
user 'news': directory '/var/spool/news' does not exist
user 'uucp': directory '/var/spool/uucp' does not exist
user 'list': directory '/var/list' does not exist
user 'irc': directory '/var/run/ircd' does not exist
user 'gnats': directory '/var/lib/gnats' does not exist
user 'nobody': directory '/nonexistent' does not exist
user 'systemd-resolve': directory '/run/systemd/resolve' does not exist
user 'ntp': directory '/home/ntp' does not exist
user 'mysql': directory '/nonexistent' does not exist
user 'dovenull': directory '/nonexistent' does not exist
user 'memcache': directory '/nonexistent' does not exist
user 'proftpd': directory '/run/proftpd' does not exist
pwck: no changes
```
grpck:

```
'userxyz123' is a member of the 'www-data' group in /etc/group but not in /etc/gshadow
'www-data' is a member of the 'client0' group in /etc/group but not in /etc/gshadow
'www-data' is a member of the 'client1' group in /etc/group but not in /etc/gshadow
```
Vielen Dank schon mal für die Hilfe!


----------



## Till (5. März 2017)

Die vhost.err datei in .vhost umbenennen, apache neu starten, dann siehst Du im apache log warum er nicht startet.


----------



## saschabe (6. März 2017)

Zitat von Till:


> Die vhost.err datei in .vhost umbenennen, apache neu starten, dann siehst Du im apache log warum er nicht startet.




```
[Mon Mar 06 06:25:03.590309 2017] [mpm_prefork:notice] [pid 28551] AH00163: Apache/2.4.10 (Debian) mod_fastcgi/mod_fastcgi-SNAP-0910052141 mod_fcgid/2.3.9 Phusion_Passenger/4.0.53 mod_python/3.3.1 Python/2.7.9 OpenSSL/1.0.2j configured $
[Mon Mar 06 06:25:03.590331 2017] [core:notice] [pid 28551] AH00094: Command line: '/usr/sbin/apache2'
[Mon Mar 06 06:25:03.590457 2017] [mpm_prefork:warn] [pid 28551] AH00167: long lost child came home! (pid 14964)
[Mon Mar 06 15:39:40.700814 2017] [mpm_prefork:notice] [pid 28551] AH00169: caught SIGTERM, shutting down
```
Mehr als ein SIGTERM, shutting down kann ich da nicht herauslesen.


----------

