[linux-l] wie netatalk starten (wg. veraenderter rc.config-...

Steffen Dettmer steffen at dett.de
Sa Mai 4 21:09:23 CEST 2002


* Roland Penzin wrote on Sat, May 04, 2002 at 10:34 +0200:
> Am Freitag, 3. Mai 2002 09:15 schrieb Hannes Stein:
> vorher, also bis 7.3 hatten wir die situation, dass _alle_ 
> start-stop-skripte in den verzeichnissen standen.

insserv/insserv -r müßte auch bei 7.3 gehen, solange der RC parameter auf
"yes" steht.

> sie haben diese dinge aber noch in den skripten drin delassen, zur 
> sicherheit. ich denke, zur naechsten version fliegt das dann auch raus.

Würde ich gut finden, wenn es überhaupt drin bleibt, weil die die
updates auch auf älteren SuSEs funktionieren könnten. Meistens
hapert das ja an genau solchen Kleinigkeiten. Aber darum hat sich
SuSE nie sehr bemüht, die Packete waren immer individuell.

> es ist ja auch irgendwie intelligent. man ueberlege mal, die ganze 
> offenlegung der programmierung verleitet uns doch, an den skripten was zu 
> aendern.

Ja, deshalb nehme ich ja GNU/Linux. Hat man die Sourcen, daß geht
eben bei init Scripten los. Inzwischen ändere ich die ungern,
weil das bei updates etc. immer klappert. 

> und gerage im ISDN - bereich koennte man einiges aendern. als ich 
> anfing, war isdn nur mit handauflegen in gang zu bringen (z.B. 5.1).  

Na ja, die Startscripte haben auch an Qualität gewonnen, weil
Benutzer öfter mal einen Patch an SuSE geschickt haben. Gerade
bei ISDN sah man das interne Chaos recht deutlich: erst wurde es
unterschätzt, dann mehrfach umgebaut. Meine ISDN-Konfig steht
jetzt in irgetwas /etc/rc.config.d/*unkown*, weil das mergen beim
update da so viel reingeschmissen hat. Dabei sourcen die Scripte
eh fast alles, was da rum liegt. Na ja, egal. Geht ja. Damit kann
man auch nette Sachen machen, z.B. kann man da ja auch Kommandos
reinschreiben, anstatt:

START_MYSERVICE="yes"

vielleicht

START_MYSERVICE="no"
test -e /etc/start/myservice && START_MYSERVICE="yes"

oder sowas. Ist aber auch ne Falle:

START_MYSERVICE=`rm -rf wichtiges_Verzeichnis`

oder sowas ist möglich. Na ja. 

> inzwischen (7.3) gibt es da keine probleme, soweit ich weiss.

Ja, irgentwie geht das inzwischen westenlich einfacher...

> hat sich jemand aus den vorhandenen suse - skripten seine eigene loegung 
> gestrickt, waere er jetzt, mit dem neuen system, voellich aufgeschmissen, 
> wenn sie ihm nicht seine variablen aus rc.config gelassen haetten.

Wieso, er kann ja seine Scripte weiterhin mit seiner rc.config
verwenden, wenn er möchte. Kann man machen, wie man möchte. Ich
denke, rc.config gab es hauptsächlich, weil dieses File für yast
am einfachsten zu verwalten war. Ist gebastelt, daß sieht man.
Aber SuSE ist inzwischen schon viel sauberer geworden. Da ist
inzwischen auch ne ganze Menge Entwicklungsaufwand drin. insserv
gabs vielleicht zu 4.4.1 Zeiten oder so noch gar nicht, wer weiß.

> ich glaube, aus dem grund befinden sie sich noch in den skripten, obwohl 
> sie sich teilweise ausgelebt haben.

Denke, hier konkret ist das einfach liegengeblieben, weil's
keiner rausgeschmissen hat...

> insserv kannst du, nach meinen erfahrungen, parallel mit yast(2) verwenden. 
> in unserem fall (atalkd) hat insserv nur die K21atalkd & S21atalkd - links 
> erzeugt. siehe (auch) oben. das macht yast auch, genauso.

Ja, schätze, daß yast2 einfach nur insserv aufruft.

> > Ich werde es zwar nicht machen, weil ich froh bin, dass das Zeugs
> > endlich laeuft, aber ich schaetze, dass er das schon abfragt.
> 
> _das_ habe ich eben nicht finden koennen.

Abfragt schon, nur setzt niemand diese Variable. Und die
Möglichkeit von 

NETATALK=no rcnetatalk start

macht in meinen Augen auch keinen Sinn...

> > In welcher Datei veraendert inserv eigentlich was?
> 
> die start-stop-skripte. weiterreichende aktionen konnte ich nicht 
> entdecken.

Ja, es guckt an Hand der "Kommentare", in welcher Reihenfolge der
Kram zu starten ist. Auch nicht ideal, aber immerhin nicht ganz
schlecht :)

oki,

Steffen

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



Mehr Informationen über die Mailingliste linux-l