On 2016-06-14 09:22, Simon Walter wrote:

> I think that maybe you read my email too fast. So I will try to be
verbose.

Hi Simon,

If I misread then I apologize.

> I install Devuan on my hardware from an iso CD-ROM image file copied to
> a USB memory device.
>
> Next I install LXC.
>
> Next I modify the debian template lxc-debian - remove systemd stuff,
> rename a bunch a of things and change the mirror.
>
> When I use that modified template to lxc-create a container, I don't
> need to download any keys.
>
> I am guessing because devuan-keyring is already installed from the iso
> CD-ROM image on the initial installation on my hardware.
>
> Does that sound like the reason? Am I missing something?

Thanks for explaining. Now I understand the context of your reference to
an ISO.

Yes that makes complete sense. The ISO media install will have the
necessary keyring.

In such a case lxc-devuan will find and use the existing keyring file:
/usr/share/keyrings/devuan-keyring.gpg

That's the first place lxc-devuan checks for it.

I'm now curious how your use of lxc-debian (Debian template) pertains to
what were doing with lxc-devuan (Devuan template) ? Is it because
lxc-debian doesn't require downloading the Debian keyring?

This is because the Debian keyring is also included as part of the
Devuan install. Devuan needs the Debian keyring to verify the
unmodified Debian packages.

From Devuan Jessie install:
# ls -l /usr/share/keyrings
total 58K
-rw-r--r-- 1 root root 27K Nov 30 2014 debian-archive-keyring.gpg
-rw-r--r-- 1 root root 11K Nov 30 2014 debian-archive-removed-keys.gpg
-rw-r--r-- 1 root root 15K May 4 2015 devuan-keyring.gpg

Hmm, this now has me thinking lxc-devuan should *also* download the
debian keyring !
And that leads straight back to my previous suggestion to use nested LXC
for testing from non-Devuan OS's.

> It downloads a keyring from a server. Is it in anyway possible to hijack
> those connections and download a different keyring to validate different
> packages from a different server? It would be a great big coordinated
> attack, but is it impossible?

Difficult yes. But no, it's not impossible.

A reasonable response is: lxc-devuan uses https protocol when
downloading the keyring to help ensure a safe download.

> The template defaults to downloading and also to passing --no-check-gpg.

Yeah, this is more of a policy decision. Which is why I made it an
option that can easily be turned off.

> I would suggest making the default to check for the devuan key and fail
> with an error message saying that the key was not found and telling the
> user that there is an argument they can specify to have it downloaded.
> That is IMHO the rule of least surprise.

An entirely reasonable position.

I'll make note of your '+1' vote to *disable* --no-check-gpg as the default.

Let's give others the chance to chime in.

> Forgive my criticisms and questioning. In a world where we have people
> planting questionable code into open source in order to create back
> doors, we should be able to answer to this kind of criticism - if only
> to aid ourselves (think rubber duck programming).

Peer-review is part of the process, and I'm very glad to have your
"valuable" input and constructive criticisms!

In fact, you may have already helped identify the need to also download
the "Debian" keyring.

> Now on to the latest test I made:
>
> The locale is set early enough to not have those warnings spew all over
> the screen. Excellent.
>
> More importantly, the errors about the config files are gone. I had a
> look at the differences, and it all seems reasonable.
>
> Also I notice gcc-4.8-base is being removed towards the end. I am sure
> there is a good reason for this and I am interested to know.

I got that from the "Minimal Install Guide":
https://git.devuan.org/dev1fanboy/Upgrade-Install-Devuan/wikis/Minimal-install-guide

See section entitled "Removing unwanted packages".

> About the random MAC address feature, I see a comment:
> ## If there is exactly one veth network entry,
> ## make sure it has an associated hwaddr.

The idea there is if there's one, and only one veth entry, then it's
clear which one to change. Whereas if there's more than one veth entry
it's ambiguous which to change and therefore best to leave as is.

> How does veth get into the config file at this point? Should the user
> create the config file before creating the container?

The stock default.conf from Jessie:
# cat /etc/lxc/default.conf.orig
lxc.network.type = empty
#

So the default for everyone regardless of the template used is "no" network.

The default.conf I use (and test with) is quite basic:
# cat /etc/lxc/default.conf
lxc.cgroup.memory.limit_in_bytes = 512M
lxc.cgroup.memory.memsw.limit_in_bytes = 1G

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.ipv4 = 0.0.0.0
#

From the README found here https://git.devuan.org/gregolsen/lxc-devuan
Example 7 does show the end result, but doesn't show the default.conf file.

My intent was not to teach how to use LXC. That's why the reference in
the README "LXC Documentation" section.

In hindsight I must admit, it will be better to show the default.conf
file, as was used to arrive at the result in Example 7. I have another
tweak planned for the README, so I can add that to the list.

> It seems like
> there are so many options on how one could create the network. However,
> if arguments were given for a few things:
> lxc.network.type
> lxc.network.link
> lxc.network.ipv4
> lxc.network.ipv6
> gateway
> network
>
> Then a simple network could be set up by the template - both the LXC
> config and the network inside the container. Otherwise it doesn't seem
> to work "out of the box." More complex configurations would require
> editing the config file.

Yep. A simple network could be set up "out of the box".

However I must first ask, what happened to your "rule of least surprise" ?

IMHO it's unfair to state it doesn't seem to work when the default use
case is, *no* network.

Being the default is *no* network, I think we have the responsibility to
also consider, the existing user base has good reason to expect no
communications can occur unless they explicitly change their default.conf.

> There are a few more things I wanted to discuss.
>
> - "Less bare bones than from debootstrap, however dependencies are kept
> minimal."

Package inclusion and exclusion is indeed open to discussion/debate.

> - OpenDNS name resolvers are set.

I thought about setting the IP's in variables with template options for
override purposes.

> - The random password is removed. (I would suggest that if a password
> argument is not given, a random one is set.)

New containers have root password = root, the same as lxc-debian provides.
I simply kept with that expectation, and that people should change the
root password.

Beyond that I haven't given much time/consideration.

What do all the other templates do with this?
Do we want to depart from the expectations admins may already have from
working with other templates?

> These seem like they are useful. My criticism is not directly at any one
> of these ideas.

I don't take any of what you said as criticism. I think tossing around
ideas for improvement is a good thing.

I also see things as falling into a category:
1. Base functionality (priority, need it now)
2. Enhancements (nice to have)

I think the immediate focus should be to get the base functionality
correct, submit upstream, and make a package available.

Work on enhancements can start anytime, including now if you're so
inclined. A typical way to handle enhancements is for each developer to
work in their own feature branch, for possible later inclusion in master
branch.

> I am thinking of the naive user who doesn't expect to
> find things set up this way.
>
> Maybe we need a bare template and then one with all the nice options. Or
> maybe we need this template to install the bare minimum if no arguments
> are given, and then when certain arguments are passed, we get OpenDNS,
> the password we want, and the nice set of packages, etc. If the
> arguments are available, then at least the user has an vague idea,
> without reading the template, of what is possible and what the container
> will be set up like.

It's not necessary to have a separate template. Template specific
options are already supported.

Here's the section where the template options parsed:

while true
do
     case "$1" in
         -h|--help)            usage $(basename $0) && exit 1;;
            --)                shift 1; break ;;

         -a|--arch)            arch=$2; shift 2;;
         -c|--clean)           clean=1; shift 1;;
            --main-only)       mainonly=1; shift 1;;
            --mirror)          MIRROR=$2; shift 2;;
         -n|--name)            name=$2; shift 2;;
            --packages)        packages=$2; shift 2;;
         -p|--path)            path=$2; shift 2;;
         -r|--release)         release=$2; shift 2;;
            --rootfs)          rootfs=$2; shift 2;;
            --security-mirror) SECURITY_MIRROR=$2; shift 2;;
         *)                    break ;;
     esac
done

I considered providing options for specifying two upstream DNS IP's as
an enhancement.

Likewise goes for providing some kind of role support. xen-tools already
does this. This falls squarely into the enhancement category.

I'm glad to know we're of like mind on doing these kinds of enhancements.

> Because packages are removed after the root password is displayed, it
> gets pushed up the screen. It would be nice to have that as the last
> thing that is displayed.
>
> If you want me to hack on any of this let me know.

You're more than welcome to do so.

Best Regards,

Greg