FreeBSD: encfs automatisch bei boot mounten
 

Hallo allerseits!

Ich habe eine "wilde" Idee für meinen Microserver auf dem FreeBSD 9.2 läuft (laufen soll):

Es geht darum, ein Verzeichnis im Netzwerk freizugeben, welches per bittorrentsync mit einem Backupserver irgendwo anders im Internet synchronisiert wird. Dieses Verzeichnis soll dateiweise verschlüsselt werden.
Vorteil: Alles was aus dem Netzwerk in diesem Ordner gespeichert wird, landet automatisch mit 30 Tage Versionssicherung verschlüsselt in einem dislozierten Backup. Wäre doch geil, oder? ;)

Ich habe die Idee das ganze mit encfs zu lösen, und das entschlüsselte Verzeichnis soll dann via Samba im Netzwerk verteilt werden. Dh. encfs (fuse) muß vor Sambastart gemounted werden.

Sicherheitsbedenken wegen des dann "offenliegenden" Passworts habe ich keine - es geht nur darum die Verschlüsselung am Backupserver sicher zu haben nicht lokal.

Nur: Wie löse ich das?
Mount in der fstab? Aber wie übergebe ich dann das Passwort? Ideen, Anregungen? Hilfe beim googlen? Irgendwie stehe ich an und finde nur automount bei Login --> wäre klarerweise zu spät.

Danke! :)

Hat sich erledigt. Wie es scheint ist encfs/fuse auf FreeBSD zerbröckelt..
Was ich auch anstelle, das gemountete Verzeichnis ist nicht lesbar. Scheint seit 2012 so zu sein:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/173240
Aber auch das Zurücksteigen auf die alte Version brachte bei mir keine Besserung. Ich hau den Hut drauf. :(:p

mit script....
#!/bin/sh
KEYFILE=/path/to/keyfile
/usr/bin/encfs --extpass="cat $KEYFILE" $*

fstab
/path/to/encfs_wrapper.sh#/encrypted /decrypted fuse defaults,kernel_cache 0 0

warum steigst nicht auf Debian um.....

Danke! :)

ad Debian: Weil mich BSD einfach interessiert. Weil bis jetzt alles funktioniert hat was mich interessiert.
Jetzt werd ich mirs überlegen.

bsd ist sehr restriktiv und imho schlecht zum "basteln" geeignet, vielleicht auch schon etwas angestaubt.....spaß macht es aber immer noch :-)

mach nur weiter, so kommt wieder etwas leben ins forum :-)

@sloter: Jetzt weiß ich was du gemeint hast mit BSD. ;)
Kurzer Auszug aus der Odyssee:
Ich verwende encfs sowohl auf Linux als auch Windows. Daher habe ich mir überhaupt keine Gedanken geamcht wie ich gelesen habe, dass es das auf FreeBSD auch gibt.
Nun, installieren aus den ports oder per pkg_add ist ja kein Problem. Nur hat sich herausgestellt, dass encfs nicht funktioniert, weil das Kernel Module von Fuse offenbar mit encfs nicht will.
Wie aus meinen obigen Post zu entnehmen, gibts es seit 2012 einen Error Report darüber. In diesem wird auch erwähnt wie man das repariert: Man steigt einfach von der Version 20080208_11 auf _10 zurück, und zwar mit portdowngrade.
Nun, das war mit portdowngrade V0.6. Seit März 2013 gibt es da aber einen neuen Maintainer, der offenbar ein Arbeitstier ist, denn seit März sind wir bei der V1.4 - sämtliche Optionen aus 0.6 gibt es nicht mehr. Die Bedienung ist komplett anders, und es funktioniert nicht. Nicht nur nicht mehr wie früher sondern es geht einfach nicht. :( Es gibt im Übrigen auch keine man page mehr darüber, keine Doku nix - es steht nur lapidar in den Changelogs: Minor behaviour changes, but still very simple to use
:hammer:
Wie auch immer. Vielleicht stolpere ich mal über eine Lösung - dann werd ich die hier nachtragen. Es war ein interessanter Ausflug in die Unix Welt - jetzt werd ich mein Hauptaugenmerk wieder auf Debian legen.
:-)
PS: Wer encfs nicht braucht, dem kann ich FreeBSD 9.2 für einen Server aber trotzdem empfehlen. ZFS, Samba, ssh usw. funktioniert prächtig.

Hab das ganze jetzt mal mit Debian Wheezy realisiert.
14GB File über Samba von einem Win7 Client ==> ~90MB/sek auf ein zfs raidz mit 4 Platten ohne Optimierung (wobei was soll da noch gehen bei GBit)

Encfs würde an sich auch funktionieren, aber:
Da die encfs Verzeichnisse am zfs liegen, aber die fstab gelesen wird bevor zfs initialisiert wird, geht das so nicht. Klarerweise kann er das verschlüsselte Verzeichnis nicht finden.
Hmm..

Damit man das lesbare Verzeichnis mit Smaba freigeben kann, muß man encfs mit --public mounten.
Trotzdem kann ich mit dem Win7 Client das Verzeichnis mit den entschlüsselten Daten nur lesen aber nix schreiben. Hab wohl irgendwo noch einen Berechtigungsknoten drin. Schaun ma mal.

Aha. Ein 35MB File läßt sich auf das encfs übers Netzwerk problemlos schreiben, nur das 14GB Testfile nicht. :confused: Jetzt wäre ein *kopfkratz* Smiley angebracht. :D

und gelöst?

Nö, noch nicht - weder das automatische Mounten noch das Schreibproblem übers Netzwerk. Hab auch die nächsten Tage keine Zeit dafür. Eine kurze Googlerei läßt mich aber vermuten, dass offenbar nicht viele Leute ein encfs/fuse Verzeichnis, das auf einen ZFS liegt, über Samba ins Netzwerk stellen. ;) :D

da script für das einbinden des encfs/Verzeichnis in den letzten runlevel verschieben. dann sollte fstab und samba abgearbeitet sein.

etwas eigen deine config für den heimbereich, aber was ist schon normal :-)

Ich hab auch was anderes gefunden:
Aus der oracle doc: http://docs.oracle.com/cd/E19253-01/...ztn/index.html
Dh. ich übernehme das mounten des zfs mit
zfs set mountpoint=legacy zfsspeicher
und trage das in der fstab ein
zfsspeicher /mountpunkt zfs defaults 0 0

Kann das jetzt gerade nicht probieren, da ich momentan nicht zum Gerät komme, aber ich werde mich melden.

Etwas eigen meine Konfig? :) Nun ja, die Beweggründe sind folgende:
1.) Warum ZFS
Ich hab mind 3 files die vermutlich durch bit-rot beschädigt wurden. Warum weiß ich das? Sie waren kaputt, nemand hat darauf zugegriffen, in einem uralt Backup auf einer DVD waren sie i.O.
Daher kommt bei mir bei der Datenspeicherung nur noch ein Dateisystem mit Integritätscheck und Compi mit ECC RAM ins Haus.
Klar, die Maschinen die das bearbeiten müssen dann auch entsprechend aufgerüstet werden. Kommt noch.
3 Files von ~1Mio und deswegen dieser Aufwand? Wenn diese 3 Files irgendwelche gerippten mp3s sind, dann scheiß drauf. Wenn diese 3 Files aber die ersten Fotos des neugeborenen Kindes sind, ist dieser Aufwand noch vergleichsweise harmlos gegenüber der Rache der Mutter. ;) :D
2.) Warum encfs
Weil das Backupverzeichnis via Bittorrentsync auf einen dislozierten Server gespiegelt wird. Wenn man nicht will, dass der andere Compi die Dateien lesbar speichert, benötigt man dazu eine dateiweise Verschlüsselung.
3.) Warum im Netzwerk verfügbar?
Das Backupverzeichnis mit Samba im Netzwerk freizugeben, wäre halt eine nette Idee, da dann sämtliche Clients ihre Daten via robocopy bzw rsync dort automatisch ablegen könnten. Kann man natürlich umgehen. (Backupverzeichnis Standardfreigabe und der Server kopiert in das encfs - Daten doppelt vorhanden).

Problem 1 - automatisches mounten des encfs, das auf einem zfs liegt - gelöst: Wie von mir beschrieben, löst man den mountpoint des zfs Filesystems auf welchen das encfs liegt, aus der zfs Verwaltung heraus:
zfs set mountpoint=legacy namezfsfilesystem
Da damit der von zfs verwaltete Mountpoint wegfällt, erstellt man einen Mountpoint zB /hier
mkdir /hier
und trägt das zfsfilesystem in der fstab ein:
namezfsfilesystem /hier zfs defaults 0 0
Damit kann in der fstab dann auch das encfs gemountet werden. Es gibt auch noch andere Lösungswege, aber der hier funktioniert auf meinem System.

Problem 2 - Schreiben von großen Dateien auf das über Samba freigegebene encfs ist weiterhin nicht möglich.
Ich habs mit allen möglichen Dateien bis 600MB probiert und das funktioniert. Allerdings mit magerer Performance von 7,5MB/sek mit 40-50% CPU Auslastung am Server. Das Kopieren von 5,7GB quittiert Windows mit einem Netzwerkfehler. Auf dem HP Server selber funktioniert das Kopieren derselben großen Dateien auf und vom encfs ohne Probleme. *kopfkratz*

Ist encfs tatsächlich so saulangsam? Der AMD Turion II Neo 2x2,2GHz ist keine Rakete aber das das derart lahm ist, hätte ich nicht gedacht.

Problem 2 gelöst: Mein Fehler. Ich habe anscheinend irrtümlich die Option "files holes" auf 'no' gesetzt.
Die Option wurde 2008 in encfs eingebaut eben weil das Kopieren großer Files mit Samba nicht möglich war. Siehe https://bugs.launchpad.net/encfs/+bug/202200
Geschwindigkeit ~9MB/sek bei der Filegröße :(

Damit funktioniert eigentlich alles an Spezialfällen, der Rest mit Email, DNS Server usw ist "Serveralltag". Bleibt nur noch das Performanceproblem bei encfs und ein "wenig" Feinschliff. :p

Frage zum Thread: Der ursprüngliche Thread bezog sich auf FreeBSD auf dem encfs ja nicht läuft. Gelöst wurde das ganze dann mit Debian. So lassen? Oder einen Mod fragen ob das aufgeteilt werden soll?

*SOLVED* :D

bast....debian :-)