EncFS mit Freetz

[olistudent]

Magst du uns mitteilen wie du es konfiguriert und gebaut hast? Ein fertiges Makefile für Freetz wäre mir natürlich noch lieber.

MfG Oliver

 

[Kontr-Olli]

@olistudent

Hi....

ja, kann ich machen....werde am Wochenende mal die Infos übers kompilieren raus geben...ev. bau ich auch ne kleine Makefile.....habe im OpenWRT Forum gesehen, dass es jemand geschafft hat EncFS auch gegen die uclibc++ zu bauen.....ev. kann man das auch mal ins Auge fassen.....das wäre denke ich ideal....

die librlog kompiliert ganz normal mit den standard einstellungen sowohl gegen die große c++-lib als auch gegen die uclibc++....probleme mit der uclibc++ gab es nur bei encfs...da waren auch noch einige kniffe nötig, damit das configure-script fehlerfrei durchlief.....aber soweit ich mich erinnern kann, war das nicht so dramatisch....

wie gesagt, werde die Infos am WE freigeben....ev. hat auch jemand dann lust, mich dabei zu unterstützen das ganze gegen die uclibc++ zu bauen?!

grüße
Kontr-Olli

 

[Kontr-Olli]

encFS 1.3.2 für FB7270

Hi leutz.....

also soweit so gut.....habe mal ein bisschen rumprobiert und siehe da....es ist mir sogar gelungen EncFS 1.3.2 samt librlog gegen die uclibc++ zu bauen....auf den ersten blick schien auch alles zu funktionieren...

hab das ganze dann auf die FB kopiert und dort mich nochmal vergewissert, dass es nur gegen die uclibc++ dynamisch gelinkt worden ist.....was der fall war......die encfs binary lies sich auch ohne probleme ausführen und beim einbinden eines verschlüsselten ordners ins filesystem lief auch alles ganz gut.....passwortabfrage etc.....ordner wurde unter mount ordnungsgemäß angezeigt.....alles klar dachte ich....

leider stürzte die uclibc++-Version dann jedesmal ab, wenn man in den so gemounteten ordner gewechselt bin.....d.h. einfach mal nen ls im ordner gemacht und schon war der prozess encfs weg.....in mount wurde es zwar noch richtig angezeigt....jedoch kam die Fehlermeldung: "Transport lost"...oder so, wenn man sich im gemounteten Ordner befand....irgendwer ne idee, was da falsch läuft??....

denn wenn ich ehrlich bin, habe ich keine ahnung wie man EncFS fehlerfrei gegen die uclibc++ bauen kann....oder ob dies überhaupt möglich ist.....zumal der uclibc++ in freetz ja auch die eine oder andere option genommen wurde (siehe menuconfig im source von uclibc++)

naja....da es ja keine probleme gab, wenn ich die große c++-lib verwende, will ich kurz im folgenden beschreiben, was ich gemacht habe, damit das kompilieren von EncFS ohne fehler durchlief.....sorry, dass ich keine fertige Makefile erstellt habe.....würde ich zwar machen, wenn mir jemand mal sagen könnte, wie das am besten geht und welche umgebungsvariablen zu setzen sind.....

ich denke so wirds ja auch erstmal gehen.....ev. könnte dann EnFS 1.3.2 ins freetz-paket mit aufgenommen werden?!

zunächst erstmal die sourcen besorgen:

• rlog 1.4 zu finden unter http://rlog.googlecode.com/files/rlog-1.4.tar.gz
• EnFS 1.3.2 zu finden unter https://launchpad.net/ubuntu/gutsy/+source/encfs/1.3.2-1-1/+files/encfs_1.3.2-1.orig.tar.gz

Umgebungsvariable $PATH auf freetz-toolchain ../toolchain/target/bin setzen....

fangen wir mit der stressfreien teil an....librlog....kompiliert ohne patch und veränderungen des configure scripts ohne Probleme gegen die c++lib:

./configure --enable-static --enable-shared --prefix=/media/disk/FritzBox-dev/rlog-mipsel --disable-docs --with-gnu-ld --build=i386-linux-gnu --target=mipsel-linux --host=mipsel-linux CFLAGS="-Os -pipe -march=4kc -Wa,--trap" CXXFLAGS="-Os -pipe -march=4kc -Wa,--trap" CC=mipsel-linux-gcc CXX=mipsel-linux-g++

dann eben make && make install......

danach die so erstellte librlog....samt symbolischen verknüpfungen, dem lib-verzeichnis sowie dem include verzeichnis in die freetz-toolchain kopieren...../toolchain/target/lib ../include usw.....sollte klar sein...

kommen wir nun zum eingenlichen....den EncFS 1.3.2 sourcen.....damit das configure-script ordnungsgemäß durchläuft, habe ich den teil auskommentiert, welcher ein kleines testprogramm startet, welches die libfuse version und verfügbarkeit testet...was natürlich nicht geht, wenn man für mipsel kompiliert....aufgrund dessen selbst nochmal nachschauen, ob die libs für FUSE auch in der toolchain vorhanden sind....fuse ist im freetz paket enthalten, und muss sich danach auch auf der Box befinden....

desweiteren habe ich die datei encfsctl.cpp im ordner encfs in den sourcen noch verändern müssen.....dort wird im Zeile 540-547 die funktion ngettext verwendet....diese stellt eine erweiterung der funktion gettext dar, wobei zusätzlich erkannt wird ob singular oder plural verwendet wird und dementsprechend die Ausgabe auch noch modifiziert wird.....
meiner meinung nach spielerei.....zumal beim kompilieren sich der freetz-kompiler darüber beschwert, dass er er eben ngettext nicht kennt....also habe ich das ganze durch gettext ersetzt und den syntax dort auf die einfache funktion angepasst.....

die beiden genannten veränderungen habe ich auch zusammen in eine patchfile gepackt (encfs-1.3.2-cross-patch.diff), welche ihr euch im anhang runterladen könnt....d.h. EncFS sourcen patchen....

patch -p0 -i encfs-1.3.2-cross-patch.diff

danach in den EncFS-source ordner wechseln und configure-script durchrennen lassen....

CPPFLAGS='-I/media/disk/freetz-trunk/toolchain/target/include' LDFLAGS='-L/media/disk/freetz-trunk/toolchain/target/lib' LIBS='-pthread -liconv' ./configure --prefix=/media/disk/FritzBox-dev/encfs-mipsel --disable-nls --enable-shared --with-gnu-ld --without-libintl-prefix --build=i386-linux-gnu --target=mipsel-linux --host=mipsel-linux CXX=mipsel-linux-g++ CFLAGS="-Os -pipe -march=4kc -Wa,--trap" CXXFLAGS="-Os -pipe -march=4kc -Wa,--trap"

besonders wichtig ist hier der flag: LIBS='-pthread -liconv'....da ansonsten das configure script abbricht und sich beschwert, dass es kein fuse-paket findet....kein plan warum das so ist, aber mit diesen beiden zusätzlichen LIBS läuft es einwandfrei durch und kompiliert auch ordnungsgemäß....

dann make && make install eben......

für EncFS wird neben librlog (siehe oben) noch die folgenden libs benötigt...

• libfuse im freetz-paket enthalten....sollte vorher installiert werden, damit in crosstoolchain vorhanden!
• openssl ebenfalls im freetz-paket enthalten....vorher prüfen ob auch bereits installiert und in toolchain vorhanden....

so....das wars erstmal....viel spaß beim nachbauen.....und ev. bekommt es ja einer von euch hin, das ding gegen die kleine, kompakte uclibc++ so zu bauen, damit es auch damit läuft.....

für die installation auf die FritzBox (d.h. kopieren der benötigten libs, samt der großen c++lib sowie der binarys ins image) bitte die Infos aus meinem vorherigen thread entnehmen....

gruß
Kontr-Olli

 

[Kontr-Olli]

verbesserte Version von EncFS 1.3.2

hi leutz....

hab grad mal ne weitere version von EncFS 1.3.2 gebaut.....hatte mit der vorherigen "version" das problem, dass wenn ich z.B. ne file in mldonkey angestellt habe, es mitunter 10min gedauert hat bis das mldonkey-webinterface wieder reagiert hat....

der grund dafür war, dass mldonkey in den temp-ordner (bei mir ebenfalls mit EncFS verschlüsselt) ne file anlegt, welche exakt der größe der zu downloadenden datei entspricht.....eigentlich ist das im nicht verschlüsselten fall kein problem, da die file nur aus "löchern" besteht....sprich anfang und ende der file ist definiert, dazwischen ists egal.....also nur nullen.....

nun, da EncFS alles verschlüsselt, sind auch brav die ganzen nullen, sprich löcher verschlüsselt worden....und dass bereits nur, wenn man nen download ausgewählt hat.....

dies machte es äußerst stressig bis ultra nervig, wenn man mal "schnell" zwei, drei files anstellen wollte.....

hab ein bisschen gegoogelt und habe einen patch (im Anhang) für die etwas neuere version (1.4.0) von EncFS gefunden, der im prinzip den zu verschlüsselten Block zunächst auf "nullen" absucht und wenn er erkennt, dass es ne file aus lauter nullen ist, die ganze file dann "unverschlüsselt" auf die platte schreibt....kurz: allow_holes implementiert.....

beim späteren auffüllen der "file" werden dann aber wieder die daten durch die verschlüsselung gejagt.....also eigentlich genau das richtige.....

problem.....da der Patch für 1.4.0 geschrieben war, und sich ab dieser Version die komplette verschlüsslung auf die ach so tolle "libboost" gestützt hat, liefen nur 3 von 4 hunks erfolgreich beim patchen durch....der vorletzte......an der stelle CipherFileIO.cpp konnte nicht angewandt werden.....hab mir den c-code mal angeschaut....und mit der 1.4.0er-Version verglichen.....er weicht deutlich von der 1.3.2er version ab....(z.B. gibts dort gar keine funktion "reverseEcryption"...etc.)

naja, hab ich mir gedacht....dann bleibt der teil des patches zunächst mal außen vor.......hab eigentlich nicht gedacht, dass das ganze dann noch funzt.....habs dann mal gebaut, und momentan auch im test....

es funzt auch soweit bestens....die löcher-files werden ohne verzögerung direkt angelet und das donkey-webinterface ist danach sofort wieder ansprechbar......fertige files sind danach aber auch "richtig" verschlüsselt.....also bestens, so wies sein soll......

im anhang also die fertige, neue gepatchte version von EncFS 1.3.2, der original-patch für die 1.4.0er version sowie der leicht geänderte/angepasste patch für die gebaute 1.3.2er version.....

viel spaß damit....
grüße
Kontr-Olli

 

[Kontr-Olli]

aktuelleste Version von EncFS 1.5 aus svn repository....

hi leutz....

hab es endlich hinbekommen die doch recht komplexe libboost 1.39 für mipsel cross zu kompilieren....war zwar nen kleines bisschen arbeit incl. diverser patches zum einspielen....jedoch kann sich das ergebnis sehen lassen ....

aufgrund dessen habe ich dann auch "schnell" mal das aktuelle EncFS aus dem 1.5er svn zweig des repositorys gebaut.....

die aktuelle Version von EnFS bietet zwar "scheinbar" die option, dass man bereits beim anlegen eines verschlüsselten ordners "allow_holes" aktivieren kann, jedoch wird in mehren foren sowie in der offiziellen bug-liste bestätigt, dass diese "option" nicht ordnungsgemäß an den programm-code weitergeben wird....sprich, auch wenn man zu beginn bei der wahl der verschlüsslung die option "allow_holes" aktiviert, wird diese nicht richtig angewandt.....

habe dies leider auch feststellen müssen, denn obwohl ich allow_holes bei der wahl der verschlüsslung zu beginn aktiviert hatte, kam es dennoch zu den ewigen wartezeiten beim anwählen eines downloads in mldonkey (siehe thread oben)...

das problem liegt daran, dass EncFS die option "allow_holes" nicht ordnungsgemäß aus der config-datei .encfs6.xml ausliest, obwohl es dort explizit nach auswahl eingetragen wurde....keine ahnung warum....

habe deswegen ne kleine änderung am EncFS source-code vorgenommen, der im Prinzip dafür sorgt, dass die option "allow_holes" unabhängig von der auswahl bei der erstellung der verschlüsslung immer aktiviert ist.....d.h. allow_holes ist per definition immer aktiv.....

ich weiß zwar, dass dies nicht optimal ist, jedoch bin ich mir sicher, dass eigentlich jeder von der option "allow_holes" profitiert, voralllem funktioniert sie jetzt reibungslos....

und damit ihr seht, dass ich keinen unsinn mit dem code getrieben habe hier kurz die stelle, an der ich die änderung vorgenommen habe....und zwar in der file ../encfs/src/BlockFileIO.cpp

[B]ursprünglich:[/B]
// 2, pad zero blocks unless holes are allowed
        if(!_allowHoles)
        {
            for(; oldLastBlock != newLastBlock; ++oldLastBlock)
            {
                rDebug("padding block %" PRIi64, oldLastBlock);
                req.offset = oldLastBlock * _blockSize;
                req.dataLen = _blockSize;
                memset( mb.data, 0, req.dataLen );
                cacheWriteOneBlock( req );
            }

[B]geändert in:[/B]
// 2, pad zero blocks unless holes are allowed
        if(0)
        {
            for(; oldLastBlock != newLastBlock; ++oldLastBlock)
            {
                rDebug("padding block %" PRIi64, oldLastBlock);
                req.offset = oldLastBlock * _blockSize;
                req.dataLen = _blockSize;
                memset( mb.data, 0, req.dataLen );
                cacheWriteOneBlock( req );
            }

des weiteren wurde für das ordnungsgemäße cross-kompilieren noch der patch encfs-1.3.2-cross-patch.diff angewand....siehe erklärung oben.....

es wurden zwei versionen gebaut....
eine dynamisch gelinkte version encFS-1.5_svn-mipsel_allowholes.tar.bz2, welche alle von freetz nicht bereitgestellten aber benötigten libs im archiv enthält....zur einbindung der libs fwmod_custom in freetz entsprechend anpassen (siehe thread oben bzw. forum)....

benötigt werden für die dynamische version folgende libs:

libencfs.so.4 => /usr/lib/libencfs.so.4 [B](im archiv enthalten)[/B]
librlog.so.5 => /usr/lib/librlog.so.5 [B](im archiv enthalten)[/B]
libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 [B](in freetz vorhanden/anwählbar)[/B]
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 [B](in freetz vorhanden/anwählbar)[/B]
libfuse.so.2 => /usr/lib/libfuse.so.2 [B](in freetz vorhanden/anwählbar)[/B]
libboost_serialization-gcc-mt-1_39.so.1.39.0 => /usr/lib/libboost_serialization-gcc-mt-1_39.so.1.39.0 [B](im archiv enthalten)[/B]
libboost_filesystem-gcc-mt-1_39.so.1.39.0 => /usr/lib/libboost_filesystem-gcc-mt-1_39.so.1.39.0 [B](im archiv enthalten)[/B]
libboost_system-gcc-mt-1_39.so.1.39.0 => /usr/lib/libboost_system-gcc-mt-1_39.so.1.39.0 [B](im archiv enthalten)[/B]
libiconv.so.2 => /usr/lib/libiconv.so.2 [B](in freetz vorhanden/anwählbar)[/B]
libstdc++.so.6 => /usr/lib/libstdc++.so.6 [B](im archiv enthalten)[/B]
libm.so.0 => /lib/libm.so.0 [B](in freetz vorhanden/anwählbar)[/B]
libgcc_s.so.1 => /lib/libgcc_s.so.1 [B](in freetz vorhanden/anwählbar)[/B]
libpthread.so.0 => /lib/libpthread.so.0 [B](in freetz vorhanden/anwählbar)[/B]
libc.so.0 => /lib/libc.so.0 [B](in freetz vorhanden/anwählbar)[/B]
libdl.so.0 => /lib/libdl.so.0 [B](in freetz vorhanden/anwählbar)[/B]
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 [B](in freetz vorhanden/anwählbar)[/B]

wer kein bock auf soviele libs hat, sowie keine lust darauf hat diese ins freetz-image einzubinden, kann einfach die andere von mir gebaute version verwenden.....encFS-1.5_svn-mipsel_allowholes_static.tar.bz2...
dabei handelt es sich um eine statisch gelinkte version von EnFS.....alles genauso wie oben, nur dass keine weiteren libs mehr benötigt werden....des weitern bietet eine statische version den vorteil, dass sie zum einen im "prinzip" auf jeder FritzBox lauffähig sein sollte und in der theorie ein wenig performanter als eine dynamische version sein sollte....in der praxis fällt dieser geschwindigkeitsvorteil eher kaum bis garnicht auf.....

also dann viel spaß bei testen.....berichtet über eure ergebnisse....

grüße
Kontr-Olli

 

[Silent-Tears]

Wie wäre es, einen Patch gegen den trunk zu erzeugen, der ein Paket mit dem Namen einbindet, und entsprechend die Libs dazuläd, bzw. die Option bietet, das statisch zu bauen?
Denn so ist dasd für nahezu Niemanden, der null Ahnung von den Boxen hat, irgendwie einzupflegen. Ein wenig menuconfig hingegen schaffen viele, und das wird - incl. weiterer Fehler - auch die Verbreitung fördern.

 

[henfri]

Erst mal Hut ab&Danke!

Wie wäre es, einen Patch gegen den trunk zu erzeugen, der ein Paket mit dem Namen einbindet, und entsprechend die Libs dazuläd, bzw. die Option bietet, das statisch zu bauen?
Denn so ist dasd für nahezu Niemanden, der null Ahnung von den Boxen hat, irgendwie einzupflegen. Ein wenig menuconfig hingegen schaffen viele, und das wird - incl. weiterer Fehler - auch die Verbreitung fördern.

Jepp, das wäre echt toll.

Gruß,
Hendrik

 

[Kontr-Olli]

@Silent-Tears

ja, natürlich wäre das praktischer, wenn man über menuconfig das ganze ins freetz-paket integrieren könnte......aber dazu müssten sich die entwickler von freetz äußern, ob überhaupt interesse an dem paket besteht....

aber wie bereits oben zu lesen: am einfachsten geht es mit der statischen version.....dazu werden überhaupt keine libs benötigt.....einfach auf den USB stick der box kopieren und ausführen......sollte eigentlich für jeden machbar sein...

gruß
Kontr-Olli

 

[Silent-Tears]

ja, natürlich wäre das praktischer, wenn man über menuconfig das ganze ins freetz-paket integrieren könnte......aber dazu müssten sich die entwickler von freetz äußern, ob überhaupt interesse an dem paket besteht....

Wieso sollte das keiner der Entwickler einpflegen? Nur ist es eben für einen Entwickler - und für andere auch - einfacher einen Patch gegen den Trunk einzuspielen, der alles enthält, so dass man es einfach im menuconfig auswählen und mit auf die Box bringen kann, sich also in den Buildprozess so integriert, dass das Binary keinerlei weiterer Pflege bedarf, um mit geflasht zu werden.
Trick daran ist: Keiner der Devs hatte bisher das Bedürfnis, so dass es funktioniert, weil es wohl keiner wirklich braucht. Somit ist es natürlich einfacher, wenn man mit nem Einzeiler die Sachen einfach im trunk hat, die neuen Files noch hinzufügen und dann testen.
Anders gesagt: Ich finds gut, ist aber für mich unnötig, was mich nicht daran hindert, es auch einzuchecken, oder?. Mach es so fertig, wie ich sagte, ich gucke drüber, obs funktioniert, und dann landet es im trunk.

 

[Kontr-Olli]

encfs in freetz-trunk integrieren....

@Silent-Tears:

jo, habs kapiert.....mach jetzt nen thread auf

folgendes vorweg......versuche grade nen Makefile für encfs zu erstellen um dieses später ev. in den freetz-trunk einchecken zu lassen......leider weißt encfs einige abhängigkeiten bezüglich neuer libs auf, welche ebenfalls in freetz integriert werden müssen.....des weiteren soll man später die möglichkeit haben, encfs entweder dynamisch samt der ganzen libs ins image zu paken oder eben halt über ne option im menuconfig "statisch" eben nur die binary einzubinden....was auch durchaus sinnvoll wäre für encfs.....

zu den randbedingungen: habe encfs schon mit der freetz-toolchain samt aller benötigten libs testweise gebaut....sowohl statisch als auch dynamisch......beides läuft auch schon lange bei mir auf ner FB7270.....keinerlei probleme......deswegen sollte es auf jedenfall machbar sein, dass ganze auch automatisiert über menuconfig ins freetz-paket zu integrieren....

probleme: also fange ich mal klein an......ich will zunächst die libboost als paket ins freetz-image integrieren.....libboost läuft leider nicht den standard-weg über configure-script und make.....sondern verwendet ein eigenes tool....die binary bjam......das ganze hab ich mit der freetz-toolchain folgendermaßen gebaut:

• herunterladen: sourcen bei http://downloads.sourceforge.net/project/boost/boost/1.39.0/boost_1_39_0.tar.bz2 gezogen und entpackt....
• PATH auf freetz-toolchain gesetzt.....danach im source-verzeichnis: sh bootstrap.sh ausgeführt
• nen patch für mipsel eingespielt.....hab ich bereits erstellt
• danach echo "using gcc : mipsel : $(TARGET_TOOLCHAIN_STAGING_DIR)/bin/mipsel-linux-gcc ; " > $($(PKG)_DIR)/tools/build/v2/user-config.jam ;
  gemacht.....damit lässt sich libboost cross-compilen
• und schließlich: ./bjam toolset=gcc-mipsel --with-serialization --with-filesystem architecture=mips32 cflags="$(TARGET_CFLAGS)" cxxflags="$(TARGET_CFLAGS)" include=$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/include variant=release --prefix=$(TARGET_TOOLCHAIN_STAGING_DIR)
  damit baut er libboost.....das ganze liegt dann in den sourcen unter stage/lib/*

jetzt würde ich das ganze automatisieren.....deswegen hab ich aus freetz im make/lib-verzeichnis die pcre.mk als beispiel genommen und nach boost.mk kopiert......danach entsprechend angepasst......das ganze sieht jetzt so aus:

kontr-olli@lapp-Kontr-Olli:/media/disk/freetz-trunk/make/libs$ cat boost.mk 
$(call PKG_INIT_LIB, 1_39_0)
$(PKG)_SOURCE:=$(pkg)_$($(PKG)_VERSION).tar.bz2
$(PKG)_SITE:=http://downloads.sourceforge.net/project/boost/boost/1.39.0

$(PKG)_SYSTEM_LIB_VERSION:=1.39.0
$(PKG)_SYSTEM_LIBNAME=libboost_system-gcc-mt-1_39.so.$($(PKG)_SYSTEM_LIB_VERSION)
$(PKG)_SYSTEM_BINARY:=$($(PKG)_DIR)/stage/lib/$($(PKG)_SYSTEM_LIBNAME)
$(PKG)_STAGING_BINARY:=$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib/$($(PKG)_SYSTEM_LIBNAME)
$(PKG)_SYSTEM_TARGET_BINARY:=$($(PKG)_TARGET_DIR)/$($(PKG)_SYSTEM_LIBNAME)

$(PKG)_FILESYSTEM_LIB_VERSION:=1.39.0
$(PKG)_FILESYSTEM_LIBNAME=libboost_filesystem-gcc-mt-1_39.so.$($(PKG)_FILESYSTEM_LIB_VERSION)
$(PKG)_FILESYSTEM_BINARY:=$($(PKG)_DIR)/stage/lib/$($(PKG)_FILESYSTEM_LIBNAME)
$(PKG)_STAGING_BINARY:=$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib/$($(PKG)_FILESYSTEM_LIBNAME)
$(PKG)_FILESYSTEM_TARGET_BINARY:=$($(PKG)_TARGET_DIR)/$($(PKG)_FILESYSTEM_LIBNAME)

$(PKG)_SERIALIZATION_LIB_VERSION:=1.39.0
$(PKG)_SERIALIZATION_LIBNAME=libboost_serialization-gcc-mt-1_39.so.$($(PKG)_SERIALIZATION_LIB_VERSION)
$(PKG)_SERIALIZATION_BINARY:=$($(PKG)_DIR)/stage/lib/$($(PKG)_SERIALIZATION_LIBNAME)
$(PKG)_STAGING_BINARY:=$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib/$($(PKG)_SERIALIZATION_LIBNAME)
$(PKG)_SERIALIZATION_TARGET_BINARY:=$($(PKG)_TARGET_DIR)/$($(PKG)_SERIALIZATION_LIBNAME)


$(PKG_SOURCE_DOWNLOAD)
$(PKG_UNPACKED)
TARGET_CONFIGURE_PRE_CMDS:=
TARGET_CONFIGURE_PRE_CMDS += $($(PKG)_DIR)/bootstrap.sh ;
TARGET_CONFIGURE_PRE_CMDS += echo "using gcc : mipsel : $(TARGET_TOOLCHAIN_STAGING_DIR)/bin/mipsel-linux-gcc  ; " > $($(PKG)_DIR)/tools/build/v2/user-config.jam ;
$(PKG_CONFIGURED_NOP)



$($(PKG)_SYSTEM_BINARY) $($(PKG)_FILESYSTEM_BINARY) $($(PKG)_SERIALIZATION_BINARY) : $($(PKG)_DIR)/.configured
	PATH=$(TARGET_PATH) \
		$($(PKG)_DIR)/bjam toolset=gcc-mipsel  --with-serialization --with-filesystem architecture=mips32  \
		cflags="$(TARGET_CFLAGS)" cxxflags="$(TARGET_CFLAGS)" \
		include=$(TARGET_TOOLCHAIN_STAGING_DIR)/usr/include variant=release --prefix=$(TARGET_TOOLCHAIN_STAGING_DIR)/usr \
	all

$($(PKG)_SYSTEM_STAGING_BINARY) $($(PKG)_FILESYSTEM_STAGING_BINARY) $($(PKG)_SERIALIZATION_STAGING_BINARY) : $($(PKG)_SYSTEM_BINARY) $($(PKG)_FILESYSTEM_BINARY $($(PKG)_SERIALIZATION_STAGING_BINARY))
	PATH=$(TARGET_PATH) \
		$($(PKG)_DIR)/bjam install --prefix=$(TARGET_TOOLCHAIN_STAGING_DIR)

$($(PKG)_SYSTEM_TARGET_BINARY): $($(PKG)_SYSTEM_STAGING_BINARY)
	cp -a $(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib/libboost_system*.so $($(PKG)_TARGET_DIR)/
	$(TARGET_STRIP) $@

$($(PKG)_FILESYSTEM_TARGET_BINARY): $($(PKG)_FILESYSTEM_STAGING_BINARY)
	cp -a $(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib/libboost_filesystem*.so $($(PKG)_TARGET_DIR)/
	$(TARGET_STRIP) $@

$($(PKG)_SERIALIZATION_TARGET_BINARY): $($(PKG)_SERIALIZATION_STAGING_BINARY)
	cp -a $(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib/libboost_serialization*.so $($(PKG)_TARGET_DIR)/
	$(TARGET_STRIP) $@

$(pkg): $($(PKG)_SYSTEM_STAGING_BINARY) $($(PKG)_FILESYSTEM_STAGING_BINARY $($(PKG)_SERIALIZATION_STAGING_BINARY)

$(pkg)-precompiled: $($(PKG)_SYSTEM_TARGET_BINARY) $($(PKG)_FILESYSTEM_TARGET_BINARY) $($(PKG)_SERIALIZATION_TARGET_BINARY)

$(pkg)-clean:
	$($(PKG)_DIR)/bjam toolset=gcc-mipsel --clean
	$(RM) $(TARGET_TOOLCHAIN_STAGING_DIR)/usr/lib/libboost*.* 
	$(RM) -r $(TARGET_TOOLCHAIN_STAGING_DIR)/usr/include/boost

$(pkg)-uninstall:
	$(RM) $($(PKG)_TARGET_DIR)/libboost*.so*

$(PKG_FINISH)

leider kommt, wenn ich make boost mache.....das für das paket nichts zu tun gibt......kann mir wer weiterhelfen?

danke und gruß
Kontr-Olli

 

[olistudent]

leider kommt, wenn ich make boost mache.....das für das paket nichts zu tun gibt......kann mir wer weiterhelfen?

Innerhalb der Targets funktionieren Makros wie $($(PKG)_DIR) leider nicht. Da musst du also explizit $(LIBBOOST_DIR) usw. schreiben.

MfG Oliver

 

[Kontr-Olli]

aktuelleste Version von EncFS 1.7.2 (stable)

Hallo,

anbei die aktuelle Version von EncFS 1.7.2. Vollständig statisch gelinkt (u.a. libboost 1.39 und rlog 1.4)

Gepatcht wurde zur Sicherheit wieder allow_holes (siehe Beitrag oben) !

viel Spaß beim Testen,
Kontr-Olli

 

[charlie22]

Hallo

... Vielen Dank für den Code

Ich -bin Unix Anfänger- habe den Code auf meiner Fritz Box 7240 mit AVM Firmware probiert.
Bekomme aber nach der PW Aufforderung den Fehler

fuse: failed to create temporary directory
fuse failed. Common problems:
- fuse kernel module not installed (modprobe fuse)
- invalid options -- see usage message
# modprobe fuse
modprobe: module fuse not found
modprobe: failed to load module fuse

Ich denke mal fuse ist nicht in der AVM Firmware enthalten.
Kann ich ein Kernel Modul statisch linken und nachladen ?
Brauche ich fuse als "root" ?

 

[RalfFriedl]

Nein, ein Kernel Modul kann man nicht statisch linken, sonst wäre es kein Modul mehr. Manche neuer Firmware-Versionen enthalten schon fuse, eben statisch und nicht als Modul.

Du bist hier im Freetz Bereich, aber es ist nicht klar, ob Du tatsächlich Freetz verwendest. Wenn nicht, kann es sein, daß es daran liegt. Insbesondere enthält die original Firmware kein /tmp Verzeichnis.

 

[charlie22]

EncFS und Samba

Danke für die Erklärungen

Ich habe nun Freetz installiert !
Wenn ich auf der Box mit dem MidnightCommander Dateien in das entsprechende Verzeichnis stelle werden die Verschlüsselt auf meinem Webdav share abgelegt. Die Sache funktioniert wunderbar !

Leider verschwindet mein Quellverzeichnis - es wird mit Freetz Samba zur Verfügung gestellt - nach außen hin sobald EncFS gestartet wurde. Intern auf der Box mit dem MC ist alles bestens.

Ist es grundsätzlich nicht möglich das EncFS Quellverzeichnis mit Samba zur Verfügung zu stellen, oder handelt es sich hierbei wohl um ein Berechtigungsproblem ?

 

[Darkyputz]

Hallo und guten Morgen!
Habe mir jetzt den ganzen Thread mit Begeisterung durchgelesen...und das Paket gezogen...
Aber was fang ich nun damit an?
Er sagt man solle die Anleitung aus seinem verhergehenden Thread entnehmen...aber ich war mit sufu nicht in der Lage was zu finden das mir beim starten mit den 3 Binarys helfen würde...
Kann mir da jemand unter die arme greifen?
Danke im Voraus!...

 

[princenewton007]

Kann mir da jemand unter die arme greifen?

Hier ist eine gute Schritt-für-Schritt-Anleitung.

Ist es grundsätzlich nicht möglich das EncFS Quellverzeichnis mit Samba zur Verfügung zu stellen...

Mit den aktuellen Fw-Versionen habe ich EncFS noch nicht benutzt. Mit der ersten AVM-WebDAV-Firmware zeigte der Freetz-Samba das "aufgeschlossene" und das "verschlossene" Verzeichnis auf dem WebDAV jedenfalls an.

 

[tobmaster1985]

Gibt's hier noch Weiterentwicklungen für neuere Firmwares (5.50+) und neuere/andere FritzBoxen (7390)?

 

[jampr]

Hat jemand das EncFS für mips (7390 + 7490) im Einsatz? Bin leider auch nicht in der Lage, das selbst zu erzeugen und würde das aber gerne benutzen.