ISPConfig [3.0.5.1] - Problem keine error.log einträge

[didiber]

Hallo!

Nach dem Update auf 3.0.5.1 hab ich grade festellen müssen das die log dateien root gehören und einfach 0 byte haben.

Was ich getan habe:
dem web devel.domain.tld seine domain.tld zugeordnet.

Meine installation läuft mit nginx.

Wo sollten sich nun die log's befinden?
in
/var/log/ispconfig/httpd/domain.tld/
oder
/var/www/clients/clinetX/webX/log/

In beiden Verzeichnissen befindet sich gerade nur eine leere error.log Datei die root gehört.

Ach ja vorher war ja im web Verzeichnis ein Symbolischer link auf die log Dateien, der ist nun ein Verzeichnis owner root hmmm ...

Es hat sich gemischt. Einige log Verzeichnisse (meisten) sind links die anderen verzeichnisse ... irgndwie ganz schön durcheinander.
Frag mich wo meine Aktuelle error Meldung landet.

hab ein 500 error und komm nicht weiter.

Danke schon mal!

didiber

Habe zum test gerade ein neues web angelegt um zu sehen wie die verzeichnise aussehen ergebniss:

1. log verzeichnis ist ein verzeichnis und der inhalt ist eine error.log besitzer ist root mit 0 byte
2. das angelegte web ist nicht mehr erreichbar!

jetzt wirds kritisch!

Mein ispconfig zerlegt sich grade. HILFE!!!

 

[Till]

Das funktioniert hier alles einwandfrei, haben einige nginx Produktivserver unter 3.0.5 am laufen.

Nach dem Update auf 3.0.5.1 hab ich grade festellen müssen das die log dateien root gehören und einfach 0 byte haben.

Richtig, logs gehören root. Das sie 0 byte haben dedeutet dass sie leer sind, das kann also an Deiner nginx installation oder Konfiguration liegen.

Wo sollten sich nun die log's befinden?
in
/var/log/ispconfig/httpd/domain.tld/
oder
/var/www/clients/clinetX/webX/log/

Da wo sie immer waren und noch sind:

/var/log/ispconfig/httpd/domain.tld/

denn /var/www/clients/clinetX/webX/log/ ist ein gemountetes Verzeichnis.

Ach ja vorher war ja im web Verzeichnis ein Symbolischer link auf die log Dateien, der ist nun ein Verzeichnis owner root hmmm ...

Völlig richtig. Denn das System funktioniert jetzt über mount binds.

Es hat sich gemischt. Einige log Verzeichnisse (meisten) sind links die anderen verzeichnisse ... irgndwie ganz schön durcheinander.

Das ist auch korrekt. Denn Webseiten werden bei einem Update auf das eue System umgestellt. Es funktioniert also mit symlink und mit mount bind.

hab ein 500 error und komm nicht weiter.

Dann prüfe mal Deine nginx Konfiguration, welche Log Pfade dort eingetragen sind und start mal nginx neu.

 

[didiber]

Ok!

Nach einem reboot:

Apache ist mir wieder in die quere gekommen mit "/etc/init.d/apace2 stop" gestoppt und auch gleich ein update-rc.d apache2 remove aus dem Startvorgang rausgenommen.

nginx:

berliserv:~# nginx
nginx: [emerg] unexpected "}" in /etc/nginx/sites-enabled/100-webmail.berliserv.net.vhost:132

Komisch was der gegen die Abschluss geschwungene Klammer hat.

Glöst mit:

mv /etc/nginx/sites-enabled/100-webmail.berliserv.net.vhost /root/
nginx startet ohne Fehler

In ispconfig das web webmail.berliserv.net geringfügig geändert, einfach mal ssl ausgeschaltet
nach dem update web-domain, neu conf schreiben lassen.

Und nun sind auch alle log's so wies sein soll:
Als verzeichnis mit root rechten , Cool mit den neuen mounts

Viellen Dank Till für deine schnelle reaktion, und sorry für den doofen bug report.

 

[didiber]

ist ja doch ein bischen ein bug!

Was ich hab nochmals getan habe:

Ausgangssituation:

Domain polytec.co.at mit einer Baustellenseite.
Domain polytec.promandant.at als Devel Platz.

Nun möchte ich den Devel Platz der Domain zuordnen.
vorteile: user und gruppe, web Optionen und Einstellungen bleiben erhalten.

In ISPConfig:

1. domain Anlage: tmp.promandant.at (als Zwischenschritt, sonst haben wir keine eindeutige Domain zum zuordnen)

2. web polytec.co.at der Domain tmp.promandant.at zugeordnet (somit ist die Baustellenseite aus dem weg und Domain polytec.co.at ist frei)

3. web polytec.promandant.at der Domain polytec.co.at zugeordnet (jetzt ist der ehemalige Devel Platz mit der Domain polytec.co.at erreichbar)

nach dieser Aktion tritt genau der oben beschriebene Effekt auf.

Abhilfe schafft nur ein manueller nginx restart, dabei tritt aber wieder die Fehlermeldung mit der geschwungenen Klammer auf.

Kurz ( ) mal die config:

db@berliserv:~$ cat /etc/nginx/sites-available/webmail.berliserv.net.vhost
server {
listen *:80;


server_name webmail.berliserv.net www.webmail.berliserv.net;

root /var/www/webmail.berliserv.net/web;



index index.html index.htm index.php index.cgi index.pl index.xhtml;



error_page 400 /error/400.html;
error_page 401 /error/401.html;
error_page 403 /error/403.html;
error_page 404 /error/404.html;
error_page 405 /error/405.html;
error_page 500 /error/500.html;
error_page 502 /error/502.html;
error_page 503 /error/503.html;
recursive_error_pages on;
location = /error/400.html {

internal;
}
location = /error/401.html {

internal;
}
location = /error/403.html {

internal;
}
location = /error/404.html {

internal;
}
location = /error/405.html {

internal;
}
location = /error/500.html {

internal;
}
location = /error/502.html {

internal;
}
location = /error/503.html {

internal;
}

error_log /var/log/ispconfig/httpd/webmail.berliserv.net/error.log;
access_log /var/log/ispconfig/httpd/webmail.berliserv.net/access.log combined;

## Disable .htaccess and other hidden files
location ~ /\. {
deny all;
access_log off;
log_not_found off;
}

location = /favicon.ico {
log_not_found off;
access_log off;
}

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

location /stats {

index index.html index.php;
auth_basic "Members Only";
auth_basic_user_file /var/www/clients/client1/web33/web/stats/.htpasswd_stats;
}

location ^~ /awstats-icon {
alias /usr/share/awstats/icon;
}

location ~ \.php$ {
try_files /de329bc6bd8943cda0f7d80f81723d1f.htm @php;
}

location @php {
try_files $uri =404;
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9042;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
#fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_intercept_errors on;
}


<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^favicon\.ico$ skins/larry/images/favicon.ico
# security rules
RewriteRule .git - [F]
RewriteRule ^/?(README(.md)?|INSTALL|LICENSE|SQL|bin|CHANGELOG)$ - [F]
</IfModule>

<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
</IfModule>

<IfModule mod_headers.c>
# replace 'append' with 'merge' for Apache version 2.2.9 and later
#Header append Cache-Control public env=!NO_CACHE
</IfModule>

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 month"
</IfModule>

FileETag MTime Size

<IfModule mod_autoindex.c>
Options -Indexes
</ifModule>


}


es handelt sich um die letzte Klammer.

Meine nginx Direktiven:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^favicon\.ico$ skins/larry/images/favicon.ico
# security rules
RewriteRule .git - [F]
RewriteRule ^/?(README(.md)?|INSTALL|LICENSE|SQL|bin|CHANGELOG)$ - [F]
</IfModule>

<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
</IfModule>

<IfModule mod_headers.c>
# replace 'append' with 'merge' for Apache version 2.2.9 and later
#Header append Cache-Control public env=!NO_CACHE
</IfModule>

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 month"
</IfModule>

FileETag MTime Size

<IfModule mod_autoindex.c>
Options -Indexes
</ifModule>


Individuelle php.ini Einstellungen:

date.timezone = Europe/Vienna
[suhosin]
suhosin.session.encrypt = Off


<IfModule mod_php5.c>
php_flag display_errors Off
php_flag log_errors On
# php_value error_log logs/errors

php_value upload_max_filesize 200M
php_value post_max_size 200M
php_value memory_limit 128M

php_flag zlib.output_compression Off
php_flag magic_quotes_gpc Off
php_flag magic_quotes_runtime Off
php_flag zend.ze1_compatibility_mode Off
php_flag suhosin.session.encrypt Off

#php_value session.cookie_path /
php_flag session.auto_start Off
php_value session.gc_maxlifetime 21600
php_value session.gc_divisor 500
php_value session.gc_probability 1

# http://bugs.php.net/bug.php?id=30766
php_value mbstring.func_overload 0
</IfModule>



didiber

 

[didiber]

Nach entfernen dieser nginx Direktiven ging das web ohne Schwierigkeiten.

 

[Till]

Das was Du als nginx Direktiven gepostet hast sieht mir sehr nach apache Direktiven aus. nginx versteht keine apache Direktiven, nginx hat eine ganz andere Syntax.