Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29

Thread: Success with desktop LXD containers! Woot!

  1. #11
    Join Date
    Mar 2011
    Location
    19th Hole
    Beans
    Hidden!
    Distro
    Ubuntu 18.04 Bionic Beaver

    Re: Success with desktop LXD containers! Woot!

    Quote Originally Posted by TheFu View Post
    …Guess I won't be moving any GUIs into LXD. ;( …
    A crying shame. I was hoping for your input on LXD vs VM. I have an ancient nVidia GPU in my old laptop running nouveau. Will try that and report back.

  2. #12
    Join Date
    Mar 2010
    Location
    Squidbilly-Land
    Beans
    19,297
    Distro
    Ubuntu Mate 16.04 Xenial Xerus

    Re: Success with desktop LXD containers! Woot!

    Quote Originally Posted by DuckHook View Post
    A crying shame. I was hoping for your input on LXD vs VM. I have an ancient nVidia GPU in my old laptop running nouveau. Will try that and report back.
    I've been watching containers for a long time. Attended lots of training and decided it wasn't fleshed out if you were running important workloads - something beyond showing cat videos. That was the situation until about 2 yrs ago. Default settings in many container helper tools were non-secure by default.

    LXD was always at the top of my list to try. I never planned to try Docker for a number of reasons. I won't deploy any docker containers on our infrastructure. This is a mix of ignorance and annual bone-head security problems with Docker. When it comes to any docker-like container, if you don't built it yourself, you've just handed over your entire infrastructure to someone else. I'm not really interested in recreating new docker containers weekly as a patching method. If I can get the same density and performance from lxd, while retaining a similar patch paradigm, why not. I just need to be cautious about the VMs that get moved into LXD. For example, getting a VPN server working seems to require some network + LXD gymnastics I'm not ready to handle, yet.

    How secure are LXD containers? Hard to say. They aren't the industry standard, so they aren't being specifically attacked like KVM and Docker containers are being attacked.

    Yesterday, I had to wipe out the ZFS stuff that was automatically generated, create a new LV and mount it into the /var/lib/lxd/ directory to prevent / from filling up. I am liking that a base OS is just 360MB. That's very nice.

    Probably will put an email gateway system into lxd first. It is tiny. Doesn't have any data and the version of debian running on it has been failing to start networking after patching. Sometimes it is fine. Other times, it requires a few reboots. Makes no sense. I'm blaming systemd - whenever something is working perfectly for 3 yrs, then a patch happens and breaks networking, it is always systemd's fault. Always.

    I'm afraid that ancient nVidia GPU means you won't find any nvidia drivers compatible with 18.04. During my last system build, I decided to get a new GPU only because the ones I have laying around are no longer supported since 14.04. Reckon I got my $40 worth from each.

    Anyway, I'll be moving some servers into LXD slowly over the next few months, depending on how the first one goes. I've been slowing reducing the number of VMs here. Started at 25, then got to 20, 15, now down to 8. Don't think I can go smaller.

    Off to reduce some ignorance now. Plenty of reading to do.

  3. #13
    Join Date
    Mar 2011
    Location
    19th Hole
    Beans
    Hidden!
    Distro
    Ubuntu 18.04 Bionic Beaver

    Re: Success with desktop LXD containers! Woot!

    My needs are not remotely as mission critical as yours. I just wanted to be able to:

    • Reduce the overhead of running VMs on old, less capable machines,
    • Sandbox my apps enough to create another effective barrier to the bad guys,
    • Take snapshots of app states that will only eat up tiny disk space,
    • Run the odd game at close to native speed.

    LXD sounded perfect when I first heard about it, but that was 3 years ago and it just wasn't ready for prime time—on the desktop anyway. I struggled mightily with it, but couldn't wrap my head around the needed sorcery. But Simos' website untangled lots of knots, and now that I'm sandboxing app after app, it's just marvellous. Am hiving off into containers all of the stuff that used to bother me so much when left on my host.

    I'm aware that it's only as secure as the next CVE, but I'm guessing that it's still a useful addition to security in depth.

  4. #14
    Join Date
    Nov 2009
    Beans
    Hidden!
    Distro
    Kubuntu 18.04 Bionic Beaver

    Re: Success with desktop LXD containers! Woot!

    so the question - why this useful feature is not made user friendly (e.g. script on install, GUI installer etc.)? would it then make it less secure? is it not useful enough?
    Read the easy to understand, lots of pics Ubuntu manual.
    Do i need antivirus/firewall in linux?
    Disk backup (works on newer PC): Clonezilla
    User friendly full disk backup Redobackup is now back as Rescuezilla

  5. #15
    Join Date
    Mar 2010
    Location
    Squidbilly-Land
    Beans
    19,297
    Distro
    Ubuntu Mate 16.04 Xenial Xerus

    Re: Success with desktop LXD containers! Woot!

    Quote Originally Posted by mastablasta View Post
    so the question - why this useful feature is not made user friendly (e.g. script on install, GUI installer etc.)? would it then make it less secure? is it not useful enough?
    Containers are mainly used by enterprises on headless servers. That's where all the action, updates, research is going because enterprises PAY for capabilities. Enterprise computing is so different from what typical Ubuntu Desktop users do, they cannot really talk with us. Everything is encrypted on the wire and at rest. User management is centralized. There aren't any GPUs. Serial consoles are key, which I suspect 90% of home Linux users have never seen. Heck, Ubuntu won't boot with just a serial console connected without some GRUB options.

    Enterprises don't use virtualbox for server virtualization. Perhaps a few developers do, but most are migrating to Docker containers for deployment. MSFT didn't have any choice except to create WSL, or they would have lost all the developer desktop OSes.
    • Reduce the overhead of running VMs on old, less capable machines,
    • Sandbox my apps enough to create another effective barrier to the bad guys,
    • Take snapshots of app states that will only eat up tiny disk space,
    • Run the odd game at close to native speed.
    • a) Yep. I'm surprised that LXD is about the same as Docker, since LXD does have more overhead being that it runs much more code inside containers.
    • b) Firejail.
    • c) LVM has snap shots. So does qcow2 VM storage.
    • d) This. This has been the harder part. My attempts to get games from 2002 and earlier to _just work_ have usually failed unless they are really bonehead. My last attempt was to get C&C running. There are so many dependencies that I gave up, installed the snapd subsystem and tried to use one of those "easy to deploy" game installers. I own C&C (The Covert Operations pak), but wasn't able to get it working. I don't do FPS, but some old flight sims should easily be playable on modern hardware at full speed even with emulation.



    LXD sounded perfect when I first heard about it, but that was 3 years ago and it just wasn't ready for prime time—on the desktop anyway. I struggled mightily with it, but couldn't wrap my head around the needed sorcery. But Simos' website untangled lots of knots, and now that I'm sandboxing app after app, it's just marvellous. Am hiving off into containers all of the stuff that used to bother me so much when left on my host.
    The best thing about LXD is the compartmentalization, but with the GUI use, there are a bunch of holes between the container and the hostOS.
    Intel has been working on a native VM solution where the host and VMs can share the same GPU (intel only) for a few years. About every 6 months I check it out and see a 2 minute demo on youtube. The demos seem to crash just after they cut the video. It works with about 5th-gen Core i5 CPUs (desktop and mobile) that have an iGPU. The problem is the packaging. There wasn't any last fall. Rebuilding the kernel was required. Around June, I'll look again. GVT - https://01.org/igvt-g is their official site. Looks like work as stalled in 2019.

    For GUI programs, firejail is my answer today. It can be used with all programs, but then we end up with unusable setups where network-centric programs cannot access any network resources. Sorta pointless. What good is whois if it can't query a remote whois server?

    In 2008, I started as CIO at a little startup. We needed to use virtualization, but didn't have too powerful systems. Xen with paravirtualization was used. This is sorta like LXD. The same kernel that runs on the host is shared by all the guests. There were some problems with Xen. We got some new, faster, hardware in 2010 and switched to KVM. KVM was pretty fast and didn't have the problems we'd had with Xen. Shared kernels bring some problems that aren't obvious at first.

    There are many choices today. Containers have been effectively marketed as a great choice. Google has gone all-in with containers. Read somewhere that each search request is spun up as a separate container, does the search, waits for the URL click, captures all the data they can from the query, then spins down. It happens so fast, we don't notice it.

  6. #16
    Join Date
    Mar 2011
    Location
    19th Hole
    Beans
    Hidden!
    Distro
    Ubuntu 18.04 Bionic Beaver

    Re: Success with desktop LXD containers! Woot!

    Quote Originally Posted by mastablasta View Post
    so the question - why this useful feature is not made user friendly (e.g. script on install, GUI installer etc.)? would it then make it less secure? is it not useful enough?
    Good question:

    • The devs are not focused on the desktop at all. The overwhelming thrust for the technology is in server-space or cloud-space.
    • Desktop implementation is an afterthought and perhaps not even that. Currently, desktop is a hobbyist's implementation.
    • It remains very bleeding edge. LXD does not even have man pages yet. It uses ZFS, btrfs or LVM at a minimum. Install scripts and GUI installers are not even on the radar.
    • It is too technical for the general user because it is not only a huge learning curve in and of itself, but requires a new infrastructure. It took me weeks to learn enough about ZFS alone to feel comfortable enough to utilize it.
    • Like a lot of amazing technology, technological superiority does not automatically translate into marketability. Other factors are at play (look at desktop Linux vs Windows, reiserfs vs NTFS)

  7. #17
    Join Date
    Mar 2011
    Location
    19th Hole
    Beans
    Hidden!
    Distro
    Ubuntu 18.04 Bionic Beaver

    Re: Success with desktop LXD containers! Woot!

    Quote Originally Posted by TheFu View Post
    …LVM has snap shots. So does qcow2 VM storage.
    Yes they do. And I use both. LVM is great, but has some limitations. I stayed away from ZFS for so long in part because LVM gave me most of what I wanted. The recent purchase of a 4 disk RPi-based micro server—a process that some prior advice of yours started btw—had me looking at some sort of equivalent to RAID-Z implementation, and that's one of the areas in which LVM is lacking. Or perhaps I should say: if an LVM solution exists, I couldn't find it.

    I find qcow2 to be limited by the more general limitations of VMs. Most of my equipment is ancient by today's standards, but still perfectly usable to Mrs Duckhook and me. VMs are at that inflection point in resource intensity that they bog down such equipment, whereas LXD works just fine.
    The best thing about LXD is the compartmentalization, but with the GUI use, there are a bunch of holes between the container and the hostOS.
    This is a legitimate worry. I know that hooking into X opens up a lot of holes. But I figure that a bad payload would have to be specially crafted to take such advantage, and the sites that I visit and files I download are highly unlikely to be compromised in this way. Maybe I'm just being naïve.
    Intel has been working on a native VM solution where the host and VMs can share the same GPU (intel only) for a few years. About every 6 months I check it out and see a 2 minute demo on youtube. The demos seem to crash just after they cut the video. It works with about 5th-gen Core i5 CPUs (desktop and mobile) that have an iGPU. The problem is the packaging. There wasn't any last fall. Rebuilding the kernel was required. Around June, I'll look again. GVT - https://01.org/igvt-g is their official site. Looks like work as stalled in 2019.
    Interesting. Thx for the link.
    For GUI programs, firejail is my answer today.
    Curiosity question… How does firejail differ from apparmor? I really don't want to learn yet another jailing system. We're now already protected by default with apparmor and Selinux. Isn't there a point of diminishing returns? Where additional security comes at the cost of so much complexity and inconvenience that it is no longer pragmatic?
    Last edited by DuckHook; 1 Week Ago at 05:01 PM.

  8. #18
    Join Date
    Mar 2010
    Location
    Squidbilly-Land
    Beans
    19,297
    Distro
    Ubuntu Mate 16.04 Xenial Xerus

    Re: Success with desktop LXD containers! Woot!

    Apparmor doesn't have nearly the number of profiles that firejail ships with by default. Plus, creating additional firejail profiles isn't hard. It is basically self-explanatory when looking at a few existing profiles. Cannot say that about apparmor.

    firejail has locally controlled profiles.
    I've not found much need to learn many complexities of firejail. I use 2 modes.
    * HOME directory access allowed
    * ZERO directory access allowed

    Code:
    firejail firefox
    firejail --private firefox
    To learn the difference, try
    Code:
    firejail bash
    firejail --private bash
    Start up each in a different terminal. Look around. See what's there, what's available, and what isn't. Try using sudo or sudoedit.
    Those 5 minutes will explain more than I could in 20 min of typing here.

    When I say "HOME directory access", I really mean access to very specific places in the HOME directory. In /etc/firejail/ are the profiles. They are pretty easy to understand. Much easier than apparmor. Much.

    Firejail's inconvenience is extremely blatant. It never leaves me wondering "why" - I know when I can't see any files in a directory in Firefox, but a bash shell shows it (not firejailed), then it is 100% firejail doing the limitations. Firejail isn't all or nothing. We can have 50 different profiles for each program we use. Generally, I have just a few. "no networking", "no access outside HOME", "no access anywhere." Sorta like how we mount /tmp/ with noexec as an option to prevent common hacks ... until something like AppImage fails to work because of it.

    But you definitely have some excellent points.

  9. #19
    Join Date
    Mar 2011
    Location
    19th Hole
    Beans
    Hidden!
    Distro
    Ubuntu 18.04 Bionic Beaver

    Re: Success with desktop LXD containers! Woot!

    Thx for all of the above. I might give firejail a try, though I've invested so much time into apparmor that I know I'll keep using it. Apparmor is absurdly arcane, but making the effort to understand it does provide one fringe benefit: often, apps misbehave because of apparmor restrictions (some snap apps for example). Knowing how to tune apparmor gives one a fighting chance at fixing such things.

  10. #20
    Join Date
    Mar 2011
    Location
    19th Hole
    Beans
    Hidden!
    Distro
    Ubuntu 18.04 Bionic Beaver

    Re: Success with desktop LXD containers! Woot!

    I've now added a section: Running a Full, Separate Distro to the tutorial.

    Running another distro within a container (instead of a VM) has been a long-unfulfilled dream when I started fooling around with containers a few years ago. I'm happy and a bit surprised that it can now be done so easily.

Page 2 of 3 FirstFirst 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •