Re: slotmem_shm zeigt Fehler beim reload an
Am 04.05.2017 um 12:11 schrieb Denny Jahnke: Hallo zusammen, ich habe ein größeres Problem, welches auch nicht wirklich beständig ist, ich hoffe es kann mir jemand einen Tipp geben. Folgende Konstellation: Server-OS: Debian 8.7 HTTPD: Apache/2.4.10 (Debian) - über APT installiert RAM: 32GB CPU: 24 vCores Nutzung: als Reverse Proxy (kein Forward Proxy von innen ins Internet!) für verschiedene Backend Applikationen, hinzu kommen diverse unterschiedliche Balancer-Konfigurationen über mod_proxy_balancer. Kein PHP/FPM/PERL oder so, nur zum Teil static content. Wir haben 2 Systeme die HA über eine vorgeschaltete F5 LB redundant ausgelegt sind. Das Verhalten: Ich habe kleinere Rewrite Änderungen in 2-3 Vhosts durchgeführt (hauptsächlich Rewrites) und diese auf die Server übertragen, als ich "service apache2 reload" (configtest war zuvor erfolgreich!) auf dem 1. System durchgeführt habe ist dieser mir unter den Händen weggestorben, Ports waren auch weg. Fork-Prozesse aber teils noch vorhanden. Folgende Fehlermeldung kam zum Vorschein in der error.log: [Thu May 04 06:25:07.104831 2017] [mpm_worker:notice] [pid 17256:tid 140267085170560] AH00292: Apache/2.4.10 (Debian) OpenSSL/1.0.1t configured -- resuming normal operations [Thu May 04 06:25:07.104876 2017] [core:notice] [pid 17256:tid 140267085170560] AH00094: Command line: '/usr/sbin/apache2' [Thu May 04 06:25:12.284974 2017] [mpm_worker:notice] [pid 17256:tid 140267085170560] AH00297: SIGUSR1 received. Doing graceful restart [Thu May 04 06:25:13.181387 2017] [slotmem_shm:error] [pid 17256:tid 140267085170560] (28)No space left on device: AH02611: create: apr_shm_create(/var/run/apache2/slotmem-shm-p9e1d2282_internet_cluster.shm) failed [Thu May 04 06:25:13.181438 2017] [:emerg] [pid 17256:tid 140267085170560] AH00020: Configuration Failed, exiting Allerdings ist mehr als genug Platz auf /var: FilesystemSize Used Avail Use% Mounted on /dev/mapper/swrvp1-var_vol 485G 9.5G 451G 3% /var Ich habe die Konfigurationen aus dem Backup wieder hergestellt, ein "service apache2 restart" hat die gleiche Fehlermeldung produziert. Erst als ich ein killall auf die verbliebenen Prozesse gemacht habe konnte ich mit einem sauberen Start den Apache wieder hoch bringen. Zur Sicherheit habe ich die Konfigurationen auf dem zweiten Apache (der keinen reload gemacht hat) wieder zurück geändert. Da allerdings die Apaches regelmäßig neu gestartet werden, kam es hier (obwohl alte Konfiguration!) zu dem gleichen Fehlerbild und -meldung im error.log innerhalb von ca. 12 Stunden. Jetzt laufen beide Systeme wieder augenscheinlich stabil und machen den reload ohne Probleme aber den Fehler hatte ich vor 1 Monat schon mal aber nur auf einem der beiden Systeme. Hat jemand eine Idee oder stand schon mal vor dem selben Problem? Sehr wahrscheinlich sind IPC-Ressourcen erschöpft. In dem Fall hier wohl Shared Memory (siehe ipcs -m zum Anzeigen, bzw. ipcs -lm zur Anzeige der konfigurierten Limits, ipcrm zum Löschen), es können aber auch mal Semaphoren sein (bei ipcs immer statt "-m" ein "-s"). IPC-Ressourcen können leaken, zum Beispiel wenn Prozesse crashen. D.h. schauen, dass alle Apaches unten sind, dann mit ipcs nachsehen, welche shared Memory-Segmente und Semaphoren noch belegt sind und ob der User passt, dann ggf. mit ipcrm löschen und die Apaches wieder starten. Bei vielen Workern und Load Balancern in mod_proxy kann es auch sein, dass die eingestellten System-Limits für Shared Memory oder Semaphoren zu klein sind. Den Fehler sollte man auch ganz gut mit strace -v -f -o /var/tmp/strace.out service apache2 start sehen können (in der großen Datei /var/tmp/strace.out), weil dort jeder system call mit Ergebniscode drin steht und an der entscheidenden Stelle dann ein "ENOSPC" auftauchen wird (der Fehlerwert für "No space left on device"). Mit "restart" wird strace nicht gehen, weil da ja nur ein Signal an den Apache Vater-Prozess gesendet wird und das Signal-Senden ja klappt. Da müsste man den laufenden Vater-Prozess vorher in das strace rein nehmen. Ist aber einfacher mit frischem Apache-Start. Grüße sendet Rainer Jung -- kippdata informationstechnologie GmbH Tel: 0228 98549 -0 Bornheimer Str. 33aFax: 0228 98549 -50 53111 Bonn www.kippdata.de HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417 Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann - To unsubscribe, e-mail: users-de-unsubscr...@httpd.apache.org For additional commands, e-mail: users-de-h...@httpd.apache.org
Re: vhost Apache Konfiguration
Am 28.03.2017 um 16:50 schrieb m...@ft-c.de: Hallo, seit einigen Monaten akzeptiert der Apache Server die vhosts nicht mehr. Beschreibung des Verhalten: Es sind web_ftimmer (und weitere) als vhosts eingebunden (s.u.). Stell mal web_ftimmer auf web-ftimmer um (Bindestrich statt Unterstrich). Unterstriche sind m.E. in Hostnamen nicht erlaubt und auch wenn Apache ServerName nur den Host-Header meint, müssen doch Deine Clients mit einem Hostnamen aus der URL klar kommen. Deshalb hier lieber keine Experimente. Gruß Rainer Ein ping von der Konsole auf web_ftimmer läuft. Ein ping auf localhost läuft auch, obwohl dieser in der Datei /etc/hosts auskommentiert ist. Wenn ich localhost im Webbrowser aufrufe, erscheint der erste Eintrag der vhosts.conf Datei. Über phpinfo wird die in vhosts (1. Eintrag) angegebene Emailadresse ausgegeben. Wenn ich web_ftimmer in Firefox oder Chromium aufrufe, erscheint die 400-Fehlerseite, bzw der Eintrag aus dem vhost (Text: Error Doc 400v) Hier die wichtigsten Daten: Hier ein Auszug aus /usr/local/etc/apache24/extra/htpd_vhosts.conf Hier die Kurzversion für web_ftimmer ServerName web_ftimmer DocumentRoot /server/www/web_ftimmer ServerAdmin ftim...@ft.de # ErrorLog /var/log/apache2/error.log # CustomLog /var/log/apache2/access.log combined LogLevel info ErrorDocument 500 "Error Doc 500v" ErrorDocument 404 "Error Doc 404v" ErrorDocument 402 "Error Doc 402v" ErrorDocument 400 "Error Doc 400v" Hier die Langversion für web_ftimmer: ServerName web_ftimmer DocumentRoot /server/www/web_ftimmer ServerAdmin f...@ft.de RewriteEngine off Options FollowSymLinks AllowOverride All Options Indexes FollowSymLinks MultiViews AllowOverride All Require all granted ErrorLog /var/log/apache2/error.log LogLevel info CustomLog /var/log/apache2/access.log combined ErrorDocument 500 "Error Doc 500v" ErrorDocument 404 "Error Doc 404v" ErrorDocument 402 "Error Doc 402v" ErrorDocument 400 "Error Doc 400v" Die Datei /etc/hosts beinhaltet: 127.0.0.1web_ftimmer .. und weitere (aber nicht localhost) % apachectl -S VirtualHost configuration: *:80 is a NameVirtualHost default server web_ftimmer (/usr/local/etc/apache24/extra/httpd-vhosts.conf:31) port 80 namevhost web_ftimmer (/usr/local/etc/apache24/extra/httpd-vhosts.conf:31) port 80 namevhost web_ft-c (/usr/local/etc/apache24/extra/httpd-vhosts.conf:64) ... und weitere ServerRoot: "/usr/local" Main DocumentRoot: "/server/www" Main ErrorLog: "/var/log/apache2/error.log" Mutex default: dir="/var/run/" mechanism=default Mutex mpm-accept: using_defaults Mutex rewrite-map: using_defaults PidFile: "/var/run/httpd.pid" Define: DUMP_VHOSTS Define: DUMP_RUN_CFG User: name="www" id=80 Group: name="www" id=80 % apachectl -t -D DUMP_INCLUDES Included configuration files: (*) /usr/local/etc/apache24/httpd.conf (503) /usr/local/etc/apache24/extra/httpd-vhosts.conf (531) /usr/local/etc/apache24/Includes/no-accf.conf Weitere Informationen: Bei einem FREEBSD Update (schon lange her) erhielt ich die Info: You may need to manually remove /usr/local/etc/apache24/extra/httpd-vhosts.conf if it is no longer needed. You may need to manually remove /usr/local/etc/apache24/httpd.conf if it is no longer needed. % uname -a FreeBSD ftc2 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0: Mon Oct 24 06:55:27 UTC 2016 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Und hier die httpd.conf % cat /usr/local/etc/apache24/httpd.conf | grep -v -e "^ *#" | grep -v -e "^ *$" ServerRoot "/usr/local" Listen 80 LoadModule authn_file_module libexec/apache24/mod_authn_file.so LoadModule authn_core_module libexec/apache24/mod_authn_core.so LoadModule authz_host_module libexec/apache24/mod_authz_host.so LoadModule authz_groupfile_module libexec/apache24/mod_authz_groupfile.so LoadModule authz_user_module libexec/apache24/mod_authz_user.so LoadModule authz_core_module libexec/apache24/mod_authz_core.so LoadModule access_compat_module libexec/apache24/mod_access_compat.so LoadModule auth_basic_module libexec/apache24/mod_auth_basic.so LoadModule reqtimeout_module libexec/apache24/mod_reqtimeout.so LoadModule filter_module libexec/apache24/mod_filter.so LoadModule mime_module libexec/apache24/mod_mime.so LoadModule log_config_module libexec/apache24/mod_log_config.so LoadModule env_module libexec/apache24/mod_env.so LoadModule headers_module libexec/apache24/mod_headers.so LoadModule setenvif_module libexec/apache24/mod_setenvif.so LoadModule version_module libexec/apache24/mod_version.so LoadModule session_module libexec/apache24/mod_session.so LoadModule session_cookie_module libexec/apache24/mod_session_cookie.so LoadModule mpm_prefork_module libexec/apache24/mod_mpm_prefork.so LoadModule unixd_module libexec/apache24/mod_unixd.so LoadModule st
Re: Probleme beim Kompilieren von Apache 2.0.65 mit OpenSSL 1.0.0k
On 25.07.2013 15:32, andre.wen...@bmw.de wrote:
> Hallo Herr Jung,
>
> vielen Dank für die schnelle Antwort und angebotene Hilfe.
>
> Nach etwas Hilfe und dem Einsatz rudimentärer C++-Kenntnisse habe ich das
> Ganze noch zum kompilieren und laufen bekommen, dabei hat mir folgender Teil
> sehr geholfen
> http://mail-index.netbsd.org/pkgsrc-users/2009/08/25/msg010530.html
>
> Ich habe um das Ganze zu lösen innerhalb der Dateien folgende Stellen
> angepasst:
>
> modules/ssl/ssl_engine_init.c
>
>> #ifdef SSL_OP_CIPHER_SERVER_PREFERENCE
>> if (sc->cipher_server_pref == TRUE) {
>> SSL_CTX_set_options(ctx, SSL_OP_CIPHER_SERVER_PREFERENCE);
>> }
>> #endif
>>
> 538c544
> < SSL_CTX_set_client_CA_list(ctx, (STACK *)ca_list);
> ---
>> SSL_CTX_set_client_CA_list(ctx, (STACK_OF(X509_NAME) *)ca_list);
>
> modules/ssl/ ssl_util_ssl.c
>
> 469c469
> < STACK *extra_certs;
> ---
>> STACK_OF(X509) *extra_certs;
Danke für die Info, ja das sieht auch für mich gut aus.
> Erste SSL-Test liefen ohne Probleme.
Ich habe diese Änderung an den von mit zitierten Bugzilla Issue gehängt.
Mit an Sicherheit grenzender Wahrscheinlichkeit wird es zwar kein
2.0-Release mehr geben, aber für User mit dem gleichen Problem beim
Bauen ist dann die Lösung besser auffindbar.
> Der Code scheint mir damals wohl nicht sehr einheitlich gepflegt worden zu
> sein bzw. die Stellen evtl. bei der Umstellung von STACK * auch Typisierung
> übersehen worden zu sein.
Ich hab es jetzt nicht nachgeschaut, aber ich denke zu der Zeit als es
relevant wurde hat sich einfach niemand gefunden, der genug Interesse
hatte 2.0 mit OpenSSL 1.0 kompatibel zu machen. Bei 2.2 ist dies ja gegeben.
Viel Spaß mit Apache (und ein baldiges Ende Ihres 2.0-Lifecycle) wünscht
Rainer Jung
--
kippdata
informationstechnologie GmbH Tel: 0228 98549 -0
Bornheimer Str. 33aFax: 0228 98549 -50
53111 Bonn www.kippdata.de
HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann
-
To unsubscribe, e-mail: users-de-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-de-h...@httpd.apache.org
Re: Probleme beim Kompilieren von Apache 2.0.65 mit OpenSSL 1.0.0k
Hallo Herr Wendel,
On 23.07.2013 14:35, andre.wen...@bmw.de wrote:
> Hallo,
>
> Ich habe ein Problem beim kompilieren des Apache 2.0.65 in Verbindung mit der
> OpenSSL Version 1.0.0k. Dabei wirft er folgenden Fehler, aus welchem ich
> leider nicht weiter schlau werde:
>
> /wwws/apache/apache2.0.65w/instroot/build/libtool --silent --mode=compile gcc
> -g -O2 -pthread-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
> -DAP_HAVE_DESIGNATED_INITIALIZER
> -I/wwws/apache/apache2.0.65w/instroot/include/apr-0
> -I/wwws/apache/apache2.0.65w/openldap/include -I.
> -I/wwws/apache/src/httpd-2.0.65/os/unix
> -I/wwws/apache/src/httpd-2.0.65/server/mpm/worker
> -I/wwws/apache/src/httpd-2.0.65/modules/http
> -I/wwws/apache/src/httpd-2.0.65/modules/filters
> -I/wwws/apache/src/httpd-2.0.65/modules/proxy
> -I/wwws/apache/src/httpd-2.0.65/include
> -I/wwws/apache/src/httpd-2.0.65/modules/generators
> -I/wwws/apache/src/httpd-2.0.65/server
> -I/wwws/apache/apache2.0.65w/openssl/include/openssl
> -I/wwws/apache/apache2.0.65w/openssl/include
> -I/wwws/apache/src/httpd-2.0.65/modules/dav/main -prefer-pic -c
> ssl_engine_init.c && touch ssl_engine_init.slo
> ssl_engine_init.c: In function âssl_init_ctx_protocolâ:
> ssl_engine_init.c:392: warning: assignment discards qualifiers from pointer
> target type
> ssl_engine_init.c:398: warning: assignment discards qualifiers from pointer
> target type
> ssl_engine_init.c: In function âssl_init_ctx_verifyâ:
> ssl_engine_init.c:538: error: âSTACKâ undeclared (first use in this function)
> ssl_engine_init.c:538: error: (Each undeclared identifier is reported only
> once
> ssl_engine_init.c:538: error: for each function it appears in.)
> ssl_engine_init.c:538: error: expected expression before â)â token
> ssl_engine_init.c: In function âssl_init_FindCAListâ:
> ssl_engine_init.c:1113: warning: pointer type mismatch in conditional
> expression
> make[4]: *** [ssl_engine_init.slo] Error 1
> make[4]: Leaving directory
> `/lfs/wwwmnt/wwws.nvgm042/apache/src/httpd-2.0.65/modules/ssl'
> make[3]: *** [shared-build-recursive] Error 1
> make[3]: Leaving directory
> `/lfs/wwwmnt/wwws.nvgm042/apache/src/httpd-2.0.65/modules/ssl'
> make[2]: *** [shared-build-recursive] Error 1
> make[2]: Leaving directory
> `/lfs/wwwmnt/wwws.nvgm042/apache/src/httpd-2.0.65/modules'
> make[1]: *** [shared-build-recursive] Error 1
> make[1]: Leaving directory `/lfs/wwwmnt/wwws.nvgm042/apache/src/httpd-2.0.65'
> make: *** [all-recursive] Error 1
> Making httpd was NOT SUCCESSFUL.
>
> Ich hatte in älteren Versionen schon das Problem mit dem Fehler "inal link
> failed: Bad value", auf welchen hin ich OpenSSL mit dem Parameter "shared"
> gebaut habe und dies dann lief.
>
> SuSe Linux 11SP1
> GCC Version aktuell: gcc (GCC) 4.1.2 20070115 (SUSE Linux)
>
> OpenSSL:
> ./config \
> --prefix=${prefix_openssl} \
> --openssldir=${prefix_openssl} \
> shared
>
> Apache:
> ./configure --prefix=${apache_prefix}/instroot \
> ...
> --enable-ssl \
> --with-ssl=${apache_prefix}/openssl \
> ...
Ich denke es handelt sich hier um die bekannte Inkompatibilität zwischen
Apache 2.0 und OpenSSL 1.0 oder höher:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49034
Ich kann mir das einmal ansehen, aber wenn Ihnen eine Übersetzung mit
dem letzten OpenSSL 0.9.8 reicht wäre das einfacher. Noch besser wäre
natürlich auf Apache 2.2.25 oder 2.4.6 zu switchen :)
Allerdings passt die oben angegebene Zeilennummer 538 nicht auf eine
Stelle, die STACK verwendet. Deshalb zunächst die Fragen:
- welche Version hatten Sie zuletzt erfolgreich mit den gleichen
Rahmenbedingungen kompiliert?
- wurde die Datei modules/ssl/ssl_engine_init.c von Ihnen angepasst?
In der Originaldatei steht in Zeile 538 der Aufruf zur Ausgabe der
Log-Meldung "Unable to determine list of available CA certificates for
client authentication", keine Spur von STACK.
Grüße sendet
Rainer Jung
--
kippdata
informationstechnologie GmbH Tel: 0228 98549 -0
Bornheimer Str. 33aFax: 0228 98549 -50
53111 Bonn www.kippdata.de
HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann
-
To unsubscribe, e-mail: users-de-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-de-h...@httpd.apache.org
Re: die libmath nachträglich in ein Modul bringen?
Hi Michael, On 15.03.2012 14:30, Michael Renner wrote: Moin, ich habe hier ein Binärmodul das einen Apache mit libmath voraussetzt. Die Mathe-Library heißt im Filesystem libm.(a|so|so...). Sie gehört zum Standard-Installationszustand Deines Systems. Eine Library wird von einem Apache-Modul eigentlich nie im Apache selbst vorausgesetzt, sondern nur im installierten System. Es kommt eher umgekehrt zu Problemen, wenn ein Modul und der Apache beide unabhängig gegen eine Library linken und dabei verschiedene Versionen verwenden. In Deinem Fall solltest Du beim Linken des Moduls einfach ein "-lm" mit dazunehmen. "-labc" bedeutet "linke libabc ein", "-lb" steht also für libm. Den Apache will/kann/darf ich nicht neu bauen. Ich frage mich: bekomme ich libmath nachträglich in das Binärmodul rein? Nachträgliches Linken oder so? Wenn Du die Sourcen hast ja, siehe oben. Wenn Du keine Sourcen hast, wird es eher schwierig. Der beste Workaround wird dann "LoadFile" sein. Mit LoadFile kannst Du vor der LoadModule-Zeile für Dein Modul dem Apache sagen, dass er eine Library laden soll. http://httpd.apache.org/docs/2.2/en/mod/mod_so.html#loadfile Bei Solaris gibt es "elfedit". Damit ginge das nachträgliche Eintragen einer Library Dependency in ein schon gelinktes shared object file wohl. Bei Linux gibt es das nicht so richtig. Erwähnt wird elfsh, aber das scheint nicht stabil zu sein: http://www.eresi-project.org/wiki/TheELFsh Schließlich könnte man noch fiese Tricks machen. Wenn das Modul eine andere Abhängigkeit zu einer Library eingetragen hat, könnte man eine Dummy-Library mit dem gleichen SO Name bauen, die gar keine Symbole enthält, aber selbst gegen die anderen Libs gelinkt ist. Würde ich aber nicht machen, ist Arbeit und schwer zu durchblicken für andere. Schließlich ginge noch LD_PRELOAD auf die libm als Environment-Variable für den Apache-Prozess vor dem Starten setzen, etwa in der envvars-Datei. Die Libs in LD_PRELOAD werden automatisch vor dem Starten jedes Prozesses zuerst geladen und dann auch immer zuerst nach Symbolen durchsucht. Dankbar für Hinweise :) Lange Rede: ich würde auf LoadFile zurückgreifen. Grüße sendet Rainer - To unsubscribe, e-mail: users-de-unsubscr...@httpd.apache.org For additional commands, e-mail: users-de-h...@httpd.apache.org
Re: win7 Applikation beenden mit -k tut nicht
On 17.01.2012 14:27, Emil Obermayr wrote: Hallo, ich möchte einen Apache 2.2 als Applikation auf Port 8080 unter Windows 7 laufen lassen. Er läßt sich auch starten und bantwortet Anfragen ganz wie er soll: ...\Apache2.2> bin\httpd.exe Und läßt sich auch mit ctrl-c (und etwas Geduld) wieder beenden. So weit so gut. Nun soll er aber gemäß Anleitung http://httpd.apache.org/docs/2.2/platform/windows.html in einem anderen Konsole-Fenster mit -k shutdown wieder beendet werden können. Statt dessen passiert folgendes: ...\Apache2.2>bin\httpd.exe -k shutdown [Tue Jan 17 14:23:27 2012] [error] (OS 2)Das System kann die angegebene Datei nicht finden. : No installed service named "Apache2.2". Einen solchen Service gibt es auch tatsächlich nicht und soll es auch nicht geben. Die Config-Datei mit -f anzugeben habe ich auch schon versucht; das ändert nichts. Das System hier ist Windows 7 Ultimate 64 auf einem core i7, falls das von Belang ist. Vielen Dank für jede Hilfe und viele Grüße Das ist leider ein lange offener Enhancement Request: https://issues.apache.org/bugzilla/show_bug.cgi?id=25484 Ich hatte mal einen Patch, der aber beim Versuch oihn ganz richtig zu machen wieder unterging. Siehe auch: http://marc.info/?t=12408480394&r=1&w=1 Grüße sendet Rainer -- Apache HTTP Server Mailing List "users-de" unsubscribe-Anfragen an users-de-unsubscr...@httpd.apache.org sonstige Anfragen an users-de-h...@httpd.apache.org --
Re: WebDAV-Upload mit XP Dateiexplorer schlägt fehl
On 13.01.2012 18:40, Michael Renner wrote:
On 11.01.2012 23:35, Rainer Jung wrote:
302 ist nicht "Found" sondern ein Redirect. Nimm doch mal
%{Location}o in Dein LogFormat fürs AccessLog auf. Dann siehst Du,
wohin der Apache den Client redirecten möchte. Das gibt uns evtl. eine
Idee.
ups, ja klar. Mir qualmte dann der Kopf. %{Location}o stand schon drin,
derzeit sieht es so aus:
LogLevel debug
RewriteLog "/var/log/apache/rewrite.log"
LogFormat "%h %l %u %t \"%r\" %>s %b %{Location}o %{pid}P %{tid}P
\"%{User-Agent}i\"" commonredir
CustomLog "| /opt/apache22/bin/rotatelogs
/var/log/apache/access.log.%Y%m%d 86400" "%v %h %l %u %t \"%r\" %>s %b
\"%{Referer}i\" \"%{User-agent}i\" %{Location}o" env=!dontlog
OK, ich hab nochmal aus Deiner ersten Mail die Zeile rausgesucht:
1.2.3.4 192.168.0.100 - renner [11/Jan/2012:15:52:33 +0100] "HEAD
/renner/in/avi/Finanzkrise.pdf HTTP/1.1" 302 - "-" "Microsoft Data
Access Internet Publishing Provider DAV"
Der UA passt zum BrowserMatch, da ist also nichts zu verbessern.
Der Location-Header scheint hier aber nicht geloggt zu werden. Entweder
die obigen Konfig-Zeilen sind nicht diejenigen, die das Logfile
produzieren, oder aber der Header ist überrachsenderweise leer.
Mach doch al folgende Anpassung (keine Zeilenumbrüche!) und rufs nochmal
auf und poste die neue Accesslog-Ausgabe.
CustomLog "|
/opt/apache22/bin/rotatelogs/var/log/apache/access.log.%Y%m%d 86400" "%v
%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"
X%{Location}oX" env=!dontlog
Jetzt sollte rund um den Location-Header ein "X" sein. Steht da also ein
XX am Zeilenende, dann ist der Header leer gewesen. Steht da gar kein X,
dann gibt es irgendwo anders in Deiner Konfig die wirlich angezogene
CustomLog-Direktive.
Gruß
Rainer
--
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an users-de-unsubscr...@httpd.apache.org
sonstige Anfragen an users-de-h...@httpd.apache.org
--
Re: WebDAV-Upload mit XP Dateiexplorer schlägt fehl
Hi Michael,
On 11.01.2012 17:06, Michael Renner wrote:
Moin,
auf einem Apache 2.2.21 funktioniert der WebDAV-Upload mit
* konquerror (Linux getestet)
* WebDrive (XP getestet)
* curl (XP getestet)
Der Upload mit dem Dateiexplorer funktioniert nicht. Wohl aber der
Download. Zum Vergleich habe ich die WebDAV-Installation mit Apache 2.0
die abgelöst werden soll. Dort funktioniert der Upload (dafür gibt es
andere Probleme).
Der Upload (Dateiexplorer) funktioniert unter Apache 2.0:
1.2.3.4 - renner[11/Jan/2012:15:51:42 +0100] "HEAD
/renner/in/avi/Finanzkrise.pdf HTTP/1.1" 404 -
1.2.3.4 - renner[11/Jan/2012:15:51:43 +0100] "PUT
/renner/in/avi/Finanzkrise.pdf HTTP/1.1" 201 204
Der Upload (Dateiexplorer) funktioniert nicht unter Apache 2.2
1.2.3.4 192.168.0.100 - renner [11/Jan/2012:15:52:33 +0100] "HEAD
/renner/in/avi/Finanzkrise.pdf HTTP/1.1" 302 - "-" "Microsoft Data
Access Internet Publishing Provider DAV"
Das anfängliche HEAD soll wohl prüfen ob die Datei am Ziel bereits
existiert. Der funktionierende Apache gibt ein 404 (also "Not Found")
zurück. Der nicht funktionierende gibt ein 302 (also "Found") zurück.
Die Datei lag jeweils nicht im Verzeichnis. Im error-Log steht auch
richtig:
File does not exist: /space/dav/htdocs/renner/in/avi/Finanzkrise.pdf
Immerhin funktioniert das Umbenennen einer Datei wenn sie erstmal auf
dem Apache 2.2 liegt:
1.2.3.4 192.168.0.100 - renner[11/Jan/2012:16:07:41 +0100] "MOVE
/renner/in/avi/Finanzkrise.pdf HTTP/1.1" 201 207 "-" "Microsoft Data
Access Internet Publishing Provider DAV"
In der httpd.conf steht u.a.
BrowserMatch "Microsoft Data Access Internet Publishing Provider"
redirect-carefully
BrowserMatch "Microsoft Data Access Internet Publishing Provider DAV"
redirect-carefully
was aber nicht ursächlich ist. Ich kommentierte das mal rein und raus.
Ohne dass der Upload dann funktionierte.
Im alten (funktionierenden) Apache gibt es noch das mod_msfix. Das lässt
sich aber auch ausschliessen, denn versuchsweise habe ich es auf der
alten Umgebung abgeschaltet und der Upload funktioniert (nach einem
Neustart) noch immer.
Ansonsten ist konfigutiert (hier wie dort):
Options +All
AllowOverride None
order allow,deny
allow from all
DAV On
DavDepthInfinity on
AuthName "Login area"
AuthType Basic
Require user renner
AuthUserFile /space/dav/var/htpasswd
Versucht hatte ich auch , das machte aber keinen
Unterschied. Auch nicht das vollständige auskommentieren des Limit-Blocks.
Nun frage ich mich: warum gibt der alte Apache ein korrektes 404 zurück,
der neue aber einen 302?
Gibt's eine Idee?
Bin für jeden Denkanstoss dankbar!
302 ist nicht "Found" sondern ein Redirect. Nimm doch mal %{Location}o
in Dein LogFormat fürs AccessLog auf. Dann siehst Du, wohin der Apache
den Client redirecten möchte. Das gibt uns evtl. eine Idee.
Dann würde ich auch den User-Agent loggen, damit wir checken können, ob
das redirect-carefully überhaupt den User-Agent "Microsoft Data Access
Internet Publishing Provider" etc. matcht. Hierzu in das LogFormat noch
aufnehmen: \"%{User-Agent}i\".
Dann poste doch nochmal die so erweiterten Access-Log-Zeilen.
Gibt der Client eigentlich noch eine Fehlermeldung aus?
Dann kannst Du noch den LogLevel auf debug setzen, evtl. ist dann im
ErrorLog noch eine Erkenntnis zu gewinnen. Ich weiß leider nicht, ob
mod_dav ein vernünftiges debug-Log schreibt.
Grüße
Rainer
--
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an users-de-unsubscr...@httpd.apache.org
sonstige Anfragen an users-de-h...@httpd.apache.org
--
Re: seltsamer Redirect bei WebDAV
On 02.01.2012 12:47, Michael Renner wrote: On 02.01.2012 11:35, Reindl Harald wrote: Am 02.01.2012 11:13, schrieb Michael Renner: Moin, Als ServerName ist in der httpd.conf ServerName https://webdav.domain.tld:443 gesetzt. Hilft nix :-( Weil das Unsinn ist und kein Servername laut http://httpd.apache.org/docs/2.2/mod/core.html#servername aber zulässig. Schema und Port können in der Direktive verwendet werden. Weiter steht dort: The ServerName directive sets the request scheme, hostname and port that the server uses to identify itself. This is used when creating redirection URLs. Beim Start moppert das error_log dass [warn] Init: (webdav.domain.tld:443) You configured HTTP(80) on the standard HTTPS(443) port! Aber nachdem ich ein wenig mit Servernamen spielte (auch Einträge auf ganz andere Servernamen) geht es nun plötzlich. Der Redirect erfolgt auf https mit abschliessendem Slash. Die Warnung ist nur eine Warnung. Wenn es noch mehr negative Seiteneffekte gibt, würde ich evtl. den Port 443 aus dem ServerName nehmen. Solange kein expliziter Port da steht, sollte der Apache beim Redirect auch keinen reinnehmen. Wenn der RP aber auf einen nicht-standard Port (!=80, 443) horcht, dann brauchst Du den 443 - oder Du spielst mit UseCanonicalName und ggf. mit UserCanonicalPhysicalPort auf dem RP. Am ehesten sollte wohl UseCanonicalName On passen (das ist nicht der Default). Gruß Rainer -- Apache HTTP Server Mailing List "users-de" unsubscribe-Anfragen an users-de-unsubscr...@httpd.apache.org sonstige Anfragen an users-de-h...@httpd.apache.org --
Re: seltsamer Redirect bei WebDAV
Hi Michael, On 02.01.2012 11:35, Reindl Harald wrote: Am 02.01.2012 11:13, schrieb Michael Renner: Klar, da fehlte etwas. Jetzt findet die passende Umsetzung von /renner auf renner/ statt. Doch leider geht dabei das https verloren. Aus den Headern vom Aufruf: Klar, siehe unten Als ServerName ist in der httpd.conf ServerName https://webdav.domain.tld:443 gesetzt. Hilft nix :-( Weil das Unsinn ist und kein Servername Na ja, laut Doku und Code geht das bei 2.2.21 schon, auch wenn ich das bis gerade eben auch nicht wusste. Und interessanterweise setzt es auch intern genau das Scheme-Feld am (virtuellen) Server, welches beim Redirect-Ausführen zum absolut machen der URL verwendet wird. Michael: Du solltest aber checken, ob Du diesen ServerName auch in dem VHost gesetzt hast, der den Request abbekommt. Außerdem bin ich nicht sicher, ob Du Dir durch diesen Hack unangenehme Seiteneffekte reinholst. Der Trailing-Slash-Redirect, den Du siehst, kommt vom mod_dir im RP, d.h. schon bevor mod_proxy zuschlägt. Wenn es nicht gelingt den Trailing-Slash-Redirect zu fixen, etwa so wie Du das schon versucht hast, kannst Du ihn auch alternativ mit "DirectorySlash Off" (evtl. im VHost) auf dem RP abstellen. Dann geht der Request zunächst zum WebDAV-Apache durch, und dort passiert ggf. der gleiche Trailing-Slash-redirect (je nach Konfig). Auf dem Web zurück kommt dann zwar ProxyPassReverse zum tragen, aber erneut muss dort aus einer lokalen URI eine volle URL gemacht werden. Ohne Trick kommt da eben wieder eine http-URL raus, weil der RP nix von https weiß. An sich sollte aber Dein ServerName-Trick klappen. Es kann halt nur sein, dass er andere negative Seiteneffekte hat. Die Crux ist, dass der Apache von SSL nichts weiss, da die SSL-Terminierung schon vorher in einem Stück Blech stattfindet, nicht am Apache selbst. Tja und an dieser kranken Config liegt das Problem Der Apache soll Proxy spielen und weiss selber nicht dass er https ist - Was soll er dann machen wenn davor schon was Proxy spielt du eine nicht existente URL eingibst, er so freundlich ist und einen Redirect macht der nun mal RFC-Konform FQ stattzufinden hat Das muss das Blech davor ausbügeln weil es die einzige Instanz ist die weiss dass sei selber Proxy spielt, der Apache danach kann dafür nichts Stimmt, besser wäre der SSL-Endpunkt korrigiert diese Probleme. Vermutlich leichter zu machen, besser zu verstehen und weniger fehleranfällig. Gruß Rainer -- Apache HTTP Server Mailing List "users-de" unsubscribe-Anfragen an users-de-unsubscr...@httpd.apache.org sonstige Anfragen an users-de-h...@httpd.apache.org --
Re: Apache 2, TLS-Debakel
On 29.09.2011 16:37, Reindl Harald wrote: > > > Am 29.09.2011 16:31, schrieb Rainer Sokoll: >> Hallo, >> >> rein interessehalber: Wie geht ihr damit um? Ich meine jetzt >> nicht Comodo, Diginotar, sondern das hier: >> http://www.heise.de/newsticker/meldung/Tool-soll-SSL-Cookies-in-zehn-Minuten-knacken-1346257.html >> >> Ich habe mir jetzt mal den letzten Snapshot von openssl-1.0.1-dev >> übersetzt mit enable-tlsext, weiß aber nicht so recht, wie ich >> nun weitermachen sollte. Ich möchte mal testen, ob ich auf meinem >> Apachen TLS 1.1 erzwingen kann, weiß aber nicht wie. >> Möglicherweise ist openssl ja auch der steinige Weg, und ich >> sollte GNUTLS verwenden? >> >> Wie geht ihr damit um? Ignorieren? > > Die Devel-Mailingliste abbonieren und warten was Upstream passiert > Da ist erst vor wenigen Minuten was zum Thema gekommen Das war dann wohl ich ... Soweit ich sehe gibt es noch keine richtig gute Lösung. Was leicht und robust geht, ist dem Client eine Cipher zu empfehlen, die gegen die Attacke nicht anfällig ist, also kein CBC verwendet. Beispiel: SSLCipherSuite RC4-SHA:AES128-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL SSLHonorCipherOrder on Die zweite Direktive sagt dem Client er soll eine Cipher wählen, die in der ersten Liste möglichst weit vorne steht. Unterstützt der Client dieses Feature (ist wohl Standard bei SSLv3 und TLSv1 und z.B.in OpenSSL seit 0.9.7 drin) und kann er RC4-SHA, dann wählt er die Cipher RC4, welche wohl kein CBC verwendet, also nicht anfällig ist. Die nächste Cipher, AES128-SHA ist übrigens eine CBC Cipher, also anfällig. Damit wird zwar nicht immer erzwungen, dass Clients nur noch sicher kommunizieren, die meisten Clients sollten aber das Verfahren unterstützen und damit - nach dem was wir aktuell wissen - sicher kommunizieren. Grüße von Rainer zu Rainer sendet Rainer -- Apache HTTP Server Mailing List "users-de" unsubscribe-Anfragen an users-de-unsubscr...@httpd.apache.org sonstige Anfragen an users-de-h...@httpd.apache.org --
Re: Solaris prefork und threaded Apache in einem PKG
On 14.09.2011 14:55, Martin Allert wrote: > Die einzigen Zusatzmodule, die ich verwende, sind PHP4, mod_jk 1.2.32 und > libmod_auth_josso. Beim mod_jk bin ich mir recht sicher, dass das geht. Bei > PHP und Josso muss ich nachlesen. Danke für den Tipp! Für mod_jk kann ich das bestätigen. In alten Versionen versuchten wir den Bedarf and Locking automatisch zu erkennen, aber seit einigen ungeklärten Problemen unter AIX machen wir immer Locking (Thread-Safety für Worker) und man muss beim configure explizit sagen, wenn man sich sicher ist, dass man das Modul nur bei prefork einsetzen will, also kein Locking braucht. Viel Erfolg! Rainer -- Apache HTTP Server Mailing List "users-de" unsubscribe-Anfragen an users-de-unsubscr...@httpd.apache.org sonstige Anfragen an users-de-h...@httpd.apache.org --
Re: Solaris prefork und threaded Apache in einem PKG
On 14.09.2011 13:18, Martin Allert wrote: > Hallo, > > Ich habe eine Frage bezüglich Solaris Packaging mit dem Apache 2.2.21. Ist es > möglich, einen prefork _UND_ einen worker Apache in ein PKG mit einem > Zielverzeichnis zu giessen? > > Die ersten zwei Test-Compileergebnisse, die ich gestartet habe und deren > prefix unterschiedlich waren, unterscheiden sich im wesentlichen in den > include Files (die werden aber nur beim Modul compilieren benötigt, daher > fliegen sie beim PKG raus) und in der httpd.exp im modules Ordner. > > Kann ich also folgendes tun: > - compile und make install des prefork apache nach /opt/apache-2.2.21 > - mv httpd httpd.prefork > - compile und make install des worker apache nach /opt/apache-2.2.21 > - mv httpd httpd.worker > > Und dann dieses in ein PKG nach Anpassung der apachectl einpacken? Habe ich > massive Schwierigkeiten zu erwarten, wenn ich dieses PKG ausrolle? > Hintergrund ist, dass ich auf einem Server sowohl einen Webserver als auch > einen RV Proxy fahren muss und zwei PKG nicht maintainen will. :) Im Prinzip geht das. Es gibt noch kleinere weitere Unterschiede (mod_cgi vs. mod_cgid fällt mir ein), aber nicht viel mehr. Aber: 1) Das ist keine zugesicherte Eigenschaft, d.h. eigentlich müsste man das entweder jedes Mal kontrollieren, oder zumindest das Changelog aufmerksam checken. An sich sollten Module stets zur Laufzeit abfragen, ob z.B. das MPM multi-threaded ist, aber es könnten Entwickler auch Macro-Tricks machen. Zur Zeit ist dies bei 2.2 nicht so. 2) Bei Apache 2.3 wurde das korrekt aufgeräumt. Dort gibt esnur noch einen Build und auch die MPMs werden als ladbare Module kompiliert, d.h. man kann einen make-Lauf machen und bekommt z.B. ein httpd-Binary und dazu prefork, worker und event als Modulfiles heraus. Das hilft aber nicht für 2.2. 2.3 ist im Beta-Status. Gruß Rainer -- Apache HTTP Server Mailing List "users-de" unsubscribe-Anfragen an users-de-unsubscr...@httpd.apache.org sonstige Anfragen an users-de-h...@httpd.apache.org --
