Skip to content

Von Debian nach Gentoo (für dieses Blog)

Ich bereite nebenher eine kleine Umstellung dieses Blogs (des Servers dafür ;-) ) von Debian auf Gentoo vor.

Es kann also immer mal wieder zu kleinen Unterbrechungen kommen.

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Daniel

WARUM würde man das tun wollen? Ernstgemeinte Frage.

Peter Geher

Der Frage schließe ich mich mal an.

Manuel Schmitt (manitu)

Weil ich Gentoo mag, und weil wir es hier intern quasi ausschließlich einsetzen.

Jens

Na weil er einen distro flamewar vom zaun brechen möchte, ist doch wohl klar ;-)

Gentoo ist eine fast-pacing rolling release distro. Der Stable tree macht server admins glücklich und der unstable tree ist sehr gepflegt und bestens geeignet für desktops.
Dazu hat gentoo mit den overlays in verbindung mit eix ein sehr mächtiges und elegantes user-repository system. Ähnlich dem AUR von Archlinux. Mit dem PPA Gekrepel von Debian/Ubuntu möchte ich es nicht vergleichen. Dazu gibt es ausgereiften Binary-Support für größere Infrastrukturen.

Debian hingegen wartet alle 3 bis 4 Jahre mit einem neuen Major-Release auf, dessen Pakete wirklich schon steinalt sind zum jeweiligen Zeitpunkt. (Gefrickel vorprogrammiert)
Debians wunderbarer Paketmanager names apt startet/restartet Dienste automatisch beim install/upgrade. Wirklich eine super sache auf servern. Braucht jeder!1!!

Zudem tendieren Debian Paketverwalter upstream total zu verbiegen, natürlich nur im Sinne des "Users". Wieviele Sicherheitslöcher hatte Debian aufgrund ihrer eigenen Drecks-Patches? Mir fällt da irgendwas mit ssh ein, liegt nur wenige Jahre zurück ...

Peter Geher

Ich bin jetzt seit 1j (Privat, Server schon etwas länger.)exklusiv auf Debian. Bin zufrieden, alles läuft. Ziehe mir gerade mal das Gentoo-Iso, mal antesten. Vielleicht ist es ja wirklich besser :)

Tetja Rediske

Die Gentoo ISOs will (und braucht) man nicht.

Daveman

Was nimmt man da so? Eine Art Netinstaller?

Bene

Nimm dir ein beliebige halbwegs aktuelle 64bit LiveCD (ich empfehle derzeit sysresccd, das auf gentoo basiert) und Folge dem Handbuch:
http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml

Das ganze kannst du auch in einer virtuellen Maschine machen. Was man dazu beachten muss, gibts im Wiki oder lässt sich per Google gut in Erfahrung bringen.

Daveman

Merci.

Peter Geher

Vielen Dank. Stand vorhin da wie Blond. Iso in VirtualBox eingebunden ... "und jetzt??" :)

Morgen mal Versuchen, die Anleitungen helfen gut weiter!

Daveman

Auf die Gefahr hin, dass ich mich nun zum Deppen machen, frage ich trotzdem.

Was spricht denn dagegen von [1] ein ISO Image zu ziehen und damit zu installieren? Warum den Umweg über z.B. die sysresccd?


[1] http://www.gentoo.org/main/en/where.xml

Tetja Rediske

Weil das ISO nichts zum installieren enthält und es nicht wirklich gepflegt wird, ist mehr zur Vollständigkeit. Leider ist das ISO dadurch im Vergleich recht crappy.

chi

Eine gemäßigtere Sprache („Drecks-Patches“) und ein paar Belege für die aufgestellten Behauptungen wären schön. Für Releases „alle 3 bis 4 Jahre“ dürfte der Beleg schwerfallen, denn der längste Abstand zwischen Releases war weniger als drei Jahre, und typisch sind eher zwei Jahre (http://en.wikipedia.org/wiki/Debian#Release_history).

Die vage erwähnte Lücke in OpenSSL ist fünf Jahre her (http://www.debian.org/security/2008/dsa-1571).

Engywuck

ich habe gentoo vor vielen Jahren mehrfach ausprobiert. Meine Erfahrungen damals:
- man musste dauernd irgendwas neu kompilieren, ccache etc. belegten ordentlich Platz und machten Probleme
- die USE-Flags waren grausam (irgendwann war ich für meine Bedürfnisse bei ca. 120)
- ein guter Teil der sinnvollen Pakete waren maskiert und sogar die semi-offiziellen Seiten riefen dazu auf, das zu ignorieren
- wenn man in USE-Flag neu hinzufügte (global) sorgte dies gerne mal für 'ne Rekompilierorgie, USE-Flag pro Paket ging nur, wenn man's explizit jedesmal angab (oder z.B. für "mp3" an nem halben dutzend Stellen in ner Zentral-Konfig selber angab)
- Doku wurde oft nicht mitgeliefert, wegen irgendwelchen (zirkulären?) Abhängigkeiten
- Bei Deinstallieren von Paketen wurde auf Abhängigkeiten zu anderen Paketen nicht geachtet.

Ist das heute besser?

Zugegeben: ganz am Anfang, als gentoo das erste mal gehypt wurde, fand ich Linux From Scratch einfacher zu installieren. Das hatte sich bei den weiteren Versuchen gebessert ;-) Aber gerade die USE-Flags und die nicht (wirklich) beachteten Abhängigkeiten haben mich dann doch jedesmal zu Debian (je nach Rechner stable oder testing) zurückkehren lassen.

Klaus

Problematisch bzgl. Gentoo im Serverumfeld finde ich:

1. Schnelle Änderungen gehen nicht, weil man neu kompilieren muss (es sei denn das geht super schnell, weil der Server nur so vor Kraft strotzt und nichts zu tun hat) - Bei Debian und Co würde man an der Stelle üblicherweise ein Zusatzpaket installieren, was einfach super schnell ist im Vergleich

2. Ich persönlich habe Bedenken bzgl. der Sicherheit. Das Security-Team von Ubuntu scheint mir chronisch unterbesetzt zu sein (wie viele andere Bereiche auch). Allerdings ist es eine Weile her, dass ich mir das angeguckt habe. Vielleicht geht es inzwischen wieder.
Ich sage nur Massen-GLSA-Releases, weil es einen entsprechenden Stau gab.

3. Wenn man so ein "fast-pacing rolling release" einsetzt, muss man auch wirklich die Muße haben kontinuierlich Updates einzuspielen. Gentoo auf einem PC, der nur sporadisch an ist, ist grausam. Dann muss man erstmal 'nen Tag Updates einspielen bis das System wieder auf einem Stand ist, wo man "mal schnell" eine neue Software installieren kann (Problem: Abhängigkeiten). - Bei einem Debian/Ubuntu kann einem das nicht passieren. Da muss man auch nur Sicherheitsupdates einspielen, was viel schneller geht und üblicherweise unproblematisch ist. Dafür hat man nicht gerade die aktuellsten Softwareversionen.

Achja: Zu 1. Ich habe mal die Neukompilierung / das Update von Apache angestoßen. Die alte Version lief ja noch. Leider hat in der Nacht das logrotate den Apache neu gestartet bzw. in dem Fall gestoppt.

Klaus

s/Ubuntu/Gentoo/ -.-

Tetja Rediske

Dafür gibt es einen eigenen Buildhost und selbst libreoffice dauert auf einer aktuellen Maschine kaum noch eine halbe Stunde (kann mich noch erinnern für openoffice nee Woche gebraucht zu haben).

Pro Maschine sind die Dienste sehr überschaubar und wir haben zusätzlich ein Auge auf die entsprechenden Upstream und Security Seiten und können dann sehr schnell selbst entscheiden ob ein Bug bei uns überhaupt eine Rolle spielt, notfalls wird auch mal selber ein Patch entwickelt.

Das beste an dem ganzen sind eben die USE-Flags, ist eine Funktion nicht aktiv, kann diese auch keinen Fehler haben, das hat uns auch schon öfters mal ansonsten dringende Updates erspart.

Engywuck

keine Frage, wenn man genug Maschinen rumstehen hat, dass man eine oder zwei nur für's "dauerkompilieren" abstellen kann ist das schön. Ebenso, wenn (fast) alle Rechner im Verbund dieselben USE-Flags verwenden.

Aber was macht eine Person, die nur ein, zwei Serverchen hat? Sich auf den Build des Hosters zu verlassen ist ja fast so wie gleich Binärpakete von $beliebigeanderedistro einsetzen.

Früher war bei OpenOffice (zumindest auf meinen Kisten) das Problem, dass der RAM nicht ausreichte, alles auf einmal zu kompilieren, und dadurch die Platte mit "temp"-Zeugs vollief... Beides heute weniger Problema :-)

Tetja Rediske

Naja, wir haben ja schon ein paar mehr Serverchen hier. ;)

Für libreoffice braucht man übrigens heute trotzdem noch mindestens 12GB im /var/tmp frei, insgesamt braucht der Build doch auch schon mal schnucklige 20GB.

Aber Dauerkompilieren ist gar nicht, so oft kommen wichtige Updates bei Servern nicht, an meinem Desktop sieht das schon anders aus.

Bene

Bei einem Projekt haben wir uns entschieden von Debian Stable auf Gentoo zu wechseln.
Der entscheidende Punkt war in dem Fall die Aktualität:
Die von uns benötigte Software war in Debian Stable unbrauchbar: total veraltet und verbugt. Selbst in Testing sind die Pakete noch veraltet. Wir hätten die Software und einige Bibliotheken selber neu bauen und aktuell halten müssen.
Wir haben uns dann für Gentoo entschieden. Inzwischen haben wir auch für einige andere Software kleine Patches, die man bei Gentoo einfach in den Build-Prozess integrieren kann.
Aus einem Rechner wurden 7 virtuelle Server, wovon einer der Buildserver ist, der den anderen die binären Pakete bereitstellt. Den Portage-Tree und die Binären-Pakete werden vom Buildserver per nfs in den Clients eingebunden. Für die Verwaltung haben wir eine Hand voll Bash-Skripte geschrieben.

Bei einem anderen Projekt bin ich gezwungen Debian zu verwenden. Da bin ich ehrlich gesagt ziemlich am Fluchen - vielleicht einfach, weil ich mich noch nicht gut genug mit Debian auskenne. Bei dem Projekt handelt es sich um einen "On-Demand-Druckdienst". Für die Aufbereitung der Druckdaten wurden einige Skripte und Tools für die Aufbereitung der Druckdaten geschrieben. Dabei sind wir schon auf viele Bugs in Cairo,Poppler,GTK+ und CUPS gestoßen.
Die meisten Bugs haben wir gemeinsam mit Upstream gefixed. In Debian Stable haben es diese nicht mehr geschafft. Also haben wir da auf Debian Testing umgestellt. Leider haben es da bisher nicht alle Fixes reingeschafft. Also dürfen wir ein paar Pakete (z.B. gtk, cairo) selber bauen und bereitstellen. Leider hab ich bisher noch kein Automatismus gefunden, der mir die Pakete neu baut, wenn Debian neue Pakete bereitstellt.
Bei einem Update muss man immer aufpassen, ob ein betroffenes Paket aktualisiert wurde und das man sich nicht aus versehen das original Paket von Debian installiert.
Desweiteren dürfen wir die cups-filter selber neu Paketieren, weil Debian ghostscript zum Rendern nimmt. Das führt bei unsren Vorlagen, die wir bekommen, aber häufig zu Problemen. Wir müssen deshalb dem cups-filter-Paket bei bringen poppler zu verwenden. Da gilt das selbe Probleme wie oben: Passt man nicht auf und installiert ein Update aus den Debian-Quellen macht auf einmal das Drucken Probleme.

Die Häufigkeit an Updates von gentoo ggü. Debian Stable mag zwar minimal höher sein, aber das compilieren und installieren dauert bei Serversoftware in der Regel nicht sonderlich viel länger als bei Debian. Auf dem Desktop kann das aber schon ein bisschen anders aussehen.
Ich compiliere z.B. meine Software auf der Workstation und installiere auf meinem Laptop die Binaries.

Die Init-Skripte von Gentoo sind jedoch in der Regel deutlich besser als die von Debian. Zum Beispiel Bind: Gentoo führt vor dem start ein named-checkconf und gibt die Fehlermeldung aus. Debian sagt einfach nur: failed.

Auch die Verwaltung und Installation von Software finde ich bei Gentoo deutlich angenehmer. Die Ausgaben nach einem Emerge sagen einem, was man ggf. noch tun muss. Wir stellen das immer so ein, dass wir zum Schluss eine Zusammenfassung per Mail zugeschickt bekommen.
Bei Debian kämpf ich häufig damit, dass bei vielen Updates/Installationen dpkg zwischen drin Fragen stellt. Da kann man den Installations-Prozess also nicht einfach mal alleine Laufen lassen, da Garantiert am Anfang irgend ein Paket ein Frage hat und damit der ganze Prozess hängt. Klar, die Fragerei kann man deaktivieren. Aber dann muss man wissen, welche Dienste man am Schluss von Hand noch nachkonfigurieren muss. Ich weiß nur noch nicht, woher man das Wissen soll.

Desweiteren wird bei Debian viel Debianspezifisches verwendet: z.B. die Skripte um apache oder exim zu konfigurieren. Bei exim kann man diese Tools zum Glück relativ einfach durch ein eigenes Dummy-Paket ersetzen. Aber für mich ist das einfach gefrickel... Ich arbeite in der Regel mit der Doku von Upstream. Bei Debian fällt man da nicht selten auf die Schnauze, weil einem irgendwas Debianspezifisches in die quere kommt.

Mir gefällt insgesamt die (Rolling Release) Philosophie besser: lieber immer wieder kleine Änderungen an einzelnen Diensten, als bei einem dist-upgrade ein Haufen Dienste auf einmal testen und ggf. neu konfigurieren müssen.
Bei Debian hab ich manchmal das Gefühl, dass man lieber einen Bug nicht fixt, als dass man ggf. von irgendjemand den Workaround kaputt macht.

Bei mir steht Debian leider häufig im Weg bei meiner Arbeit, was für mich sehr frustrierend ist. Bei Maschinen, bei denen ich jedoch kaum von den Vorstellungen der Debian Maintainer abweiche (z.B. dem Desktop meiner Mutter), da ist Debian ganz nett. So bald man aber vom Debian-Weg abweichen will, werden einem nur Steine in den Weg gelegt. Gentoo lässt mir deutlich mehr Freiheit.

Im Prinzip muss aber jeder für sich selber entscheiden, was ihm lieber ist.

Engywuck

gegen das "debian installiert sich über eigene Pakete"-Problem sollte apt-pinning helfen. Einfach ein eigenes Repository aufsetzen (geht primitiv oder extrem komplex, ersteres reicht) und dieses via Pinning auf Wert 1001 setzen. Schon sind Pakete des Privat-Repos "wichtiger" als die Debian-eigenen, man kann aber bei Bedarf immer noch die Debain-Pakete installieren. Bei euch sollte sich so ein Repo ja ohnehin lohnen, da genug Server.

Gerade bei so einem wichtigen Server wie einem On-Demand-Druckdienst würde ich aber lieber Debain stable plus evtl. selbstkompiliertes nehmen. Da will man keine häufigen Updates, die (potentiell) Bugs haben und alles zerschießen. Lieber uralte Grundlage mit nur(!) Sicherheitsupdates.

Das Verhalten dpkg sollte einstellbar sein (z.B. kann man die häufigste Nachfrage, die nach modifizierten Configdateien, über ein --force-confold (oder -confnew und/oder -confdef) abschalten). Allerdings finde ich die Situation, nach einem (nächtlichen?) Update erstmal einige Stunden "unkonfiguriert" zu arbeiten auch nicht grade glücklich...

"Im Prinzip muss aber jeder für sich selber entscheiden, was ihm lieber ist. "

Bene

Erfahr ich bei Pinning, dass es aktuelle Pakete gibt, die ich ggf. selber neu bauen muss? Oder darf ich mir dann ein Skript schreiben, dass mir das überpürft?

Debian Stable macht in diesem Fall absolut kein Sinn, da es viel zu veraltet ist. Unsere Software würde vorne und hinten nicht laufen und wir müssten noch mehr Pakete selber bauen. Das erzeugt deutlich mehr Aufwand, als Debian Testing an Fehler reinbringt.

Eben das unkonfiguriert arbeiten gefällt mir nicht. Ich würde gerne die Konfigurationsabfragen entweder gesammelt am Anfang oder am Ende haben.

Engywuck

so genau kenne ich mich mit pinning auch wieder nicht aus - habe das bisher nur in seltenen Ausnahmefällen gebraucht.
Allerdings - woher soll debian wissen, dass es eine neue Upstream-release von einem Programm in deinem Privat-Repo gibt? Sofern das Programm aber nicht (wirklich) sicherheits- aber dafür produktionsrelevant ist muss ja auch nicht 10 Sekunden nach Updates im Upstream die neue Version installiert sein. Natürlich ist das immer eine Abwägung...

Daveman

Oh ha!
Nachdem ich das alles so glesen habe, muss ich wohl doch mal Gentoo installieren. Ich hatte (zugegeben ist das paar Jahre her) öfters gehört, dass es sei eine Frickel- und Bastel Distribution. Bin bis jetzt im Serverbereich immer gut mit Debian gefahren und für Desktop Ubuntu. Klar flucht man hin und wieder mal. Das ist denke ich mal Distributionsunabhängig :-)

Bene

Je tiefer ich mich in Debian einarbeite, desto frickeliger finde ich es.
Wenn man dann in der ML zu Bugfixes so etwas ließt: "Das Problem tritt in folgender Zeile auf [...] Wir haben keine Ahnung was die macht. Wenn die Zeile gelöscht wird, funktioniert das Programm und der Fehler tritt nicht mehr auf. Diese Lösung haben wir jetzt im VCS eingecheckt."
Da stehen einem die Haare zu Berge.
Ich möchte Debian nicht bashen, dass ist dank des Umfang des Repositories die Distribution meiner zweiten Wahl.
Aber es gibt eindeutig noch viel Verbesserungspotential in den debianspezifischen Software. So bald das neue Testing aufgemacht wird, werde ich ein paar Vorschläge einreichen.

Damage

Sorry, hatte Heute Clown zumFrühstück, deshalb:

Vi ist besser als Emacs... :D

Bene

Pah, es geht nichts über einen ordentlichen Mix aus bashism, sed, grep, nano, gedit und Python (;

Peter Geher

Zu emacs fällt mir nur des ein:

Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als wenn
ich nach einem Fahrrad frage und einen pangalaktischen
Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht, was ich damit soll.

-- Frank Klemm, de.comp.os.unix.discussion

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
BBCode-Formatierung erlaubt
Formular-Optionen