[linux-l] Woody-nachbesserungs-tool

[Steffen Dettmer]

* Carsten Posingies wrote on Sun, Jan 19, 2003 at 16:37 +0100:
> Steffen Dettmer <steffen at dett.de> schrieb:
> > 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... ;-)

Ja, aber dann bist Du ja auch kein Standard-Anwender mehr, der
kein technisches Interesse hat. Es kann auch Spaß machen,
manchmal, und wenn man sich notfalls (weil es eben wichtig ist),
die Sourcen angucken kann, hilft einem das auch oft genug. Wenn
also was wirklich wichtig ist, kann man hier noch viel drehen.
Das finde ich prima. Das heißt natürlich nicht, daß man das immer
muß oder sollte, ganz im Gegenteil...

> > > ... 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. 

Wenn man sich mit MFC, SDK und Co beschäftigt, bekommt man aber
ein Gefühl dafür, warum die meisten Anwendungen so blöd sind. MFC
und Co sind zwar schnell, aber unhandlich und unsauber. Der alte
Kompromiß: schnell und schick, aber nicht sauber und sicher.

> Bei Linux liegt das (noch) nicht an einer
> Closed-Code-Strategie, sondern daran, dass Unix nunmal
> saukomplex ist.  

Ich finde es einfacher als Windows. Es gibt Files und Prozeße.
Alles (na ja, fast) ist klar und simpel. Kann man verstehen und
richtig anwenden. Bei Win gibt's immer ne Million Ausnahmen,
übersieht man eine, ist's schon nicht mehr stabil. Es gibt
Millionen Funktionen, die genau das Windows-Verhalten zeigen:
möchte man etwas machen, was noch nicht vorgesehen ist, muß man
einen Trick kennen...

> 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...

GUIs können eh immer nur Standardfälle abbilden, und wenn's
wichtig ist, braucht man meistens den einen oder anderen
Spezialfall... z.B. beim Kernel oder diverser Software.

> (...)
> 
> 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". 

Na ja, das liegt IMHO weniger an yast, als an den rc.d
Scriptchens. mit rc.config konnte ich immer ganz gut leben; wenn
man hier was mit'm vi ändert, geht's ja. Man muß ein bißchen
wissen, wie es funktioniert, dann kann man auch gut eingenen Kram
dazubasteln. Das geht schon. Yast hab ich nach der Installation
eigentlich NIE benutzt. Ich hab mir kurz die Scripte angeguckt,
früher ein paar elementare Bugs entfernt, und den Kram eben
entsprechend in rc.config geschmissen, oder einfach eigene
rc-Scripte verwendet. rc-Scripte sind wohl genau das, wo eine
Distribution richtig arbeiten muß. Aber hier kann man oft einfach
reinpfuschen. Dann geht eben yast für diesen Dienst nicht mehr.
Oder man macht es "kompatibel".

> 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. 

mmm... Mach ich bei SuSE auch immer so... Ist manchmal bißchen
komisch, ja, aber geht irgendwie.

> Bei RH kann ich gleich bei der Installation alles RH-Tools
> abschalten, und das Ding rennt immer noch.

Bei SuSE doch genauso? Ich glaub, eigentlich nimmt sich das alles
nix, heißt nur anders.

> 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. 

Na ja, oft hilft rpm --nodeps :) Das Problem hat SuSE aber auch
teils. Manchmal ist das ja auch klar: da werden libs gelinkt, die
müssen dann eben da sein. Inzwischen haben ja viele libs eingene
Packete, die dann nicht mehr von Anwendungen abhängen, aber RPM
bauen ist nicht so einfach, da kann sich schnell sowas
einschleichen. Ich hatte mal angefangen, ein paar RPM
Abhängigkeiten zu korrigieren, daß geht oft nicht so "schön",
ohne auf Funktionen zu verzichten. Seit ich die Schwierigkeiten
kenne, bin ich hier deutlich ruhiger geworden :)

> welche wiederum... und schwupps! hat man Windows NT Server auf
> der Mühle.

Ja, nervig... Wie installiert man X? Xterm und auto-depenencies
:) Na ja, so ungefähr jedenfalls. Na, hier macht das ja auch
oft Sinn, aber was ist, wenn ich mein xterm niemals auf lokalem
Display starten möchte? Inzwischen hat SuSE das aber hingekriegt
:)

Noch schöner ist es bei KDE oder bei PHP. PHP braucht in der
Regel auch die neuesten Beta(!) Versionen von tausenden von Libs.
Das liegt aber weniger an den Distries, sondern an der Software.

> > > 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 finde, man muß es nicht wissen, solange es funktioniert. Wenn
es nicht funktioniert, oder man es aus anderen Gründen wissen
möchte, muß man es sowohl herrauskriegen als auch ändern können.

Hier geht es oft schon los: wie debugt man den Bootablauf, wenn
man keine Console dranhat? Hier gibt's oft einfach keinen
vernünftigen Mechanismus. Gleiches gilt natürlich auch für
shutdown, hier ist's oft noch schwieriger bis unmöglich.

> > 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. 

Ja, sollte man, aber wenn man sich den Muß so anguckt, sieht man
oft: es muß einfach gehen, 95% genau reicht, wenn dafür recht gut
geht. Wie bei Windows. Aber kann man SuSE einen Vorwurf machen?
Oder RH? Das sind Unternehmen, die Geld verdienen müssen. In den
letzten Jahren kam immer stärker durch, daß die Leute es eben
genau so haben wollen (bis auf die, die Debian "kaufen" :)). Also
macht man das eben so. Für mich persönlich ist das Schade, ich
will lieber eine sichere Firewall, die ich unter Kontrolle hab,
als eine, die sich halbautomatisch unter merkwürdigen Annahmen
konfiguriert, und ich bei den hunderten erzeugten Regeln keine
Lust mehr auf Debuggen hab...

> 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, 

Warum so? Ich starte mein Firewall script mit S04, also vor
network. Wegen remote-syslogging läuft syslog da leider noch
nicht, aber geht hier wohl nicht anders (mein Firewallscript
verwendet syslog für Fehlermeldungen, nicht stdout, was eh keiner
liest, wenn keine Console dran ist!). Die Firewall ist also zu
erst korrekt konfiguriert. Die Zeiten, in denen Interfaces da
sein müssen, um Regeln anzubinden, sind seit ipchains vorbei (ich
stehe noch auf chains-Stand wegen mangels an Einarbeitungszeit;
wie Du schon sagst, muß man sich dafür schon etwas Zeit nehmen,
soll dabei was rauskommen).

> 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?

Ich möchte das z.B. anders. Firewall, Netzwerk, syslog (so früh
wie eben möglich), dann DNS mit "außen reden", brauch er ja, dann
falls gewünscht PostgreSQL und Apache (aber nicht auf der
gleichen Maschine, falls möglich :)). 

> 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. 

Ja, SuSE fängt auch in ip-up an, Firewall umzukonfigurieren.
Könnte ich ausrasten bei solchem Mist! Warum zum Geier? Meine
Firewall ist so aufgebaut, daß sie immer paßt. Warum geht beim
Anwählen eines dial-in kurz kein DNS mehr? Fetzt, kriegt man
komische Phänomene, wenn man Pech hat!

Der Hammer ist überhaupt, daß ip-up nie so gemacht ist, daß man
es parallel starten kann. Was ist, wenn zwei Interfaces im
Abstand von 1 Sekunden up gehen, oder eines up, ein anderes down,
und die Firewall 3 Sekunden für's Setup braucht? Was kommt dann
für ne Konfig bei raus? Doch garantiert irgendein Mist.
Netterweise merkt man das dann vielleicht gar nicht, wie auch,
man guckt sich das ja nicht ständig an. Wie kommt man auf solche
Ideen? Warum loggt ip-up nicht über syslog? Na gut, weil
überhaupt keine Fehlerbehandlung gemacht wird, aber warum nicht?!

> 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.

In den paar Sekunden fällt dann aber vielleicht Deine
rest-Anbindung aus! Der Server ist im dunkeln, ne SSH Verbindung
reißt dabei (angeblich) öfter mal ab, selbst wenn idle, und wozu
das ganze? Kann man doch gleich richtig einstellen. Firewall
einmal konfigurieren und gut.

> 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. 

Genau! Das suggeriert aber zum Kompott noch Sicherheit, die
vielleicht gar nicht da ist, weil irgendjemand aktives FTP
erlaubt hat, und damit auch PostgreSQL (port 5432) in
"Gegenrichtung" geöffent hat, weil aktives FTP ja
"zurück connected". Da darf also jemand von "innen" nach "außen"
ins Internet aktives FTP machen, und damit darf dann jeder auch
die Datenbank connecten... Alles schon gesehen!

> 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.

Dann heißt es wieder "RedHat geht gar nicht". Erinnere mich
damals an die HTML Fehlerdiskussion. Es hieß, warum amcht
Netscape nicht ne Fehlermeldung, wenn die Seite falsch ist,
anstatt die anzuzeigen? Ganz einfach: die Leute fixen dann nicht
ihre Seiten, weil "Internet Explorer kann das, Netscape macht da
irgendwelche komischen Fehler". Die Diskussion hatten wir
irgendwo mal vor Jahren. Inzwischen sind Seiten
"InternetExplorer 800x600, JavaScript, Active-X-Hallo-Du und weiß
ich was optimiert". Das ist leider Praxis!

> 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...

genau, hier müssen die Annahmen eben nicht stimmen. Vielleicht
hab ich ne Datenbank, die soviel Speicher nimmt, wie sie kriegen
kann, die also durch swap ausgebremst wird. Vielleicht hab ich ne
Kiste mit 512MB ohne lokale Disk und möchte überhaupt keinen
Swap. Vielleicht hab ich aber gerade ne 10 GB Platte dran, weil
ich nicht gerne CD wechsle. Kann ein Tool nicht wissen.

> 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.

Na ja, ich möchte jetzt keine mySQL Diskussion, aber "LAMP" ist
oft in Verwendung durch Leute, die überhaupt nicht wissen, was
sie tun. Nie programmiert, aber PHP hacken, drei Tabellen in
mySQL anlegen und das Datenbank nennen, was willste da machen! Ne
Datenbank lebt von Konsistenz, das braucht Datenbankseitige
Logik, und wenn eine GUI genau das nicht anbietet, behaupte ich
eben, daß sie Mist ist, und rate davon ab; schließlich fördert
das ja gerade wieder so ne Tabellensammlungen, die dann Datenbank
heißt. Dann kommen Leute an, die Datenbanken mit komplexen
Konsistenzbedinungen in einem Tag haben wollen. Sagt man, das das
so schnell nicht geht, kommen die mit so einer mySQL Halblösung,
und glauben einfach nicht, daß das in Produktion Mist ist.
Deshalb dann lieber gar keine Guis, dann kommt wenigestens keiner
ohne Ahnung und behauptet, ist doch alles ganz einfach.

> 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.

Nee, man kann sowas auf zur Laufzeit- oder mindestens Startzeit
einstellen. Meistens jedenfalls.

In der Praxis knien sich IMHO die Leute eben oft nicht rein,
sondern haben irgendwas, was (erstmal, irgendwie) funktioniert,
und das geht dann in Produktion. Später stellt sich dann herraus,
daß es massive Probleme gibt - das liegt dann natürlich NIE an
dem schlechten Datenbank-Design oder fehlendem Wissen über
Normalformen...

Und *das* macht mir eben keinen Spaß!

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.