Re: [DNG] LXC template for Devuan

[Greg Olsen]

On 06/20/2016 09:47 PM, Simon Walter wrote:

Hi Greg,

I've added a branch called add-netconf, which you have probably seen.

I thought to just add one feature per branch so that review is easier. 
Let me know how you prefer to collaborate.


That's perfect.  Branch as often as you see fit, that's what they're for.




I was not sure about what style/standards we are using. However, the 
hashbang tells me bash. I looked at the other templates, and most use 
bash.


Yes it's Bash, so I use Bash'isms including the ugly [[ expr ]]
syntax.  It's more efficient to use builtins over external utilities,
including [ (test) which is also an external program.

Regarding style, I'm comfortable reading shell programs regardless
of individual coding preferences.  It's usually best to match the
existing style, however I didn't entirely do this with lxc-devuan
because it's a new shell program, and I prefer builtins for
efficiency.  Therefore the new code is clearly Bash.

I don't have the time now for a coding style discussion, but here's
just a couple things:

Variables:
Upper-case names which (can) derive value from an environment var.
Declare function variables local.
Initialize variables.

Tabs:  there are some strong opinions on this, but here goes:
I don't use tabs unless absolutely necessary, and in shell scripts
it's not necessary.
   Caveat: here docs for config files with syntax that requires tabs.

Tabs display differently in different environments.
If tabs are used, placing *only* at beginning of a line will at least
keep indentation consistent.
But as I said, I don't use tabs in shell scripts.

Indentation:
Yes, please do it. Whitespace is good.

Obviously I'm not a stickler with Bash scripts.
Just keep code as simple and readable as possible.
And if something is not at all obvious, then throw in a comment.




I wasn't sure if having all the settings in one argument or separate 
was better. The logic behind having them all in one argument is that 
all those are needed and cannot be derived from one another. So IP, 
netmask, and gateway are all in one comma separated argument. Maybe 
the parameter name should be "interface" or "ifconfig".


Sorry about the length here but I don't see how to further simplify.

To try and put things delicately, I think we need to consider an
approach that accomplishes the same thing (external to container) and
covers more use cases.

For instance, cloning customized containers is a very common
practice. However an internally configured IP will *prevent* cloning
the container to use as a drop in for another. At least *not* if the
intent is to use them at the same time.

I've also setup Vagrant boxes, and trust me, an internally configured
IP will severely limit its potential uses as a Vagrant box. I.e. the
box added via: `vagrant box add user/box` and specified in Vagrantfile
as `config.vm.box = user/box`).  You could have a whole bunch of
Vagrantfile's all referring to the same user/box and a hard-coded IP
will prevent using more than one at a time.

IMO, configuring the network interface *internally* within the
container will definitely limit the usefulness of the container.

I'm not trying to shoot down the idea here. I just want to point the
way towards, IMHO, a more effective way to implement a version
of the idea.

We really need to target the LXC config, and not the internal
interfaces file.

Using the lxc.network.* options we can accomplish the same thing.
It's just harder to get right because of the `/etc/lxc/default.conf`
network options that may, or may not be present.

You can still have a "combined arg" if you want, but I think it's
important to first get the individual options working correctly.

I suggest using the same names, or similar to, lxc.network
options. That will help prevent users from getting confused
about what's being affected.

Ex.
  --net-type [veth]
  --net-flags [up|down]
  --net-link [linkname]
  --net-hwaddr [MAC]
  --net-ipv4 [x.y.z.t/cidr]
  --net-ipv4-gw [x.y.z.t | auto]
  --net-mtu [maxmtu]
  --net-ipv6 [x::y]
  --net-ipv6-gw [x::y | auto]

Of course, I'm *not* suggesting that if one option is coded then *all*
must be coded.

For reference here's a container.conf link:
http://man7.org/linux/man-pages/man5/lxc.container.conf.5.html

Things start to get complex when considering the possible combinations
of what may or may not already be specified in `/etc/lxc/default.conf`.

Use divide and conquer to keep things as simple as possible:
1. Restrict use to when only 0 or 1 layer-2 interface is present in
`/etc/lxc/default.conf`
2. I've already isolated all network options from the rest of the
config: Use Bash associative array to enumerate options from
`${path}/config-network`. The keys can be the option names.
3. CLI --net-* options (stored separately) then override, or add
to options stored in the enumerated default options array.
4. Perform edits to ensure keys like --net-type and --net-flags exist,
and add them as 

Re: [DNG] LXC template for Devuan

[Simon Walter]

On 06/20/2016 07:28 AM, Greg Olsen wrote:

Hi Simon,

No rush. Unless I find some glaring bug, after a bit more testing I
intend to refocus on pushing upstream and what's needed to make
"lxc-devuan" packages for Jessie/Ascii/Ceres. It'll be the first .deb
package I've made completely from scratch (suggestions are welcome,
please).

Disable --no-check-gpg as the fallback?  No votes against this:
+1 Simon Walter
+1 Greg Olsen

So when convenient, I may go ahead and disable that.



Hi Greg,

I've added a branch called add-netconf, which you have probably seen.

I thought to just add one feature per branch so that review is easier. 
Let me know how you prefer to collaborate.


I was not sure about what style/standards we are using. However, the 
hashbang tells me bash. I looked at the other templates, and most use bash.


I wasn't sure if having all the settings in one argument or separate was 
better. The logic behind having them all in one argument is that all 
those are needed and cannot be derived from one another. So IP, netmask, 
and gateway are all in one comma separated argument. Maybe the parameter 
name should be "interface" or "ifconfig".


For my next edit, I would like to add the password parameter and if not 
specified would set a random one.


Then I was thinking of adding a parameter for MAC address, in case it 
should be explicitly set or not set or set to a random address.


I would appreciate your comments on that and of course on the netconf 
parameter and it's functionality.


One question, is --main-only the default? What is the default for the 
Devuan install? I am not sure, but I think the default is only main. If 
so, maybe we should reverse that argument to be something like 
--extra-repos. Or even --add-repos=main,non-free. That way the use can 
specify exactly the additional repositories on the command line.


I think that would be very useful for orchestration tools such as 
vagrant or cdist for example.


Cheers,

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Greg Olsen]

On 2016-06-19 01:26, Simon Walter wrote:
> On 06/18/2016 10:31 AM, Greg Olsen wrote:
> ...
> >
> > In the meantime, I added Simon Walter as a Developer for lxc-devuan.
> >
> > Simon,
> >
> > As a developer you can push directly to the main development branch. I
> > added a "draft" Contribution guide, and I'll be following the same
> > process myself as outlined.
> >
>
> Hi Greg,
>
> Thanks for that. I will dig in soon. I am pretty busy at the day job. So
> much so that I'm in the office on the weekend.
>
> Simon
>

Hi Simon,

No rush. Unless I find some glaring bug, after a bit more testing I 
intend to refocus on pushing upstream and what's needed to make 
"lxc-devuan" packages for Jessie/Ascii/Ceres. It'll be the first .deb 
package I've made completely from scratch (suggestions are welcome, please).


Disable --no-check-gpg as the fallback?  No votes against this:
+1 Simon Walter
+1 Greg Olsen

So when convenient, I may go ahead and disable that.

Get the downtime and rest you need.  It'll be there when you're ready.

Kind regards

Greg

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Simon Walter]

On 06/18/2016 10:31 AM, Greg Olsen wrote:
...


In the meantime, I added Simon Walter as a Developer for lxc-devuan.

Simon,

As a developer you can push directly to the main development branch. I
added a "draft" Contribution guide, and I'll be following the same
process myself as outlined.



Hi Greg,

Thanks for that. I will dig in soon. I am pretty busy at the day job. So 
much so that I'm in the office on the weekend.


Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Greg Olsen]

Hi Folks,

I fixed a subtle bug in the lxc-devuan template which causes some 
packages to be reinstalled.


In the original download function, the 'packages' variable (used by: 
debootstrap --include=$packages ...) leaks to the post_process function 
causing packages to be reinstalled.


It's my fault. My normal habit is to declare all function variables 
local, however I when I cloned download_debian() function I neglected to 
change that. For shame!


The problem doesn't cause any failure, or any problems with the newly 
built containers.  By reinstalling the packages list, it just 
unnecessarily duplicates part of what debootstrap already did for you, 
making you wait longer and watch a bunch more messages.


With the commit (below) the install goes *much* smoother. It was such a 
simple fix, it went in with the commit to "Generate random root 
password". (I know, it should have been a separate commit, but it's too 
late now.)


Commit:
https://git.devuan.org/gregolsen/lxc-devuan/commit/a0aa14bb31ca1675547b239d0806920ccf098c46

Anyone who uses the lxc-devuan template is encouraged to update to the 
latest lxc-devuan.


Cheers

Greg
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Greg Olsen]

On 2016-06-13 08:23, Jaromil wrote:
>
> hi,
>
> On Mon, 13 Jun 2016, Simon Walter wrote:
>
> > I've made an account on git.devuan.org (user: smwltr) How do you 
want to do

> > this? Shall I fork your repo and apply a patch and then send you a pull
> > request?
>
> we can create a group (named lxc?) and make you admins for it, or
> simply a single project as there may be no need for more packages.
>
> i'm cc: hellekin to stimulate a quicker response on what should be the
> naming scheme, since so far it has been curated with great attention
> to be meaningful. to me it makes sense to have something like
> 'virtualization-' as a prefix for repositories like lxc, but I'm also
> not sure what else would fall in there.
>
> ciao

In the meantime, I added Simon Walter as a Developer for lxc-devuan.

Simon,

As a developer you can push directly to the main development branch. I 
added a "draft" Contribution guide, and I'll be following the same 
process myself as outlined.


Cheers

Greg
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Greg Olsen]

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 

Re: [DNG] LXC template for Devuan

[Simon Walter]

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
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Greg Olsen]

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 

Re: [DNG] LXC template for Devuan

[Simon Walter]

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

Re: [DNG] LXC template for Devuan

[Greg Olsen]

Hi Folks,

The lxc-devuan README is now updated to contain the LXC testing coverage 
to this point:



 Test Machine Specs / LXC Version Coverage

LXC versions tested:

 * LXC 1.1.5 on my Workstation/Laptop
 o Devuan Ceres
 o Devuan Jessie
 o Devuan Jessie (32-bit)
 * Nested LXC 1.0.6 within Devuan Jessie container
 o Devuan Ascii
 o Devuan Ceres
 o Devuan Jessie
 * Nested LXC 2.0.1 within Devuan Ceres container
 o Devuan Ascii
 o Devuan Ceres
 o Devuan Jessie

Best Regards,

Greg




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Greg Olsen]

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.

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


Greg

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Greg Olsen]

On 2016-06-13 13:42, Rainer Weikusat wrote:
> The message means that using a certain locale has been requested by
> setting the LANGUAGE and LANG environment variables to its name but that
> it can't really be used because the compiled locale definitions for the
> requested locale aren't available. The two obvious ways to deal with
> that would be
>
>
>
> The source files used for these reside in /usr/share/i18n and the file
> containg the compiled equivalents is /usr/lib/locale/locale-archive. An
> LXC-container could use a read-only bind mount to get access to the
> locale-archive file of the host.

Rainer,

Thank very much for the info.

In this case is was a timing issue of when lxc-devuan configures the 
locale. It needed to be configured before the /usr/sbin/update-rc.d 
commands.  It was happening after that.


I've since fixed by moving into a separate function and calling earlier:

configure_locale ()
{
if [ -z "$LANG" ]; then
cat >> $rootfs/etc/locale.gen << EOF
en_US.UTF-8 UTF-8
EOF
chroot $rootfs locale-gen
chroot $rootfs update-locale LANG=en_US.UTF-8
else
encoding=$(echo $LANG | cut -d. -f2)
chroot $rootfs sed -e "s/^# \(${LANG} ${encoding}\)/\1/" \
-i /etc/locale.gen 2> /dev/null
if ! grep -q ^${LANG}\ ${encoding} /etc/locale.gen ; then
   cat >> $rootfs/etc/locale.gen << EOF
$LANG $encoding
EOF
fi
chroot $rootfs locale-gen
chroot $rootfs update-locale LANG=$LANG
fi
}


Greg




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Simon Walter]

On 06/14/2016 09:26 AM, Greg Olsen wrote:

On 2016-06-13 01:28, Simon Walter wrote:
[snip]
 > > This might be a bit surprising but I actually wrote lxc-devuan with
 > > *non-Devuan* OS's in mind. To not discourage people from running
Devuan,
 > > it automatically downloads and uses the Devuan keyring. Without that
 > > capability it won't get past square one on a non-Devuan OS, and the
user
 > > is likely to mumble some not so nice things about Devuan. Something to
 > > be avoided if at all possible.
 >
 > It seems to be fine with the 'auto' sub domain maybe because the keys
 > are registered for that domain name. Are you saying that those keys are
 > pre-installed on the image? If that's the case, I think we should make
 > two versions, that are based on the same source - an include or
 > something. One to be used on Devuan, one to be used by other distros
 > that want to run Devuan containers.

The issue isn't the domain and there's no pre-installed image.  It's a
chicken and egg problem to bootstrap the keyring to validate the signed
packages.


Well, maybe I didn't say it correctly. Is there already a devuan-keyring 
package on the iso-image? If so, that would explain why it works fine 
when the "host" is a Devuan installation.


My personal opinion is that keys should not be automatically downloaded 
and installed. But I am a bit paranoid.




Assume install on a foreign OS.  The foreign OS probably won't have a
Devuan keyring. When running debootstrap, among the packages it will
download is the keyring package. When it goes to validate the download
(which includes the keyring package), it doesn't have a key to validate,
so it fails with "Release signed by unknown key".


Yes. So, perhaps we have one script maintained for the Devuan OS and 
another for non-Devaun OSes, and they have most things in common.




[snip]
 > I've made an account on git.devuan.org (user: smwltr) How do you want to
 > do this? Shall I fork your repo and apply a patch and then send you a
 > pull request? After a look maybe the solution will present itself. I
 > guess the .conf files too.

Hi Simon,

For now we can work it that way.

I just pushed an update that adds support for LXC <= 1.0.8.

The README is updated to use ./config-1.0.8 for LXC <= 1.0.8
The existing ./config directory is for LXC >= 1.1.0

It'll be great if you'll test again.

So if you've already forked, please fetch and rebase.


Nice. Sure thing. I will be testing it out soon.

Kind regards,

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Greg Olsen]

On 2016-06-13 08:23, Jaromil wrote:

> we can create a group (named lxc?) and make you admins for it, or
> simply a single project as there may be no need for more packages.
>
> i'm cc: hellekin to stimulate a quicker response on what should be the
> naming scheme, since so far it has been curated with great attention
> to be meaningful. to me it makes sense to have something like
> 'virtualization-' as a prefix for repositories like lxc, but I'm also
> not sure what else would fall in there.

A generic name seems better. But I'm OK with whatever you think is 
appropriate.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Greg Olsen]

On 2016-06-13 01:28, Simon Walter wrote:
   [snip]
> > This might be a bit surprising but I actually wrote lxc-devuan with
> > *non-Devuan* OS's in mind. To not discourage people from running 
Devuan,

> > it automatically downloads and uses the Devuan keyring. Without that
> > capability it won't get past square one on a non-Devuan OS, and the 
user

> > is likely to mumble some not so nice things about Devuan. Something to
> > be avoided if at all possible.
>
> It seems to be fine with the 'auto' sub domain maybe because the keys
> are registered for that domain name. Are you saying that those keys are
> pre-installed on the image? If that's the case, I think we should make
> two versions, that are based on the same source - an include or
> something. One to be used on Devuan, one to be used by other distros
> that want to run Devuan containers.

The issue isn't the domain and there's no pre-installed image.  It's a 
chicken and egg problem to bootstrap the keyring to validate the signed 
packages.


Assume install on a foreign OS.  The foreign OS probably won't have a 
Devuan keyring. When running debootstrap, among the packages it will 
download is the keyring package. When it goes to validate the download 
(which includes the keyring package), it doesn't have a key to validate, 
so it fails with "Release signed by unknown key".


   [snip]
> I've made an account on git.devuan.org (user: smwltr) How do you want to
> do this? Shall I fork your repo and apply a patch and then send you a
> pull request? After a look maybe the solution will present itself. I
> guess the .conf files too.

Hi Simon,

For now we can work it that way.

I just pushed an update that adds support for LXC <= 1.0.8.

The README is updated to use ./config-1.0.8 for LXC <= 1.0.8
The existing ./config directory is for LXC >= 1.1.0

It'll be great if you'll test again.

So if you've already forked, please fetch and rebase.

Thanks

Greg

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Rainer Weikusat]

KatolaZ  writes:
> On Fri, Jun 10, 2016 at 09:39:49AM -0400, Greg Olsen wrote:
>> On 2016-06-10 08:59, Simon Walter wrote:
>>[snip]
>> > > I will give the templates a go now.
>> 
>> >I had some issues:
>> >perl: warning: Setting locale failed.
>> >perl: warning: Please check that your locale settings:
>> >LANGUAGE = "en_US:en",
>> >LC_ALL = (unset),
>> >LANG = "en_US.UTF-8"
>> >are supported and installed on your system.
>> >perl: warning: Falling back to the standard locale ("C").
>> >
>> >Over ten times repeated, but more importantly:
>> 
>> Simon, thanks for testing.
>> 
>> I think the locale just isn't setup yet at that early point.
>> Perhaps a Perl expert can opine?
>> 
>
> I have had those messages on a server for the best part of the last 9
> years, just to checl whether those stupid warning actually meant to be
> serious. It's just perl which complains because you have not set the
> locale properly.

The message means that using a certain locale has been requested by
setting the LANGUAGE and LANG environment variables to its name but that
it can't really be used because the compiled locale definitions for the
requested locale aren't available. The two obvious ways to deal with
that would be

- change the requested locale to one that's actually supported
  (/etc/locale.gen contains the so-far created one) or to C to
  use the POSIX locale

- generate the locales

The source files used for these reside in /usr/share/i18n and the file
containg the compiled equivalents is /usr/lib/locale/locale-archive. An
LXC-container could use a read-only bind mount to get access to the
locale-archive file of the host.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Jaromil]

hi,

On Mon, 13 Jun 2016, Simon Walter wrote:

> I've made an account on git.devuan.org (user: smwltr) How do you want to do
> this? Shall I fork your repo and apply a patch and then send you a pull
> request?

we can create a group (named lxc?) and make you admins for it, or
simply a single project as there may be no need for more packages.

i'm cc: hellekin to stimulate a quicker response on what should be the
naming scheme, since so far it has been curated with great attention
to be meaningful. to me it makes sense to have something like
'virtualization-' as a prefix for repositories like lxc, but I'm also
not sure what else would fall in there.

ciao

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Simon Walter]

On 06/10/2016 10:39 PM, Greg Olsen wrote:

On 2016-06-10 08:59, Simon Walter wrote:
[snip]
 > > I will give the templates a go now.


I had some issues:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Over ten times repeated, but more importantly:


Simon, thanks for testing.

I think the locale just isn't setup yet at that early point.
Perhaps a Perl expert can opine?


Maybe we can diff that?

> ...

This might be a bit surprising but I actually wrote lxc-devuan with
*non-Devuan* OS's in mind. To not discourage people from running Devuan,
it automatically downloads and uses the Devuan keyring. Without that
capability it won't get past square one on a non-Devuan OS, and the user
is likely to mumble some not so nice things about Devuan. Something to
be avoided if at all possible.


It seems to be fine with the 'auto' sub domain maybe because the keys 
are registered for that domain name. Are you saying that those keys are 
pre-installed on the image? If that's the case, I think we should make 
two versions, that are based on the same source - an include or 
something. One to be used on Devuan, one to be used by other distros 
that want to run Devuan containers.



I also added a feature or two that other OS templates don't have, such
as the ability to pre-assign the MAC address. I have absolutely no idea
if that's of interest to anyone but me. But if it is, that's yet one
more reason for people to choose Devuan over something else.


Yes, I really like that. It is very useful.



Of course, the paths won't end up correct on all distros until a version
of it makes it upstream, and then back down again, and that could take
quite some time. Therefore a script can/should be written to help
install it.


wget or maybe curl? What's on a base install?



In the meantime, anyone with a mind to "clone" and use the template as
is (without a proper package or script to install it) will have to
adjust paths as needed to match their system.

On the other hand there's nothing written anywhere that says we have to
use the lxc-devuan that I wrote. Not that I want to give up on it, but
If yours is already working correctly on Devuan Beta, we can always put
it in a different branch and use that.  We'll just have to see how
things plays out.


I've made an account on git.devuan.org (user: smwltr) How do you want to 
do this? Shall I fork your repo and apply a patch and then send you a 
pull request? After a look maybe the solution will present itself. I 
guess the .conf files too.


Let see how it goes.

Cheers,

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Greg Olsen]

Greetings,

Just a quick update.

The problem we had with lxc-devuan is indeed a version incompatibility 
between the later LXC version 1.1.5 and the Devuan version 1.0.6.  But 
hey, at least we're ready for the later version!


I haven't updated on GitLab yet, but the good news is I already have a 
fix ready for the incompatibility problem, and have successfully tested 
it with Devuan's lxc package. Please see test info at bottom.


*All* other issues identified up to this point have also been fixed, 
including those pesky Perl warnings (Thanks KatolaZ for your response on 
that!)


To support earlier releases the easiest thing is to supply a different 
config directory.  The updated template works fine for both the old and 
new releases, so that won't require special treatment.


I intend to do a bit more testing tomorrow PM before pushing the updates 
to GitLab. I'll let everyone know once it's available.



Simon, Once the updates are in GitLab, and since you expressed an 
interest, can I email you directly about testing?


I successfully nested LXC within LXC so that technique can be used to 
test lxc-devuan inside some other OS distros.


Once the wrinkles have been ironed out, we can write a simple install 
script to figure out the install path, and detect which config to copy.


Thanks,

Greg


Test info:

# cat /etc/os-release
PRETTY_NAME="Devuan GNU/Linux 1 (jessie)"
NAME="Devuan GNU/Linux"
VERSION_ID="1"
VERSION="1 (jessie)"
ID=devuan
HOME_URL="http://www.devuan.org/;
SUPPORT_URL="http://www.devuan.org/support/;
BUG_REPORT_URL="https://bugs.devuan.org/;

# apt-cache show lxc
Package: lxc
Version: 1:1.0.6-6+deb8u2

# lxc-attach -n test
root@test:/etc# ps aux
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root 1  0.0  0.0  15484  1712 ?Ss   04:51   0:00 init [3]
root   408  0.0  0.0  25396  8476 ?Ss   04:52   0:00 
dhclient -v -pf /run/dhclient.eth0.pid -lf 
/var/lib/dhcp/dhclient.eth0.leases eth0
root   494  0.0  0.0  55184  2432 ?Ss   04:52   0:00 
/usr/sbin/sshd
root   505  0.0  0.0  12664  1700 lxc/console Ss+ 04:52   0:00 
/sbin/getty 38400 console
root   506  0.0  0.0  12664  1760 lxc/tty1 Ss+  04:52   0:00 
/sbin/getty 38400 tty1 linux
root   507  0.0  0.0  12664  1856 lxc/tty2 Ss+  04:52   0:00 
/sbin/getty 38400 tty2 linux
root   508  0.0  0.0  12664  1728 lxc/tty3 Ss+  04:52   0:00 
/sbin/getty 38400 tty3 linux
root   509  0.0  0.0  12664  1872 lxc/tty4 Ss+  04:52   0:00 
/sbin/getty 38400 tty4 linux

root   548  0.0  0.0  21856  3424 ?S05:37   0:00 /bin/bash
root   549  0.0  0.0  19100  2448 ?R+   05:38   0:00 ps aux

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[KatolaZ]

On Fri, Jun 10, 2016 at 09:39:49AM -0400, Greg Olsen wrote:
> On 2016-06-10 08:59, Simon Walter wrote:
>[snip]
> > > I will give the templates a go now.
> 
> >I had some issues:
> >perl: warning: Setting locale failed.
> >perl: warning: Please check that your locale settings:
> >LANGUAGE = "en_US:en",
> >LC_ALL = (unset),
> >LANG = "en_US.UTF-8"
> >are supported and installed on your system.
> >perl: warning: Falling back to the standard locale ("C").
> >
> >Over ten times repeated, but more importantly:
> 
> Simon, thanks for testing.
> 
> I think the locale just isn't setup yet at that early point.
> Perhaps a Perl expert can opine?
> 

I have had those messages on a server for the best part of the last 9
years, just to checl whether those stupid warning actually meant to be
serious. It's just perl which complains because you have not set the
locale properly. IMHO, you can ignore it altogether, without any
serious consequence. The user of the container will fix it *if* and
*when* he needs to fiddle with locales.

Naturally, if you want the whole thing to "look slick", you can just
set the locale to "en_US" and shut the damn perl up...

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Greg Olsen]

On 2016-06-10 08:59, Simon Walter wrote:
   [snip]
> > I will give the templates a go now.


I had some issues:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Over ten times repeated, but more importantly:


Simon, thanks for testing.

I think the locale just isn't setup yet at that early point.
Perhaps a Perl expert can opine?


> lxc_container: Failed to parse config: lxc.include =
> /usr/share/lxc/config/common.conf
>
> lxc_container: Failed to parse config: lxc.include =
> /usr/share/lxc/config/devuan.common.conf

I tested with LXC 1.1.5 installed from upstream source so some include 
paths might be screwed up because they're different on my system.  Or 
possibly it's a version compatibility issue.  At this early stage, and 
without a proper package, I expect it to take some tweaking to get it 
working.


I'll look into making the paths conform based on the latest lxc package 
from Devuan :

lxc_1%3a1.0.6-6+deb8u2_amd64.deb

Arguably maybe I should have already done that.  Then again I wrote it 
for LXC 1.1.5 and I honestly don't know how far back it's compatible.  
If it's a version compatibility problem, we can always create another 
branch to support the earlier Devuan version, but only if we have to.


Here's a look at my /usr/share/lxc/config/ directory:
-rw-r--r-- 1 root staff 1.3K Mar 15 00:10 archlinux.common.conf
-rw-r--r-- 1 root staff  114 Mar 15 00:10 archlinux.userns.conf
-rw-r--r-- 1 root staff  988 Mar 15 00:10 centos.common.conf
-rw-r--r-- 1 root staff  114 Mar 15 00:10 centos.userns.conf
-rw-r--r-- 1 root staff 1.7K Mar 15 00:10 common.conf
drwxr-sr-x 2 root staff 4.0K Mar 15 00:10 common.conf.d
-rw-r--r-- 1 root staff  199 Mar 15 00:10 common.seccomp
-rw-r--r-- 1 root staff 1.2K Mar 15 00:10 debian.common.conf
-rw-r--r-- 1 root staff  114 Mar 15 00:10 debian.userns.conf
-rw-r--r-- 1 root staff 1.1K May 22 01:48 devuan.common.conf
-rw-r--r-- 1 root staff   93 May 22 01:49 devuan.userns.conf
-rw-r--r-- 1 root staff 1.1K Mar 15 00:10 fedora.common.conf
-rw-r--r-- 1 root staff  114 Mar 15 00:10 fedora.userns.conf
-rw-r--r-- 1 root staff  886 Mar 15 00:10 gentoo.common.conf
-rw-r--r-- 1 root staff 2.5K Mar 15 00:10 gentoo.moresecure.conf
-rw-r--r-- 1 root staff  114 Mar 15 00:10 gentoo.userns.conf
-rw-r--r-- 1 root staff  309 Mar 15 00:10 nesting.conf
-rw-r--r-- 1 root staff 1.1K Mar 15 00:10 opensuse.common.conf
-rw-r--r-- 1 root staff  114 Mar 15 00:10 opensuse.userns.conf
-rw-r--r-- 1 root staff 1.4K Mar 15 00:10 openwrt.common.conf
-rw-r--r-- 1 root staff  988 Mar 15 00:10 oracle.common.conf
-rw-r--r-- 1 root staff  114 Mar 15 00:10 oracle.userns.conf
-rw-r--r-- 1 root staff  246 Mar 15 00:10 plamo.common.conf
-rw-r--r-- 1 root staff  114 Mar 15 00:10 plamo.userns.conf
-rw-r--r-- 1 root staff  197 Mar 15 00:10 ubuntu-cloud.common.conf
-rw-r--r-- 1 root staff  124 Mar 15 00:10 ubuntu-cloud.lucid.conf
-rw-r--r-- 1 root staff  126 Mar 15 00:10 ubuntu-cloud.userns.conf
-rw-r--r-- 1 root staff 1.7K Mar 15 00:10 ubuntu.common.conf
-rw-r--r-- 1 root staff   58 Mar 15 00:10 ubuntu.lucid.conf
-rw-r--r-- 1 root staff  359 Mar 15 00:10 ubuntu.userns.conf
-rw-r--r-- 1 root staff  672 Mar 15 00:10 userns.conf


> By the way, I have Devuan alpha4 installed. So maybe that is the issue
> there. Though, with my modified config and templates, I didn't have
> those errors.

Yeah, it could be a version incompatibility.


It's very late for me, so here's some random thoughts before I sign out 
for the day:


This might be a bit surprising but I actually wrote lxc-devuan with 
*non-Devuan* OS's in mind. To not discourage people from running Devuan, 
it automatically downloads and uses the Devuan keyring. Without that 
capability it won't get past square one on a non-Devuan OS, and the user 
is likely to mumble some not so nice things about Devuan. Something to 
be avoided if at all possible.


I also added a feature or two that other OS templates don't have, such 
as the ability to pre-assign the MAC address. I have absolutely no idea 
if that's of interest to anyone but me. But if it is, that's yet one 
more reason for people to choose Devuan over something else.


Of course, the paths won't end up correct on all distros until a version 
of it makes it upstream, and then back down again, and that could take 
quite some time. Therefore a script can/should be written to help 
install it.


In the meantime, anyone with a mind to "clone" and use the template as 
is (without a proper package or script to install it) will have to 
adjust paths as needed to match their system.


On the other hand there's nothing written anywhere that says we have to 
use the lxc-devuan that I wrote. Not that I want to give up on it, but 
If yours is already working correctly on Devuan Beta, we 

Re: [DNG] LXC template for Devuan

[Greg Olsen]

On 2016-06-10 08:35, Simon Walter wrote:

   [snip]
> Greg, on the page there is:
> $ git clone git@???:gregolsen/lxc-devuan.git
>
> For read access maybe it would work better if it was:
> $ git clone http://git.devuan.org/gregolsen/lxc-devuan.git

Simon, thanks for pointing out I used the git URL.

Please clone via https:

|$ git clone https://git.devuan.org/gregolsen/lxc-devuan.git|

I should have put the https URL out there to begin with. When I get a 
chance I'll fix it.



> I will give the templates a go now.

Great, please let me know if you have issues or suggestions.


> Do you have plans to include that into an upstream release? Do you know
> if those are maintained by a Debian maintainer or by the LXC project
> itself? I am guess that those are distro specific. So would that mean
> that the Debian maintainer might not be interested in the Devuan
> templates? Of course Debian users may very well want a Devaun
> containers. If so, then it would be nice if there was an LXC package for
> Devuan so we don't need to clone a git repo to have those templates.

Yes, once I have the time to prepare a suitable branch, I'll submit a 
pull request for its inclusion upstream into Linux Containers project 
"lxc".  This may take some time as it must also conform to their project 
guidelines. Whatever those are, I'll have to figure it out.


Once accepted, it should eventually make it into the LXC package for 
each distro that has one, including Debian.


In the meantime, I hope people will try it out and provide feedback or 
submit an issue if they're so inclined. I'd hate to miss something 
stupid right out of the gate!


Greg

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Simon Walter]

On 06/10/2016 06:16 PM, Jaromil wrote:

On Fri, 10 Jun 2016, Simon Walter wrote:

I will give the templates a go now.


thanks!



I am going to try Greg's template on the BETA release.

My simple edit on the alpha4 worked fine, but Greg's templates didn't 
work as well. So I am trying with BETA.



Do you have plans to include that into an upstream release?


yes, especially if more than one person gets involved so we have some
degree of peer review. Also please note we are in the process of
setting up a builder server on the premises of our HQ in Amsterdam and
all its setup is based on LXC. Hellekin is currently going through its
configuration and I can hear little sounds of satisfaction and success
across the day coming from his desk. But I'm not aware if Hk is using
Greg's template.


So you are bootstraped? Using Devuan to build Devuan?




If so, then it would be nice if there was an LXC package for Devuan
so we don't need to clone a git repo to have those templates.


sure, if such a team forms and a .deb package is ready, made through a
somehow collective process involving more than one developer, it will
be certainly included in our repositories.



OK, wonderful. I am doing lots of tests for my work too. So I will 
definitely be sending feedback around.


Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Jaromil]

On Fri, 10 Jun 2016, Simon Walter wrote:
> I will give the templates a go now.

thanks!

> Do you have plans to include that into an upstream release?

yes, especially if more than one person gets involved so we have some
degree of peer review. Also please note we are in the process of
setting up a builder server on the premises of our HQ in Amsterdam and
all its setup is based on LXC. Hellekin is currently going through its
configuration and I can hear little sounds of satisfaction and success
across the day coming from his desk. But I'm not aware if Hk is using
Greg's template.

> If so, then it would be nice if there was an LXC package for Devuan
> so we don't need to clone a git repo to have those templates.

sure, if such a team forms and a .deb package is ready, made through a
somehow collective process involving more than one developer, it will
be certainly included in our repositories.

ciao
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Simon Walter]

On 06/10/2016 05:35 PM, Simon Walter wrote:

On 06/10/2016 05:11 PM, KatolaZ wrote:

On Fri, Jun 10, 2016 at 12:41:36PM +0900, Simon Walter wrote:

Hi all,

I am wondering if it is a good idea to submit a modified version of the
debian template to the upstream LXC project.

I am not sure who wrote those scripts. It seems like that is part of LXC
source. So I am guessing it has nothing to do with the Debian LXC
package
maintainer.


Hi Simon,

I think you might want to liaise with Greg Olsen on Devuan support for
LXC. You probably know that there is already some material on the
gitlab:

   https://git.devuan.org/gregolsen/lxc-devuan



Nice. Thank you for pointing that out. I see Greg has already done most
of this.

Greg, on the page there is:
$ git clone g...@git.devuan.org:gregolsen/lxc-devuan.git

For read access maybe it would work better if it was:
$ git clone http://git.devuan.org/gregolsen/lxc-devuan.git

I couldn't clone it using the git protocol (if that is what is called).

I will give the templates a go now.


I had some issues:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Over ten times repeated, but more importantly:
lxc_container: Failed to parse config: lxc.include = 
/usr/share/lxc/config/common.conf


lxc_container: Failed to parse config: lxc.include = 
/usr/share/lxc/config/devuan.common.conf


By the way, I have Devuan alpha4 installed. So maybe that is the issue 
there. Though, with my modified config and templates, I didn't have 
those errors.


Let me know if there is anything I can do to help test etc.

Many thanks,

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Simon Walter]

On 06/10/2016 05:11 PM, KatolaZ wrote:

On Fri, Jun 10, 2016 at 12:41:36PM +0900, Simon Walter wrote:

Hi all,

I am wondering if it is a good idea to submit a modified version of the
debian template to the upstream LXC project.

I am not sure who wrote those scripts. It seems like that is part of LXC
source. So I am guessing it has nothing to do with the Debian LXC package
maintainer.


Hi Simon,

I think you might want to liaise with Greg Olsen on Devuan support for
LXC. You probably know that there is already some material on the
gitlab:

   https://git.devuan.org/gregolsen/lxc-devuan



Nice. Thank you for pointing that out. I see Greg has already done most 
of this.


Greg, on the page there is:
$ git clone g...@git.devuan.org:gregolsen/lxc-devuan.git

For read access maybe it would work better if it was:
$ git clone http://git.devuan.org/gregolsen/lxc-devuan.git

I couldn't clone it using the git protocol (if that is what is called).

I will give the templates a go now.

Do you have plans to include that into an upstream release? Do you know 
if those are maintained by a Debian maintainer or by the LXC project 
itself? I am guess that those are distro specific. So would that mean 
that the Debian maintainer might not be interested in the Devuan 
templates? Of course Debian users may very well want a Devaun 
containers. If so, then it would be nice if there was an LXC package for 
Devuan so we don't need to clone a git repo to have those templates.


Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] LXC template for Devuan

[Simon Walter]

(A little update)

What I did was:
cp /usr/share/lxc/templates/lxc-debian /usr/share/lxc/templates/lxc-devuan
cp /usr/share/lxc/config/debian.common.conf 
/usr/share/lxc/config/devuan.common.conf
cp /usr/share/lxc/config/debian.userns.conf 
/usr/share/lxc/config/devuan.userns.conf


I don't know if the last one is used. It doesn't seem to be referenced 
in the template.


Then I:
- removed the function configure_debian_systemd.
- changed the MIRROR to https://auto.mirror.devuan.org/merged/
- removed debian from all the function names
- changed debian to devuan in all the messages

Then I created a container the new template.

There were some warnings.

insserv: warning: current start runlevel(s) (empty) of script 
`checkroot.sh' overrides LSB defaults (S).
insserv: warning: current stop runlevel(s) (S) of script `checkroot.sh' 
overrides LSB defaults (empty).
insserv: warning: current start runlevel(s) (empty) of script 
`checkroot.sh' overrides LSB defaults (S).

update-rc.d: error: umountfs Default-Start contains no runlevels, aborting.
insserv: warning: current start runlevel(s) (empty) of script 
`hwclock.sh' overrides LSB defaults (S).
insserv: warning: current stop runlevel(s) (0 6 S) of script 
`hwclock.sh' overrides LSB defaults (0 6).

update-rc.d: error: cannot find a LSB script for hwclockfirst.sh

These are the same warning encountered with the Debian template. So if 
anything we should fix that for Devuan, but it doesn't seem to be a problem.


I then modified the containters config and network settings and it 
started and seems to work fine.


Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] LXC template for Devuan

[Simon Walter]

Hi all,

I am wondering if it is a good idea to submit a modified version of the 
debian template to the upstream LXC project.


I am not sure who wrote those scripts. It seems like that is part of LXC 
source. So I am guessing it has nothing to do with the Debian LXC 
package maintainer.


Also, I wouldn't want to submit something for Devaun to LXC without at 
least one other LXC + Devaun user taking a look at it and kicking the tires.


Or maybe someone has already modified the debian template for Devuan.

Checking (/usr/share/lxc/templates/lxc-debian), it looks like sysvinit 
is in use:

# configure the inittab
cat < $rootfs/etc/inittab
id:3:initdefault:
si::sysinit:/etc/init.d/rcS
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin
1:2345:respawn:/sbin/getty 38400 console
c1:12345:respawn:/sbin/getty 38400 tty1 linux
c2:12345:respawn:/sbin/getty 38400 tty2 linux
c3:12345:respawn:/sbin/getty 38400 tty3 linux
c4:12345:respawn:/sbin/getty 38400 tty4 linux
p6::ctrlaltdel:/sbin/init 6
p0::powerfail:/sbin/init 0
EOF

Hence there is a bug about LXC containers not working with systemd yet.

So maybe this is a good base and just the MIRROR needs changing.

Kind regards,

Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng