Subversion auf Fritzbox

hi nochmal,

wenn man eh schon am Editieren der debug.cfg ist, kann man das virtuelle interface auch gleich mit einbauen:
"ifconfig lan:1 192.168.178.244 netmask 255.255.255.0"
Dann in der Benutzeroberfläche unter Portfreigabe unter "Andere Anwendungen" den TCP-Port 3690 auf die Adresse 192.168.178.244 weiterleiten.

PS: bekomme eben auf dem Telnet folgenden Fehler:
Mar 15 18:31:30 dsld[1316]: internet: 192.168.178.244 not an intern host, forwardrule "tcp 0.0.0.0:3690 192.168.178.244:
3690 0 # SVNonFRITZ" ignored

Der Zugriff (natürlich nur von "innen" getestet) über dyndns funzt aber.

Am ssh arbeite ich noch.

danke für die antwort
diese netzwerkkarte ist schon bei mir eingerichtet, habe die freigabe gemacht.
wie greife ich denn jetzt auf svn zu? svn://.....dyndns.org:3690/repository geht nicht

@radislav: Sollte aber gehen. Welche Fehlermeldung bekommst du? Wie genau hast du svnserve aufgerufen? Also mit welchen Parametern?
@fabianhu: Die Meldung tritt afaik immer auf, wenn du an ein virtuelles Interface weiterleitest. Die Weiterleitung funktioniert aber trotzdem.

@HAL 9000: tortoiseSVN sagt: cannt connect to host "....dyndns.org" kann es daran liegen, dass ich es nicht von extern versuche (also mit dem pc, der an die fritzbox angeschloßen ist)?
hier ist der ausschnitt mit dem aufruf in debug.cfg:
#>> svn
cd /var/media/ftp/$HDD/svn
./svnserve -d -r ./
#<< svn

@radislav: bist du sicher, dass deine dyndns-Konfiguration überhaupt geht?
versuch mal auf deinem PC: ping DeinHost.dyndns.org
Es sollte eine Antwort von der externen IP deiner Fritzbox kommen.

ansonsten mal die debug.cfg leeren und die einzelnen Kommandos über telnet "zu Fuß" ausführen. evtl. gibt's ja einen Fehler.

@HAL9000 ...blöde Meldung, wenn's dann trotzdem geht.

@fabianhu: dyndns geht sicherlich - habe auch nochmal mit ping getestet. ich versuche vielleicht fritzbox neuzustarten:
neugestartet, prozess gekillt, nochmal gestartet: keine fehlermeldungen, fernzugriff geht nicht :/

@all: vielleicht hat jemand ähnliches problem und die lösung schon gefunden?

fabianhu schrieb:

@HAL9000 ...blöde Meldung, wenn's dann trotzdem geht.

Zum Vergrößern anklicken....

Ich hab sie nicht programmiert Aber ich bekomme die gleiche Meldung für die Weiterleitung für mein VPN, und funktionieren tuts trotzdem.
@radislav: Von Intern kommst du aber drauf? Wie genau sieht denn die Portweiterleitung bei dir aus? Und wie legst du das virtuelle interface an? Ich habe mein svn nach außen nicht direkt freigegeben, deshalb ist das ein bisschen neu für mich, aber ich forsche da später nochmal nach.

@ HAL 9000:
von intern habe ich kein problem, aber es würde für mich nicht so viel sinn machen, wenn ich nicht noch von außen zugreifen könnte. benutze momentan visualSVN, vielleicht stören sie sich gegenseitig?
porterweiterung:
homepage: svn-fritz TCP 3690 192.168.178.253 3690
debug.cfg: ifconfig eth0:0 192.168.178.253 netmask 255.255.255.0 up
funzt ja auch momentan für apache wunderbar - kommische sache

Ich sehe nicht was sich da stören sollte. Und das Problem mit dem Fernzugriff sehe ich leider auch nicht, das sieht alles richtig aus... :?

hallo, all

hab den fehler bei mir gefunden: die portfreigabe auf die addresse 192.168.178.253 hat bei mir einfach nicht funktioniert, aus welchem grund auch immer! ich haber per hand die /var/flash/ar7.cfg folgendermaßen korrigiert:

forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
[...]
"tcp 0.0.0.0:3690 0.0.0.0:3690 0 # svn-fritz";
[...]
shaper = "globalshaper";

nach dem neustart ging das auschecken per svn://......dyndns.org/repository ohne probleme!

wäre ziemlich cool, wenn mir einer erklären würde, warum dies nicht mit einer virtuellen nezwerkkarte funktioniert...

ansonnsten viel spass beim cooden!

Frag ich mich auch. Eigentlich hätte es mit der virtuellen Netzwerkkarte funktionieren müssen. Mit OpenVPN gibts da wohl ein ähnliches Problem, das auch keiner versteht.

ich hab jetzt bei mir die virtuelle netzwerkkarte weggeschmissen - mache nun die portfreigabe auf die box per hand. so würde ich es auch allen anderen empfehlen, denn es ist wirklich nicht schwieriger.

Mit Tortoise SVN kann ich von einem Windows Rechner über svn+ssh:// eine Verbindung mit meiner Fritzbox aufbauen, auf der sich '/var/media/ftp/uStor00/svnserve' (also auf USB Stick) befindet.

In den TortoiseSVN Settings habe ich unter Network-SSH client den ssh client und den private key wie folgt eingetragen: "C:\Programme\TortoiseSVN\bin\TortoisePlink.exe -i D:\private.ppk"

Wenn ich svn+ssh://xxxx.selfhost.tk in den Explorer eintippe, klappt die Verbindung zwar. Allerdings wird svnserve nicht gefunden, also auch nicht gestartet. Offensichtlich weiß TurtoiseSVN nicht, wo svnserve liegt (woher auch?).

Hier komme ich nicht weiter. HAL 9000 hat geschrieben, daß er einen symbolischen Link auf svnserve eingerichtet hat. Wo macht man das? Ich habe schon verschiedene Einträge (u.a. export PATH=$PATH:/var/media/ftp/uStor00/) in die debug.cfg probiert. Aber das klappt nicht.

Es gibt m.E. folgende 2 Möglichkeiten:
1) Gibt es irgendwo eine Initialisierungsdatei (so was wie .bashrc) auf der Fritz Box? (Bitte nicht killen, wenn das irgendwo im Forum steht, ich habe es wirklich nicht gefunden)
2) Kann man TortoiseSVN sagen, wo es nach dem svnserve suchen soll?
Klar kann man auch den svnserve mit in einen Standardpfad (z.B. /usr/sbin) ins Image aufnehmen, dann sollte das Programm gefunden werden; aber es muß doch auch anders gehen.

Anm.: Eine ungesicherte Verbindung über svn://xxxx.selfhost.tk und den Port 3690 funktioniert bestens, wenn ich vorher den svnserve von Hand starte, d.h. das Repository ist richtig eingerichtet.

Für Hinweise wäre ich dankbar.

Sorry, das war etwas unklar geschrieben. Das mit dem Symlink funktioniert nur, wenn du Freetz benutzt. Ich habe den Link mit in mein Freetz-Image gebaut (einfach anlegen unter freetz-trunk/root/usr/bin oder so). Anders wird es nicht gehen, da du in /usr/bin und co normalerweise nicht schreiben kannst. Alternativ könntest du (auch nur mit freetz) eine .profile im Homeverzeichnis auf der Box anlegen und darin den passenden PATH definieren. Sollte hier genauso funktionieren wie .bashrc. In dem Fall musst du aber daran denken, dass diese Datei nach einem Neustart der Box wieder weg ist, also am besten per rc.custom anlegen lassen.
Ohne Freetz sieht es leider relativ schlecht aus.

Can't commit changes

@HAL 9000
Danke Dir, ich habe svnserver und svnadmin in das image eingebunden. Jetzt geht es. Und schon bin ich beim nächsten Problem:

Ich nutze svn+ssh://..., um auf ein fertig eingerichtetes und initialisiertes Repository zuzugreifen. Allerdings bekomme ich, wenn ich Änderungen committen möchte, immer folgende Fehlermeldung:

"Can't chmod: '/var/media/ftp/uStor00/rep/db/transactions/1-1.txn/rev': Operation not permitted"

Ich benutze, um das ganze mal vorab auszuprobieren, einen relativ alten USB Stick, der mit FAT32 formatiert ist.

Ist jemanden dieser Fehler bekannt? Gibt es Hoffnung, daß ich bei Benutzung eines neueren Sticks den Fehler nicht mehr habe? Warum kann man eigentlich die Berechtigungen für Dateien auf dem Stick nicht ändern?

P.S.: Ich bekomme den Fehler nicht, wenn ich mich als root über ssh einlogge. Ich habe allerdings noch einen anderen Account auf meiner FBF eingerichtet, der zur Gruppe 'users' gehört, mit dem ich auch Änderungen auf das Repository schreiben möchte. Die Idee ist, daß da noch weitere Benutzer dazukommen, die alle einen eigenen key bekommen und so ihre Änderungen im Repository zusammenführen können.

Der Fehler tritt auch dann auch, wenn ich unter ../config/svnserve.conf bei auth-none=write eingebe.

Jetzt habe ich es auch noch als 'ftpuser', der ja bekanntlich zur Gruppe 'root' gehört probiert (vorher password etc. eingerichtet, so daß normales ssh über putty funktioniert). Hier kommt genau der gleiche Fehler.

Warum kann nur 'root' schreiben?

Ich kann das jetzt gerade nicht nachvollziehen, da ich keinen FAT32-Stick da habe, aber ich rate einfach mal
Du kannst auf den Stick keine Rechte setzen, da FAT32 einfach keine Rechte unterstützt. Alle Dateien bekommen deshalb gewisse Standardrechte. Normalerweise wird automatisch root zum Besitzer, und alle Dateien bekommen die Rechte 755 (rwxr-xr-x). Daraus folgt dann direkt dein Fehler: svnserve läuft immer mit den Rechten des Benutzers, als der du dich über ssh einloggst. Wenn dieser Benutzer nicht root ist, dann hat er keine Schreibrechte auf dem Stick. Und da du die Rechte auf dem Stick mit FAT32 nicht ändern kannst, wird das, was du vorhast, wohl nur mit einem anderen Dateisystem klappen.
Ein neuer Stick hat damit übrigens wenig zu tun. Auf einem neuen Stick mit FAT32 hättest du genau das gleiche Problem.

Alle Dateien im USB-Repository haben entweder die Berechtigung 777 oder 555. Schreiben kann ich in einer Shell, wenn ich mich als 'user' über ssh einlogge.

Berechtigungen kann ich setzen, wenn ich als 'root' eingeloggt bin, sonst nicht
==> Am filesystem liegt es nicht

Ich habe den Stick gestern trotzdem mal mit Ext2 formatiert; die Ext2-Partition wurde aber auf der FBF nicht erkannt. Dann habe ich wieder FAT32 verwendet. Erkennt die FBF eigentlich andere FS-Formate? Was benutzt Ihr denn für Euer Repository?

Das Problem ist scheinbar, daß svnserve als 'user:users' oder 'ftpuser:root' ein chmod Kommando absetzt. Das wird in beiden Fällen nicht akzeptiert, weil alle Dateien 'root' gehören.
==> Ich muß erreichen, daß das Kommando chmod immer als root läuft. Hierzu brauche ich wahrscheinlich 'sudo'. Kann man das nachrüsten?

05.04.08:
Man könnte 'svnserve -t --tunnel-user user' als 'option' im authorized key file starten (s. http://www.ip-phone-forum.de/showpost.php?p=1072638&postcount=11). Dann könnten sich alle externen Benutzer als root einloggen und würden sich über ihren individuellen key identifizieren. Den Shell Zugriff kann man über weitere Parameter verhindern. Das wäre eigentlich eine sehr elegante Lösung. Allerdings geht das mit dropbear wieder nicht, da er das 'options' Feld ignoriert. Man benötigt den Original sshd auf der FBF - gibt es hier schon Hinweise irgendwo?

Original sshd auf der Box gibts momentan nicht. Ich weiß auch nicht, ob das überhaupt möglich wäre (Platz!). Sudo dürfte möglich sein, gibt es aber afaik auch nicht. Was mit dropbear möglich ist und was nicht weiß ich leider nicht so genau
ext2/3 erkennt die Box, wenn du in Freetz die entsprechenden Kernelmodule mitinstallierst. Im menuconfig unter Advanced options --> Kernel odules --> fs kannst du die auswählen. Dann kannst du noch unter Patches --> Patch USB storage names, ... einstellen, dass ext-Partitionen automatisch gemounted werden. Mein Stick läuft mit ext3 ziemlich problemlos.

Subversion und Freetz

Hallo zusammen,

hab auch schon nen Subversion-Server auf meiner 7170 laufen. Ist wegen USB 1.1 zwar nicht das schnellste, aber was solls

Wollte nur mal fragen, ob es Pläne gibt, das Ganze auch in Freetz zu integrieren. Das wäre wirklich klasse!

Markus

@HAL 9000
Du hast ja so ziemlich alle Fragen in Kürze auf einmal beantwortet - prima!

Also: mit ext3 kann man sich als 'user1:users' ein 'rep' Verzeichnis auf dem USB-Stick anlegen und die Rechte übernehmen. Dann können alle von der gleichen Gruppe und 'root' auf dieses Verzeichnis und seine Unterverzeichnisse schreiben.

Jeder 'user1', 'user2', etc. bekommt einen eigenen private key und einen eigenen login. Vorher non-root login bei dropbear ausschalten --> http://www.ip-phone-forum.de/showthread.php?t=143821. Außerdem muß man die user-Einrichtung natürlich in die debug.cfg reinschreiben, wenn alles nach einem Neustart noch funktionieren soll.

So können alle 'xxx:users' auf das rep zugreifen und drauf schreiben. Das ist so eigentlich ziemlich sicher.

Jetzt wäre es noch gut, wenn man den usern den Shell access vergrätzen könnte. Hierzu braucht man aber das options-field in der authorized key file. Das kann dropbear aber scheinbar nicht (http://www.ip-phone-forum.de/showpost.php?p=1072638&postcount=12).

Hier hilft nur ein volles sshd, am besten als static binary. Ich schau erst mal, ob ich das wirklich brauche.