[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Dbian 2.2r3] System-Administration



Eduard Bloch <edi@gmx.de> writes:

> > runterschreiben können und ebenso die genauen Probleme, Schwierigkeiten und
> > Stärken eines ganz speziellen MTAs den ich einsetze bis ins letzte Detail
> > kennen, ohne dass ich mich zwangsläufig mit den Details der
> > Konfigurationsdatei und ihrer Syntax auseinandersetzen muss. Die Arbeitsweise
> 
> Warum werde ich das Gefühl nicht los, du hast noch nie etwas derartiges
> zuverlässig implementiert? Was du da von dir ablässt, errinert an den

Sorry, du hast mich falsch verstanden. Das "runterschreiben" war bezogen auf
einen wirklich simplen MTA, ohne große Extras, ohne großartige Fehlertoleranz
etc. Es sollte nur unterstreichen, dass sich jemand wirklich gut mit einem
Problembereich auskennt, ohne sich mit den Details z.B. der sendmail.cf
auskennen zu müssen. Eben weil die Arbeitsweise einer Software völlig
unabhängig von der Syntax ihrer Konfigurationsdatei ist -- sonst könnte man ja
z.B. für exim nicht eine völlig andere Syntax als für sendmail wählen.

Und wenn die Syntax und der Aufbau der Konfigurationsdatei eben nicht fest an
an ein Programm und seine Arbeitsweise gekoppelt ist, dann kann ich auch eine
andere Syntax wählen -- also ist es prinzipiell möglich, allen Programmen
dieselbe Konfigurationsdatei-Syntax vorzusetzen oder eben umgekehrt einen
Adapter zu benutzen, der eine Syntax in eine andere umsetzt (und da praktisch
alle Konfigurationsdateien aus regulären Sprachen aufgebaut sind, kann eine
solche Umsetzung sogar effizient implementiert und in linearer Zeit
durchgeführt werden).

Wenn du bis hierhin zustimmen konnest, musst du auch zustimmen, dass es völlig
egal ist, ob ich eine Konfigurations in einer Textdatei vornehme, indem ich
dort ein Wort reinschreibe, oder ob ich in einem Browser eine Checkbox
anklicke. Und das war einer der Punkte, der bestritten wurde.

> Wo bist du eigentlich die letzten 10 Jahre gewesen? Abgesehen von z.B.
> sendmail-Konfiguration (ohne Hilfsmittel) wirst du bei den meisten MTAs
> mehr oder weniger sinnvoll organisierte Konfigurationsdateien finden,
> mit recht aussagekräftigen Variablennamen. Beispiel: Exim, Debians
> Default-MTA.

sendmail.cf diente mir ja auch nur als Extrembeispiel. Mit einem Tool wie
Webmin kann man halt auch bei Exim und Co noch einiges gewinnen.

> Mag sein. Der Trend geht aber schon in diese Richtung:
> gemeinsamme Konfig-Parser, Options-Parser usw. sind nicht selten.

Richtig, sowas meine ich. Langsam merken die Leute, dass es schlicht
hirnverbrannt ist, für jedes neue Programm, die Lieblingssyntax des Tages zu
benutzen. Und diesen Trend kann man durchaus noch verstärken. Und ob man eine
Vereinheitlichung nun auf unterster Ebene durch einheitliche Konfig-Syntax
erreicht oder durch einen Adaper a la Webmin, ist doch eher nebensächlich. Und
genau darauf wollte ich hinaus.

> > Ich will also nichts anderes, als eine Adaptionsschicht, so dass mir für meine
> > Arbeit eine kohärente und übersichtiche Syntax bzw. ein übersichtliches UI
> > geboten wird, die dann von der Adaptionsschicht in die konkrete Syntax der
> > Wahl der jeweiligen Programme umgesetzt wird.
> 
> Nennt sich z.B. Debconf. Da werden bekannte Sachen abgefragt,
> abgespeichert, und die Config-Dateien ggf. neugeneriert.

Nein, das will ich ja gerade nicht! Webmin integriert sich transparent ins
System, d.h. da werden keine Dateien generiert und damit werden auch keine von
Hand gemachten Änderungen und/oder Kommentare gelöscht. Es sollen auch nicht
ein paar Dinge abgefragt werden, sondern wirklich alle verfügbaren
Einstellungen eines Programms sollen auch voll unterstützt werden. Stell dir
sowas wie (X)Emacs/AucTeX angepasst für jede Konfigurationsdatei vor, dann
weißt du, was ich gerne hätte.

> Webmin macht das im Prinzip nicht viel anders. Das Problem muss man halt
> an der Wurzel packen, nur ist es halt nicht einfach realisierbar.
> Theoretisch muss man für jede einzelne, per UI und per Config-File
> konfigurierbare Option eine kleine KI entwerfen, die die Funktionsweise

Was für eine KI? Völliger Unsinn. Du musst einfach nur für jedes Programm ein
Modul haben, dass dann halt den Aufbau der Konfigurationsdatei kennst, sie
lesen kann (dafür nimmt man im schlimmsten Fall denselben Parser, den auch das
jeweilige Programm benutzt) und halt Kommentare nicht ersatzlos streicht,
sondern beibehält. Das ist kein Kunststück und nichts imens kompliziertes,
denn es wird beim Einlesen dasselbe gemacht, was auch das Programm selbst
machen würde -- dazu dann ein kleines Interface, um die aktuellen
Konfigurationen zu präsentieren und modifizierbar zu machen und alles wieder
wegschreiben. Siehe z.B. auch SWAT -- das Ding merkt sich allerdings die
ursprünglichen Inhalte und vor allem die vorhandenen Kommentare nicht, aber
das einzubauen ist nahezu trivial.

> Was hast du nur für ein Problem mit den Konfig-Dateien? Falls

Was findet ihr an Textdateien so geil, dass ihr alles andere verteufelt?

> > Teil von Einstellungen ermöglicht, ich will nicht wie eximconfig, dass mir ein
> > paar Fragen stellt und daraus eine Standardkonfiguration erzeugt. Ich will
> > vollen Zugriff auf alle Einstellmöglichkeiten.
> 
> Dann würde man sich ins eigene Fleisch schneiden, früher oder später.

Wieso? Was ist der Unterschied zu den Textdateien? Da kann ich mir ja auch ins
eigene Fleisch schneiden.

> > Angefangen bei der Treiberinstallation (hier macht sich dann doch Linus
> > Beharren auf den Verzicht von Binärschnittstellen für Treiber negativ
> 
> Es gibt binäre Schnittstellen, diese sind aber nicht zwischen den
> grösseren Kernel-Generationen kompatibel. Aber das ist technisch nicht

Falsch! Es gibt keine binäre Treiberschnittstelle in Linux. Ein Treiber, der
für Linux-2.2.1 kompliert wurde, wird nicht mit Linux-2.2.2 oder Linux-2.2.0
laufen, selbst wenn sich am entsprechenden Teil des Kernel nicht mal ein
einziges Bit verändert hat. Es gibt nur reine Sourcecode-Schnittstellen für
Treiber, ein Treiber muss immer für exakt den Kernel compiliert sein, mit dem
er zusammenarbeiten soll. Selbst ein Treiber für 2.2.2 arbeitet unter
Umständen nicht mit einem Kernel 2.2.2 zusammen, selbst wenn alle nötigen
sonstigen Optionen richtig gesetzt sind.

Und genau dieses Problem ist kein Zufall oder ein Bug, sondern ein Feature,
sprich von Linus (und vielen anderen) *gewollt*.

-- 
Until the next mail...,
Stefan.

-- 
-----------------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie bitte eine
E-Mail an debian-user-de-request@lehmanns.de die im Subject
"unsubscribe <deine_email_adresse>" enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@Lehmanns.de
-----------------------------------------------------------

832 eingetragene Mitglieder in dieser Liste.


Reply to: