On Wed, Sep 11, 2013 at 3:10 PM, .. ink .. <mhogomchungu@xxxxxxxxx> wrote:
You dont seem to have the necessary systemd support to do that and you seem uncomfortable to roll your own solution and hence i suggest zuluCrypt as an alternative convenient solution.I think it is a better alternative since with a GUI application,you will get to unlock the volume when you need access to it and then lock it when done with it.You have a truecrypt volume and you want a convenient way to unlock it.No,it can not,zuluCrypt is a desktop GUI application not designed to be used from root account or as part of boot up process.>I don't think that's the problem: I can open the volume when I'm logged in (as a matter of fact, it's open right now) so cryptsetup >it's working; it's the boot script (cryptdisks_start) that's failing.. Can zulucrypt modify that?
with systemd,it will get unlocked at boot time each and everytime even when you have no need to access the encrypted volume and unlocking later on will involve going to root terminal,something that may not always be convenient.This assumes you are on a desktop system,not a headless server.Choosing btw rolling your own solution and updating systemd components to gain support,i think rolling your solution will be a better alternative.
I think I did not explain my problem well: I have the necessity of unlocking the volume at boot time, because I require constat access to some data that are now stored on the truecrypt volume.
This makes inefficient - at least for me - unlocking the volume after booting the system. The cryptsetup command line allows me to unlock it and, if for some reasons it fails, I can always use truecrypt command line (they have a tar.gz with the CLI) which can be scripted.
This makes inefficient - at least for me - unlocking the volume after booting the system. The cryptsetup command line allows me to unlock it and, if for some reasons it fails, I can always use truecrypt command line (they have a tar.gz with the CLI) which can be scripted.
I'd like to use the system-provided tools, though, and at the moment the cryptdisks_start action that is triggered at boot time (along with /etc/crypttab) is the most efficient way to do it. What I'm trying to understand is what is triggering the "bad variable name" error, because it can't be systemd (it's not installed), so I believe it can only be sysvinit; my current workaround is failing, for some reason, that's what makes me unhappy with rolling my own solution.
My concerns with switching to zulucrypt are mostly two, at the moment: (1) since it appears to me as a GUI interface for cryptsetup, it doesn't seem to fit my current need and (2) even if it can help me (by, for example, providing a CLI which I can trigger from rc.local or some other script at logon), it has no permissions to mount a device in /media/ (because, as you said, it does not require administrative privileges), nor can 'mount -o bind' the folders I'm mounting in my home.
If there's anything I missed, or a way to do what I'm trying to do using zulucrypt, I'm open to any suggestions, and I'll be willing to try them. My goal is to reach what I had when my Windows disk was unencrypted.
Thanks,
Claudio
Thanks,
Claudio
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
