subversion für freetz

[cuma]

vielleicht hast Du nur vergessen, nach dem Umstellen auf manuell, den Dienst zu beenden oder dieser aus irgendwelchen anderen Gründen nicht beendet werden konnte, das wäre dann aber ein komplett anderes Problem.

Den svnserve aus dem Binary-Paket musst ich auch schon öfter mit "kill -9" beenden, das scheint öfter mal aufzutreten

 

[RalfFriedl]

Temporäre Lösung

chmod 1777 /var/tmp

Die Rechte 1777 für tmp sind üblich auf UNIX-Systemen. Ich würde es daher nicht als temporäre Lösung betrachten.

 

[er13]

Die Rechte 1777 für tmp sind üblich auf UNIX-Systemen. Ich würde es daher nicht als temporäre Lösung betrachten.

temporär im Sinne, dass es ein Reboot nicht übersteht (sofern man es in rc.custom nicht einträgt) und auch im Sinne "bis der angehängte Patch seinen Weg in trunk findet" Inhaltlich unterscheiden sich die beiden Lösungen ja nicht - beide setzen die Rechte von /var/tmp auf 1777. Der Patch macht es allerdings bereits beim Erstellen des Images. Die Frage ist eher, gibt es irgendwelche AVM/FritzBox spezifischen Gründe, die dagegen sprechen (z.B. dass /var/tmp sich in RAM befindet) - ich bin der Meinung nein, aber vielleicht entgeht mir etwas.

 

[cuma]

Es könnte ungeahnte Auswirkungen nach sich ziehen?!

 

[er13]

Den svnserve aus dem Binary-Paket musst ich auch schon öfter mit "kill -9" beenden, das scheint öfter mal aufzutreten

Hmm, bei mir noch nie, es dauert manchmal ein wenig bis der Prozess beendet wird (daher habe ich beim Restart ein "sleep 2" eingebaut), aber ein "kill $pid" aus modlib_stop hat bisher immer ausgereicht. Was liefert denn der letzte(bevor der Prozess hängen bleibt) "rc.subversion stop"-Aufruf - "done", killt den Prozess aber nicht, oder "failed"?

 

[cuma]

Wie gesagt, war nur eine Binary ohne rc-Skript

 

[er13]

Es könnte ungeahnte Auswirkungen nach sich ziehen?!

nicht dass ich wüsste, ich wollte mich halt vor dem Einchecken absichern und sonst nichts

 

[cuma]

nicht dass ich wüsste

deshalb ja ungeahnte Auswirkungen...

 

[RalfFriedl]

Ok, wenn es Auswirkungen hat, dann sind sie ungeahnt. Da aber normale Linux-System die gleichen Rechte haben, spricht bis jetzt nichts dagegen.

 

[cuma]

Bei normalen Linux-Systemen liegen aber keine Systemeinstllungen im tmp Verzeichnis. Somit wären die ganzen Bemühungen mit anderen unpriviligierten Benutzern unnütz, da jeder User alles ändern kann. In /tmp/flash liegen dann auch noch alle Freetz-Dateien.

 

[RalfFriedl]

Dann könnte man überdenken, ob man Systemeinstellungen im tmp-Verzeichnis ablegt.

Andererseits bedeutet 1777 nicht, daß jeder etwas an den Einstellungen ändern kann.

 

[er13]

da jeder User alles ändern kann.

Das stimmt so ganz und gar nicht, s. z.B. hier. Das einzige, was ein bösartiger User machen kann, ist irgendeine Config-Datei anlegen, die es nocht nicht gibt. Er kann aber keine der existierenden Dateien löschen oder umbennen - das verhindert das Sticky Bit an dem Directory. Eine Datei verändern kann er auch nur dann, wenn die Permissions an dieser es ihm erlauben. Das letzte gilt aber auch dann, wenn /var/tmp 755 als Rechte hat - d.h. Änderung der Rechte von 755 in 1777 ändert in dieser Hinsicht nichts.

 

[cuma]

Ja stimmt. Allerdings nur solange sich die Programme an diese Konvention halten. Bei mir hat die /tmp/resolv.conf die Rechte 777

 

[er13]

Ja stimmt. Allerdings nur solange sich die Programme an diese Konvention halten. Bei mir hat die /tmp/resolv.conf die Rechte 777

wie gesagt, ob /tmp 755 oder 1777 als Rechte hat, spielt keine Rolle, Deine /tmp/resolv.conf kann aufgrund dessen, dass sie selbst 777 als Permissions hat, von jedem verändert werden... Mein Patch aus #40 korrigiert übrigens dieses Problem mit resolv.conf-Rechten. Ich tendiere stark dazu, den einzuchecken...

 

[cuma]

Da kann ich nur sagen m'kay.

 

[er13]

Hi, könnte ihr das SSL noch statisch ermöglichen? Ich hab eine libcrypto-Warnung :-(

erledigt in 3778 und 3779

 

[astrapi]

Wenn ich per "chmod 1777 /var/tmp" die Rechte setze und inetd per WebIF neustarte, bleibt alles beim alten. Beim Zugriff per RapidSVN erscheint die Meldung "Error: Error while refreshing filelist (Fehlerhafte Netzwerkdaten). Habe die IP's 0.0.0.0, 127.0.0.1 und die IP der fb getestet, ohne Erfolg. Nach dem Umstellen auf "normalen" Start, klappt der Zugriff.

Log ist aktiviert und bleibt im inetd-Modus leer.

 

[cuma]

Cool, hab es eben ausprobiert. Mir ist aufgefallen, dass FREETZ_LIB_libneon_WITH_SSL=y und FREETZ_LIB_libneon_WITH_ZLIB=y noch gesetzt sind. Ist das ok?

 

[er13]

Edit frank_m24: Zwei Beiträge zusammengefasst. Man kann seine Beiträge auch editieren.

Mir ist aufgefallen, dass FREETZ_LIB_libneon_WITH_SSL=y und FREETZ_LIB_libneon_WITH_ZLIB=y noch gesetzt sind. Ist das ok?

ja, es ist ok und sogar genau das, was man haben will, hat mich zunächst mal auch irritiert (daher 3779). Die Selects einer menuconfig-Suboption werden nur/erst dann ausgeführt, wenn der Suboption-Depend selektiert ist/wird, die Suboption bleibt aber an sich ausgewählt. Um libneon mit SSL Support zu bauen, muss FREETZ_LIB_libneon_WITH_SSL selektiert sein, aus dem Makefile kannst Du es mittels DEPENDS_ON nicht mehr erzwingen.

Edit frank_m24: Beitrag 2:.

Habe die IP's 0.0.0.0, 127.0.0.1 und die IP der fb getestet, ohne Erfolg.

Im inetd-Modus spielt die Bind-Adresse-Einstellung (momentan noch) keine Rolle, muss mich schlau machen, wie und ob das überhaupt geht

Wenn ich per "chmod 1777 /var/tmp" die Rechte setze und inetd per WebIF neustarte, bleibt alles beim alten. Beim Zugriff per RapidSVN erscheint die Meldung "Error: Error while refreshing filelist (Fehlerhafte Netzwerkdaten).
Nach dem Umstellen auf "normalen" Start, klappt der Zugriff.

Ich bin leider mit meinem Latein am Ende. Bei mir läuft der Server mittlerweile ausschließlich im inetd-Modus unter dem svn-user und es gibt keine Probleme. Könntest Du bitte alle Schritte, die du machst, der Reihe nach nochmal beschreiben, damit ich das Problem vielleicht doch noch nachstellen kann. Ich würde Dich auch bitten diese selbst nochmals auszuführen, vorher entferne bitte Deinen manuell gemachten svnserve betreffenden Eintrag aus inetd-Konfigdatei. Beim Umstellen von manuell/automatisch auf inetd vergewissere Dich bitte, dass der svnserve-Prozess auch tatsächlich beendet wird, kille ihn mit -9 wenn es sein muss.

Versuch' auch bitte mit irgendeinem anderen Client zuzugreifen (z.B. Eclipse oder TortoiseSVN). Versuch' von der Box aus auf den auf ihr laufenden Server über svn-Protokoll zuzugreifen.

Läuft bei Dir sonst irgendein Dienst im inetd-Modus. Gibt es da Probleme, ist Deine manuell editierte inetd-Konfigdatei vielleicht fehlerhaft, kommentiere alles testweise aus.

Danke!

Log ist aktiviert und bleibt im inetd-Modus leer.

Die Logdatei müsste eigentlich AccessLog heißen, da werden nur Zugriffe protokolliert und keine Fehler...

 

[cuma]

Statisch gelinkt brauchen die svn-Dateien übrigens 4 mb mehr im Image ^^