On 06/15/2016 10:26 AM, Greg Olsen wrote:
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.
No need to!
...
>
> 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".
I will have a read.
...
> 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 coin drops. I see. That is what is going on.
...
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.
Nice. Thank you for explaining. I must admit, I didn't know that even
file existed.
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" ?
Yes, I stand by my suggestion that the default is minimal and everything
else takes parameters. How does that contradict the rule of least
surprise? If they are not specified, then no action is taken. By the way
it's not *my* rule - just something I was taught similar to convention
over configuration.
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.
Yes, please pardon my ignorance. Everything makes more sense in light of
that file.
> 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?
Hmmm... I am not sure which version you are using. I see this in lxc-debian:
password="$(dd if=/dev/urandom bs=6 count=1 2> /dev/null | base64)"
echo "root:$password" | chroot $rootfs chpasswd
echo "Root password is '$password', please change !"
I know some of the other templates to use 'root' as the password. I have
seen this criticized:
https://fedoraproject.org/wiki/LXC_Template_Security_Improvements
> 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.
OK. Good. I don't want to piss anyone off, and my social skills are not
that smooth. So I worry.
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.
I think what you have so far is most of the way there.
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 not familiar with gitlab. Does one join a project? Or should I
create a new project? Or should I just hack locally and send a pull
request? I am also wondering if some place on gitlab is better to
discuss when I have a question for this project. Or right here on DNG? I
don't want to start on adding things like some of those template
parameters and then you've already done it. You seem pretty fast paced.
I hope I can keep up!
Cheers,
Simon
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
