Posts by ikogan

    zfs-mount was not in S, in fact, the default script is defined thusly:


    Code
    ### BEGIN INIT INFO
    # Provides:          zfs-mount
    # Required-Start:    $local_fs zfs-import
    # Required-Stop:     $local_fs zfs-import
    # Default-Start:     2 3 4 5
    # Default-Stop:      0 1 6
    # X-Stop-After:      zfs-zed
    # Short-Description: Mount ZFS filesystems and volumes
    # Description: Run the `zfs mount -a` or `zfs umount -a` commands.
    ### END INIT INFO


    So it clearly depends on $local_fs and doesn't start during S. I've setup an override for it and that's moved it into S, we'll see if that does the job.

    Yes, it looks like zfs-mount runs too late:



    The line right before rpcbind is the zfs-mount script.

    It does take quite a bit of time for the import to complete, but I figured the import operating was synchronous and boot wouldn't continue until it's fully imported. Is that not the case? Is there any way to tell when import is completed?


    Oh, it looks like "zfs-import" runs "zpool import" with the "-N" argument, which doesn't mount any filesystems. It looks like zfs-mount takes care of mounting, and it requires "$local_fs". Perhaps that's the issue? I've enabled verbose mounting in /etc/default/zfs, we'll see what happens the next time I reboot.

    It looks like it is:



    Though... it *is* importing before other things try to mount...so I'm not sure why the bind mounts are failing.

    Well, when I did it, all my existing containers vanished, so...that's probably an issue :-P. One of the problems I'm going to run into here soon is goign to be plugin related. I'm trying to build a FreeIPA plugin to provide a first class Directory implementation to OMV. FreeIPA creates a server with LDAP, Kerberos, DNS, and other things integrated to support managing of network users, groups, hosts, as well as sudo, selinux, and host login policies, domain trusts with AD, etc. It's all wrapped up nicely in a web UI. The problem is, I *might* need to use the device mapper driver for it, but I'm not sure yet. I'll know more later. The major issue here is that when installing the plugin, I'd need to switch the docker daemon over to that driver, potentially blowing away people's containers or creating other weird behavior. I'm not sure of the best way to solve that yet.

    I'm still having boot issues with the latest version of ZFS. It looks like zfs-import runs after the local filesystems are mounted. I have a lot of "bind" mounts setup for NFS and one for Docker that obviously won't work unless my zfs is imported first.


    Can I just add $local_fs to the dependencies for the zfs-import init script? Should I provide an insserv override?

    I think it may be a good idea to change the default filesystem driver to "devicemapper". It looks like AUFS (the current default) has some bugs with Fedora based containers. Some RPMs try to use "cpio" to install things and it turns out AUFS doesn't quite work with that when running inside of an LXC container, you get a CAP_CPIO error.


    Adding


    Code
    DOCKER_OPTS="-s devicemapper"


    to the `/etc/default/docker` fixed this for me and I was able to get FreeIPA to start afterwards too.

    So I created a new docker container by choosing "Run Image" and filling out the form. The container wasn't able to start up properly because apparently I had told it to map a port that was already in use. This resulted in some confusing behavior:


    1. The "Run Image/Create Container" dialog did not go away.
    2. A container was created, or at least, the bottom section lists the container I tried to create but this was not immediately obvious due to (1). I tried to hit the "Run" button on that dialog again and it informed me that the container already exists.
    3. I can't seem to start the container as all of the "Start", "Stop", and "Restart" buttons are disabled. The container is in "Created" status. If I do "docker ps" on the command line, the container is not listed. I can get the container details though...


    So, what gives? Where do I go from here? Copying the container resulted in two containers with the same status. I'm also a little unclear what the "Create" button does. It seems to create a container similar to the one that's currently selected?

    I finally found the time to update my system due to the ZFS related init issues and ran into a strange problem. It seems that the kernel is unable to initialize my USB thumb drive boot device during the initramfs phase properly unless I yank it out and re-insert it while it's "Waiting for root filesystem". I have a SuperMicro X7QC3 motherboard with an AMI BIOS and my USB controller is set to boot at "HiSpeed" in the BIOS. It gets through Grub with no issues and loads the kernel image and the initrd into memory without issue. It then happily detects all of my hard disks used in my ZFS setup with no problem. If I do nothing it will wait for the root FS (on the USB drive) to show up until something times out at which point it will drop me to an initramfs busybox prompt. Looking for the device shows that nothing has been detected. Sometimes I will get errors about a USB device not being able to be enumerated.


    If I, instead, wait for "Waiting for root file system" to show up and pull out and re-insert the USB drive, it will properly detect it and boot up fine. So...what gives? Does anyone have any idea what's going on?


    Woops, forgot to provide any useful information. The USB thumb drive is a "SanDisk Ultra Fit" with ID "0781:4483".


    uname output: Linux ezra 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u5 x86_64 GNU/Linux
    apt-show-versions: linux-image-amd64/wheezy uptodate 3.2+46
    dmesg:



    In that log, I waited until I saw


    Code
    [ 18.232033] usb 1-4: device descriptor read/64, error -110
    [ 23.456021] usb 1-4: device descriptor read/64, error -71
    [ 23.616253] hub 1-0:1.0: unable to enumerate USB device on port 4


    before yanking and re-inserting the thumb drive.

    I'm not sure why @gderf is being downvoted. While Linux certainly does allow multiple IP addresses on the same subnet the behavior is *not* the same as having multiple *interfaces* on the same subnet. The issue is that Linux, by default, will identify a given IP address as "itself", and will thus respond to ARP requests for any of it's IPs with the first interface on that network (or a random interface on that network?). This is a solvable problem but is less than intuitive and oftentimes a bit complex. Useful reading:


    http://unix.stackexchange.com/…-for-correct-arp-response
    http://linux-ip.net/html/ether-arp.html (specifically the "ARP Flux" section)
    http://askubuntu.com/questions…ddresses-with-one-gateway
    https://www.centos.org/forums/viewtopic.php?t=8401


    Also, you may actually want to solve your issue via Bonding rather than doing load balancing the way you're trying to do.

    Quote

    I mean, creating a container that is stored on the NAS and opened on the Client


    What about multiple clients having access to the same container? I'll agree that, in your use case, VeraCrypt is effectively necessary since it's the only real cross platform solution.

    It's possible, but at that point it just depends on what the plugin wants to do. I think having Docker as an option for plugins would be great, especially if the Docker plugin could provide some APIs for other plugin authors to easily stop/start/create/etc. containers.

    I might look into the deep silences. The problem isn't so much the case fans but the PSUs. The box has dual 1000W redundant hot swap PSUs with tiny fans. Those are the loud ones. They're even on (though slower) when the machine is powered off! The SuperMicro motherboard is pretty huge, so I'm worried about other cases and I would really like to have hot swapping support. I'm assuming the Deep Silence doesn't come with any kind of hostswap backplane?


    Edit: Do not use ZFS with a hardware raid controller, it won't provide any benefit and will usually cause problems. You want ZFS to have native, direct access to the disks as that's what it's designed for. http://serverfault.com/questio…ctices-with-hardware-raid

    You're fine. I did use TrueCrypt, I don't see why it's easier on a Linux box than native encryption for an entire filesystem, unless you're suggesting they create an encrypted container on an existing drive which...has a lot of drawbacks and is hackery that needs to be done carefully for the rest of OMV to work. Are you suggesting they install a desktop environment so they can use a VeraCrypt GUI?


    Now, it's certainly easier on a desktop system for a container within the larger system (though I'd never create a many-terabyte container on a RAID, maybe if the RAID was XFS?) or for an external drive but the key being desktop system, where you have access to the VeraCrypt GUI.


    For a console:


    Code
    dd if=/dev/urandom of=/data/encrypted bs=1G count=128 # Or /dev/random if you want to be more secure
    cryptsetup -y luksFormat /data/encrypted
    cryptsetup luksOpen /data/encrypted encrypted
    mkfs.ext4 -j /dev/mapper/encrypted
    mkdir /media/encrypted
    mount /dev/mapper/encrypted /media/encrypted


    Doesn't seem too bad. Mounting it again later with


    Code
    cryptsetup luksOpen /data/encrypted encrypted
    mount /dev/mapper/encrypted /media/encrypted


    Is quite easy and scriptable. You still end up with a huge container on your filesystem (the example being 128gb). I'd prefer to use something like encfs, which encrypts individual files but it has some weaknesses. I'm hoping that https://github.com/vgough/encfs will be ready and viable soon for that purpose.


    The trick is integrating whatever encryption software is used with the OMV GUI and system so it works sufficiently seamlessly.

    If this is for home users than I feel it's even *more* important that users are protected from screwing themselves over.


    "What do you mean the Docker container I was using for my PhD dissertation is gone?"


    In later news: divorce caused by clicking button in home server.