LUKS disk encryption plugin

    • OMV 2.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • wget http://omv-extras.org/debian/pool/main/o/openmediavault-luksencryption/openmediavault-luksencryption_1.1.0_all.deb
      dpkg --force-all -i openmediavault-luksencryption_1.1.0_all.deb
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.4
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      wget http://omv-extras.org/debian/pool/main/o/openmediavault-luksencryption/openmediavault-luksencryption_1.1.0_all.deb
      dpkg --force-all -i openmediavault-luksencryption_1.1.0_all.deb


      Cool, and thanks.

      So the bit "openmediavault-luksencryption depends on cryptsetup (>= 1.4); however:
      Package cryptsetup is not installed." can be safely ignored?
      OMV 3.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • tekkb wrote:

      That will ignore control file? and force it to install?

      I didn't try it but it should. Otherwise, I will just change the depends since it does work with 2.18 even though there is a visual issue.
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.4
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • Does cryptsetup need to be entered differently in the control file??? 2:1-4

      Source Code

      1. apt-cache policy cryptsetup
      2. cryptsetup:
      3. Installed: (none)
      4. Candidate: 2:1.4.3-4
      5. Version table:
      6. 2:1.6.4-4~bpo70+1 0
      7. 100 http://ftp.debian.org/debian/ wheezy-backports/main amd64 Packages
      8. 100 http://http.debian.net/debian/ wheezy-backports/main amd64 Packages
      9. 2:1.4.3-4 0
      10. 995 http://ftp.us.debian.org/debian/ wheezy/main amd64 Packages
      Display All
    • @ryecoaaron's method is best, manually force the deb to install with dpkg. As observed, this doesn't bring in dependencies, so then you'll to manually install the crypt utilities with apt-get install cryptsetup cryptsetup-bin (@gderf this should fix your issues).
      apt-get -f install will not work because it will attempt to remove openmedia-luksencryption (until OMV 2.1.19 is out).

      @tekkb not sure if the control file deps is written properly or not. It does however, work i.e. bring in all the right crypt stuff, when installing the plugin (for older versions that didn't have the 2.1.19 req that is). I actually probably don't need the min v1.4 dep, but I put that on because I hadn't tested with older cryptsetup and 1.4 is what is in wheezy anyway.

      Hopefully OMV 2.1.19 will be released soon anyway, it's only a small patch.
    • When I wrote the instructions, I was assuming people were upgrading the plugin and already had cryptsetup installed :)

      Your control file is fine. As far as the cryptsetup version, if the version in the normal wheezy repo is acceptable, I wouldn't put a version on it but it doesn't hurt anything.
      omv 4.0.5 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.0.4
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • Ah yes, much like the rest of OMV, if you want to work with encrypted partitions you have to create them yourself via the command line or some other means.
      Having said that, even then it's not straightforward at the moment with the encryption plugin, encrypted partitions will show up in the interface, but unlocking doesn't work, I haven't tried the key stuff on a partition, but might also be problems.
      I do plan to look into this so that existing partitions are better supported, but it will remain largely a 'you're on your own' situation to some extent.
      Moreover, partitions on top of encrypted devices will never be supported - I highly advise against this method.
    • Perhaps I was a bit hasty, I thought 2.1.19 would be out quickly, given that 2.1.18 came out quickly when I submitted a patch for that.
      If 2.1.19 is not out by the time I next release a version, I will downgrade the dependency to 2.1.18 again.
      I appreciate it's inconvenient, but to be fair the plugin is still in testing/development.
    • I am finding the plugin very useful, thanks for this.

      When I unlock a disk, it mounts automatically, neat!

      I have some aufs br: mountpoints in my fstab and these are mounted automatically at boot.

      But one of these aufs br: mountpoints, a new one, is inside the encrypted disk. To make it accessible after unlocking the encrypted disk, I run 'mount -a' from the shell. Is there some way this could be incorporated into the plugin, ie via a button, or if not otherwise harmful, just run 'mount -a' after unlocking and mounting an encrypted disk? Or is there some other method that would not require any user interaction?
      OMV 3.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • I don't know anything about aufs br - is it radically different from other filesystems? It's an overlay thing of some type, right?
      I don't think causing the plugin to run 'mount -a' is a good idea, as this causes the system to mount all filesystems in /etc/fstab - a user might have unmounted a particular filesystem on purpose and this would cause it to remount, which would be an unexpected side effect (i.e. violates the principle of 'least surprises' - or at least, the bad ones!).
      The plugin will mount a filesystem inside an encrypted container when unlocking if the filesystem is 'known' to OMV, that is, it is found in the /etc/openmediavault/config.xml file. The most likely way that this can occur is if you have clicked the 'Mount' button on the Filesystem panel in the WebGUI, this causes it to be written to the config file and also /etc/fstab, along with setting up the requisite mountpoint directory.
      So this would seem to suggest your aufs filesystem is not mounted in this way - is this so?