Re: [DNG] LXC template for Devuan
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 needed
Re: [DNG] LXC template for Devuan
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
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
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
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
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
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 autho
Re: [DNG] LXC template for Devuan
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
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 sh
Re: [DNG] LXC template for Devuan
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
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
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
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
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
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
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
Hi Folks, I just pushed an update to lxc-devuan. This adds support for LXC versions <= 1.0.8. LXC version 1.1.0 came with the updated config that caused the previous problem. Greg ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] LXC template for Devuan
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
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
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
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
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
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
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
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
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
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
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
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 and it would be useful to join efforts. 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
(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
Re: [DNG] LXC template
Answering self, using the gentoo template as base: -- MIRROR=${MIRROR:-http://http.debian.net/debian} ++ MIRROR=${MIRROR:-http://auto.mirror.devuan.org/merged/} -- configure_debian_systemd $path $rootfs ++ #configure_debian_systemd $path $rootfs lxc-create -n lxcdev -f /path/to/your/lxc.conf -t /usr/share/lxc/templates/lxc-devuan lxc-start -n lxcdev myuser@lxcdev:~$ ps -ef|head -2 UIDPID PPID C STIME TTY TIME CMD root 1 0 0 14:12 ?00:00:00 /sbin/init Uses about 378M, 135 packages installed. However, i see these in top: root20 1 0 14:12 ?00:00:00 /lib/systemd/systemd-udevd root 128 1 0 14:21 ?00:00:00 /lib/systemd/systemd-journald So it's a work in progress. Cheers, Nuno ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng