Hi Greg,
I've read had a look and a test. Please see my ramblings below. I am in
no hurry. So please take your time. ;)
On 06/14/2016 10:02 AM, Greg Olsen wrote:
On 2016-06-14 00:39, Simon Walter wrote:
> Well, maybe I didn't say it correctly. Is there already a devuan-keyring
> package on the iso-image?
It's a debootstrap install. There's no iso-image involved.
I think that maybe you read my email too fast. So I will try to be verbose.
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?
> My personal opinion is that keys should not be automatically downloaded
> and installed. But I am a bit paranoid.
I understand your reservations. However it does **not** trust the
keyring on the user system.
Does that mean that it does not trust the keyring on the host? Is there
a good reason for that? I thought the template checks for
/usr/share/keyrings/devuan-keyring.gpg on the host.
It simply downloads it, issues a message it
was downloaded, and then passes the keyring file to the debootstrap
command for it to use validating packages. So it's completely safe.
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?
The template defaults to downloading and also to passing --no-check-gpg.
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.
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).
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.
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.
How does veth get into the config file at this point? Should the user
create the config file before creating the container? 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.
There are a few more things I wanted to discuss.
- "Less bare bones than from debootstrap, however dependencies are kept
minimal."
- OpenDNS name resolvers are set.
- The random password is removed. (I would suggest that if a password
argument is not given, a random one is set.)
These seem like they are useful. My criticism is not directly at any one
of these ideas. 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.
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.
Kind regards,
Simon
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
