On 2016-06-15 02:30, Simon Walter wrote:
> On 06/15/2016 10:26 AM, Greg Olsen wrote:
> > So the default for everyone regardless of the template used is "no"
> > network.
>
> The coin drops. I see. That is what is going on.

    [snip]

>
> > 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.

Yes, I'm familiar with the (POLA) principle of least astonishment/surprise.
For a minute there, I was left with a different impression.
I see now you did write "/if arguments were given"/. And I do concur.

To further the idea:

In addition to arguments (specified as template options), we can source
an optional file '/etc/default/lxc-devuan' to support local defaults for
template options. Any parameter set prior to sourcing the file can be
overridden by it, with CLI template options later taking precedence.

> 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

The lxc-debian version I have from LXC 1.1.5 has this:

     echo "root:root" | chroot $rootfs chpasswd
     echo "Root password is 'root', please change !"

Therefore I didn't remove it. It just wasn't upstream in v1.1.5.

However I do see the random pw in Devuan Jessie LXC 1.0.6. It
(lxc-debian) must have updated in the Jessie lxc package. That's a good
catch on your part!

I noticed the lxc-debian template is getting more attention lately,
finally. Probably more than they've given to xen-tools for years (for
debian images/roles specifically).

My first impression when using the lxc-debian template (from v.1.1.5)
was similar to your reaction to all the perl warnings, and the like. At
the time I chose to overlook the messages because they were
insignificant to the initial goal of simply getting it working correctly.

Interestingly, I also had a similar impression when using
"xen-create-image --dist=squeeze ...". from what now seems very long
ago. To my recollection, the lxc-debian (1.1.5) template seems to have
some of the exact same issues 'xen-create-image --dist=squeeze' had way
back when. Who knows, maybe now they're starting to polish out some of
the rough edges?

Back to the topic at hand:
Regarding the password, I take no issue with changing to the random method.

>
> >
> > > 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.

Neither are mine. So I'd like to take this opportunity to apologize in
advance for my behavior!

>
> >
> > 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.

I just added LXC version coverage to the README, and testing lxc-devuan
from a non-Devuan LXC host is curiously missing. (Although it's probably
better to track test coverage on a project wiki page.)

The point is, we still need more testing under non-Devuan OS's. Can you
help with that?

>
> >
> > 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!

Don't feel bad. I'm learning GitLab too.

Here's some of what I've been able to glean from the GitLab documentation:

The simple feature branch/master branch workflow seems appropriate for a
small project like lxc-devuan. A developer/feature branch is created
that you have authority to push to, and use merge requests. Periodically
a release is tagged.

Issues can also be used for various purposes. Per your concerns, a way
to avoid duplication of effort is to create an Issue for each problem
and enhancement. The *minute* details regarding an Issue can then be
discussed directly within that Issue on GitLab. (I'm not implying to
avoid discussion on Dng, just a potential way to reduce some of the noise.)

An issue can also be assigned for a person to work on (which I believe
auto-creates a Todo for the assignee). Merge requests with commits that
reference Issues, (I think) will cause GitLab to auto-close the
associated Todo's.

For more info here's a link to the GitLab workflow doc:
http://docs.gitlab.com/ee/workflow/gitlab_flow.html

Are there any GitLab experts who wish to opine on any of that?

I left out mention of creating a Group to which developers are added.
However we need see how Jaromil, hellekin, et.al. want things set up.

Best Regards

Greg