[PATCH] modusers

[olistudent]

So ganz verstanden hab ich deine Änderung jetzt nicht. Du sagst, dass es nicht nötig ist beides (nicht exportieren und Env löschen) zu machen. Wieso hast du dann beides eingebaut?
Außerdem tritt doch jetzt (mit modlib_loadconfig) genau der Fall auf, dass der Aufruf von
/mod/etc/default.$DAEMON/${DAEMON}_conf aus dem rc-Skript nicht mehr funktioniert, wie oben von mehle für lighttpd beschrieben?

MfG Oliver

 

[RalfFriedl]

Hauptsächlich liegt es daran, daß ich damit angefangen habe, die eingelesenen Variablen nicht zu exportieren (modlib_loadconfig). Dann habe ich den Aufruf mit env von Dir gesehen und gedacht, daß ist auch eine gute Idee, da nimmt man gleich nur das nötigste.

Allerdings stimmt es, daß das Erstellen der Konfigurationsdateien auf diese Art nicht funktioniert, wahrscheinlich bei keinem Paket.

Dann ist es besser, Deinen Ansatz zu verwenden und das Environment komplett zu löschen, soweit es möglich ist.

 

[mehle]

@RalfFriedl: wie soll ich nun deine Änderungen in einem rc Skript verwenden?

Ciao
Stephan

 

[RalfFriedl]

Meine erste Idee, die Variablen erst gar nicht ins Environment zu exportieren, funktioniert nicht, weil die Start-Skripte bei vielen Diensten ein externes Skript aufrufen, das die Config-Datei erstellen soll. Ich habe daher das "alias export=" in der Funktion wieder entfernt. Durch die Änderung kann man aber mit einer zusätzlichen gesetzten Variable die Konfiguration gleich einlesen lassen, auch wenn die Datei anders heißt als der daemon dazu. Dies betrifft die Kern-Dienste, deren Konfiguration in /mod/etc/conf/mod.cfg steht.

Die andere Funktion greift die Idee von Oliver auf, statt dessen den Dienst mit einem minimalen Environment zu starten. modlib_startdaemon zu schreiben ist zwar nicht kürzer als 'env - PATH="$PATH"', aber wenn sich herausstellen sollte, daß man sinnvollerweise noch andere Pfade mit übergibt, hätte man eine zentrale Stelle, wo man das ändern kann.

Zum Beispiel rc.telnetd Zeile 20:

# vorher
$DAEMON -l /sbin/ar7login
# nachher
modlib_startdaemon $DAEMON -l /sbin/ar7login

Zum Testen kann man die Änderung im RAM der Box machen und ausprobieren, ob der Dienst danach noch funktioniert. So spart man sich, das gleich zu Flashen. Also ungefähr so:

cp /etc/init.d/rc.telnetd /tmp
Ersetzen wie oben beschrieben
/tmp/rc.telnetd restart
# Schauen, ob es funktioniert

 

[mehle]

Dieser Patch funktioniert erst einmal gut.

Aber warum muss es denn in den rc Dateien geändert werden? Wenn es da gemacht werden soll, werden mit Sicherheit einige Löcher irgendwo über bleiben.

Warum kann denn die rc Datei nicht gleich mit der Umgebung gestartet werden, die auch vom Webfrontend geschaffen wird?

Das Webfrontend (mit olistudent's Änderungen) startet die rc Datei mit den Variablen des zu startenden Dienstes. Damit brauchen wir keine Änderungen an den rc Dateien. Genau so sollte IMHO das Starten der rc Dateien von der Kommandozeile auch aussehen.

Ciao
Stephan

 

[olistudent]

Wenn man den Daemon nicht mit "env -" startet, dann gibt es in den Dateien von mod.cfg wieder das Passwort im Environment. Außer man fügt in diesen Dateien die von Ralf rückgängig gemachte Änderung mit dem "export alias= " ein.

MfG Oliver

 

[RalfFriedl]

Das Webfrontend (mit olistudent's Änderungen) startet die rc Datei mit den Variablen des zu startenden Dienstes. Damit brauchen wir keine Änderungen an den rc Dateien. Genau so sollte IMHO das Starten der rc Dateien von der Kommandozeile auch aussehen.

Vielleicht reden wir hier etwas aneinander vorbei.

Olivers Änderung funktioniert deswegen, weil er den Aufruf des rc-Skripts geändert hat von "rc.pkg" in "env - rc.pkg" (leicht gekürzt). Dadurch wird das rc-Skript mit einem leeren Environment aufgerufen. Für diese Änderung spricht, daß er nur an wenigen Stellen etwas ändern mußte.

Gegen diese Änderung spricht, daß diese Änderung keine Auswirkungen auf den manuellen Start hat. Man müßte also immer, wenn man an der Kommandozeile ein rc-Skript aufruft, auch das "env - " davor schreiben, also jedes mal von Hand eintippen. Da halte ich es für sinnvoller, wenn man sich einmal die rc-Skripte vornimmt und das dort ändert, so daß der Aufruf von der Kommandozeile so bleibt, wie man es gewohnt ist.

 

[mehle]

Wenn nun das rc Skript geändert wird, dann brauchen wir ja olistudent's Änderung im Webfrontend nicht mehr, oder?

Ist jetzt der Patch in trunk nun beschlossene Sache? Wenn ja, dann kann ich ja ein paar Patches für rc Skripte beisteuern.

Ciao
Stephan

 

[mehle]

Hier Patches für lighttpd und dropbear. OpenVPN kommt auch noch.

Ciao
Stephan

 

[mehle]

Bitte den dropbear patch NICHT nutzen - dropbear started damit nicht :-(

Ciao
Stephan

 

[olistudent]

Da fehlt dann wohl die ein oder andere Umgebungsvariable (TERM?).

MfG Oliver

 

[RalfFriedl]

Nein, viel einfacher: in der Start-Datei fehlt das Include von /etc/init.d/modlibrc, daher ist modlib_startdaemon unbekannt. Mit dem Include funktioniert es.

Der dropbear Server braucht keine TERM-Variable, die wird vom jeweiligen Client übergeben, wenn eine Verbindung aufgebaut wird.

PS:
Ich habe das im SVN geändert.

 

[olistudent]

Ups. An so was triviales hab ich gar nicht gedacht.

MfG Oliver

 

[mehle]

Ah, ok - @olistudent: kannst du dann diese kleine Änderung noch Aufnehmen und alles ins SVN schieben?

Danke
Stephan

 

[olistudent]

http://trac.freetz.org/changeset/3262

Sind meine Änderungen okay?

MfG Oliver

 

[mehle]

Die Änderungen sind klasse, danke.

Ciao
Stephan

 

[mehle]

Dort wird schon 600 für shadow und gshadow gesetzt. Allerdings sind in der TAR-Datei trotzdem nicht diese Rechte. Das liegt an dieser Zeile:

"$TAR" -c --owner=0 --group=0 [B]--mode=0755[/B] --format=oldgnu -C "$VARTAR_MOD_DIR" . > "$VARTAR_MOD" || exit 1

Das mode sollte hier entfernt werden. Es bringt nichts, vorher gezielt Rechte für Dateien zu vergeben und diese nachher zu überschreiben.

Bei mir ist immer noch die /tmp/shadow und /tmp/gshadow 755. Weiterhin sind die /tmp/flash/users/[shadow|gshadow] 755.

Bitte, können wir dies ändern?

Danke
Stephan

 

[RalfFriedl]

Zumindest im Trunc ist diese Änderung schon seit April drin.
Hast Du eine ältere Version, oder einen Branch, wo das noch anders ist?

 

[mehle]

Ich fahre mit trunk 3604. Zumindest in modusers ist kein chmod oder ähnliches. Wo wird denn dieses tar gemacht, wovon du schreibst?

/tmp/flash/users ist 700, aber die Dateien darin nicht. Und in modusers:save() wird kein chmod gemacht. Vielleicht ist deine tar-Änderung schon in trunk, bezieht sich aber nur auf vorher unberührte Boxen?

Ciao
Stephan

 

[cuma]

Das ganze wird wohl keine Auswirkung auf im Flash existierende Dateien haben