From announcements at tlug.de Sun May 2 06:00:02 2010 From: announcements at tlug.de (announcements at tlug.de) Date: Sun, 2 May 2010 06:00:02 +0200 (CEST) Subject: TLUG Termin: 2010-05-05 19:00:00 in Ichtershausen (EF und IK) Message-ID: <20100502040002.79EBA59D58@tlug.de> Naechster Termin der Thueringer Linux User Group: * 2010-05-05 19:00:00: Stammtisch in Ichtershausen (EF und IK) Viel Spass dabei! -- - automatically generated, do NOT reply - From foren at privat.kaemer.de Mon May 3 00:11:14 2010 From: foren at privat.kaemer.de (foren at privat.kaemer.de) Date: Mon, 03 May 2010 00:11:14 +0200 Subject: TLUG Termin: 2010-05-05 19:00:00 in Ichtershausen (EF und IK) Message-ID: Hi All, Mitfahrer von EF aus gesucht ;-). Gruß Thomas Am 02.05.2010 um 06:00 Uhr haben Sie geschrieben: > Naechster Termin der Thueringer Linux User Group: > > * 2010-05-05 19:00:00: Stammtisch in Ichtershausen (EF und IK) From announcements at tlug.de Mon May 3 06:00:02 2010 From: announcements at tlug.de (announcements at tlug.de) Date: Mon, 3 May 2010 06:00:02 +0200 (CEST) Subject: TLUG Termin: 2010-05-06 19:00:00 in Jena Message-ID: <20100503040002.A7F2359D49@tlug.de> Naechste Termine der Thueringer Linux User Group: * 2010-05-06 19:00:00: Stammtisch in Jena * 2010-05-06 19:00:00: Vortrag eXtreme Programming in Jena Viel Spass dabei! -- - automatically generated, do NOT reply - From foren at privat.kaemer.de Tue May 4 22:19:49 2010 From: foren at privat.kaemer.de (=?ISO-8859-1?Q?Thomas_K=E4mer?=) Date: Tue, 04 May 2010 22:19:49 +0200 Subject: TLUG Termin: 2010-05-06 19:00:00 in Jena In-Reply-To: <20100503040002.A7F2359D49@tlug.de> References: <20100503040002.A7F2359D49@tlug.de> Message-ID: <4BE08165.3080401@privat.kaemer.de> On 03.05.2010 06:00, announcements at tlug.de wrote: > > * 2010-05-06 19:00:00: Stammtisch in Jena > * 2010-05-06 19:00:00: Vortrag eXtreme Programming in Jena Braucht jemand ein "Taxi" nach J? Fahre allerdings nicht zurück. Gruß Thomas From weigelt at metux.de Fri May 14 10:29:42 2010 From: weigelt at metux.de (Enrico Weigelt) Date: Fri, 14 May 2010 10:29:42 +0200 Subject: 2 Instanzen von Apache - geht das, wenn ja - wie? In-Reply-To: <4B21514A.9060801@gmx.de> References: <4B1D3EB8.5020607@gmx.de> <4B1D45A5.7050300@rob-schulze.de> <4B1D5692.80100@gmx.de> <4B1FE479.2050908@rob-schulze.de> <4B1FFC76.1050009@gmx.de> <4B21278C.9050703@rob-schulze.de> <20091210172506.GB16827@nibiru.local> <4B21514A.9060801@gmx.de> Message-ID: <20100514082937.GA25585@nibiru.local> * Hans-Dietrich Kirmse schrieb: > Ich bin kein PHP-Fan. Aber warum ist safe_mode eine Krücke? > so ist es einfach nur eine (abfällige) Meinung. Aber ich hätte gern > Argumente. Weil damit das Problem nicht sauber gelöst wird. a) _alle_ extensions müssen ihn entsprechend berücksichtigen (sonst wird er schnell wirkungslos) b) wichtige features, zB. exec() gehen nicht mehr. Besser: jeden User unter seiner eigenen UID laufen lassen und alles weitere via FS-permissions regeln (wer ganz paranoid ist, kann ja gern auch noch chroot() oder container hinzunehmen). cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- From weigelt at metux.de Fri May 14 10:45:50 2010 From: weigelt at metux.de (Enrico Weigelt) Date: Fri, 14 May 2010 10:45:50 +0200 Subject: 2 Instanzen von Apache - geht das, wenn ja - wie? In-Reply-To: <4B21516A.1020305@gmx.de> References: <4B1D3EB8.5020607@gmx.de> <4B1D45A5.7050300@rob-schulze.de> <4B1D5692.80100@gmx.de> <4B1FE479.2050908@rob-schulze.de> <4B1FFC76.1050009@gmx.de> <20091210172310.GA16827@nibiru.local> <4B21516A.1020305@gmx.de> Message-ID: <20100514084534.GB25585@nibiru.local> * Hans-Dietrich Kirmse schrieb: > wie ich schon in der mail von 09.12.2009 20:33 geschrieben habe, > braucht der lighttpd mit fastcgi mehr als doppelt soviel Ram > wie eine Instanz des Apache. Wie genau hast Du das gemessen ? Wie genau sah die Last aus ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- From hd.kirmse at gmx.de Fri May 14 22:08:56 2010 From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse) Date: Fri, 14 May 2010 22:08:56 +0200 Subject: 2 Instanzen von Apache - geht das, wenn ja - wie? In-Reply-To: <20100514082937.GA25585@nibiru.local> References: <4B1D3EB8.5020607@gmx.de> <4B1D45A5.7050300@rob-schulze.de> <4B1D5692.80100@gmx.de> <4B1FE479.2050908@rob-schulze.de> <4B1FFC76.1050009@gmx.de> <4B21278C.9050703@rob-schulze.de> <20091210172506.GB16827@nibiru.local> <4B21514A.9060801@gmx.de> <20100514082937.GA25585@nibiru.local> Message-ID: <4BEDADD8.7080808@gmx.de> Hallo Enrico, auch wenn der Thread nun doch schon sehr lange her ist, trotzdem ersteinmal recht herzlichen Dank für deine Antwort. Nur habe ich mit beiden Antworten so meine Probleme. Enrico Weigelt schrieb: > * Hans-Dietrich Kirmse schrieb: > >> Ich bin kein PHP-Fan. Aber warum ist safe_mode eine Krücke? >> so ist es einfach nur eine (abfällige) Meinung. Aber ich hätte gern >> Argumente. > > Weil damit das Problem nicht sauber gelöst wird. das es nicht sauber gelöst ist, das leuchtet mir schon ein, weil in der PHP-FAQ angegeben ist, dass die Lösung unsicher ist, also (irgendwie?) ausgehebelt werden kann. Allerdings sehe ich noch keinen Ansatz dafür. > a) _alle_ extensions müssen ihn entsprechend berücksichtigen > (sonst wird er schnell wirkungslos) verstehe ich nicht. nehmen wir an, es kommen 5 solcher Extensions zum Tragen. Es ist doch letztlich völlig egal, an welcher Stelle diese Extension (safe-mode) zur Wirkung kommt egal ob an 1. 2. ... 5. Stelle. Wenn die Datei nicht unter der UID des Nutzers ist, dann wird diese PHP-Datei nicht mehr ausgeführt - sprich abgebrochen. Gerade bei dieser Sache verstehe ich nicht, wie das berücksichtigt werden muss. > b) wichtige features, zB. exec() gehen nicht mehr. wieso nicht? safe-mode heißt doch (so wie ich das verstanden habe), dass nur Dateien gelesen bzw. bearbeitet werden können, die den gleichen Owner haben, wie die PHP-Datei, die gerade ausgeführt wird. Wieso kann dann ein Script per exec() nicht ausgeführt werden, wenn es als Owner eben den User hat, der auch der Owner der PHP-Datei ist und das per exec aufzurufende Script z.B. für alle ausführbar ist. Warum soll das nicht gehen? Es würde der Philosophie von safe-mode komplett entsprechen! Aber wie schon geschrieben, habe mich seit Jahren nicht mehr mit PHP beschäftigt. (meine Sympathie gilt uneingeschränkt Perl) Mit freundlichen Grüßen Hans-Dietrich From hd.kirmse at gmx.de Fri May 14 22:17:02 2010 From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse) Date: Fri, 14 May 2010 22:17:02 +0200 Subject: 2 Instanzen von Apache - geht das, wenn ja - wie? In-Reply-To: <20100514084534.GB25585@nibiru.local> References: <4B1D3EB8.5020607@gmx.de> <4B1D45A5.7050300@rob-schulze.de> <4B1D5692.80100@gmx.de> <4B1FE479.2050908@rob-schulze.de> <4B1FFC76.1050009@gmx.de> <20091210172310.GA16827@nibiru.local> <4B21516A.1020305@gmx.de> <20100514084534.GB25585@nibiru.local> Message-ID: <4BEDAFBE.7070306@gmx.de> Enrico Weigelt schrieb: > * Hans-Dietrich Kirmse schrieb: > >> wie ich schon in der mail von 09.12.2009 20:33 geschrieben habe, >> braucht der lighttpd mit fastcgi mehr als doppelt soviel Ram >> wie eine Instanz des Apache. > > Wie genau hast Du das gemessen ? mit "top". Ist sicherlich recht ungenau, aber bei mehreren Wiederholungen waren die Ergebnisse sehr stabil. > Wie genau sah die Last aus ? gar keine Last. Das entsprach auch dem, was uns interessierte, denn der 2. Webserver läuft ja praktisch immer im Leerlauf (er soll ja nur zur Administration dienen). Und es ging gerade darum, wieviel Ram wird dafür eben gebraucht bzw. wieviel steht für den normalen Betrieb nicht zur Verfügung. Mit freundlichen Grüßen Hans-Dietrich From announcements at tlug.de Mon May 17 06:00:02 2010 From: announcements at tlug.de (announcements at tlug.de) Date: Mon, 17 May 2010 06:00:02 +0200 (CEST) Subject: TLUG Termin: 2010-05-20 19:00:00 in Jena Message-ID: <20100517040002.CF53959E40@tlug.de> Naechster Termin der Thueringer Linux User Group: * 2010-05-20 19:00:00: Stammtisch in Jena Viel Spass dabei! -- - automatically generated, do NOT reply - From lugjena at kubieziel.de Mon May 17 11:00:47 2010 From: lugjena at kubieziel.de (Jens Kubieziel) Date: Mon, 17 May 2010 11:00:47 +0200 Subject: TLUG Termin: 2010-05-20 19:00:00 in Jena In-Reply-To: <20100517040002.CF53959E40@tlug.de> References: <20100517040002.CF53959E40@tlug.de> Message-ID: <20100517090047.GA11883@kubieziel.de> * announcements at tlug.de schrieb am 2010-05-17 um 06:00 Uhr: > Naechster Termin der Thueringer Linux User Group: > * 2010-05-20 19:00:00: Stammtisch in Jena Vor dem eigentlichen Stammtisch gibt es den zweiten Teil es Vortrages zu Extreme Programming. siehe http://lug-jena.de/ Besten Gruß -- Jens Kubieziel http://www.kubieziel.de FdI#373: C-Programme C-Programme sehen aus, als hätte jemand ein Gürteltier über die Tastatur gewälzt. (Wolfgang Lorenz) -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-signature Dateigröße : 827 bytes Beschreibung: Digital signature URL : http://www.tlug.de/pipermail/tlug_allgemein/attachments/20100517/7dd50bcf/attachment.pgp From Schwirz.Linux-AG at freenet.de Tue May 18 09:46:28 2010 From: Schwirz.Linux-AG at freenet.de (Norman) Date: Tue, 18 May 2010 09:46:28 +0200 Subject: Mfg. zum Linux-Tag in Berlin im Juni gesucht Message-ID: <4BF245D4.4080705@freenet.de> Hallo allerseits, wer von Euch fährt zum Berliner Linux Tag (9.-12.6.2010)? Norman Linux Tag Berlin: http://www.linuxtag.org/2010/ From weigelt at metux.de Wed May 26 15:35:10 2010 From: weigelt at metux.de (Enrico Weigelt) Date: Wed, 26 May 2010 15:35:10 +0200 Subject: 2 Instanzen von Apache - geht das, wenn ja - wie? In-Reply-To: <4BEDADD8.7080808@gmx.de> References: <4B1D3EB8.5020607@gmx.de> <4B1D45A5.7050300@rob-schulze.de> <4B1D5692.80100@gmx.de> <4B1FE479.2050908@rob-schulze.de> <4B1FFC76.1050009@gmx.de> <4B21278C.9050703@rob-schulze.de> <20091210172506.GB16827@nibiru.local> <4B21514A.9060801@gmx.de> <20100514082937.GA25585@nibiru.local> <4BEDADD8.7080808@gmx.de> Message-ID: <20100526133510.GB6862@nibiru.local> * Hans-Dietrich Kirmse schrieb: moin, > das es nicht sauber gelöst ist, das leuchtet mir schon ein, weil in der > PHP-FAQ angegeben ist, dass die Lösung unsicher ist, also (irgendwie?) > ausgehebelt werden kann. Allerdings sehe ich noch keinen Ansatz dafür. Mit safe_mode muß _jede_ einzelne API-Routine - einschließlich _aller_ extensions separat auf potentielle Ausbruchsmöglichkeiten überprüft und ggf. speziell angepaßt werden. Der klassische Unix-Ansatz hingegen ist, jeden User unter seiner eigenen UID laufen zu lassen (dh. auch entsprechend strikt getrennte Prozesse) und alles über die Filesystem-Permissions (und ggf. auch capabilities) zu lösen. > >a) _alle_ extensions müssen ihn entsprechend berücksichtigen > > (sonst wird er schnell wirkungslos) > > verstehe ich nicht. nehmen wir an, es kommen 5 solcher Extensions zum > Tragen. Es ist doch letztlich völlig egal, an welcher Stelle diese > Extension (safe-mode) zur Wirkung kommt egal ob an 1. 2. ... 5. Stelle. Nein. Jede einzelne extension-Routine, die ggf. auf abzuschirmende Resourcen (Filesystem, Prozesse, etc, etc) zugreift, muß entsprechend angepaßt werden. Außerdem lassen sich dann auch eventuelle local- exploits innerhalb einer extension, die bei separaten UIDs/Prozessen nur den angreifenden User selbst betreffen könnten, dann gleich auch alle anderen User angreifen. Im Massenhosting damit völlig unbrauchbar. > Wenn die Datei nicht unter der UID des Nutzers ist, dann wird diese > PHP-Datei nicht mehr ausgeführt - sprich abgebrochen. Gerade bei dieser > Sache verstehe ich nicht, wie das berücksichtigt werden muss. Dieses "Feature" ist ziemlich sinnlos. Es schützt allenfalls vor dem spezifischen Fall, daß es einem angreifenden User gelingt, scripte in fremden User-Verzeichnissen einzuschleusen. Gegen Manipulation von data files (die nicht als script ausgeführt werden) oder bereits existierenden Scripts hilft das nicht. > >b) wichtige features, zB. exec() gehen nicht mehr. > > wieso nicht? safe-mode heißt doch (so wie ich das verstanden habe), dass > nur Dateien gelesen bzw. bearbeitet werden können, die den gleichen > Owner haben, wie die PHP-Datei, die gerade ausgeführt wird. Wieso kann > dann ein Script per exec() nicht ausgeführt werden, wenn es als Owner > eben den User hat, der auch der Owner der PHP-Datei ist und das per exec > aufzurufende Script z.B. für alle ausführbar ist. exec() dient dazu, _beliebige_ (idR. binäre) Programme auszuführen, und zwar als eigenständige Prozesse - nicht innerhalb des PHP-Interpreters. In dem Falle kann dann der safe_mode (innerhalb des sub-Prozesses) nicht mehr greifen. Ergo: entweder man verbietet exec() komplett, oder der safe_mode ist wirkungslos. Die einzig sinnvolle Lösung ist, alles über separate Prozesse unter eigenen UIDs abzubilden und alles weitere wie gewohnt den Kernel erledigen zu lassen (dafür ist er ja schließlich da). An der Stelle kann man dann auch noch feiner granuliertere Abschirmungen via Containers machen (zB. um fremde Prozesse unsichtbar zu machen, Netzwerkverkehr regeln, etc, etc) cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- From hd.kirmse at gmx.de Wed May 26 19:56:21 2010 From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse) Date: Wed, 26 May 2010 19:56:21 +0200 Subject: 2 Instanzen von Apache - geht das, wenn ja - wie? In-Reply-To: <20100526133510.GB6862@nibiru.local> References: <4B1D3EB8.5020607@gmx.de> <4B1D45A5.7050300@rob-schulze.de> <4B1D5692.80100@gmx.de> <4B1FE479.2050908@rob-schulze.de> <4B1FFC76.1050009@gmx.de> <4B21278C.9050703@rob-schulze.de> <20091210172506.GB16827@nibiru.local> <4B21514A.9060801@gmx.de> <20100514082937.GA25585@nibiru.local> <4BEDADD8.7080808@gmx.de> <20100526133510.GB6862@nibiru.local> Message-ID: <4BFD60C5.9010608@gmx.de> Hallo Enrico, ersteinmal danke für deine Antwort. Allerdings muss ich zugeben, dass ich das nicht alles raffe (was aber für einen reinen Anwender auch nicht zwingend ist). Enrico Weigelt schrieb: > * Hans-Dietrich Kirmse schrieb: > > moin, > >> das es nicht sauber gelöst ist, das leuchtet mir schon ein, weil in der >> PHP-FAQ angegeben ist, dass die Lösung unsicher ist, also (irgendwie?) >> ausgehebelt werden kann. Allerdings sehe ich noch keinen Ansatz dafür. > > Mit safe_mode muß _jede_ einzelne API-Routine - einschließlich > _aller_ extensions separat auf potentielle Ausbruchsmöglichkeiten > überprüft und ggf. speziell angepaßt werden. das hattest du schonmal geschrieben. Allerdings ist das keine Begründung (schon gar keine verständliche Begründung), sondern nur die wiederholte Feststellung, was du m.E. schonmal zum Ausdruck gebracht hast. > Der klassische Unix-Ansatz hingegen ist, jeden User unter seiner > eigenen UID laufen zu lassen (dh. auch entsprechend strikt getrennte > Prozesse) und alles über die Filesystem-Permissions (und ggf. > auch capabilities) zu lösen. Das ist mir ja bekannt. Und mir ist auch klar, dass diese Lösung sicher ist. Aber es geht nicht um einen Webserver mit vielen Nutzern, der im Internet steht, sondern es geht "nur" um einen Schulserver, dabei um die public_html-Verzeichnisse - die übliche Nutzerzahl liegt um die 500. >>> a) _alle_ extensions müssen ihn entsprechend berücksichtigen >>> (sonst wird er schnell wirkungslos) >> verstehe ich nicht. nehmen wir an, es kommen 5 solcher Extensions zum >> Tragen. Es ist doch letztlich völlig egal, an welcher Stelle diese >> Extension (safe-mode) zur Wirkung kommt egal ob an 1. 2. ... 5. Stelle. > > Nein. Jede einzelne extension-Routine, die ggf. auf abzuschirmende > Resourcen (Filesystem, Prozesse, etc, etc) zugreift, muß entsprechend > angepaßt werden. Weshalb? > Außerdem lassen sich dann auch eventuelle local- > exploits innerhalb einer extension, die bei separaten UIDs/Prozessen > nur den angreifenden User selbst betreffen könnten, dann gleich auch > alle anderen User angreifen. > > Im Massenhosting damit völlig unbrauchbar. darum geht es *NICHT*. wie gesagt, es geht nur um einen Schulserver. Ich bilde mir ein, du warst am Albert-Schweitzer-Gymnasium in Erfurt. auch da haben doch die Schüler ein Homeverzeichnis mit PHP (also Modul im Apache). Und wenn ich richtig liege mit meiner Vermutung, sprich Spezi Erfurt, dass Angriffspotential ist doch deutlich größer als an einer normalen Schule. Trotzdem ist das meines Wissens auch an der Schule immer noch so. (da beißt sich was - oder?) >> Wenn die Datei nicht unter der UID des Nutzers ist, dann wird diese >> PHP-Datei nicht mehr ausgeführt - sprich abgebrochen. Gerade bei dieser >> Sache verstehe ich nicht, wie das berücksichtigt werden muss. > > Dieses "Feature" ist ziemlich sinnlos. Es schützt allenfalls vor > dem spezifischen Fall, daß es einem angreifenden User gelingt, > scripte in fremden User-Verzeichnissen einzuschleusen. Gegen > Manipulation von data files (die nicht als script ausgeführt > werden) oder bereits existierenden Scripts hilft das nicht. diese Antwort ist mir zu pauschal. natürlich ist der "safe-mode" allein kein Allheilmittel, aber den jetzt einfach als ziemlos nutzlos abzutun, ist mir viel zu schnell. Es gibt ja auch noch weitere Einstellungen für PHP, z.B. auf welche Verzeichnisse es zugreifen kann und wo es seine Bibliotheken her holen soll ... . Im Zusammenhang betrachtet bekommt man da m.E. schon eine hohe Sicherheit hin. >>> b) wichtige features, zB. exec() gehen nicht mehr. >> wieso nicht? safe-mode heißt doch (so wie ich das verstanden habe), dass >> nur Dateien gelesen bzw. bearbeitet werden können, die den gleichen >> Owner haben, wie die PHP-Datei, die gerade ausgeführt wird. Wieso kann >> dann ein Script per exec() nicht ausgeführt werden, wenn es als Owner >> eben den User hat, der auch der Owner der PHP-Datei ist und das per exec >> aufzurufende Script z.B. für alle ausführbar ist. > > exec() dient dazu, _beliebige_ (idR. binäre) Programme > auszuführen, und zwar als eigenständige Prozesse - nicht > innerhalb des PHP-Interpreters. In dem Falle kann dann der > safe_mode (innerhalb des sub-Prozesses) nicht mehr greifen. leuchtet mir nicht ein. der safe-mode gibt doch an, welche Prozesse ausgeführt werden können (mit exec). Insofern kann er mit exec dann eben nur auf seine (binären) Dateien zugreifen. das ist doch gut und macht doch durchaus Sinn! > Ergo: entweder man verbietet exec() komplett, oder der safe_mode > ist wirkungslos. für mich völlig unlogisch. :( > Die einzig sinnvolle Lösung ist, alles über separate Prozesse > unter eigenen UIDs abzubilden und alles weitere wie gewohnt den > Kernel erledigen zu lassen (dafür ist er ja schließlich da). > An der Stelle kann man dann auch noch feiner granuliertere > Abschirmungen via Containers machen (zB. um fremde Prozesse > unsichtbar zu machen, Netzwerkverkehr regeln, etc, etc) Das will ich alles nicht bestreiten. Mir geht es um die Schwachstellen des safe-modes. Dazu kam leider nichts Substanzielles - sorry. Genau das würde mich aber (immernoch) interessieren. Mit freundlichen Grüßen Hans-Dietrich From weigelt at metux.de Wed May 26 15:19:50 2010 From: weigelt at metux.de (Enrico Weigelt) Date: Wed, 26 May 2010 15:19:50 +0200 Subject: 2 Instanzen von Apache - geht das, wenn ja - wie? In-Reply-To: <4BEDAFBE.7070306@gmx.de> References: <4B1D3EB8.5020607@gmx.de> <4B1D45A5.7050300@rob-schulze.de> <4B1D5692.80100@gmx.de> <4B1FE479.2050908@rob-schulze.de> <4B1FFC76.1050009@gmx.de> <20091210172310.GA16827@nibiru.local> <4B21516A.1020305@gmx.de> <20100514084534.GB25585@nibiru.local> <4BEDAFBE.7070306@gmx.de> Message-ID: <20100526131946.GA6862@nibiru.local> * Hans-Dietrich Kirmse schrieb: > Enrico Weigelt schrieb: > >* Hans-Dietrich Kirmse schrieb: > > > >>wie ich schon in der mail von 09.12.2009 20:33 geschrieben habe, > >>braucht der lighttpd mit fastcgi mehr als doppelt soviel Ram > >>wie eine Instanz des Apache. > > > >Wie genau hast Du das gemessen ? > > mit "top". Ist sicherlich recht ungenau, aber bei mehreren > Wiederholungen waren die Ergebnisse sehr stabil. Sehr ungenau. Top zeigt leider jeweils nur die Allokation per Prozess (und gesamt) - allerdings sieht man damit nicht ohne weiteres Dinge wie zB. shared pages, geschweige denn die realen Zugriffsmuster (welche Pages müssen wie oft eingeswappt werden ? etc.) - das sind aber die entscheidenden Parameter für die Performance. > >Wie genau sah die Last aus ? > > gar keine Last. Das entsprach auch dem, was uns interessierte, denn der > 2. Webserver läuft ja praktisch immer im Leerlauf (er soll ja nur zur > Administration dienen). Und es ging gerade darum, wieviel Ram wird dafür > eben gebraucht bzw. wieviel steht für den normalen Betrieb nicht zur > Verfügung. lighttpd braucht im Leerlauf (mal abgesehen von unswappable kernel structures) fast nix. Es gibt zwar alle paar Sekunden ein paar wakeups im master-Prozess, aber da werden nur ein paar wenige Pages angefaßt. Beim Apachen gibts die Wakeups auch, aber da wird noch einges mehr getan, vorallem aber sind die Heap-Strukturen und der Codeflow _wesentlich_ komplexer, dh. viel mehr Pages müssen angefaßt werden und damit im RAM liegen. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- From announcements at tlug.de Sun May 30 06:00:01 2010 From: announcements at tlug.de (announcements at tlug.de) Date: Sun, 30 May 2010 06:00:01 +0200 (CEST) Subject: TLUG Termin: 2010-06-02 19:00:00 in Ichtershausen (EF und IK) Message-ID: <20100530040001.ABA2F59E7C@tlug.de> Naechster Termin der Thueringer Linux User Group: * 2010-06-02 19:00:00: Stammtisch in Ichtershausen (EF und IK) Viel Spass dabei! -- - automatically generated, do NOT reply - From mat-lorenz at gmx.de Sun May 30 22:15:24 2010 From: mat-lorenz at gmx.de (Matthias Lorenz) Date: Sun, 30 May 2010 22:15:24 +0200 Subject: TLUG Termin: 2010-06-02 19:00:00 in Ichtershausen (EF und IK) In-Reply-To: <20100530040001.ABA2F59E7C@tlug.de> References: <20100530040001.ABA2F59E7C@tlug.de> Message-ID: <4C02C75C.60109@gmx.de> announcements at tlug.de schrieb: > Naechster Termin der Thueringer Linux User Group: > > * 2010-06-02 19:00:00: Stammtisch in Ichtershausen (EF und IK) > > Viel Spass dabei! > > Leider kann ich mal wieder nicht. Bis Bald ML From announcements at tlug.de Mon May 31 06:00:02 2010 From: announcements at tlug.de (announcements at tlug.de) Date: Mon, 31 May 2010 06:00:02 +0200 (CEST) Subject: TLUG Termin: 2010-06-03 19:00:00 in Jena Message-ID: <20100531040002.9A49359E89@tlug.de> Naechster Termin der Thueringer Linux User Group: * 2010-06-03 19:00:00: Stammtisch in Jena Viel Spass dabei! -- - automatically generated, do NOT reply -