# Gentoo als Betriebssystem für produktiven Webserver

## andreask

Hallo!

Ich überlege gerade, ob ich gentoo auf einem produktiven Webserver (nur Apache, mod_php, Postgres) verwenden sollte.

Ich bekomme oft zu hören dass Gentoo ne prima Disttribution für den Desktop sei, aber nix auf Servern zu suchen hätte. Eben weil die Pakete immer so aktuell sind, und nicht wie bei RedHat ... gepatched werden.

Nur gefält mir Gentoo wirklich sehr gut, und ich hatte auch bisher keine Probleme im Betrieb, wobei ich auch erst wenig Erfahrung mit Gentoo habe.

Es wird halt immer gesagt, "die aggresiven optimierungen", vor allem in den gentoo-sources, oder auch der Trend zu "überoptimierten" Compilerflags...

Nicht falsch verstehen, das ist nur dass was man andauernd zu hören und zu lesen bekommt.

Daher wollte ich mal nachfragen, was man bei einer Gentoo Server-installation, wo es definitiv auf stabilität und nicht auf performance ankommt beachten sollte. Ich habe mal die vanilla-sources verwendet, weil die ja als besonder stabil gelten. Oder sollte man vielleicht eher dei redhat-sources verwenden?

und was ist mit compiler-flags? --march=<cpu> ist ja sicher nicht verkehrt, und sonst? Ich verwende zur Zeit 

```
CFLAGS="-march=pentium2 -O2 -pipe -fomit-frame-pointer"
```

, später soll das mal auf einem DUAL-Xeon laufen, also würde ich noch --march anpassen, und vermutlich auch -fomit-frame-pointer rausnehem, weil -O2 das AFAIK eh impliziert und nicht erzwungen werden sollte. Oder sollte man der Stabilität zu liebe auch noch von -O2 runter gehen?

Meine Use-Flags sehen so aus:

```
USE="ipv6 openssh pear-db postgres -oss -arts -avi -cups \

     -encode -foomaticdb -gtk -gtk2 -kde -gnome -mad -mikmod -motif -mpeg \

     -oggvorbis -opengl -qt -quicktime -sdl -X -xmms -xv -perl"
```

sieht das OK aus für nen reinen Webserver? 

Mich würde mal Eure Meinung zum Thema interessieren, prinzipiell überlege ich zwischen Fedora, Gentoo, Debian und FreeBSD, wobei ich auf den Server keinen direkten Zugriff haben werde(steht in einem RZ, nur Linux rescue-console), so dass die Installation von FreeBSD und Fedora erheblich schwieriger ist als von gentoo oder debian.

Viele empfehlen für den Server ja Debian, aber mir persönlich gefällt Gentoo erheblich besser.

Viele Grüße

Andreas

----------

## toskala

gentoo für server bekommt bei mir ein klares doppelplus.

ich betreibe hier in der firma 5 server mit gentoo linux, die ich nach und nach allesamt umgezogen habe von suse linux.

die hardware reicht von xeon bis pentium über amds und celerons.

ich sehe keinen grund warum man gentoo nicht auf produktiven servern einsetzen sollte.

persönlich halte ich aber auch erst einmal so rein gar nichts von rpm-basierten distributionen und noch viel weniger von redhat im speziellen.

was mich an den dingern so extrem aufregt sind die extremen patch-krankheiten die sie allesamt haben.

gentoo ist source und das ist gut so.

das thema agressive optimierungen ist imho langsam durchgekaut.

du bestimmst selbst wieviel wie wenig optimierung du möchtest. wer eben meint mit -O4 besser zu fahren soll es tun, darf sich aber nicht beklagen das etwas nicht stabil läuft.

zur info, suse optimiert die meisten sachen mit -O4 was ich als fahrlässig empfinde...

zu deinen kernel sourcen.

ich benutze auf allen kisten grsec sources vom 2.4er tree. die sind sehr stabil und haben ein dickes plus an sicherheitsbonus. wobei du darauf achten musst, dass manchmal applikationen (speziell java und das apache jakarta projekt) nicht damit laufen wollen.

alle meine server sind seit langer zeit up and running und ich hatte nie probleme damit.

ich compiliere hier auf meinen servern mit "-march=<cpu> -O2 -pipe" kein anderer schnickschnack.

useflags musst du eben so anpassen wie du sie brauchst. sieht aber brauchbar aus was du vorschlägst. ich würde noch -truetype hinzufügen.

nun, noch meine meinung zu fedora, debian und bsd...

fedora == müll, einfach weil es ein grafischer klickibunti scheissendreck ist der meiner meinung nach genausowenig für server geeignet ist wie mandrake. das sind halt desktop-distros (imho).

debian == seltsam, ich mag es halt nicht. das liegt aber an einer pers. abneigung gegenüber dpkg und dem elendig outdateten.

bsd == nett, aber unkomfortabel  :Smile: 

achja, eines vielleicht noch.

wenn du wenig erfahrung mit gentoo hast rate ich dir _dringend_ an dich vorher damit vertraut zu machen bevor du ein produktiv system aufsetzt. sonst kannst du in eine böse falle laufen und mehr als nur einen roten kopf kriegen, wenn dein chef dich mal n paar sachen fragt die du nicht beantworten kannst.

----------

## holla die waldfee

du solltest noch "apache2" in deine use flags setzen, damit die php module für apache 2 kompiliert werden

gruß

holla

----------

## toskala

 *holla die waldfee wrote:*   

> du solltest noch "apache2" in deine use flags setzen, damit die php module für apache 2 kompiliert werden

 

ich pers. halte apache2 noch nicht für ausgereift genug in den produktiv betrieb zu gehen.

----------

## sirro

Neben den grsecurity-sources (wann kommt endlich gresecurity für 2.6???   :Twisted Evil: ) gibt es noch das Gentoo Hardened Project[1], das auch die entsprechenden hardened-sources liefert. Die werden (fast?) komplett mit Stack Smashing Proktektoren compiliert und verfügen über eine Reihe von Sicherheits-Patches wie grsecurity, systrace [3] [4] (auch hier: ich will nen 2.6er patch. der 2.5er läauft nicht mehr  :Wink: ) und dazu noch viel mehr. schau dich einfach mal um.

Der Gentoo Security Guide [5] ist sicher auch eine Must-do.

Für einen Server würde ich sicher auch "-march -O2 -pipe -fomit-frame-pointer" benutzen. Das fomit-frame-pointer ist nicht bei allen Architekturen mit in -O drin (nur bei denen wo es keinen konflikt beim debuggen gibt, siehe man-page). Aber bei x86 IMHO schon, ansonsten schadet es nicht wenn man sie trotzdem aufführt...

Ich hoffe das hilft ein bißchen weiter bei deiner Entscheidung...

BTW: Das SuSE mit -O4 compiliert kann ich mir kaum vorstellen. gibt doch (laut man-page) nur -O[0-3,s].

[1] http://www.gentoo.org/proj/en/hardened/

[2] http://www.grsecurity.net/

[3] http://www.citi.umich.edu/u/provos/systrace/

[4] http://www.linux-magazin.de/Artikel/ausgabe/2003/01/systrace/systrace.html

[5] http://www.gentoo.org/doc/en/gentoo-security.xml

----------

## toskala

 *sirro wrote:*   

> 
> 
> BTW: Das SuSE mit -O4 compiliert kann ich mir kaum vorstellen. gibt doch (laut man-page) nur -O[0-3,s].
> 
> 

 

imho konnte man mit > O3 compilieren bis vor einiger zeit. aber ich bin mir sehr sicher, dass ich letzt als ich ein srpm rebuilded hatte eine sehr hohe -O gesehen hatte.

nagel mich aber nicht drauf fest  :Wink: 

----------

## andreask

Hallo!

Vielen Dank für Eure Antworten!

Vorab - das sind alles noch Überlegungen, natürlich teste ich gentoo vorher, ich habe es jetzt seit kurzem auf einem alten Celeron-Rechner(ohne Monitor...) installiert, und probiere ein wenig rum, per ssh. 

Ich hatte mal ne Zeit parallel RedHat  und Windows auf dem Desktop verwendet, irgendwann ist meien Platte kaputt gegangen und seitdem verwende ich auf dem Desktop wieder nur Windows.  Aber hier werde ich auch gentoo drauf installieren, einfach um täglich mit zu arbeiten, ist sicher hilfreich zum Erfahrungen sammeln.

Als nächstes werde ich es dann auf einem Tstserver im RZ installieren, udn  erst wenn das ausgiebig getestet ist und gut läuft auf einen produktiven Server spielen. Linux setze ich schon länger produktiv ein, aber eben RedHat, nur gefällt mir die Politik von RedHat wie mit der freien Distri umgegangen wird überhaupt nicht, also will ich davon weg und Gentoo erscheint mir als die beste Lösung. Und bisher bin ich auch absolut begeistert.

Bisher habe ich auf RedHat mit apt-get gearbeitet, was gegenüber Portage den Vorteil hat dass es viel schneller geht, ich kann mir nicht gut vorstellen auf einem produktiven Server für ein emerge -u system 12 Stunden zu benötigen(vor allem gcc, glibs, kernel... kompilieen dauert ja unerträglich lange). So lang ist die Nacht leider nicht. Daher suche ich noch nach Servern wo man evtl. binäre Pakete bekommen kann.  Kennt da jemand was? Und wie ist das mit  den CFLAGS? Haben die überhaupt Einfluss darauf ob ein binär-Paket in Frage kommt?

Bei RedHat habe ich Apache, PHP und PostgreSQL immer selber konfiguriert und kompiliert. Da muss ich noch ein bisschen sehen, denn bei gentoo wird ja standardmäßig so ziemlich jede Extension mitgenommen...

Was mir nicht so gefällt,  dass sich die Konfiguration des Apachen über mehrere Dateien verteilt, früher hatte  ich immer eine httpd.conf, und gut ist. Da konnte ich einstellen welche Module geladen werden... 

Jetzt werden zum einen alle stanrdmäßigen Module per DSO geladen, aber nicht 3rd-Party wie PHP4, dass steht dann nicht in der eigentlichen Konfig, sondern in einer Extra-Datei. Naja, vermutlich ist es nur eine Umgewöhnung, die Files sind dafür schön aufgeräumt. Naja und bei PHP muss ich mal sehen, da wird ja auch alles installiert, ich brauche aber eigentlich nur sehr wenige Module...

Was ich auch etwas verwirrend finde ist dass man Apache 2 an manchen Stellen als "apache" bezeichnet(emerge) und hinterher dann als "apache2"(/etc/conf.d/apache2...)

Zur Diskussion:

Apache 2 vs. Apache 1, Apache 2 hat einige Vorteile, die mir aber nicht viel bringen. Zum einen die Filter-Funktionen brauche ich nicht, das SAPI-Modul von PHP für Apache2 gilt immer noch als "experimentell", und wenn läuft es überhaupt nur mit dem prefork-mpm stabil. Das liegt daran dass in PHP viele 3rd-Party Libs nicht threadsafe sind., somit hat man also nichts von dem worker-mpm. Zumal der 2.4er Kernel eh nicht die beste Posix-Thread Implementierung hat. Und 2.6 auf nem produktiven Server - macht wohl wenig Sinn. Man könnte höchstens die redhat-sources verwenden, denn die haben die neue Implementierung ja in den 2.4er geportet.  Aber wie gesagt, mit PHP macht das eh keinen Sinn.

Wenn ich aber den Apachen im Prefork-Modus laufen lasse ist das genau dasselbe wie der 1.3er, nur dass man ein paar zusätzliche Unsicherheiten hat, weil noch recht neue...

zu -fomit-frame-pointer:

wenn es bei x86 in -O enthalten ist, dann braucht man es ja nicht zu setzen, oder? Zumal ich schon in einigen ebuilds gesehen habe dass -fomit-frame-pointer ausgeschlossen wird, weil as irgendwelche Probleme macht. Daher werde ich es wohl weglassen, das bisschen Performance was das vielleicht bringt  - wenn überhaupt - lohnt sich ja nicht wirklich deswegen irgendein Risiko bzgl. Stabilität einzugehen.

zu den Kernel-Sourcen:

Damit habe ich mich noch nicht so genau beschäfftigt, nur dieses Kernel-Howto gelesen. Zu grsec sources finde ich überhaupt keine Infos, was genau ist das? hardened-sources sind von gentoo-devs gepatched, in Richtung Sicherheit und Stabilität, ja?  Ist das "nur" um den Kernel selber gegen mögliche Verwundbarkeiten abzusichern, oder dazu um bestimmte zusätzliche Software nutzen zu können, bzgl. Sicherheit...?

Und die sind auch mindestens so stabil wie die vanilla-sources? 

redhat-sources würdet Ihr von abraten? Ich hatte gedacht gerade wegen der ein paar nette Kleinigkeiten vom 2.6er Kernel und Sicherheits-Patches von Redhat wäre das ne echte Alternative?

zu -truetype:

Ich bin nicht 100%ig sicher, aber ich verwende in PHP gd-Funkitonen in denen ich AFAIK auch truetype Schriften benötige. Also müsste ich das eigentlich brauchen, ich gucke aber niochmal nach.

Auf jeden Fall vielen Dank für die hilfreichen Antworten!

Viele Grüße,

Andreas

----------

## sirro

zu dem emerge -u world: Bei einem Server würde ich darauf weitesgehend verzichten. Wichtige Updates sind für einen Server schließlich nur solche, die zusätzliche Features (die auch benötigt werden) bzw. mehr Stabilität mitbringen und solche die Bugs fixen. Schließlich ist auch jedes Update ein gewisses Risiko, gerade auf einem Produktivsystem. Also sollte man nicht "jeden scheiß" updaten

Insofern veringert sich die anzahl der aufzuspielenden Updates schonmal entscheidend. Wenn du nun updaten musst würde ich behaupten, dass ein Xeon-System über nacht ziehmlich viel gerissen bekommt, wenn es nicht dauerhaft unter Last steht natürlich. Auf der anderen Seite kannst du dir auch selber auf einem anderen Rechner Binärpakete für den Server bauen (emerge -B siehe auch man emerge), die dann auf dem Server sehr schnell eingespielt werden können.

Bei Binärpaketen von Fremdenquellen ist zuersteinmal die Frage nach der Sicherheit (ist garantiert, dass die Pakete in Ordnung sind?) und zum anderen nach den CFLAGS (Benutzt der andere -O3 -hurt-me-plenty bringt das auf dem Server nur Instabilität.)

Zu den CFLAGS sei dir noch ein Blick auf -fstack-protector ans Herz gelegt, dass ist der Stack Smashing Protector (Pro Police) mit dem der gcc bei gentoo gepatcht ist und mit dem auch die hardened-sources kompiliert werden.

zu emerge: Du kannst dir auch die Quellen entpacken lassen, dann ./configure und make selber ausführen und das ganze von ebuild mergen lassen. Oder ein angepasstes Ebuild erstellen. Einen passenden Thread findest du im Forum.

zu -fomit-frame-pointer: ich bin mir nicht 100%ig sicher ob es wirklich bei -Ox auf x86 dabei ist, aber wenn du es dazu nimmst, dann hast du es auf jeden Fall, das ist sicher. Ob man es sicher weg bekommt wenn es automatisch dabei ist weiß ich leider nicht...

zu den Kernel-Sourcen: Die grsec-sources sind quasi die Vanilla-Sources mit Pax und grsec (pax ist mitlerweile bestandteil davon). Weitere Infos siehe Link oben... Oder (zu Pax) im aktuellen Linux-Magazin Security Spezial.

Mit dem systrace Patch kannst du Programme mit dem systrace-befehl (emerge systrace) aufrufen und diese mit einer Policie austatten, so dass diese nur bestimmte syscalls ausführen und nur auf bestimmte Dateien/Verzeichnisse zurückgreifen können. Auch hierzu siehe Link oben!

Hauptsächlich dienen die Patches allerdings zur Absicherung des Kernels und z.B. des Speichers oder z.B. von chroot-umgebungen usw. Einfach mal auf dem test-rechner ausprobieren was es da alles gibt.

----------

## Marlo

hi, 

wir sind in der firma auch vor 1/2 jahr von suse zu gentoo migriert. Ca. 50 clients mit m$ 2000, 5 großen druckern, samba, mail und was man noch so braucht. Serverseitig null problemo. Emerge world ist in so einer umgebung nicht wirklich hilfreich. Emerge security wär schon besser, aber daran wird gearbeitet. Hatten gerade ziemliches rätzelraten mit vpn, hardwaremäßig, bin deshalb jetzt gerade dabei einen P2 350 als gateway aufzusetzen. Von stage1 dauert es, klar. Ansonsten - nur zu empfehlen - und die flags auf "sicher" setzen, auch richtig. 

Gruß

Ma

----------

## andreask

 *Marlboro wrote:*   

> Emerge world ist in so einer umgebung nicht wirklich hilfreich. Emerge security wär schon besser, aber daran wird gearbeitet. Hatten gerade ziemliches rätzelraten mit vpn, hardwaremäßig, bin deshalb jetzt gerade dabei einen P2 350 als gateway aufzusetzen. Von stage1 dauert es, klar. Ansonsten - nur zu empfehlen - und die flags auf "sicher" setzen, auch richtig.

 

OK, das sehe ich ein, emerge system/world macht nicht wirklich Sinn. 

emerge security hört sich interessant an, ist jedenfalls mal wieder ne sehr gute Idee.

Aber stage 1 oder 2, da verstehe ich den Nutzen bisher nicht wirklich. Angenommen ich habe eine P4-CPU - da ist es doch total egal ob die hierfür optimierte Version auf meinem Rechner live erstellt wird (wo aus irgendeinem Grund möglicherweise irgerndwelche Probleme auftreten, die der Profi "mal eben löst", ich aber nicht...), oder eben von einem Profi auf exakt derselben Maschine, das heißt mit entsprechenden Compiler-Flags...

Das Resultat dürfte doch dasselbe sein, oder?

Und ob ich mir jetzt Quellcode vom gentoo-Server runterlade oder was Kompiliertes, am Ende muss ich den Devs halt vertrauen dass die mich nicht verarschen  :Wink: 

Und auf das letzte Quäntchen Performance kommt es mir eh nicht an wie gesagt. Stabilität und Sicherheit - das sind die Kriterien für mich. Und da sehe ich nicht wie stage 1 oder 2 das erhöhen.

Aber was meinst Du damit, "die Flags auf sicher setzen"?

Viele Grüße

Andreas

----------

## andreask

 *sirro wrote:*   

> Auf der anderen Seite kannst du dir auch selber auf einem anderen Rechner Binärpakete für den Server bauen (emerge -B siehe auch man emerge), die dann auf dem Server sehr schnell eingespielt werden können.

 

ja, daran hatte ich auch gedacht, nur - wie ist das hier mit den Compiler-Flags und dem erzeugten Binaries, wenn es sich möglicherweise um einen anderen Rechner handelt, z.B. einen Athlon oder einen Pentium 2? Kann ich auch auf solchen Rechnern Code kompilieren der für einen "höheren" Rechner (also z.B. P4 statt P2) optimiert ist? Sind die erzeugten Binaries am Ende 100% identisch mit denen die auf dem Rechner selbst erzeugt werden?

Früher oder später werden das einige produktive Server sein, evtl. kann ich ja einen abstellen der Pakete für die anderen kompiliert, nur könnte ich hierfür höchstens nen Celeron oder PIII  bekommen.

 *Quote:*   

> Zu den CFLAGS sei dir noch ein Blick auf -fstack-protector ans Herz gelegt, dass ist der Stack Smashing Protector (Pro Police) mit dem der gcc bei gentoo gepatcht ist

 

Was heißt das? Grundsätzlich? Oder nur unter bestimmten Voraussetzungen? Könnte ich das auch jetzt schon verwenden?

 *Quote:*   

> zu emerge: Du kannst dir auch die Quellen entpacken lassen, dann ./configure und make selber ausführen und das ganze von ebuild mergen lassen. Oder ein angepasstes Ebuild erstellen. Einen passenden Thread findest du im Forum.

 

äm, warum sollte ich das wollen?

 *Quote:*   

> zu -fomit-frame-pointer: ich bin mir nicht 100%ig sicher ob es wirklich bei -Ox auf x86 dabei ist, aber wenn du es dazu nimmst, dann hast du es auf jeden Fall, das ist sicher. Ob man es sicher weg bekommt wenn es automatisch dabei ist weiß ich leider nicht...

 

Solange sichergestellt ist, dass es auf der anderen Seite keinen Sachaden anrichten kann wenn es erzwngen wird, ist das ja OK.

Im Manual von gcc steht nur:

-fomit-frame-pointer

    Don't keep the frame pointer in a register for functions that don't need one

Solange das auch verhindert wird ist das OK. Debugging brauche ich normalerweise ja nicht.

 *Quote:*   

> Mit dem systrace Patch kannst du Programme mit dem systrace-befehl (emerge systrace) aufrufen und diese mit einer Policie austatten, so dass diese nur bestimmte syscalls ausführen und nur auf bestimmte Dateien/Verzeichnisse zurückgreifen können. Auch hierzu siehe Link oben!
> 
> Hauptsächlich dienen die Patches allerdings zur Absicherung des Kernels und z.B. des Speichers oder z.B. von chroot-umgebungen usw. Einfach mal auf dem test-rechner ausprobieren was es da alles gibt.

 

Vielen Dank. Werde ich mal machen, wobei sich das mit den Policies kompliziert anhört, da ich ja dann die "normalen" konfigurationen zum starten... ändern muss. Naja, ich werde sehen...

Viele Grüße

Andreas

----------

## DarKRaveR

 *Quote:*   

> 
> 
> ja, daran hatte ich auch gedacht, nur - wie ist das hier mit den Compiler-Flags und dem erzeugten Binaries, wenn es sich möglicherweise um einen anderen Rechner handelt, z.B. einen Athlon oder einen Pentium 2? Kann ich auch auf solchen Rechnern Code kompilieren der für einen "höheren" Rechner (also z.B. P4 statt P2) optimiert ist? Sind die erzeugten Binaries am Ende 100% identisch mit denen die auf dem Rechner selbst erzeugt werden?
> 
> Früher oder später werden das einige produktive Server sein, evtl. kann ich ja einen abstellen der Pakete für die anderen kompiliert, nur könnte ich hierfür höchstens nen Celeron oder PIII bekommen. 
> ...

 

Schau einfach mal auf -mcpu versus -march, in kombination kannst du sagen, ab welchem prozessor es läuf tund wo es optimal läuft. Aber was sollte dagegen sprechen für einen prozessor zu bauen, den du lokal nicht hast, darfst es halt auf der maschine nur nicht installieren   :Wink:  .

Du kannst ja sogar cross-compilen, sprich auf ner solaris die intel pakete bauen etc. da hat doch niemand etwas dagegen.

----------

