(internal dummy connection) und php-zugriffe

[schmidtedv]

Ich verzweifel gerade mit dem ominösen access.log und der berühmten Meldung:

::1 - - [04/Aug/2008:13:56:03 +0200] "GET / HTTP/1.0" 302 296 "-" "Apache (internal dummy connection)"

Ich dachte ::1 deutet auf IP6 hin, was ich aber eigentlich laut syslog gar nicht nutze...

Die Dummy-Meldung erschient aber sowohl mit als auch ohne den Eintrag in der hosts (jeweils mit reboot getestet):

::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Ich habe einiges hierzu schon herausbekommen:

1) Dieses log erscheint wohl nur bei Zugriffen mit PHP (oder mysql?), also wenn ich z.B. das phpBB-Forum nutze, und nicht, wenn ich eine normale HTML-Seite aufrufe.

2) Im access.log erscheint dann auch NUR die Dummy-Meldung und sonst nichts, wohingegen die ispconfig_access_log alles normal loggt, wie es sich gehört.

3) Ich habe den Apache mal nur "Apache" auswerfen lassen, damit ich:

SetEnvIf User-Agent "Apache (internal dummy connection)" dontlog
CustomLog /var/log/apache2/access.log combined env=!dontlog

eingeben kann.

Nach /etc/init.d/apache2 restart erhalte ich dann mal netterweise (nach erneutem Foren-Zugriff) im access.log normale Meldungen wie:

80.133.49.50 - - [04/Aug/2008:13:57:38 +0200] "GET /templates/ca_aphrodite/images/folder.gif HTTP/1.1" 304 - "http://forum.schmidtedv.de/index.php?sid=70f8092aa02eaa02202873bc08f24faa" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; InfoPath.1)"
80.133.49.50 - - [04/Aug/2008:13:57:38 +0200] "GET /templates/ca_aphrodite/pseudo-hover.htc HTTP/1.1" 304 - "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; InfoPath.1)"

Vor der env=!dontlog waren solche Einträge gar nicht da drin (uiuiui).

Dennoch kriege ich bei forenzugriff AUCH erneute dummy-Meldungen.

Habe ich mich hier das System wie und wodurch auch immer total zerbröselt? Ich bin etwas verzweifelt und kurz davor neu anzufangen.

Was mir dazu einfällt wäre höchstens noch, das das forum auf einer subdomain läuft, die ich mittels forum.domain.de anspreche und hierfür nach anleitung von huschi.net das [R] aus der ISPConfig-Lib entfernt habe...aber das wäre wohl etwas weit hergeholt hier den Fehler zu suchen, oder?

 

[Till]

Das ist nichts worüber Du Dir Sorgen machen solltest, das ist absolut normal.

Zitat:

These requests are perfectly normal and you do not, in general, need to worry about them. They can simply be ignored.

http://wiki.apache.org/httpd/InternalDummyConnection

 

[schmidtedv]

Naja, da ich ja nur mit 256MB hantiere, dachte ich ich müßte mal versuchen, es einzukreisen.

Fakt ist, es entsteht mit Zugriff auf das Forum (Ich nehme an bei 16 Querries im Schnitt pro Seite macht hier der Apache schlapp). Um das zu testen habe ich das komplette System nochmals über Nacht aufgesetzt. Bis auf TeamSpeak (im Leerlauf) ohne Schnickschnack (munin, etc.) macht ein 733er mit 256MB halt nicht viel her mit so einem, zugegeben, klein wenig aufgemotzten Forum wie es scheint?

Entweder es hat (nach Neuinstallation wieder auf dem Standardwert) mit der apache2.conf zu tun (da scheinen kleinere Werte aber den gleichen Effekt zu haben):

<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>

Oder ich müßte MySQL und PHP irgendwie ein wenig den Hahn zudrehen.

Ich werde mal auf jeden Fall ProFTPd abschalten, da ich FTP ja eh selten brauche und alles über SSH geht, wenn es sein muss.

 

[schmidtedv]

Eine Frage zu PHP-Modulen (finde nix gescheites im Web). Ich müchte mich mal auf ein phpBB beschränken. Die geladenen Module sind wie folgt:

curl.ini
eaccelerator.ini
gd.ini
imagick.ini
imap.ini
json.ini
mcrypt.ini
memcache.ini
mhash.ini
mysql.ini
mysqli.ini
pdo.ini
pdo_mysql.ini
pdo_sqlite.ini
ps.ini
pspell.ini
recode.ini
snmp.ini
sqlite.ini
tidy.ini
xmlrpc.ini
xsl.ini

Zuzüglich die Einkompilierten des Debian Etch HowTo's.

Ich hätte gerne drin:

curl.ini
eaccelerator.ini
gd.ini
imagick.ini
mcrypt.ini
mhash.ini
mysql.ini
sqlite.ini

...wofür ist der Rest und brauche ich den...macht der was schneller (memcache nehme ich an tut das) oder ist der für spezielle dinge, die ich im phpBB nicht brauche (json, die pdo's....etc.)

 

[Till]

Du kannst die anderen Module alle entfernen, wenn Du sie nicht brauscht. Die Beschreibunden zu den einzelnen Modulen findest Du auf php.net.

 

[schmidtedv]

Du kannst die anderen Module alle entfernen, wenn Du sie nicht brauscht. Die Beschreibunden zu den einzelnen Modulen findest Du auf php.net.

Hm, ich hatte das so verstanden das ich in der jeweiligen ini unter /conf.d einfach die Zeile mit ; auskommentiere und dann ein /etc/init.d/apache2 restart abschicke. Wenn ich dann phpinfo.php aufrufe, sind aber z.B. json und die anderen noch aktiviert/enabled ???

 

[Till]

Am einfachsten machst Du ein neues Verzeichnis und verschiebst alle Dateien von conf.d da hinein, die du nicht brauchst.

 

[schmidtedv]

...klappt nun doch, json kann ich zwar auskommentieren, bleibt aber dennoch enabled, daher die Verwirrung, die anderen gehn und es läuft definitiv sehr viel flüssiger.


Nochmal zur Dummy-Meldung:

::1 - - [05/Aug/2008:09:52:59 +0200] "GET / HTTP/1.0" 302 302 "-" "Apache/2.2.3 (internal dummy connection)"

Kann ich die nicht an bestimmter Stelle zumindest dazu bringen, das sie nicht im access.log aufgezeichnet wird? Das ist unnötiger Balast. Mittels

SetEnvIf User-Agent "Apache/2.2.3 (internal dummy connection)" dontlog
CustomLog /var/log/apache2/access.log combined env=!dontlog

in der 000-default und als Ersatz für die zeile

CustomLog /var/log/apache2/access.log combined

geht's nicht. Setz ich das flasche in oder muß ich ein anderes SetEnvIf nehmen was eher an der Stelle ::1 ansetzt?

 

[Till]

Also, dies Lst für dieses Logging ist so minimal, dass Du es nicht festellen können wirst. Wenn Du Dir Sorgen um so ein paar Log Zeilen machst, dann würde ich Dir raten Dir lieber für ein paar Euro einen virtual Server oder nenen dedicated Server bei einem Hoster zu holen.

 

[schmidtedv]

da staunt der Laie....da lacht der Profi. Sorgen mache ich mir da keine, aber wenn im access.log nur noch der Dummy steht und sonst nix mehr, ist das ganze Log ein wenig sinnlos. Der Dummy-Eintrag über ::1 blockt ja scheinbar alle anderen Einträge. Oder greift hier ISPConfig alles ab, was normalerweise im access.log drin stehen würde?

 

[Till]

Das access log ist für ISPConfig nicht von Interesse, da ispconfig sowieso selbst ein custm log anlegt.

Wie gesagt, in dem Link den ich Dir oben gepostst habe, ist ads alles erläutert:

When the Apache HTTP Server manages its child processes, it needs a way to wake up processes that are listening for new connections. To do this, it sends a simple HTTP request back to itself. This request will appear in the access_log file with the remote address set to the loop-back interface (typically 127.0.0.1 or ::1 if IPv6 is configured). If you log the User-Agent string (as in the combined log format), you will see the server signature followed by "(internal dummy connection)" on non-SSL servers. During certain periods you may see up to one such request for each httpd child process.
These requests are perfectly normal and you do not, in general, need to worry about them. They can simply be ignored.

 

[schmidtedv]

Kenne ich ja...war ja mehrere Stunden unterwegs im Web bevor ich's hier mal angesprochen habe.

Ist aber auch egal und nicht weiter schlimm, ich werd's halt mal länger beobachten.

Es kommt mir halt nur etwas komisch vor, dass, wenn der Log erstmal mit Dummy-Meldungen anfängt, keinerlei "normale" Einträge mehr erscheinen und das kann ich so halt aus dem Link und den anderen Quellen nicht heraushören.

Trotzdem Danke


Wenn bei mir nun ::1 und nicht 127.0.0.1 steht, was setz ich denn dann statt SetEnvIf Remote_Addr "127\.0\.0\.1" loopback ein? Das gleiche, weil ::1 eh 127.0.0.1 ist?

 

[Till]

Meines Wissens nach ist ::1 die IPv6 Schreibweise von 127.0.0.1, somit ist es das Gleiche. Du kannst aber mal:

SetEnvIf Remote_Addr "::1" loopback

versuchen.

 

[schmidtedv]

Ja, danke...learning by doing. 127.0.0.1 geht nicht, aber ::1 bringt den gewünschten Erfolg, auch wenn mein access.log nun halt immer leer ist.