[linux-l] Woody-nachbesserungs-tool

So Jan 19 16:37:46 CET 2003

Steffen Dettmer <steffen at dett.de> schrieb:

> * Carsten Posingies wrote on Sun, Jan 19, 2003 at 10:04 +0100:
>> Wer Linux ernsthaft einsetzen will, muss sich eben nicht nur mit der
>> KDE und ein paar Shell-Kommandos beschäftigen. Und das Kernel-Backen
>> gehört immer noch zum Handwerkszeug selbst für Hobby-Linuxer dazu.
>
> Finde ich kaum. Hab unter SuSE seit Jahren keinen Kernel mehr
> gebaut.

Sagen wir es mal so: Spaß machen tut's nicht. Aber wenn diese
#@&&!!-PCMCIA-Karte von ***** partout nicht gehen will, weil man bei "lsmod"
nen Fehler kriegt (wie ich das mit dieser 3c589C hier habe, und zwar immer
noch ohne Lösung), ist's gut, wenn man nen Kernel bauen und testen kann, um
sich sicher zu sein, dass es daran nicht liegt... ;-)

>>>> Jedenfalls sehe ich die Gefahr, daß es immer einfacher wird, bis
>>>> nichts mehr geht :)
>>
>> ... oder jedenfalls alles "irgendwie" geht, aber keiner weiß mehr,
>> wieso eigentlich.
>
> Ja, Deine Aussage ist noch treffender!

Das ist eben Windows. Es funktioniert, man nimmt es zur Kenntnis, und wenn
was klemmt, bootet man. Selbst den allerhardcoresten Programmierern bleibt
unter Windows ne Menge verborgen. Bei Linux liegt das (noch) nicht an einer
Closed-Code-Strategie, sondern daran, dass Unix nunmal saukomplex ist.
Deswegen ist Linux für mich auch nach wie vor kein Desktop-Betriebssystem.
Wer wirklich Power braucht, der verdient auch genug Geld und orientiert sich
dann vermutlich eher Richtung MacOS X oder Solaris -- denn die
High-End-Killeranwendungen für Linux gibt es bisher noch nicht. Für den
Hobby-Video-Schnibbler oder -3d-Animateur reicht Windows allemal, während
die Profis spezielle Hardware brauchen, die in genügend großer Stückzahl nur
für Macs, Suns und hochgezüchtete Intel-Kisten zu haben ist.

Ich sehe Linux nach wie vor als Server-OS an, das sich vom kleinen
Privat-File- und Printserver bis zum Hochverfügbarkeits-Internet-Server
wunderbar eignet. Aber dann braucht es eben kein GUI...

>> Nun, warum man als ernsthafter Linux-Interessierter überhaupt ne
>> SuSE nimmt, ist MIR ein Rätsel ;-)
>
> Ist zwar ein Smilie dran, aber das es auch für andere ein Rätsel
> ist, hier meine Gründe:
>
> SuSE kenn ich inzwischen recht gut.

(...)

Mein Problem mit SuSE ist eigentlich "nur" yast. Denn das Ding hängt mir zu
tief im System. Selbst wenn ich es nicht benutzen will, renne ich irgendwann
immer wieder vor diese dösige "rc.config". Bei RH und vor allem bei Debian
kann ich wie "in den guten alten Zeiten" (TM) per "joe" oder "vi" alles per
Hand konfigurieren, und es klappt. Bei RH kann ich gleich bei der
Installation alles RH-Tools abschalten, und das Ding rennt immer noch.

Gut, da ich RH am besten kenne, nehm ich mir mal raus, speziell über RH was
Negatives zu sagen. Die Puzzelei mit den Packet-Dependencies ist wirklich
krötig. Macht man den Fehler, an irgendeiner Stelle vor der eigentlichen
Installation die Abhängigkeiten automatisch auflösen zu lassen, hat man
garantiert nen X-Server und Python und Gnome auf der Kiste -- weil PHP
braucht angeblich die libpng und sowas, was natürlich totaler Stuss ist.
Hier gehört eine Abstufung rein der Art, dass es nötige und nützliche
Abhängigkeiten gibt. Dass nix ohne die glibc geht, ist klar, aber dass die
meisten PHP-Anwendungen dynamisch PNGs erzeugen werden, kann mir keiner
ernsthaft erzählen wollen.

Eine RedHat-Installation auch in der aktuellen Version dauert bei mir
deshalb immer gute 3 Stunden, bis ich diese ganzen Dependencies aufgedröselt
habe. Das allerbeste Beispiel für total beknackte Dependencies ist hierbei
übrigens "expect". Das hätte gerne Tcl. So weit, so gut. Tcl hätte aber
gerne Tk, und Tk hätte gerne nen XFree86-xyz, welches dann den xfm möchte,
der dann als Dienst rennt, und der xfm hätte natürlich gerne ein paar Fonts,
welche wiederum... und schwupps! hat man Windows NT Server auf der Mühle.

>>> Ich habe mit yast sehr gute Erfahrungen gemacht. Die Konfiguration
>>> meiner SuSE 8.0 war supereinfach und klappte auf Anhieb.
>>
>> Und Du weißt jetzt genau, warum beim Start Deiner Box welcher
>> Prozess wann gestartet wird?
>
> Muß er doch nicht. Er will ja arbeiten, nicht booten :)

Genau DIESE windows'sche Einstellung gegenüber Linux ist das, was ich mit
meinem Schlussstatement sagen wollte: genau DIESE Einstellung wird Linux
immer weiter in Richtung Windows drängen.

>> Ich jedenfalls habe noch keine Distribution gesehen, bei der
>> "/etc/rc3.d" sinnvoll aufgebaut und vollständig war. Da startet
>> der Apache vor dem DNS-Server, das Netzwerk ist für mindestens
>> 30 Sekunden hochgefahren, bevor die iptables scharfgeschaltet
>> werden etc. etc.
>
> Na, ich weiß nicht, ob das so stimmt. Spätenstens seit "insserv"
> sollte das klappen.

Jau, aber man sollte doch davon ausgehen, dass sich die Ersteller einer
Linux-Distribution mal ein paar Gedanken darüber machen, in welcher
Reihenfolge Dienste gestartet werden sollten. Wenn man es auf die Spitze
treibt, müsste man aus Sicherheits-Sicht sowieso jedes init-Skript anpassen.
Nur mal kurz angerissen: "network start" ist ein Sicherheitsloch erster
Güte. Die korrekte Reihenfolge für einen Web-Server wäre: lo hoch, eth0
konfigurieren, aber noch down lassen, iptables konfigurieren, falls
gewünscht DNS starten (aber so konfigurieren, dass er nicht nach außen reden
muss), falls gewünscht MySQL starten, dann Apache, dann erst eth0 up
bringen. Wer macht das schon?

ADSL ist auch so ein Kandidat. Das Skript, was da kommt, bringt erst ppp0
hoch, anschließend (!) wird per "echo 1 >/..." IP-Forwarding aktiviert, und
dann (!!) werden die iptables aufgesetzt. Sind zwar "nur" ein paar Sekunden,
aber würde man generische iptables aktivieren, die allen Verkehr sperren,
dann ppp0 hochbringen, dann die iptables lockern und dann das Forwarding
einschalten, wären die paar Sekunden erledigt.

> Die SuSEFirewall finde ich auch blöd, ersten
> sourct man keine Configfiles, weil vielleicht mal jemand device=*
> reinschreibt, und zweitens sehe ich keinen Grund, das Ding
> ständig neu zu starten. Na, man kann ja was eigenens nehmen.

Zumal diese Toy-Firewalls - wie schon gesagt - sowieso nur gefährliche
Spielzeuge sind. iptables versteht man nunmal nicht in 10 Minuten während
der "ran"-Werbepause. Die "pädagogisch richtige" Methode wäre, jedem, der
eine Wall installiert auf seinem Rechner, erstmal für alles eine "drop
all"-Regel einzurichten, sodass man gezwungen ist, sich mit der Thematik zu
befassen, damit man weiß, was man tut.

Betrifft natürlich nicht nur Firewalls. Selbst eine so "simple" Entscheidung
wie "Wohin tue ich meine Swap-Partition, und wie groß sollte sie sein?" kann
ein Installationstool nicht wirklich richtig machen, weil die Performance
eben nicht mal eben mittels "ganz vorne" oder "ganz hinten" und "Swap-Space
= 2 x realer Speicher" oder "Swap-Space = 4 x realer Speicher" optmiert
wird. Von den Dateisystemen will ich gar nicht reden...

Im Übrigen zieht das Argument nicht, dass es anders als so (sprich: dem User
alles so leicht wie möglich machen) nicht geht, um Linux zum Erfolg zu
verhelfen. Für den Workstation-User vielleicht noch, aber nicht für den
Server-Admin. Datenbanksysteme wie die beliebte MySQL kommen zwar auch mit
kleinen GUI- oder Web-Schnittstellen daher, aber die bieten ganz bewusst die
"fiesen" Stellen gar nicht erst an. Da muss sich der Datenbank-Op wohl oder
übel knietief ins Eingemachte begeben, und die MySQL-Doku sagt oft genug im
Manual, dass für dieses und jenes Tuning eine Neukompilierung nötig ist.
Recht haben sie. Wer rasen will, muss schrauben.