[lxc-users] would there be value in starting an LXD community online collection of how-to related information

[Sean McNamara]

On Wed, Jan 18, 2017 at 12:15 PM, Guido Jäkel <G.Jaekel at dnb.de> wrote:
>> Here is my opinion on it:
>>
>> 1) We do need documentation, especially tutorials. Lots and lots of
>> tutorials and how-tos . LXD and Docker compete in different niches, but
>> LXD can easily do what Docker does (and sometimes better in certain
>> situations) and part of the reason that Docker is used so much is
>> because of the volume of articles/tutorials for setting it up in
>> production scenarios.
>>
>> 2) I agree with the poster who mentioned that the archive is not
>> searchable (but should be IMO). Is there some way to make it a
>> searchable archive? I understand that there are software-tools that
>> allow the conversion of mail-archives into a forum-like appearance, so
>> that might help
>
> Dear all,
>
> I ask about such some years before. But in my opinion, a typical forum is not much better than list mail -- I would suggest to present all the community information as a Wiki space or something in that way!
>
> Because to my (mostly bad) experiences, in a forum the information is spread around in different threads. And you have to read through pages of statements to extract the "core" and/or "head" of information. In a typical Wiki, you'll get the most up-to-date information on the main page, you may use an history to extract changes and there might be a comment feature enabled for discussions. And a typical wiki engine would allow to search in a full-text-index, of corse.
>
> I think, one important topic for HowTo's is around networking. This is because LXC/LXD (and others) become more and more easy to use. This is a great success, but in the other hand it attract more and more users with a lower level of basic skills.


Yes! Part of it is that LXD's network configuration steps are a bit
different from some of its predecessors in the container/virt space,
like OpenVZ and VMware, so people trying to "migrate" to LXD instead
get a migraine trying to learn new networking concepts so they can
wrap their head around the network configuration for LXD.

I currently run LXD in production with about 8 containers on a
non-mission-critical server (if it crashes, it's not the end of the
world), and things are going very well -- it's stable, secure enough
for my needs, great guest/host isolation, guests can do all the things
I expect them to be able to do, etc. -- but the one area that still
eludes me to this day is how exactly macvlan works.

To me, macvlan is just a magic black box. I followed a tutorial by
rote on one of stgraber's blogs and got it working perfectly, but if
it ever breaks, I won't be able to dig very deep in my troubleshooting
efforts due to the perceived opacity of the technology and the weird
way it works compared to traditional networking (physical interfaces
and bridges are about as far as I go, normally; but I don't even know
where macvlan sits in the OSI model!). I think we need some (better)
pictures/diagrams, analogies, concrete examples, etc. for some of the
more common networking topologies involving LXD, even if the "details"
of those networking setups are not a feature of LXD itself (if we are
borrowing features from the Linux kernel and expecting our users to
use them to accomplish tasks, it would be helpful to explain how those
features work in a user-friendly way.)

And I'd like to see "LXD hardening" guides for doing system-level
configuration unrelated to LXD to increase the security of LXD. For
example, if you are exposing a public /27 IP subnet to a bunch of LXD
containers through macvlan, out of the box there is nothing preventing
one of those containers' root users from acquiring and using any IP
address within that /27. This is a very bad thing for hosting
companies with multi-tenant boxes, so we just have to hope that nobody
is going to try and start a hosting company based on LXD and then
launch their service without locking that down. Ideally, the host-side
configuration would specify which exact IP(s) each container can use,
and the container's root user can do nothing to circumvent those
restrictions.

In the end, what I envision LXD as capable of becoming, is something
equivalent from a user's perspective to VMware, where all the
sysadmin's assumptions about isolation and security in VMware (except
sharing the same kernel) also hold in LXD, except that since you're
not doing virtualization, your performance overhead is extremely low.
And in practice, the "sharing the same kernel" bit *shouldn't* be a
security problem, because if the Linux kernel security team does their
job, the vulnerabilities will get found and closed in short order so
your customers can't break out of the container. Then you just have to
enable rebootless kernel updates on the host and you're good to go.

But LXD out of the box is a long way from that. It can probably be
made to work that way if you know enough about which isolation
weaknesses exist and how to close them using system tools, but I
personally don't know how to do that. So unless there are plans to
make the LXD code automatically fix those weaknesses (e.g., as
mentioned, restricting the IPs that each container can use), we need
documentation and maybe helper scripts to take care of it so people
can start using LXD in production.

It *would* be great to see some of those commercial hosting providers
who are still on the OpenVZ stable 2.6.32 kernel, upgrading to the
much faster and more featureful modern 4.x kernel with LXD instead of
OpenVZ. But not as long as container root users can trample on another
user's IP address with a single `ifconfig` command :)

TL;DR: +1 for "production use case" LXD docs, please.

Sean

>
> To promote LXC, a section with success stories would be great, too.
>
>
> Grüße
>
> Guido
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users