subversion für freetz

[er13]

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

inetd per WebIF neustarte, bleibt alles beim alten. Beim Zugriff per RapidSVN erscheint die Meldung "Error: Error while refreshing filelist (Fehlerhafte Netzwerkdaten).

Könnte bitte noch jemand den svnserve im inetd-Modus testen (entweder trunk >= 3780 oder manuell Rechte von /var/tmp auf 1777). Momentan läuft es bei mir und läuft nicht bei astrapi. Danke!

Beitrag 2:

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

Meinst Du komprimiert? Kann ich nicht testen, ich habe eine 7170, auch dynamisch gelinkt muss subversion bei mir komplett ausgelagert werden. Übrigens habe ich auch keine Probleme mit den ersetzten ssl/crypto Libraries, das Einzige, was nicht geht, ist /sbin/mailer - das kann ich aber verschmerzen.

 

[cuma]

Die Größe des Images erhöht sich bei Wahl von "statisch" um 4 MB, also komprimiert

 

[astrapi]

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.

Ich mach nichts besonderes. Auf inetd stellen, box neustarten, svnserve startet nicht beim Zugriff.

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.

Auch der direkte Zugriff von der shell aus, bring die gleiche Meldung.

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.

Andere Dienste, wie dropbear, wol und sane laufen ohne Probleme.

 

[er13]

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

Es wäre auch noch toll wenn svnserve "nice" gestartet werden kann.

erledigt in 3788

Beitrag 2:

Ich mach nichts besonderes. Auf inetd stellen, box neustarten, svnserve startet nicht beim Zugriff.

Nur als Anmerkung, sofern Du eine Rev. < 3780 hast, gehen die manuell gesetzten 1777-Rechte beim Reboot verloren.

Könntest Du bitte "telnet fritz.box 3690" machen, kommt da eine Antwort? Es wäre schon wichtig rauszufinden, ob der svnserve tatsächlich (wie Du es sagst) nicht gestartet wird oder der Client und der Server sich nicht unterhalten können. Kommt da sowas

( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops partial-replay ) ) )

als Antwort, dann wird der svnserve-Prozess gestartet.

Kommt keine Antwort, so würde ich mal behaupten, dass es gar nicht an subversion liegt, sondern an dem inetd. Kannst Du dann bitte Deine (nach dem Umstellen von subversion auf inetd generierte) /var/tmp/flash/inetd.conf hier posten.

Beim Zugriff per RapidSVN erscheint die Meldung "Error: Error while refreshing filelist.

hab' gegoogelt, bei Franzosen kommt ähnliche Meldung, wenn sie Dateien mit ihren Sonderbuchstaben im Namen im Repository haben, hast Du vielleicht auch welche mit Umlauten? Dies würde allerdings nicht erklären, warum es im Normalmodus läuft.

 

[astrapi]

derzeitige Version: freetz-devel-3781

telnet fritz.box 3690:

Trying 192.168.1.254...
Connected to fritz.box.
Escape character is '^]'.
svnserve: Can't check path '/var/media/ftp/uStor01/root/srv/svn/repos': Permission denied
Connection closed by foreign host.

ping fritz.box:

PING fritz.box (192.168.1.254) 56(84) bytes of data.
64 bytes from fritz.box (192.168.1.254): icmp_seq=1 ttl=64 time=0.504 ms
64 bytes from fritz.box (192.168.1.254): icmp_seq=2 ttl=64 time=0.519 ms
64 bytes from fritz.box (192.168.1.254): icmp_seq=3 ttl=64 time=0.519 ms
64 bytes from fritz.box (192.168.1.254): icmp_seq=4 ttl=64 time=0.517 ms

Die Verzeichnisse auf der Box:

/var/media/ftp/uStor01/root/srv/svn # ls -la
drwxrwx---    5 svn      svn          4096 Aug  8 18:03 .
drwxrwxrwx    3 root     root         4096 Jul 25 21:21 ..
drwxrwx---    2 svn      svn          4096 Jul 25 21:21 conf
drwxrwx---    9 svn      svn          4096 Aug  8 18:12 repos
drwxrwx---    5 svn      svn          4096 Aug  8 18:03 tmp
/var/media/ftp/uStor01/root/srv/svn #

Alle Unterverzeichnisse haben die Rechte wie "repos"

Edit_1: Meine inetd.conf

#:dropbear: dropbear ssh server
22    stream    tcp    nowait    root    /usr/sbin/dropbear    dropbear -i 

#:sane-backends: saned SANE server
6566    stream    tcp    nowait    root    /usr/sbin/saned    saned -i 

#:subversion: subversion server
3690    stream    tcp    nowait    svn    /usr/bin/svnserve    svnserve -i --root /var/media/ftp/uStor01/root/srv/svn/repos --log-file /var/media/ftp/uStor01/svnserve.log

#:telnetd: telnet daemon
#<off>#23    stream    tcp    nowait    root    /usr/sbin/telnetd    telnetd -i -l /sbin/ar7login

#:webcfg: mod web interface
#<off>#81    stream    tcp    nowait    root    /usr/bin/webcfg    webcfg -i

#:wol: WOL web interface
82    stream    tcp    nowait    root    /usr/bin/webcfg-wol    webcfg-wol -i

 

[er13]

telnet fritz.box 3690:

Trying 192.168.1.254...
Connected to fritz.box.
Escape character is '^]'.
svnserve: Can't check path '/var/media/ftp/uStor01/root/srv/svn/repos': Permission denied
Connection closed by foreign host.

an der Ausgabe sieht man, denke ich, ziemlich deutlich, dass der svnserve-Prozess gestartet wird...
er sagt auch, was ihm nicht passt...

Zwar weiß ich nicht welche Rechte genau ihm fehlen und wieso es Normalmodus mit demselben Repository geht, aber versuch' halt Rechte zu ändern und schaue, ob's was bringt. Ich würde mit

chmod -R o+x /var/media/ftp/uStor01/root/srv

anfangen

und bei mir schaut's übrigens so aus:

root@fritz:/var/media/ftp/uStor01/SVNROOT# ls -al /var/media/ftp/uStor01/SVNROOT 
drwxr-xr-x    6 svn      svn          4096 Oct 17 16:40 .
drwxr-xr-x   14 root     root         4096 Oct 24 21:20 ..
-rw-r--r--    1 svn      svn           229 Oct 17 16:40 README.txt
drwxr-xr-x    2 svn      svn          4096 Oct 17 16:40 conf
drwxr-sr-x    6 svn      svn          4096 Oct 24 22:21 db
-r--r--r--    1 svn      svn             2 Oct 17 16:40 format
drwxr-xr-x    2 svn      svn          4096 Oct 17 16:40 hooks
drwxr-xr-x    2 svn      svn          4096 Oct 17 16:40 locks

Und alle Verzeichnisse unter db haben dieselben Bits(Rechte) gesetzt wie db selbst. Solltest Du Dich fragen, was s in drwxr-sr-x bedeutet, so ist es hier erklärt

 

[astrapi]

hab grad nich viel zeit ... mit einem neuen (leeren Verzeichnis für die repos klappt es. Darin neues leeres Repo erstellt und der Zugriff klappt. Wenns die Zeit erlaubt kopier ich meine "alten" repos mal dorthin und dann schaun wir weiter.

 

[cuma]

Wollte Subversion für eine Box dynamisch ohne SSL bauen, bin mit dem aktuellen Trunk aber auf dieses Problem gestossen:

# /etc/init.d/rc.subversion start
Starting svnserve.../usr/bin/svnserve: can't load library 'libsqlite3.so.0'
failed.
failed.

 ls -al  `find / -name libsqlit*`
lrwxrwxrwx    1 root     root           53 Oct 25 15:49 /lib/libsqlite3-3.6.13.so.0 -> /var/plugin-mediasrv/./lib/libsqlite3-3.6.13.so.0.8.6
lrwxrwxrwx    1 root     root           53 Oct 25 15:49 /lib/libsqlite3-3.6.13.so.0.8.6 -> /var/plugin-mediasrv/./lib/libsqlite3-3.6.13.so.0.8.6
lrwxrwxrwx    1 root     root           53 Oct 25 15:49 /lib/libsqlite3.so -> /var/plugin-mediasrv/./lib/libsqlite3-3.6.13.so.0.8.6

 

[er13]

[Edit frank_m24: Sinnfreies Vollzitat vom Beitrag direkt darüber gelöscht, siehe Forumregeln.]

Das, was da unter /lib gefunden wird, ist die (umbenannte) Version von AVM, diese wird meines Wissens von keinem freetz-Paket verwendet. Du brauchst die von freetz zur Verfügung gestellte Version der library (i.e. FREETZ_LIB_libsqlite3). Vermutung, Du hast libsqlite mittels external (bist Du nicht der Autor davon ) ausgelagert und vergessen das external-Verzeichnis zu aktualisieren.

p.s. in der subversion.mk fehlt zwar $(PKG)_DEPENDS_ON += sqlite, dies sollte aber nicht Dein Problem erklären

 

[cuma]

Wegen der 16MB-Flash Boxen ist external fast überflüssig :-( Hatte das damals für die gute alte 7170 gebraucht da die 8MB viel zu klein waren. Ich verwende es mittlerweile nicht mehr

Hier noch ein paar Ausgaben:

$cat .config|grep -E "SQLI|sql|SUBV"

# FREETZ_PACKAGE_SQLITE is not set
FREETZ_PACKAGE_SUBVERSION_LIBRARIES=y
FREETZ_PACKAGE_SUBVERSION=y
# FREETZ_PACKAGE_SUBVERSION_WITH_SSL is not set
FREETZ_PACKAGE_SUBVERSION_SVN=y
FREETZ_PACKAGE_SUBVERSION_SVNADMIN=y
FREETZ_PACKAGE_SUBVERSION_SVNDUMPFILTER=y
FREETZ_PACKAGE_SUBVERSION_SVNLOOK=y
FREETZ_PACKAGE_SUBVERSION_SVNSERVE=y
FREETZ_PACKAGE_SUBVERSION_SVNSYNC=y
FREETZ_PACKAGE_SUBVERSION_SVNVERSION=y
# FREETZ_PACKAGE_SUBVERSION_STATIC is not set
FREETZ_SUBVERSION_STRING=y
FREETZ_LIB_libsqlite3=y

$ find build/ -name *sqlit*

build/modified/filesystem/lib/libsqlite3-3.6.13.so.0
build/modified/filesystem/lib/libsqlite3-3.6.13.so.0.8.6
build/modified/filesystem/lib/libsqlite3.so
build/modified/kernel/plugins.image/plugin-mediasrv/lib/libsqlite3-3.6.13.so.0
build/modified/kernel/plugins.image/plugin-mediasrv/lib/libsqlite3-3.6.13.so.0.8.6
build/modified/kernel/plugins.image/plugin-mediasrv/lib/libsqlite3.so
build/original/filesystem/lib/libsqlite3-3.6.13.so.0
build/original/filesystem/lib/libsqlite3-3.6.13.so.0.8.6
build/original/filesystem/lib/libsqlite3.so
build/original/kernel/plugins.image/plugin-mediasrv/lib/libsqlite3-3.6.13.so.0
build/original/kernel/plugins.image/plugin-mediasrv/lib/libsqlite3-3.6.13.so.0.8.6
build/original/kernel/plugins.image/plugin-mediasrv/lib/libsqlite3.so

 

[Peter931]

Firmware: 54.04.78freetz-devel-3788

Wenn ich auf der Fritzbox 7270 16 MB
/usr/bin/svnadmin create project1
starte, bekomme ich folgende Fehlermeldung:

svnadmin: SQLite compiled for 3.6.19 , but running with 3.6.18

Kann ich das ignorieren?

Gruß
Peter


( SVN-Newbie, seid gnädig !!! )

 

[er13]

Wegen der 16MB-Flash Boxen ist external fast überflüssig :-(

ein Update von ausgelagerten Dateien lässt sich deutlich einfacher durchführen - man muss die Box nicht neu flaschen.

Hier noch ein paar Ausgaben:
[entfernt]

ja, bei Dir fehlt in der Tat in dem Ausgabe-Verzeichnis libsqlite3. Ich frag' mal aber vorsichtig, was hat's mit subversion zu tun Hast Du zufällig noch die make-Ausgabe (ich übersetze übrigens immer mit "make 2>&1 | tee make.log"), da wo die Libraries installiert werden, taucht da libsqlite auf?

Firmware: 54.04.78freetz-devel-3788
svnadmin: SQLite compiled for 3.6.19 , but running with 3.6.18

keine Ahnung, hab's nicht ausprobiert. Die Entwickler von SQLite haben aber die Library-Version (0.8.6) nicht erhöht, soll heißen 3.6.18 und 3.6.19 sind binärkompatibel. Am besten hälst Du aber geflashten und external-Teil synchron.

 

[Peter931]

Zitat von Er13
keine Ahnung, hab's nicht ausprobiert. Die Entwickler von SQLite haben aber die Library-Version (0.8.6) nicht erhöht, soll heißen 3.6.18 und 3.6.19 sind binärkompatibel. Am besten hälst Du aber geflashten und external-Teil synchro

Wie halte ich denn geflashten Teil und External-Teil gleich? ( Habe bewußt keine unterschiedlichen Versionen genommen )
Was muss ich ändern?
Bin leider nicht so tief drin.

 

[cuma]

ein Update von ausgelagerten Dateien lässt sich deutlich einfacher durchführen - man muss die Box nicht neu flaschen.

Meine "make" startet die Box automatisch neu und flasht per adam. Einfacher geht's nicht ;-)

ja, bei Dir fehlt in der Tat in dem Ausgabe-Verzeichnis libsqlite3. Ich frag' mal aber vorsichtig, was hat's mit subversion zu tun Hast Du zufällig noch die make-Ausgabe

Nun, vor ein paar Revisionen funktionierte das noch. Außer durch subversion hab ich sqlite nicht in Benutzung. Ich vermute dass es etwas mit dem "static" von subversion zu tun hat.

Ausgabe

  installing libs
    ld_uClibc
    libart_lgpl_2
    libdl
    libelf
    libfreetype
    libfreetz
    libftdi
    libgcc_s
    libipt_LOG
    libipt_REJECT
    libm
    libncurses
    libnsl
    libpcap
    libpng12
    libpopt
    libpthread
    libresolv
    librt
    libuClibc
    libuClibc__
    libusb
    libutil
    libxt_limit
    libxt_standard
    libxt_tcp
    libxt_udp
    libz
  installing terminfos

Also kein sqlite

 

[er13]

Nun, vor ein paar Revisionen funktionierte das noch. Außer durch subversion hab ich sqlite nicht in Benutzung. Ich vermute dass es etwas mit dem "static" von subversion zu tun hat.

also mit subversion hat's doch nichts zu tun, schuldig bin ich dennoch Einige der Änderungen aus 3787 waren falsch (das Paket ist insofern spezifisch, dass es sowohl ein Binary- als auch ein Library-Paket ist). Wurde sqlite-Binary mitgewählt, so landete auch die Library mit in der Firmrware, wurde nur Library gewählt, so geschah nichts. Sorry... Kannst Du bitte r3790 testen

Wie halte ich denn geflashten Teil und External-Teil gleich? ( Habe bewußt keine unterschiedlichen Versionen genommen )
Was muss ich ändern?
Bin leider nicht so tief drin.

Diesmal hast Du höchstwahrscheinlich nichts falsch gemacht, derselbe Fehler aus r3787 verursacht auch die Warning, die Du siehst. Kannst Du bitte auf 3790 updaten, make sqlite-dirclean und dann make machen. Sofern du sqlite mittels external ausgelagert hast, dann musst Du die Firmware nicht neu flashen, es reicht nur das External-Verzeichnis zu aktualisieren.

 

[cuma]

Image bootet nicht mehr! Mir ist noch aufgefallen:

WARNING: library libneon_WITH_ZLIB selected, but no files found

(Im Falle von Nachfragen: wird auch von subversion genutzt)

 

[er13]

Image bootet nicht mehr!

Ist ein Witz oder!? die Änderungen, die ich gestern gemacht habe, können dadran doch nicht schuldig sein, bei mir bootet alles, hast Du vielleicht mit Deinem UMTS-Stick experementiert? Die beiden FREETZ_LIB_libneon_WITH_{SSL,ZLIB} Warnings kannst Du getrost ignorieren, es muss sogar so sein, dass fwmod da nichts findet

 

[cuma]

Leider nicht, mal schauen ob noch jemand da Probleme hat. UMTS teste ich mit einer 7170. Images baue ich immer mit unverändertem trunk + ein paar Gimmiks

 

[er13]

@cuma: gestern, wo die Box noch gebootet hat, hast Du doch r3788 gehabt oder? D.h. es kommen nur 3789-3792 in Frage. 3789, 3790 und 3792 schließe ich fast zu 100% aus. Nur bei 3791 kann ich mir ein oder sogar zwei Szenarios ausdenken, die zum Nicht-Booten der Box führen können.

• Zum einen könnte es sein, dass Deine Eingaben in Feldern Bind-Adresse/Port bei subversion nicht ganz ok sind, z.B. enthalten überflüssige Leerzeichen vorne oder hinten, oder sogar einfach leer sind - ich habe da keinen Schutz gegen solche Eingaben eingebaut. Das könnte eventuell zum Generieren einer fehlerhaften inetd-Konfiguration führen, dies wiederum zum Nicht-Starten von inetd, dies wiederum zum Abbrechen des Boot-Vorgangs.
• Das zweite weniger wahrscheinliche Szenario ist, dass aufgrund etwas größer gewordenen inetd-Konfig es zum Überschreiten von MOD_LIMIT kommt, das durch Speichern der neuen inetd-Konfigdatei verursachte "modsave flash" scheitert, die Box bootet nicht. Hatte ich mal als Du (bin mir nicht sicher, aber ich glaube das bist Du gewesen) die Verzeichnisstruktur des mods geändert hast. Geholfen hat dann: telnet per Telefon aktivieren, Platz schaffen, modsave flash und neubooten.

 

[astrapi]

mal kurz zwischendurch zu meinem Problem ... GELÖST ... habe meine alten Repos per dump gesichert, ein neues Verzeichnis und neue Repos erstellt und die Daten wieder eingelesen (load). Seitdem gehts auch mit inetd.