Auto unmount truecrypt volume bei shutdown

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallo Leute,
    ich bin noch neu mit raspberry pi und linux und bin gerade dabei mich damit auseinander zu setzen. komme soweit auch klar, habe jedoch jetzt eine frage und ich hoffe ihr könnt mir helfen: Ich habe es geschafft, dass ein Truecrypt-Volume per USB angeschlossen automatisch beim start des raspberry pis gestartet wird. jetzt ist meine frage: muss das volume auch unmountet werden, wenn der rapsberry pi runtergefahren wird? ich denke nämlich schon. Aber wie bekomme ich es hin, dass nach dem befehl "sudo shutdown -h now" automatisch das truecrypt volume ausgeworfen wird?

    Danke euch für die Hilfe, ich habe nämlich leider bei google und auch hier nicht viel gefunden. Das einzige, was ich dazu gefunden habe ist, dass es wohl "rc.local.shutdown" gibt. Aber diese Datei ist auf meinen Raspberry nicht verfügbar und ich habe leider nicht rausgefunden, wie ich diese datei anlegen kann und auch dafür sorgen kann, dass diese ausgeführt wird!

    lieben Gruß und Danke,
    jaithn

  • Wie hast Du denn das mounten beim Booten gemacht?

    Wenn Du dafür ein init Script in /etc/init.d/ abgelegt hast und das dann per Symlink in /etc/rc2.d/S06mounttruecrypt gelinkt hast kannst Du das auch genau so in /etc/rc2.d/K06mounttruecrypt linken. Das S sagt beim Starten ausführen und K beim herunterfahren.

    Dafür sind ja im Script die Case Anweisungen mit start), Stop), usw. da.

    /etc/init.d/mounttruecrypt
    #/bin/bash
    ### BEGIN INIT INFO
    # Provides: mounttruecrypt
    # Required-Start:
    # Required-Stop:
    # Default-Start: 2
    # Default-Stop: 0 2 6
    # Short-Description: mount and umount truecrypt
    # Description: Auto mount and unmount Truecrypt Container
    ### END INIT INFO
    MOUNTPOINT="/path/to/truecrypt.container"
    TRUECRYPTCONTAINER="/mnt/openconainter"
    PATH=/bin:/usr/bin:/sbin:/usr/sbin
    start()
    {
    truecrypt --mount ${TRUECRYPTCONTAINER} ${MOUNTPOINT}
    }
    stop()
    {
    truecrypt -d ${MOUNTPOINT}
    }
    case "$1" in
    start)
    start
    ;;
    stop|0)
    stop
    ;;
    *)
    echo "Usage: /etc/init.d/mounttruecrypt {start|stop} "
    exit 1
    ;;
    esac
    exit 0

    Der Blöcke ### BEGIN INIT INFO bis ### END INIT INFO ist wichtig damit es LSB Konform ist. Würde auch ohne klappen, aber beim apt und Installation von neuen Paketen kommt es dann zu Problemen.

    Das dann nach /etc/rc2.d/S99mounttruecrypt und /etc/rc2.d/K99mounttruecrypt linken:

    ln -nfs /etc/init.d/mounttruecrypt /etc/rc2.d/S06mounttruecrypt
    ln -nfs /etc/init.d/mounttruecrypt /etc/rc2.d/K06mounttruecrypt

    Du kannst vorher noch mal "runlevel" eingeben, da sollte dann "N 2" rauskommen. Falls da was anderes raus kommt wie z.B. 3,4 oder 5 musst Du als Ziel bei rcX.d das X durch das passende Runlevel ersetzen.

    Da ich dir Runlevel jetzt eh schon angesprochen habe:
    0 shutdown
    1 Singleuser Modus (zum reparieren des System angedacht)
    2 Meistens das standard Runleven, keine Grafik
    3 usw.
    4 usw.
    5 meistens grafische Oberfläche
    6 reboot

    Das wird alles in /etc/rcX.d/ gesteuert. Damit kann man in den einzelnen Runleveln welche Scripte, Programme und Dienste beim booten hochgefahren werden sollen. Hat man mal ein Problem mit einem Dienst oder Programm und will nicht das es beim Starten schon mit hochgefahren wird trägt man es nicht in das Runlevel mit ein. Man kann erst etwas vorbereiten, wie Logfiles schon mal öffnen usw. und erst wenn man alles vorbereitet hat zum debuggen den Dienst manuell starten. Oder man wechselt mit "init 3" nach Runlevel 3 wo der Start des Dienstes mit eingetragen ist.
    Andersrum geht das auch. Möchte man z.B. in Runlevel 3 das System so weit gestartet haben das alle Dienste wie Webserver, Datenbank usw. aus sind, für Backups oder Updates/Wartung träge man für Runlevel alles so ein das sie gestoppt werden und man schnell alles ausschalten kann.
    init 3
    # Wartung/Update/Backup usw. und dann wieder zurück
    init 2

    Die Dienste werden dann wieder gestartet.

  • Eine wirklich super ausführliche Beschreibung ruedigerp, hätte nur an 2 stellen kleine Verbesserungsvorschläge ;)

    Einmal der LSB Header des Scripts, da würde ich die Required auch noch ausfühhlen sowie ggf auch die Start / Stop Runlevels abändern - du hast das Script nämlich laut dem Header so eingestellt das es nur beim Runlevel 2 gestartet werden soll, aber das wäre dann nur:

    Zitat


    Lokaler Mehrnutzerbetrieb ohne Netzwerk mit ausschließlich lokalen Ressourcen. Unter einigen Linuxdistributionen (z. B. Debian) wird in Runlevel 2 auch das Netzwerk konfiguriert.


    Würde er also kein Debian nutzen, würde dieser Runlevel vermutlich eher selten genutzt werden da die meisten vorzugsweise einen Runlevel mit Netzwerk verwenden ;)

    Üblicher wären Runlevel 3 und 5:

    Zitat


    Runlevel 3:
    Im Runlevel 3 sind alle lokalen Ressourcen verfügbar, und es bestehen Mehrbenutzer- sowie Netzwerkunterstützung. Dies ist der übliche Runlevel für Systeme ohne grafische Benutzerschnittstelle und nach einer Arch-Grundinstallation der Standard-Runlevel.

    Runlevel 5:
    Wie 3, zusätzlich wird die grafische Oberfläche bereitgestellt.

    Guckt man in die bereits vorhandenen /etc/initd.d/ Scripts sieht man das die meisten zumindest " 2 3 4 5 " bei Default-Start stehen haben und bei Default-Stop steht meistens " 0 1 6 " (auch wenn beim Start eine 2 gelistet ist)

    Dazu kommt das ich bei " Required-Start: " auch $local_fs eintragen würde, das muss vorher bereits gestartet sein bevor das Script ausgeführt werden kann

    Da gibt es aber eben geringfügige Unterschiede je nach Linux Distribution - zB für Ubuntu gibts da eine ausführliche Beschreibung: http://wiki.ubuntuusers.de/Dienste

    Und für Debian (Raspbian ist quasi Debian) wird das hier beschrieben: https://wiki.debian.org/LSBInitScripts


    Also ich würde das Script von ruedigerp eher so nutzen:

    In dem Script müsste noch MOUNTPOINT sowie TRUECRYPTCONTAINER vom Benutzer angepasst werden und anschliesend natürlich auch noch ausführbar machen:
    chmod 755 /etc/init.d/mounttruecrypt


    Und das zweite wäre das man vorzugsweise den Befehl update-rc.d benutzen sollte um die init.d Scripts einzubinden, dabei wird dann nämlich auch geprüft ob der LSB Header korrekt ist und die Symlinks werden entsprechend angelegt usw - du hast nämlich leider zwar geschrieben "Das dann nach /etc/rc2.d/S99mounttruecrypt und /etc/rc2.d/K99mounttruecrypt linken:" aber im Symlink steht dann S06 und K06

    Welche Nummer es dort kriegt, würde davon abhängig sein wann der USB-Stick gemounted beziehungsweise unmounted wird - also K99 wird vermutlich bereits zu spät sein und ein sauberes schliesen des Containers wäre dann nicht mehr möglich :-/

    Dazu müsste also zunächst geklärt werden wie bzw wann der USB-Stick mit dem TrueCrypt Container gemounted wird bzw wie jaithn das derzeit geregelt hat


    Ein weiterer wichtiger Punkt ist das bisher nicht erwähnt wurde dass beim mounten des Trucrypt-Containers normalerweise nach dem Passphrase gefragt wird - das kann man aber auf diese Art und Weise natürlich nicht eingeben

    Dann fängt allerdings auch schon der Knackpunkt an:
    Würde man ein Keyfile nutzen was sich auf dem selben Datenträger wie der Container befindet, würde es eigentlich garkein Sinn mehr machen überhaupt einen verschlüsselten Container zu benutzen - wenn jemand den Stick mit nimmt kann er ohne ein Passphrase wissen zu müssen auf den Container zugreifen da er das Keyfile ja auch gleich mit dabei hat....

    Packt man aber den Container auf die SD-Karte würde diese verstärkt mit Lese/Schreib-Zugriffen belastet werden, also kämen dann eigentlich nur 2 Dinge in Frage das Keyfile getrennt vom Container aufzubewahren:
    1. zweiten USB-Stick mit Keyfile
    2. Keyfile auf die SD-Karte

    Eine weitere aber auch nicht so schöne Möglichkeit wäre den Parameter " -password='' " beim mounten zu nutzen - dabei stellt sich dann allerdings wieder die Frage nach dem Sinn eines Verschlüsselten Containers - also ich würde einen getrennt aufbewahrten Keyfile bevorzugen


    PS: Eine google Suche nach DE:truecrypt init.d gibt auch einige Scripts zur Auswahl


    Wer wissen möchte wie er truecrypt überhaupt installiert kriegt kann das dort nachlesen: http://jankarres.de/2013/04/raspbe…en-und-mounten/

  • Ok, mit dem Header bin ich einverstanden ;)
    update-rc.d pfff, gab es früher nicht, daher konnte ich mich nie da dran gewöhnen.
    Aber ja, für manche ist das besser die Abhängigkeiten von dem Tool machen zu lassen.

    Wenn das Script K99 gelinkt wäre würde das nicht zu spät sein, der Kernel räumt die eingehängten FS eh sauber aus bevor er sich verabschiedet.

    Kurze Frage, hab das in der Doku so schnell nicht gefunden.
    # Required-Start: $local_fs
    Was ist mit $local_fs beim Required-Start noch mal gemeint gewesen? Weil das Root-FS ist vom Kernel eh dann schon eingebunden, sonst würde der init nicht starten können und das wieder die Initscripte nicht finden.

    Zu dem automount wollte ich auch erst noch etwas schreiben, da mir auch im ersten Moment das gleiche durch den Kopf gegangen ist, da ich es auch sehr unschön finde ein FS zu verschlüsseln und dann aber per Script mit Passwordparameter oder PassKey dann das FS wieder zu entschlüsseln.
    Das ist gefühlt wie die Haustür abschliessen und den Schlüssel auf die Fußmatte davor legen.


  • Kurze Frage, hab das in der Doku so schnell nicht gefunden.
    # Required-Start: $local_fs
    Was ist mit $local_fs beim Required-Start noch mal gemeint gewesen? Weil das Root-FS ist vom Kernel eh dann schon eingebunden, sonst würde der init nicht starten können und das wieder die Initscripte nicht finden.

    Es geht aber ja nicht darum wann die init.d Scripts gemounted sind um ausgeführt werden zu können, sondern wann auf den Truecrypt Container zugegriffen werden kann und der läge in diesem Fall ja extern auf einem anderen Device - also wäre eigentlich sogar $remote_fs richtiger wenn ich da genauer drüber nachdenk :D

    Genaueres kann man am Ende von https://wiki.debian.org/LSBInitScripts nachlesen

  • Hey ihr,
    danke für eure Rückmeldungen. Ich hatte das automount vorher in der rc.local datei. habe es da jetzt aber wieder rausgenommen und wie ihr erklärt habt habe ich eine neue datei /etc/init.d/mounttruecrypt erstellt. Aber wie genau soll ich die jetzt [font="Tahoma, Verdana, Arial, sans-serif"] [/font][font="Tahoma, Verdana, Arial, sans-serif"]update-rc.d[/font][font="Tahoma, Verdana, Arial, sans-serif"] benutzen?[/font]

    [font="Tahoma, Verdana, Arial, sans-serif"]Ja, das mit dem Password ist ziemlich doof. Aber wie kann man das generell besser machen? [/font]

    [font="Tahoma, Verdana, Arial, sans-serif"]Danke für eure Hilfe,[/font]
    [font="Tahoma, Verdana, Arial, sans-serif"]Janik[/font]

  • Bevor man auf update-rc.d eingeht solltest du dir nochmal Post#4 genauer durchlesen, ab dem grösseren und fettgedruckten Satz .. denn die Fragen nach dem "wie entschlüsselungs password eingeben" sollte man erstmal klären ;)

  • Hey Leute,
    vielen Dank für die ganze Hilfe. Ich habe da jetzt noch mal eine Frage: Wenn ich das skript selber ausführe, dann funktioniert alles sehr gut. Wenn es jedoch durch das system bei einem neustart durchgeführt wird, bekomme ich beim zugriff auf den truecrypt-mount nur ein "access denied". Was muss ich tun?

    jaithn

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!