from:"Michael H. Warfield"

On Tue, 2014-09-30 at 18:00 -0400, Michael H. Warfield wrote:
 On Tue, 2014-09-30 at 15:56 -0400, Stéphane Graber wrote:
  Hey everyone,
 
  So just wanted to let you know that current git master is the alpha-2
  candidate.
 
  If you have some time today/tonight, please grab git master and test it
  to find any major issue which we shouldn't release alpha-2 with.
 
 We have two open buzilla reports, one at Debian and one at Fedora that
 are flagged as security issues due to fixed, predicatable, user ids and
 passwords in the containers created from the live templates.  Can we get
 these issues addressed?  In a distro, that would be a hard stop critical
 dependency.  I would throw a blocker on that alone just to get two
 security reports off our desks.
 
  If there's no report of such issue by tomorrow morning, I'll tag alpha-2
  and then we'll resume landing changes into git master.
 
  Thanks everyone who's contributed to LXC 1.1 so far and sorry for not
  releasing an alpha earlier, I'd been postponing most of it due for the
  systemd changes and those took longer to figure out than expected.

 Surprise, surprise...  Has the lxc.kmsg thing and systemd-journald going
 rogue been sorted?  Dwight has had it covered in Oracle and I'm trying
 to cover it in a pending patch for Fedora and CentOS.  Is there anything
 I've missed or Dwight has missed in the rpm camps (Oracle, Fedora,
 CentOS, SUSE)?

Oh, duh...  You are referring to the init script and rpm fixes that I
put together as the systemd changes.  I wasn't thinking clearly about
that last night since it was.  Disregard that last remark, yeah.

My last set of changes for the templates is also systemd related er the
systemd-journald problem.

 Regards,
 Mike

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.

Responding to my own hasty post from last night...

On Tue, 2014-09-30 at 17:13 -0400, Michael H. Warfield wrote:
 Sorry, I was completely out of touch from the net for several days and
 then I totally missed this when I got back...  I should have responded
 to this days ago...  Sigh...
 
 On Fri, 2014-09-19 at 17:15 -0400, Stéphane Graber wrote:
  On Sun, Sep 14, 2014 at 08:57:58PM -0400, Michael H. Warfield wrote:
   Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
   
   This patch integrates several fixes for several template issues
   and open bugzilla bugs at the Fedora project.
   
   The lxc-centos template now supports CentOS 7 and correct configuration
   of systemd in CentOS.
   
   The CentOS and Fedora template have been fixed for a rootfs bug that
   was a skew between the parsed parameter (rootfs) and the working variable
   (rootfs_path) by normalizing to rootfs, congruent with several other
   templates.  This should fix the backing store problem.
   
   The user password generation logic has been refactored out of the
   Fedora and CentOS templates into a new template/functions file.  This
   is the beginning of a security fix that has been reported as a bug in
   Fedora and Debian.  The functions support random password generation
   and/or disabled password on accounts.  Templates need to convert over
   and avoid static passwords like root:root or ubuntu:ubuntu in order
   to avoid this security issue.  Function supports multiple user setup.
   
   The template/functions file includes a function for static MAC address
   generation (not yet used) and may contain other common functions we
   standardize on.
 
  Can we stop including MAc address generation everywhere now that we have
  the MAC address templating stuff done in C? :)

 Does no harm and I'm still running into the perpetual recreate new Mac
 addresses on my Ubuntu containers (which screws up IPv6 royally).
 Probably because I have an old default and older containers but I don't
 particularly mind double fixing something like this...  The function is
 there in a common location but it's not currently called by anything and
 I've left the current generating logic in the templates themselves
 alone, so there was no change there at all.  Pull that little function
 if you like but it won't make any difference to any live code, since
 it's not currently called.

   Added fedora user to lxc-fedora template.
   
   Added centos user to lxc-centos template.
   
   Dropping setfcap has been moved to a comment for Fedora, CentOS,
   and SUSE due to it's interference with yum update in containers
   (yum fails to update several packages including httpd).
   
   Added sudo to the package list for CentOS and Fedora.
   
   Set the apparmor profile for CentOS, Fedora, and SUSE containers to
   unconfined, until someone comes up with something better, in order
   to have containers run out of the box on apparmor hosts.  Commented
   code in the individual templates has been moved to explicit settings
   in the common config files.
 
  From a security point of view, I much prefer things to fail badly than
  be able to wreak havoc on my system, so I'd prefer we don't do that.
 
 This came up months ago and there was all sorts of discussions over on
 the -user list of profiles and options and I even pinged you and Serge
 in private E-Mail asking if a consensus was agreed on.  All I got were
 crickets and, in the mean time, we still have failing containers.  We
 got nowhere then.  Where are we now?  It's been months.  In the absence
 of any more constructive solutions or feedback, I went with this.  I
 don't use apparmour so I can't test or resolve the problem and I have no
 better solution.  Failing badly is an understatement and we have had
 complaints and we have no better solution to the complaints.
 
  Instead, let's land the rest of your systemd fixes and then I can spend
  a few minutes figure out exactly what's failing when running on current
  Ubuntu and come up with a proper profile for it which still prevents
  most of the usual issues (proc, sys, ...).

Ah, ok, you're going to look into is, I see.  That's good.

 
 Ok, but we need something in the next cuts of both 1.1 and 1.0.  The
 gods-be-damned systemd-journald is causing bugzilla bug reports (one
 report was complaining of CPU heating problems from that nonsense) and
 the password problem is the subject of bugzilla security reports in both
 Fedora and Debian that I can't even begin to address till we move
 forward on this (CentOS and Fedora are fine...  I'll fix the others if I
 have to just to clear the security flags).  I've cleared a few bugzilla
 reports over at the Fedora but I would really like to clear these things
 that are flagged as security issues.
 
   Addressed systemd-journald runaway CPU issue by setting lxc.kmsg = 0
   in affected template (including Mandriva) and establishing a run time
   default to autoswitch lxc.kmsg depending on the state

Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.

On Wed, 2014-10-01 at 17:25 +0200, Thomas Moschny wrote:
 2014-10-01 14:15 GMT+02:00 Michael H. Warfield m...@wittsend.com:
  This bug is now closed, after I explained to the originator what the
  problem was, but it points out the problem we're seeing from having kmsg
  being a symlink to console and having journald run crazy in the
  container...
 
  https://bugzilla.redhat.com/show_bug.cgi?id=1141456

 Just ftr, this bug is not closed, and it should not be, because the
 patches have not yet landed in an LXC release (unless I am missing
 something) and thus are also not present in the Fedora/EPEL RPMs.

Ah crap.  You're right.  It was the other one, about lxc-stop and a
debian container, that the original poster closed after I pointed him at
the fix.  This one is still open, you're absolutely correct.  Thank you!

 - Thomas

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.

On Wed, 2014-10-01 at 11:34 -0400, Stéphane Graber wrote:

[snip]

  Would this be better if this paralleled autodev an we only disabled kmsg
  by default if and when systemd was detected as the init system?  The
  situation is very analogous to the autodev situation.  If a user were to
  switch from say upstart to systemd and autodev is not specified in the
  config, we default that to enabled when we detect systemd as the init
  system at run time.  We could also default kmsg to 0 in the case of
  systemd being the run time init system manager to prevent journald from
  going into it's console message loop and burning CPU.  Would that work
  better for you?  Since you can switch init systems from within the
  container and may not have access to the container config file that's in
  the host, something should be done to cover the run time case, like we
  do with autodev.  That's what I was attempting to do...

 I'm not very much fond of having to do per-init system config changes
 but yeah, that sounds like a reasonable way to go.

 If we start getting more and more of those cases we may want to make
 things slightly more configurable by just having LXC include some
 default configuration files based on that detection.

Oh?  Sort of like conditional includes?  If lxc.init = systemd include
systemd.conf sort of thing?  It would have to be runtime conditional but
that does make some sense at that.

  This bug is now closed, after I explained to the originator what the
  problem was, but it points out the problem we're seeing from having kmsg
  being a symlink to console and having journald run crazy in the
  container...
  
  https://bugzilla.redhat.com/show_bug.cgi?id=1141456
  
  -- 
  
   (1) Starting a basic LXC container, which is not configured to do 
   anything at all, *immediately* (and without delay) raises the temperature 
   *substantially* of one of the cores.
   
   (2) Starting a second LXC container (also not configured to do anything), 
   does the same as (1), but on a different core (i.e. the one that that LXC 
   uses).
  -- 
  

[Big snip - this time I remembered...]

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.

On Wed, 2014-10-01 at 12:06 -0400, Stéphane Graber wrote:
 On Wed, Oct 01, 2014 at 11:51:47AM -0400, Michael H. Warfield wrote:
  On Wed, 2014-10-01 at 11:34 -0400, Stéphane Graber wrote:
  
  [snip]
  
Would this be better if this paralleled autodev an we only disabled kmsg
by default if and when systemd was detected as the init system?  The
situation is very analogous to the autodev situation.  If a user were to
switch from say upstart to systemd and autodev is not specified in the
config, we default that to enabled when we detect systemd as the init
system at run time.  We could also default kmsg to 0 in the case of
systemd being the run time init system manager to prevent journald from
going into it's console message loop and burning CPU.  Would that work
better for you?  Since you can switch init systems from within the
container and may not have access to the container config file that's in
the host, something should be done to cover the run time case, like we
do with autodev.  That's what I was attempting to do...
  
   I'm not very much fond of having to do per-init system config changes
   but yeah, that sounds like a reasonable way to go.
  
   If we start getting more and more of those cases we may want to make
   things slightly more configurable by just having LXC include some
   default configuration files based on that detection.
  
  Oh?  Sort of like conditional includes?  If lxc.init = systemd include
  systemd.conf sort of thing?  It would have to be runtime conditional but
  that does make some sense at that.

 So I see a few ways of doing it:
  0) We keep all the logic hardcoded as it is today for autodev.

  1) We keep your detection code and simply call
 load_config(/usr/share/lxc/config/init-system.conf) before parsing
 anything else, so the container's own config will override anything
 that's in there.

  2) We make our parser support conditionals and export init_system as a
 variable so that we can have the default distro configs do things like:
 [init_system==systemd] lxc.include = 
 /usr/share/lxc/config/systemd.common.conf
 [privileged==false] lxc.include = /usr/share/lxc/config/unpriv.common.conf

 This would be more flexible and allow for the addition of extra
 variables later on. It'd also allow switching between privileged and
 unprivileged and between init systems without configuration changes.

  3) We do a slightly simpler version of the above by adding two things:
 - Simple variables, like ${init_system} and ${runtime_mode} and
   allow using them in the config with the parser replacing them with the
   right thing at parsing time.
 - Add a @ keyword which when placed at the beginning of the line
   will tell the parser to ignore any failure caused by the line in
   question.

 This then allows us to put things like:
 @lxc.include = /usr/share/lxc/config/ubuntu.${init_system}.conf
 @lxc.include = /usr/share/lxc/config/ubuntu.${runtime_mode}.conf

 And not have the parser fail if I somehow decide to run OpenRC as my
 container's init system without an existing ubuntu.openrc.conf.

Ok...  Option 0 is just about recoded so that the default kmsg is
dependent on systemd and not merely autodev.  I've turned
check_autodev into check_systemd and conditionalized both autodev
and kmsg based on that return value, dependent on any explicitly set
value.  For the short term, that appears to be the quickest and easiest.

Option 3 sounds like a good versatile long term option but we still need
some runtime autodetection of some of those values.  Where does that
${init_system} come from?  Since container owners can internally change
their run-time configuration to switch init system manager and then
reboot the container, something needs to be detected at runtime or the
container could end up being configured in ways that degrade the
performance or behavior of the host.  Even then, we still might have a
gap in the reboot process if the configuration is not reevaluated when
the container is rebooted (aot shut down and restarted).

Not sure if I care that much for option #1.  #2 would be my second
choice for a long term strategy with the proviso that we have some sort
of runtime detection.

Regards,
Mike

This bug is now closed, after I explained to the originator what the
problem was, but it points out the problem we're seeing from having kmsg
being a symlink to console and having journald run crazy in the
container...

https://bugzilla.redhat.com/show_bug.cgi?id=1141456

-- 

 (1) Starting a basic LXC container, which is not configured to do 
 anything at all, *immediately* (and without delay) raises the 
 temperature *substantially* of one of the cores.
 
 (2) Starting a second LXC container (also not configured to do 
 anything), does the same as (1), but on a different core (i.e. the 
 one

Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.

On Wed, 2014-10-01 at 14:18 -0400, Stéphane Graber wrote:
 On Wed, Oct 01, 2014 at 12:41:26PM -0400, Michael H. Warfield wrote:
  On Wed, 2014-10-01 at 12:06 -0400, Stéphane Graber wrote:
   On Wed, Oct 01, 2014 at 11:51:47AM -0400, Michael H. Warfield wrote:
On Wed, 2014-10-01 at 11:34 -0400, Stéphane Graber wrote:

[snip]

  Would this be better if this paralleled autodev an we only disabled 
  kmsg
  by default if and when systemd was detected as the init system?  The
  situation is very analogous to the autodev situation.  If a user 
  were to
  switch from say upstart to systemd and autodev is not specified in 
  the
  config, we default that to enabled when we detect systemd as the 
  init
  system at run time.  We could also default kmsg to 0 in the case of
  systemd being the run time init system manager to prevent journald 
  from
  going into it's console message loop and burning CPU.  Would that 
  work
  better for you?  Since you can switch init systems from within the
  container and may not have access to the container config file 
  that's in
  the host, something should be done to cover the run time case, like 
  we
  do with autodev.  That's what I was attempting to do...

 I'm not very much fond of having to do per-init system config changes
 but yeah, that sounds like a reasonable way to go.

 If we start getting more and more of those cases we may want to make
 things slightly more configurable by just having LXC include some
 default configuration files based on that detection.

Oh?  Sort of like conditional includes?  If lxc.init = systemd include
systemd.conf sort of thing?  It would have to be runtime conditional but
that does make some sense at that.
  
   So I see a few ways of doing it:
0) We keep all the logic hardcoded as it is today for autodev.
  
1) We keep your detection code and simply call
   load_config(/usr/share/lxc/config/init-system.conf) before parsing
   anything else, so the container's own config will override anything
   that's in there.
  
2) We make our parser support conditionals and export init_system as a
   variable so that we can have the default distro configs do things 
   like:
   [init_system==systemd] lxc.include = 
   /usr/share/lxc/config/systemd.common.conf
   [privileged==false] lxc.include = 
   /usr/share/lxc/config/unpriv.common.conf
  
   This would be more flexible and allow for the addition of extra
   variables later on. It'd also allow switching between privileged and
   unprivileged and between init systems without configuration changes.
  
3) We do a slightly simpler version of the above by adding two things:
   - Simple variables, like ${init_system} and ${runtime_mode} and
 allow using them in the config with the parser replacing them with 
   the
 right thing at parsing time.
   - Add a @ keyword which when placed at the beginning of the line
 will tell the parser to ignore any failure caused by the line in
 question.
  
   This then allows us to put things like:
   @lxc.include = /usr/share/lxc/config/ubuntu.${init_system}.conf
   @lxc.include = /usr/share/lxc/config/ubuntu.${runtime_mode}.conf
  
   And not have the parser fail if I somehow decide to run OpenRC as my
   container's init system without an existing ubuntu.openrc.conf.
  
  Ok...  Option 0 is just about recoded so that the default kmsg is
  dependent on systemd and not merely autodev.  I've turned
  check_autodev into check_systemd and conditionalized both autodev
  and kmsg based on that return value, dependent on any explicitly set
  value.  For the short term, that appears to be the quickest and easiest.
  
  Option 3 sounds like a good versatile long term option but we still need
  some runtime autodetection of some of those values.  Where does that
  ${init_system} come from?  Since container owners can internally change
  their run-time configuration to switch init system manager and then
  reboot the container, something needs to be detected at runtime or the
  container could end up being configured in ways that degrade the
  performance or behavior of the host.  Even then, we still might have a
  gap in the reboot process if the configuration is not reevaluated when
  the container is rebooted (aot shut down and restarted).
  
  Not sure if I care that much for option #1.  #2 would be my second
  choice for a long term strategy with the proviso that we have some sort
  of runtime detection.

 There would be a list of variables which LXC exposes to the config
 parser, so LXC would still do the init system detection as it does
 today, though possibly add detection for a few more init systems and
 then set init_system accordingly before passing it to the parser. Same
 goes for runtime_mode, LXC would set

Re: [lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.

2014-09-30 Thread Michael H. Warfield

Sorry, I was completely out of touch from the net for several days and
then I totally missed this when I got back...  I should have responded
to this days ago...  Sigh...

On Fri, 2014-09-19 at 17:15 -0400, Stéphane Graber wrote:
 On Sun, Sep 14, 2014 at 08:57:58PM -0400, Michael H. Warfield wrote:
  Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
  
  This patch integrates several fixes for several template issues
  and open bugzilla bugs at the Fedora project.
  
  The lxc-centos template now supports CentOS 7 and correct configuration
  of systemd in CentOS.
  
  The CentOS and Fedora template have been fixed for a rootfs bug that
  was a skew between the parsed parameter (rootfs) and the working variable
  (rootfs_path) by normalizing to rootfs, congruent with several other
  templates.  This should fix the backing store problem.
  
  The user password generation logic has been refactored out of the
  Fedora and CentOS templates into a new template/functions file.  This
  is the beginning of a security fix that has been reported as a bug in
  Fedora and Debian.  The functions support random password generation
  and/or disabled password on accounts.  Templates need to convert over
  and avoid static passwords like root:root or ubuntu:ubuntu in order
  to avoid this security issue.  Function supports multiple user setup.
  
  The template/functions file includes a function for static MAC address
  generation (not yet used) and may contain other common functions we
  standardize on.

 Can we stop including MAc address generation everywhere now that we have
 the MAC address templating stuff done in C? :)

Does no harm and I'm still running into the perpetual recreate new Mac
addresses on my Ubuntu containers (which screws up IPv6 royally).
Probably because I have an old default and older containers but I don't
particularly mind double fixing something like this...  The function is
there in a common location but it's not currently called by anything and
I've left the current generating logic in the templates themselves
alone, so there was no change there at all.  Pull that little function
if you like but it won't make any difference to any live code, since
it's not currently called.

  Added fedora user to lxc-fedora template.
  
  Added centos user to lxc-centos template.
  
  Dropping setfcap has been moved to a comment for Fedora, CentOS,
  and SUSE due to it's interference with yum update in containers
  (yum fails to update several packages including httpd).
  
  Added sudo to the package list for CentOS and Fedora.
  
  Set the apparmor profile for CentOS, Fedora, and SUSE containers to
  unconfined, until someone comes up with something better, in order
  to have containers run out of the box on apparmor hosts.  Commented
  code in the individual templates has been moved to explicit settings
  in the common config files.

 From a security point of view, I much prefer things to fail badly than
 be able to wreak havoc on my system, so I'd prefer we don't do that.

This came up months ago and there was all sorts of discussions over on
the -user list of profiles and options and I even pinged you and Serge
in private E-Mail asking if a consensus was agreed on.  All I got were
crickets and, in the mean time, we still have failing containers.  We
got nowhere then.  Where are we now?  It's been months.  In the absence
of any more constructive solutions or feedback, I went with this.  I
don't use apparmour so I can't test or resolve the problem and I have no
better solution.  Failing badly is an understatement and we have had
complaints and we have no better solution to the complaints.

 Instead, let's land the rest of your systemd fixes and then I can spend
 a few minutes figure out exactly what's failing when running on current
 Ubuntu and come up with a proper profile for it which still prevents
 most of the usual issues (proc, sys, ...).

Ok, but we need something in the next cuts of both 1.1 and 1.0.  The
gods-be-damned systemd-journald is causing bugzilla bug reports (one
report was complaining of CPU heating problems from that nonsense) and
the password problem is the subject of bugzilla security reports in both
Fedora and Debian that I can't even begin to address till we move
forward on this (CentOS and Fedora are fine...  I'll fix the others if I
have to just to clear the security flags).  I've cleared a few bugzilla
reports over at the Fedora but I would really like to clear these things
that are flagged as security issues.

  Addressed systemd-journald runaway CPU issue by setting lxc.kmsg = 0
  in affected template (including Mandriva) and establishing a run time
  default to autoswitch lxc.kmsg depending on the state of lxc.autodev
  (systemd case).  lxc.kmsg will be set to 0 in the case of lxc.autodev = 1
  and set to 1 in the case of lxc.autodev = 0, unless overridden in
  the config file.

 I think if our long term goal is to switch to autodev by default (and I
 believe

Re: [lxc-devel] About to tag alpha-2

2014-09-30 Thread Michael H. Warfield

On Tue, 2014-09-30 at 15:56 -0400, Stéphane Graber wrote:
 Hey everyone,

 So just wanted to let you know that current git master is the alpha-2
 candidate.

 If you have some time today/tonight, please grab git master and test it
 to find any major issue which we shouldn't release alpha-2 with.

We have two open buzilla reports, one at Debian and one at Fedora that
are flagged as security issues due to fixed, predicatable, user ids and
passwords in the containers created from the live templates.  Can we get
these issues addressed?  In a distro, that would be a hard stop critical
dependency.  I would throw a blocker on that alone just to get two
security reports off our desks.

 If there's no report of such issue by tomorrow morning, I'll tag alpha-2
 and then we'll resume landing changes into git master.

 Thanks everyone who's contributed to LXC 1.1 so far and sorry for not
 releasing an alpha earlier, I'd been postponing most of it due for the
 systemd changes and those took longer to figure out than expected.

Surprise, surprise...  Has the lxc.kmsg thing and systemd-journald going
rogue been sorted?  Dwight has had it covered in Oracle and I'm trying
to cover it in a pending patch for Fedora and CentOS.  Is there anything
I've missed or Dwight has missed in the rpm camps (Oracle, Fedora,
CentOS, SUSE)?

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] pivot_root: umount ., not /

2014-09-29 Thread Michael H. Warfield

On Mon, 2014-09-29 at 18:56 -0400, Stéphane Graber wrote:
 On Mon, Sep 29, 2014 at 10:51:35PM +, Serge Hallyn wrote:
  This fixes pivot_root on 3.11 and older kernels.
  
  Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com

 Got to love one char bugfixes :)

+1

 Acked-by: Stéphane Graber stgra...@ubuntu.com
 
  ---
   src/lxc/conf.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/src/lxc/conf.c b/src/lxc/conf.c
  index 31673d5..e8979c9 100644
  --- a/src/lxc/conf.c
  +++ b/src/lxc/conf.c
  @@ -1062,7 +1062,7 @@ static int setup_rootfs_pivot_root(const char 
  *rootfs, const char *pivotdir)
  SYSERROR(Error entering oldroot);
  goto fail;
  }
  -   if (umount2(/, MNT_DETACH)  0) {
  +   if (umount2(., MNT_DETACH)  0) {
  SYSERROR(Error detaching old root);
  goto fail;
  }
  -- 
  2.1.0
  
  ___
  lxc-devel mailing list
  lxc-devel@lists.linuxcontainers.org
  http://lists.linuxcontainers.org/listinfo/lxc-devel
 
 ___
 lxc-devel mailing list
 lxc-devel@lists.linuxcontainers.org
 http://lists.linuxcontainers.org/listinfo/lxc-devel

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [lxc-users] Compile fails under Fedora

2014-09-20 Thread Michael H. Warfield

On Sat, 2014-09-20 at 03:23 -0400, CDR wrote:
 I did a git pull and ´when I issued a make rpm, it failed
 
 error: Installed (but unpackaged) file(s) found:
/usr/lib/systemd/system/lxc-net.service
 RPM build errors:
 File listed twice:
 /usr/lib64/python3.3/site-packages/_lxc-0.1-py3.3.egg-info
 File listed twice: /usr/lib64/python3.3/site-packages/_lxc.cpython-33m.so
 File listed twice: /usr/lib64/python3.3/site-packages/lxc/__init__.py
 File listed twice: /usr/lib64/python3.3/site-packages/lxc/__pycache__
 File listed twice:
 /usr/lib64/python3.3/site-packages/lxc/__pycache__/__init__.cpython-33.pyc
 File listed twice:
 /usr/lib64/python3.3/site-packages/lxc/__pycache__/__init__.cpython-33.pyo
 File listed twice: /usr/libexec/lxc/lxc-autostart-helper
 File listed twice: /usr/libexec/lxc/lxc-devsetup
 File listed twice: /usr/libexec/lxc/lxc-user-nic
 Installed (but unpackaged) file(s) found:
/usr/lib/systemd/system/lxc-net.service
 make: *** [rpm] Error 1
 
 Any idea how can I compile the software?

You raised this issue on 08/09 for 1.1.0alpha1 under Fedora 20.  At that
time yours was the second report and I was already looking into it.  You
then raised the issue again on the -devel list on 09/05 for 1.1.0alpha1
under CentOS 7 - exact same issue.  At that time the patches had already
been submitted on 08/25 to Stéphane and were then under review.  I
responded to you to that effect on 09/09 along with the reason for the
original failure and a pointer to my patches that had been posted to the
list.

The patches are still being reviewed as he's been exceptionally busy
lately and the patches are fairly involved and involved some
disagreements in approach which were discussed in private E-Mail between
the involved parties.

The patches have not been committed to git master to date and he's
working on integrating the changes.  As a consequence, the answer I gave
to you on 09/09 on the -devel list remains the same and is equally
applicable to 1.1.0alpha1 and to git master...

i.e. ... You can either apply the patches I posted to the -devel list
several weeks ago or you can wait for Stéphane to commit the fully
integrated patches to git master.  At this time, applying my changes
will result in some patch warnings due to others submitting some warning
changes in parallel patches.

I would recommend monitoring the -devel list for further (cough)
developments (yes, pun intended).

Regards,
Mike

On Tue, 2014-09-09 at 12:06 -0400, Michael H. Warfield wrote:
 This was due to a refactoring of the upstart init network code nearly
 a
 month ago by someone, AFAIK, not currently on the list which created
 some files in an incorrect location and the creation of dependencies
 on
 it in the systemd code.  Patches for this fax paux have been submitted
 by me and Stéphane is currently evaluating my patch set to correct the
 problems that were created by the earlier submission by another that
 inadvertently broke all the rpm based systems.  This was reported
 several weeks ago and I submitted my fix, after some private
 discussion,
 on 08/25.
 
 Please review the following thread, starting on 08/25/2014, on this
 list
 for the patches and some discussion...


 Thanks,
 Philip
 ___
 lxc-users mailing list
 lxc-us...@lists.linuxcontainers.org
 http://lists.linuxcontainers.org/listinfo/lxc-users
 

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

[lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.

2014-09-15 Thread Michael H. Warfield

Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.

This patch integrates several fixes for several template issues
and open bugzilla bugs at the Fedora project.

The lxc-centos template now supports CentOS 7 and correct configuration
of systemd in CentOS.

The CentOS and Fedora template have been fixed for a rootfs bug that
was a skew between the parsed parameter (rootfs) and the working variable
(rootfs_path) by normalizing to rootfs, congruent with several other
templates.  This should fix the backing store problem.

The user password generation logic has been refactored out of the
Fedora and CentOS templates into a new template/functions file.  This
is the beginning of a security fix that has been reported as a bug in
Fedora and Debian.  The functions support random password generation
and/or disabled password on accounts.  Templates need to convert over
and avoid static passwords like root:root or ubuntu:ubuntu in order
to avoid this security issue.  Function supports multiple user setup.

The template/functions file includes a function for static MAC address
generation (not yet used) and may contain other common functions we
standardize on.

Added fedora user to lxc-fedora template.

Added centos user to lxc-centos template.

Dropping setfcap has been moved to a comment for Fedora, CentOS,
and SUSE due to it's interference with yum update in containers
(yum fails to update several packages including httpd).

Added sudo to the package list for CentOS and Fedora.

Set the apparmor profile for CentOS, Fedora, and SUSE containers to
unconfined, until someone comes up with something better, in order
to have containers run out of the box on apparmor hosts.  Commented
code in the individual templates has been moved to explicit settings
in the common config files.

Addressed systemd-journald runaway CPU issue by setting lxc.kmsg = 0
in affected template (including Mandriva) and establishing a run time
default to autoswitch lxc.kmsg depending on the state of lxc.autodev
(systemd case).  lxc.kmsg will be set to 0 in the case of lxc.autodev = 1
and set to 1 in the case of lxc.autodev = 0, unless overridden in
the config file.

Signed-off-by: Michael H. Warfield m...@wittsend.com
---
 config/templates/centos.common.conf.in   |   8 +-
 config/templates/fedora.common.conf.in   |   8 +-
 config/templates/opensuse.common.conf.in |   7 +-
 configure.ac |   1 +
 src/lxc/conf.c   |  23 +-
 templates/Makefile.am|   1 +
 templates/functions.in   | 208 +
 templates/lxc-centos.in  | 387 ---
 templates/lxc-fedora.in  | 318 ++---
 templates/lxc-openmandriva.in|   1 +
 templates/lxc-opensuse.in|  50 +++-
 11 files changed, 612 insertions(+), 400 deletions(-)
 create mode 100644 templates/functions.in

diff --git a/config/templates/centos.common.conf.in 
b/config/templates/centos.common.conf.in
index 4ce2fda..7f39ddf 100644
--- a/config/templates/centos.common.conf.in
+++ b/config/templates/centos.common.conf.in
@@ -20,4 +20,10 @@ lxc.mount.auto = proc:mixed sys:ro
 # lxc.cap.drop = setuid   # breaks sshd,nfs statd
 # lxc.cap.drop = audit_control# breaks sshd (set_loginuid failed)
 # lxc.cap.drop = audit_write
-lxc.cap.drop = setfcap setpcap sys_nice sys_pacct sys_rawio
+# lxc.cap.drop = setfcap  # setfcap causes all sorts of problems with 
yum update
+lxc.cap.drop = sys_nice sys_pacct sys_rawio
+
+# This lets LXC CentOS containers run on hosts with apparmor.
+# It does nothing on hosts which do not have apparmor enabled.
+lxc.aa_profile = unconfined
+
diff --git a/config/templates/fedora.common.conf.in 
b/config/templates/fedora.common.conf.in
index acebe3c..7794945 100644
--- a/config/templates/fedora.common.conf.in
+++ b/config/templates/fedora.common.conf.in
@@ -18,4 +18,10 @@ lxc.include = @LXCTEMPLATECONFIG@/common.conf
 # lxc.cap.drop = audit_control# breaks sshd (set_loginuid failed)
 # lxc.cap.drop = audit_write
 # lxc.cap.drop = setpcap  # big big login delays in Fedora 20 systemd
-lxc.cap.drop = setfcap sys_nice sys_pacct sys_rawio
+# lxc.cap.drop = setfcap  # setfcap causes all sorts of problems with 
yum update
+lxc.cap.drop = sys_nice sys_pacct sys_rawio
+
+# This lets LXC Fedora containers run on hosts with apparmor.
+# It does nothing on hosts which do not have apparmor enabled.
+lxc.aa_profile = unconfined
+
diff --git a/config/templates/opensuse.common.conf.in 
b/config/templates/opensuse.common.conf.in
index 4026975..813d296 100644
--- a/config/templates/opensuse.common.conf.in
+++ b/config/templates/opensuse.common.conf.in
@@ -21,5 +21,10 @@ lxc.autodev = 1
 # lxc.cap.drop = audit_control# breaks sshd (set_loginuid failed)
 # lxc.cap.drop = audit_write
 # lxc.cap.drop = setpcap  # big big login delays in Fedora 20 systemd

Re: [lxc-devel] [PATCH V1] Use pivot_root and umount2 instead of chroot

2014-08-31 Thread Michael H. Warfield

On Mon, 2014-09-01 at 03:24 +, Steven Stewart-Gallus wrote:
 chrooting leaves the old mount information in /proc/mounts and gives
 me anxiety. Explicitly switch root directories and unmount the old
 root directory.

 Signed-off-by: Steven Stewart-Gallus sstewartgallu...@mylangara.bc.ca

(/me checks watch and checks calendar)...  Here there be dragons.

We have gone back and forth on this for years.  There were SERIOUS
reasons for the decisions that were made (maybe right, maybe wrong and
which maybe changed now).  Not just the pollution of the mount table
(which is a seriouos PITA) but the issues of security and mount (mount
remount) security in containers and the interaction with other
containers.  This subject cause no ends of problems of ro/rw remount
issues across templates.

Has this been tested against the security and operational cases we have
faced and evaluated in the past?  I'd like to hear from Stephane and
Serge on this but I'm extremely leary of this lacking a security
evaluation of this change.  This is at the heart of a security issue for
the whole project.

IF things have changed and IF this can be done securely and IF this can
be done where one container does NOT contaminate the state of another, I
am comfortable with it.  With out that assurance, I am not.

This needs some serious evaluation, IMNSO.

Regards,
Mike

 ---
 
 Hello! In my own little sandbox program I use pivot_root and umount2
 instead of chroot.  It seems a lot more fool proof to me and also
 removes the old mount information from /proc/mounts.  I noticed that
 LXC didn't use this technique so I wanted to share it with LXC.
 Unfortunately, LXC's build system was mysteriously failing at building
 the documentation so I couldn't test this patch.  In any case, I
 wanted to discuss the general approach anyways mostly.
 
 Thank you,
 Steven Stewart-Gallus
 
 diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
 index ee8f491..38e33f4 100644
 --- a/src/lxc/lxccontainer.c
 +++ b/src/lxc/lxccontainer.c
 @@ -3397,10 +3397,17 @@ static bool do_add_remove_node(pid_t init_pid, const
 char *path, bool add,
   if (ret  0 || ret = MAXPATHLEN)
   return false;
  
 - if (chroot(chrootpath)  0)
 + if (chdir(chrootpath)  0)
   exit(1);
 - if (chdir(/)  0)
 +
 + if (syscall(__NR_pivot_root, ., .)  0) {
 + exit(1);
 + }
 +
 + if (umount2(., MNT_DETACH)  0) {
   exit(1);
 + }
 +
   /* remove path if it exists */
   if(faccessat(AT_FDCWD, path, F_OK, AT_SYMLINK_NOFOLLOW) == 0) {
   if (unlink(path)  0) {
 
 ___
 lxc-devel mailing list
 lxc-devel@lists.linuxcontainers.org
 http://lists.linuxcontainers.org/listinfo/lxc-devel
 

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH v2] Remove a comment part from a config value

2014-08-28 Thread Michael H. Warfield

On Fri, 2014-08-29 at 02:02 +0900, KATOH Yasufumi wrote:
  On Thu, 28 Aug 2014 09:54:32 -0400
 in message   Re: [lxc-devel] [PATCH v2] Remove a comment part from a 
 config value
   Stéphane Graber-san wrote:
 
  So my understanding there is that we simply don't support in-line
  comments (comments after meaningful content), one of the reason being
  for the case you just described.
 
  Comments on their own line should already be properly handled by the
  config parser, that is, they are stored in a separate list and restored
  on save_config.
 
 
  I suspect this is a case where the right answer is additional
  documentation, making it clear that we only support comments on their
  own lines.
 
 OK, I understand.
 
 The reason that I sent that patch is that there are the standard
 config files (in tree) that have in-line comments. 

 For example, centos.common.conf, oracle.common.conf, common.conf(on
 master branch)...

???

Just checked centos.common.conf, oracle.common.conf and
fedora.common.conf.  I don't see them.  I do see lines like this:

# lxc.cap.drop = net_raw  # breaks dhcp/ping
# lxc.cap.drop = setgid   # breaks login (initgroups/setgroups)
# lxc.cap.drop = dac_read_search  # breaks login (pam unix_chkpwd)
# lxc.cap.drop = setuid   # breaks sshd,nfs statd
# lxc.cap.drop = audit_control# breaks sshd (set_loginuid failed)

But those are comments to begin with.  If you merely uncommented them,
you would end up with in-line comments but I don't see any active
entries that have in-line comments at this time.

Perhaps that's a bad practice and maybe that needs to be documented
better that you would have to remove the leading comment hash as well as
the trailing in-line comment to uncomment the entry.

 Thanks,
 KATOH Yasufumi

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH v2] Remove a comment part from a config value

2014-08-28 Thread Michael H. Warfield

On Fri, 2014-08-29 at 09:27 +0900, KATOH Yasufumi wrote:
  On Thu, 28 Aug 2014 14:52:21 -0400
 in message   Re: [lxc-devel] [PATCH v2] Remove a comment part from a 
 config value
   Michael H. Warfield-san wrote:
 
  ???
 
  Just checked centos.common.conf, oracle.common.conf and
  fedora.common.conf.  I don't see them.  I do see lines like this:
 
  # lxc.cap.drop = net_raw  # breaks dhcp/ping
  # lxc.cap.drop = setgid   # breaks login (initgroups/setgroups)
  # lxc.cap.drop = dac_read_search  # breaks login (pam unix_chkpwd)
  # lxc.cap.drop = setuid   # breaks sshd,nfs statd
  # lxc.cap.drop = audit_control# breaks sshd (set_loginuid failed)
 
 On stable-1.0, centos.common.conf and oracle.common.conf have:
 
 lxc.cgroup.devices.allow = c 1:3 rwm  # /dev/null
 lxc.cgroup.devices.allow = c 1:5 rwm  # /dev/zero
 lxc.cgroup.devices.allow = c 1:7 rwm  # /dev/full
 lxc.cgroup.devices.allow = c 5:0 rwm  # /dev/tty
 lxc.cgroup.devices.allow = c 1:8 rwm  # /dev/random
 lxc.cgroup.devices.allow = c 1:9 rwm  # /dev/urandom
 lxc.cgroup.devices.allow = c 136:* rwm# /dev/tty[1-4] ptys and lxc 
 console
 lxc.cgroup.devices.allow = c 5:2 rwm  # /dev/ptmx pty master

Oh.  You said master branch.  That's where I was working.  I didn't look
in the stable-1.0 branch.  My oversight.

Stephane has already remarked that we need to clean those out.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] [v3] Integrated lxc-net service for rpm based platforms.

2014-08-26 Thread Michael H. Warfield

On Tue, 2014-08-26 at 11:58 -0400, Stéphane Graber wrote:
 I'm doing some testing and iterating on your patch some more to try and
 get this to work and be policy compliant for Debian systems too.

 The current work is happening at:
 https://github.com/stgraber/lxc

 I'll send an updated patch once I'm satisfied by the result.

Excellent.  Let me know where there any discrepancies with the Debian
policy stuff too, so I can file that for future reference.  I suspect
there's going to be some more evolution in this area (including
refactoring the Upstart lxc.conf code ala the lxc-net.conf code).

The Debian / Ubuntu build areas are some of the ones I'm not equipped to
test.

ITMT, I'm working on some much postponed template work.

Regards,
Mike

 On Mon, Aug 25, 2014 at 03:00:46PM -0400, Michael H. Warfield wrote:
  Version 3 Integration of lxc-net service for rpm based platforms.
  
  Initial version is deprecated and obsoleted by this version.
  
  Version 2 was discussed in private E-Mail
  
  Patch is against current master.
  
  This includes some patches for the SUSE / OpenSUSE platforms.
  
  Regards,
  Mike
  
  -- 
  [v3] Integrated lxc-net service for rpm based platforms.
  
  This fixes build and run problems on rpm based platforms (CentOS,
  Fedora, Oracle, SUSE) running with the systemd init following the
  refactoring of the Ubuntu lxc networking logic into a systemd service.
  
  Added lxc-net.in based on src/lxc/lxc.net and lxc.in for sysvinit
  and systemd init systems in parallel with lxc.in.
  
  Added autoconfigure variable for distro specific sysconfigdir and
  implemented in both lxc.in and lxc-net.in.
  
  Fixed configure.ac for OpenSUSE project return from lsb_release.
  
  Renamed config/etc/default.conf.ubuntu to config/etc/default.conf.lxcbr
  and set that as the default for Ubuntu, Fedora, CentOS, Oracle, SUSE,
  and OpenSUSE*.  Only other things left are unknown.
  
  Updated lxc-net.service.in for new path to lxc-net script in
  LIBEXECDIR instead of DATADIR.
  
  Renamed config/init/sysvinit to config/init/common reflecting the
  fact that the code in that directory is common to all three init
  paradigms.
  
  Removed src/lxc/lxc.net as it has been replaced by
  config/init/common/lxc-net.in installed in /usr/libexec/lxc.
  
  Changed name of lxc-autostart-helper.in to lxc-containers.in
  
  Added the lxc-net sysvinit script for sysvinit rpm packaging
  (CentOS 6, Oracle 6, etc).
  
  Added autogeneration of /etc/sysconfig/lxc-net for rpm based
  distributions into the lxc.spec file.
  
  Added creation of lxc-dnsmasq system user.
  
  Fixed fallbacks for action init script verb and lock file
  locations.
  
  Fixed potentially uninitialized variable in lxc_user_nic.c which
  was causing builds to fail on CentOS and Oracle with warnings
  treated as errors.
  
  Fixed lxc.spec.in for several SUSE build gotcha's.
  
  Signed-off-by: Michael H. Warfield m...@wittsend.com
  ---
   config/Makefile.am |   2 +-
   config/etc/Makefile.am |   2 +-
   config/etc/default.conf.ubuntu |   4 -
   config/init/Makefile.am|   2 +-
   config/init/systemd/Makefile.am|  14 +---
   config/init/systemd/lxc-net.service.in |   4 +-
   config/init/systemd/lxc.service.in |   4 +-
   config/init/sysvinit/Makefile.am   |  14 
   config/init/sysvinit/lxc.in| 131 
  -
   config/init/upstart/lxc-net.conf   |   4 +-
   configure.ac   |  19 +++--
   lxc.spec.in| 110 ++-
   src/lxc/Makefile.am|   4 +-
   src/lxc/lxc.net| 103 --
   src/lxc/lxc_user_nic.c |   2 +-
   15 files changed, 134 insertions(+), 285 deletions(-)
   delete mode 100644 config/etc/default.conf.ubuntu
   delete mode 100644 config/init/sysvinit/Makefile.am
   delete mode 100644 config/init/sysvinit/lxc.in
   delete mode 100755 src/lxc/lxc.net
  
  diff --git a/config/Makefile.am b/config/Makefile.am
  index 37fd24b..54f8859 100644
  --- a/config/Makefile.am
  +++ b/config/Makefile.am
  @@ -1 +1 @@
  -SUBDIRS = apparmor bash etc init selinux templates yum
  +SUBDIRS = apparmor bash etc init selinux templates yum sysconfig
  diff --git a/config/etc/Makefile.am b/config/etc/Makefile.am
  index 03193da..fa8bc2f 100644
  --- a/config/etc/Makefile.am
  +++ b/config/etc/Makefile.am
  @@ -1,7 +1,7 @@
   configdir = $(sysconfdir)/lxc
   config_DATA = default.conf
   
  -EXTRA_DIST = default.conf.ubuntu default.conf.libvirt default.conf.unknown
  +EXTRA_DIST = default.conf.lxcbr default.conf.libvirt default.conf.unknown
   
   clean-local:
  @$(RM) -f default.conf
  diff --git a/config/etc/default.conf.ubuntu b/config/etc/default.conf.ubuntu
  deleted file mode 100644
  index 661718b..000
  --- a/config/etc/default.conf.ubuntu
  +++ /dev/null
  @@ -1,4 +0,0

Re: [lxc-devel] default root password has to be random in default debian template

2014-08-23 Thread Michael H. Warfield

On Sat, 2014-08-23 at 11:04 +0200, Thomas Moschny wrote:
 2014-08-20 18:32 GMT+02:00 Michael H. Warfield m...@wittsend.com:
  Yes, it does apply to more templates (but not all templates).
 
  This has been discussed before.  Please look at the Fedora and CentOS
  templates for how we handle them there.  In those cases, it's
  configurable and supports templating.  It's up to the other template
  maintainers if they want to pull that over and there are issues with the
  download template and its defaults (if you use the download template to
  pull a Fedora rootfs, you still get root:root).  I'm not familiar with
  who the maintainer of the Debian template is.  I've only contributed to
  the Fedora, CentOS, and OpenSUSE templates.

 This issue has been reported as a security bug against the Fedora packages:

 https://bugzilla.redhat.com/show_bug.cgi?id=1132001

Sigh...

 It would be nice if we could get that fixed for all templates. Instead
 of letting different template maintainers fix that in different ways,
 we should probably factor this out into a common routine?

I just looked at the code I did in the Fedora template.  Yeah, I think I
could abstract that out into a functions file without too much
trouble.  I know Stéphane wants users to be using the download template
more, because the raw templates generally can not be used by non-priv
users but it would make things easier if we started building up a
scaffolding of common functions that could be used in templates.  This
might be a good place to start.

This has also raised the complicating question of changing the root
password from the host system when needed.  Some cases are straight
forward with a chroot ${root_fs} passwd but things can get much more
complicated depending on backing store (cow2, lvm, etc).

The download template is a special case where the whole rootfs is
downloaded and cached from an image site.

 Regards,
 Thomas

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] default root password has to be random in default debian template

2014-08-20 Thread Michael H. Warfield

On Tue, 2014-08-19 at 17:28 +0200, Ondřej Surý wrote:
 Hi,

 [probably also applies to more templates]

 the default security of debian template is horrible. Default sshd_config
 permits root login with password and sets the default password to
 'root'.

 Please at least pull changes from:
 https://bugs.debian.org/758643
 https://bugs.debian.org/758647

 Note that this needs pwgen to generate new password, so you might
 want to generate random password using some common tool or method
 (openssl, etc...)

 And please do a similar security audit of all templates shipping with
 lxc,
 I have also seen ubuntu/ubuntu in the ubuntu template...

Yes, it does apply to more templates (but not all templates).

This has been discussed before.  Please look at the Fedora and CentOS
templates for how we handle them there.  In those cases, it's
configurable and supports templating.  It's up to the other template
maintainers if they want to pull that over and there are issues with the
download template and its defaults (if you use the download template to
pull a Fedora rootfs, you still get root:root).  I'm not familiar with
who the maintainer of the Debian template is.  I've only contributed to
the Fedora, CentOS, and OpenSUSE templates.

 Cheers,

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Building upstream lxc.spec on openSUSE OBS

2014-08-19 Thread Michael H. Warfield

On Tue, 2014-08-19 at 20:56 +0200, Johannes Kastl wrote:
 On 18.08.2014 18:29 Michael H. Warfield wrote:
 
  That's going to be my gold standard for merging your changes in.
  There have been some changes in the area of the %post sections of
  that spec file and your patch won't apply cleanly.  I can cherry
  pick the Suse specific changes out of it but there still remains
  the issue of missing source files.

 See my other mail for the source issues.

 Of course the docbook2x-thing is an issue with the OBS, I never
 proposed building without just to workaround that. That was just to
 see if the spec builds at all.

Yeah, while waiting for the dust to settle on some private conversations
over the next round of patches and some reorganization, I've been
working on this under SuSE 13.1.  I've pretty much worked through the
required changes but ran into some peculiar gotcha's.

Still sorting out why but configure / configure.ac is not picking up on
the SuSe distro properly for me (which affects where the new default
config files live) and the apparmour things briefly threw me for a loop.
I've got those sorted now and it is building on SuSe 13.1 native (in a
container) for me.  I may be able to get some or all of this rolled into
the next patch set if it's not too involved (so far it's not).

 Regards,
 Johannes

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Building upstream lxc.spec on openSUSE OBS

2014-08-19 Thread Michael H. Warfield

On Tue, 2014-08-19 at 15:58 -0400, Michael H. Warfield wrote:
 On Tue, 2014-08-19 at 20:56 +0200, Johannes Kastl wrote:
  On 18.08.2014 18:29 Michael H. Warfield wrote:
  
   That's going to be my gold standard for merging your changes in.
   There have been some changes in the area of the %post sections of
   that spec file and your patch won't apply cleanly.  I can cherry
   pick the Suse specific changes out of it but there still remains
   the issue of missing source files.

  See my other mail for the source issues.

  Of course the docbook2x-thing is an issue with the OBS, I never
  proposed building without just to workaround that. That was just to
  see if the spec builds at all.

 Yeah, while waiting for the dust to settle on some private conversations
 over the next round of patches and some reorganization, I've been
 working on this under SuSE 13.1.  I've pretty much worked through the
 required changes but ran into some peculiar gotcha's.

 Still sorting out why but configure / configure.ac is not picking up on
 the SuSe distro properly for me (which affects where the new default
 config files live) and the apparmour things briefly threw me for a loop.
 I've got those sorted now and it is building on SuSe 13.1 native (in a
 container) for me.  I may be able to get some or all of this rolled into
 the next patch set if it's not too involved (so far it's not).

Got the distro recognition sorted.  Seems that lsb_release was
returning OpenSuSe Project and configure wasn't recognizing it
resulting in an unknown.  I'm surprised you didn't run into that.
Required a couple of fixes to configured.ac for opensuse* but maybe you
didn't have the impacted files in play for your build.  Mostly affected
where the default sysconfig config files resided which is not in 1.0.5
at all.  I'm real close at this point.  It's building on 13.1.

  Regards,
  Johannes

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Building upstream lxc.spec on openSUSE OBS

2014-08-18 Thread Michael H. Warfield

On Thu, 2014-08-14 at 21:52 +0200, Johannes Kastl wrote:
 On 13.08.2014 21:10 Johannes Kastl wrote:
  On 13.08.2014 20:41 Johannes Kastl wrote:
  Hi MIke, hi Dwight,
  
  sorry for the long long delay. I finally got time to work on
  that a little, and produced a patch against lxc.spec.in. At
  least, I got a working spec, and I am in the middle of patching.
  Stay tuned...
  
  Here it is. I hope this patch has the right format, if not just
  say what's wrong.

 I attach the second version of my patch, which has been cleaned up,
 has clearer distinctions between distributions and builds on CentOS7
 (if I comment out the BuildRequires for docbook2x).

 Can someone build it on CentOS 5/6/7 where docbook2x is available?

There's no reason to even attempt to build on CentOS 5.  Latest kernel
on CentOS 5 is 2.6.18 which will not support LXC containers anyways.  We
can support CentOS 5 in a container but we can not support it as a host
due to lack of kernel infrastructure support for cgroups and name
spaces.

CentOS 6 (and presumably 7) has docbook2X in EPEL.  Since LXC is an EPEL
package for CentOS and RHEL as well (and has the same EPEL project
maintainer as the Fedora distro maintainer for LXC), there's no need to
try and build it without docbook2X.  If this is a problem with building
under that OBS build system then it's their problem.

I have built the lxc rpm's under CentOS6 w/ docbook2X from EPEL from git
head (1.1.0alpha1 ++) plus my patches for the lxc-net refactoring from
Martin Pitt and a couple of misc fixes (potentially uninitialized
ifindex in lxc_user_nic.c at 478).  I'm also building with Python 3.3
from the Alt repository, which may cause a great deal more heartburn for
Thomas Moschny thomas.mosc...@gmx.de (the EPEL / Fedora package
maintainer) but that's a choice between doing that and lost
functionality we'll have to work out.

That's going to be my gold standard for merging your changes in.  There
have been some changes in the area of the %post sections of that spec
file and your patch won't apply cleanly.  I can cherry pick the Suse
specific changes out of it but there still remains the issue of missing
source files.

I still have work to do on the CentOS 7 patches for the CentOS template
and containers but it should build under CentOS 7 with docbook2X
installed from EPEL.

I'll be submitting my current patch set in the next day or so.  I just
found a couple more gotcha's in the sysvinit area of the lxc.spec.in
file thanks to your suggestion of building on CentOS (I missed adding
lxc-net to the sysvinit block for CentOS 6) so I'm still doing some
regression testing on my platforms.  I had almost forgotten to recheck
the builds on CentOS.  Thanks for reminding me!

 Regards,
 Johannes

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Building upstream lxc.spec on openSUSE OBS

2014-08-17 Thread Michael H. Warfield

On Thu, 2014-08-14 at 21:52 +0200, Johannes Kastl wrote:
 On 13.08.2014 21:10 Johannes Kastl wrote:
  On 13.08.2014 20:41 Johannes Kastl wrote:
  Hi MIke, hi Dwight,
  
  sorry for the long long delay. I finally got time to work on
  that a little, and produced a patch against lxc.spec.in. At
  least, I got a working spec, and I am in the middle of patching.
  Stay tuned...
  
  Here it is. I hope this patch has the right format, if not just
  say what's wrong.

 I attach the second version of my patch, which has been cleaned up,
 has clearer distinctions between distributions and builds on CentOS7
 (if I comment out the BuildRequires for docbook2x).

I would have liked a cleaner patch with fewer cosmetic changes or style
changes.  It's making the merge distinctly more difficult.

-%{_libdir}/python3.3/site-packages/_lxc*
-%{_libdir}/python3.3/site-packages/lxc/*
+%{_libdir}/python3.3/site-packages/_%{name}*
+%{_libdir}/python3.3/site-packages/%{name}/*

While these changes may be nice, I would have rather had things like
this broken out in a separate clean-up patch rather than gemixed with
functional changes.

You have two external sources called out here:

+%if 0%{?suse_version} = 1210
+Source1:README.SUSE
+Source2:lxc-createconfig.in
+%endif

I don't think that's going to fly.  That would mean that someone taking
our source tree would not be able to build the rpm on Suse unless they
obtained those sources from somewhere else.  That really needs to be
submitted and integrated into the source tree to be acceptable.

Why this change in the License?  I'm not saying either is right or wrong
or that they're not functionally equivalent, but there must have been
some reason for changing it and I would like to know what it was...

 Summary: Linux Containers userspace tools
 Group: Applications/System
-License: LGPLv2+
+License: LGPL-2.0+
 BuildRoot: %{_tmppath}/%{name}-%{version}-build

You changed the man directory code like this:

from this:

-%{_mandir}/man1/lxc*
-%{_mandir}/man5/lxc*
-%{_mandir}/man7/lxc*
-%{_mandir}/ja/man1/lxc*
-%{_mandir}/ja/man5/lxc*
-%{_mandir}/ja/man7/lxc*

to this:

+# openSUSE/SUSE
+%if %{defined suse_version} 
+%{_mandir}/man[^3]/*
+# not openSUSE/SUSE
+%else
+%if %{undefined rhel} 
+%{_mandir}/man[^3]/*
+%{_mandir}/ja/*
+%endif

Looks like the man dir is the same for Suse and not Suse other than the
Japanese pages (which I believe is what we need docbook2X for) or when
rhel is defined.  I recall seeing a remark from you over the use of that
regex on rhel, as well.  So you're NOT installing any man pages on
RHEL/CentOS?  Why make this change (other than excluding the ja pages
under Suse)?  Do you have some specific need for that regex at all?
What is the problem with the way it was coded?  Were we missing
something in another section?

Seems like there were a number of changes in here that were not
necessary to make it build under Suse (or it's unclear why they were
necessary).  Can we split the functionally substantive changes from the
purely cosmetic changes and style changes?

 Can someone build it on CentOS 5/6/7 where docbook2x is available?

Right now, let's focus on getting the patch into an acceptable form with
minimal cosmetic changes and undo the use of that regex for the man
pages.

 Regards,
 Johannes
 ___
 lxc-devel mailing list
 lxc-devel@lists.linuxcontainers.org
 http://lists.linuxcontainers.org/listinfo/lxc-devel

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] lxc-autostart-helper working even if action is not available

2014-08-15 Thread Michael H. Warfield

On Fri, 2014-08-15 at 16:52 +0200, Johannes Kastl wrote:
 On 14.08.2014 22:01 Johannes Kastl wrote:

  Basically, Martins patch just does an
  
  echo ... bindir/lxc-autostart ...
  
  But it does not execute the lxc-autostart command itself.

 The attached patch introduces an if-clause, and if action is not
 available, it uses echo, but also starts $bindir/lxc-autostart.

 Please, can someone confirm that this works?

 I'm working on a patch to check for the /var/lock/subdir thingy.

This code is being worked on right now and will probably make and
appearance under a new name.  I'll look this over but expect a patch
early to mid-week.

 Regards,
 Johannes

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Starting lxc via systemd on openSUSE: action: command not found

2014-08-15 Thread Michael H. Warfield

This is going to be addressed in an upcoming patch.  It was a failure in
an earlier patch from another individual.

On Wed, 2014-08-13 at 21:22 +0200, Johannes Kastl wrote:
 Hi everyone,
 
 I tried to get some lxc containers to start on openSUSE, but could not
 get the systemd-service to start:
 
  sudo systemctl status lxc.service lxc.service - LXC Container
  Initialization and Autoboot Code Loaded: loaded
  (/usr/lib/systemd/system/lxc.service; disabled) Active: failed
  (Result: exit-code) since Di 2014-08-12 10:41:47 CEST; 5s ago 
  Process: 2792 ExecStart=/usr/lib/lxc/lxc-autostart-helper start
  (code=exited, status=1/FAILURE) Process: 2790
  ExecStartPre=/usr/lib/lxc/lxc-devsetup (code=exited,
  status=0/SUCCESS) Main PID: 2792 (code=exited, status=1/FAILURE)
  
  Aug 12 10:41:47 XXX lxc-autostart-helper[2792]:
  /usr/lib/lxc/lxc-autostart-helper: line 101: action: command not
  found Aug 12 10:41:47 XXX lxc-autostart-helper[2792]: [73B blob
  data] Aug 12 10:41:47 XXX systemd[1]: lxc.service: main process
  exited, code=exited, status=1/FAILURE Aug 12 10:41:47 XXX
  systemd[1]: Failed to start LXC Container Initialization and
  Autoboot Code. Aug 12 10:41:47 XXX systemd[1]: Unit lxc.service
  entered failed state.
 
 The reason seem to be lines containing 'action' in
 /usr/lib/lxc-autostart-helper:
 
  $ grep -C 2 action /usr/lib/lxc/lxc-autostart-helper 
  wait_for_bridge # Start autoboot containers first then the NULL
  group onboot,. action $Starting LXC autoboot containers: 
  /usr/bin/lxc-autostart $OPTIONS $BOOTGROUPS touch
  $localstatedir/lock/subsys/lxc ;; -- # delaying the system
  shutdown / reboot as much as we can since it's not #
  parallelized...  Even 5 second timout may be too long. action
  $Stopping LXC containers:  $bindir/lxc-autostart $STOPOPTS
  $SHUTDOWNDELAY rm -f $localstatedir/lock/subsys/lxc ;;
 
 I have never seen a shell command action before, so maybe this is some
 systemd/sysvinit-related thing? Why does this not work on openSUSE?
 Maybe the rc-file is not sourced (I remember there is a file being
 sourced, I just do not have the autostart-helper script right here...)?
 
 Any openSUSE-users out there?
 
 Regards,
 Johannes
 ___
 lxc-devel mailing list
 lxc-devel@lists.linuxcontainers.org
 http://lists.linuxcontainers.org/listinfo/lxc-devel
 

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

[lxc-devel] [PATCH] Integrated lxc-net service for rpm based platforms.

Integrated lxc-net service for rpm based platforms.

This fixes build and run problems on rpm based platforms (CentOS,
Fedora, Oracle*) running with the systemd init following the
refactoring of the Ubuntu lxc networking logic into a systemd service.

Added lxc-net.in based on src/lxc/lxc.net and lxc.in for sysvinit
and systemd init systems in parallel with lxc.in.

Added autoconfigure variable for distro specific sysconf and
implimented in both lxc.in and lxc-net.in.

Updated lxc-net.service.in for new path to lxc-net script in
LIBEXECDIR instead of DATADIR.

Updated src/lxc/lxc.net to check both /etc/default/lxc and
/etc/sysconfig/lxc.  This file should now be deprecated but
is left for reference until all conversions are complete.

Signed-off-by: Michael H. Warfield m...@wittsend.com
---
 config/init/systemd/Makefile.am|  20 ++---
 config/init/systemd/lxc-net.service.in |   4 +-
 config/init/sysvinit/Makefile.am   |   4 +-
 config/init/sysvinit/lxc-net.in| 134 +
 config/init/sysvinit/lxc.in|   6 +-
 configure.ac   |   5 ++
 lxc.spec.in|   2 +
 src/lxc/lxc.net|  13 ++--
 8 files changed, 167 insertions(+), 21 deletions(-)
 create mode 100644 config/init/sysvinit/lxc-net.in

diff --git a/config/init/systemd/Makefile.am b/config/init/systemd/Makefile.am
index 5959cd8..767556b 100644
--- a/config/init/systemd/Makefile.am
+++ b/config/init/systemd/Makefile.am
@@ -6,17 +6,17 @@ EXTRA_DIST = \
$(NULL)
 
 if INIT_SCRIPT_SYSTEMD
-lxc-autostart-helper: ../sysvinit/lxc.in $(top_builddir)/config.status
-   $(AM_V_GEN)sed  \
-   -e 's|[@]SYSCONFDIR[@]|$(sysconfdir)|g' \
-   -e 's|[@]LOCALSTATEDIR[@]|$(localstatedir)|g'   \
-   -e 's|[@]BINDIR[@]|$(bindir)|g' \
-$  $@-t   \
-   chmod a+x $@-t\
-   mv $@-t $@
+lxc-autostart-helper: ../sysvinit/lxc $(top_builddir)/config.status
+#  This was already autoconfed over in the sysvinit dir
+   cp ../sysvinit/lxc $@
+
+lxc-net: ../sysvinit/lxc-net $(top_builddir)/config.status
+#  This was already autoconfed over in the sysvinit dir
+   cp ../sysvinit/lxc-net $@
+
 BUILT_SOURCES = lxc-autostart-helper lxc.service lxc-net.service
 
-install-systemd: lxc.service lxc-net.service lxc-devsetup lxc-apparmor-load 
lxc-autostart-helper
+install-systemd: lxc.service lxc-net.service lxc-devsetup lxc-apparmor-load 
lxc-autostart-helper lxc-net
$(MKDIR_P) $(DESTDIR)$(SYSTEMD_UNIT_DIR)
$(INSTALL_DATA) lxc.service lxc-net.service 
$(DESTDIR)$(SYSTEMD_UNIT_DIR)/
 
@@ -25,7 +25,7 @@ uninstall-systemd:
rm -f $(DESTDIR)$(SYSTEMD_UNIT_DIR)/lxc-net.service
rmdir $(DESTDIR)$(SYSTEMD_UNIT_DIR) || :
 
-pkglibexec_SCRIPTS = lxc-devsetup lxc-apparmor-load lxc-autostart-helper
+pkglibexec_SCRIPTS = lxc-devsetup lxc-apparmor-load lxc-autostart-helper 
lxc-net
 
 install-data-local: install-systemd
 uninstall-local: uninstall-systemd
diff --git a/config/init/systemd/lxc-net.service.in 
b/config/init/systemd/lxc-net.service.in
index 37d1d69..c054702 100644
--- a/config/init/systemd/lxc-net.service.in
+++ b/config/init/systemd/lxc-net.service.in
@@ -6,5 +6,5 @@ Before=lxc.service
 [Service]
 Type=oneshot
 RemainAfterExit=yes
-ExecStart=@DATADIR@/lxc/lxc.net start
-ExecStop=@DATADIR@/lxc/lxc.net stop
+ExecStart=@LIBEXECDIR@/lxc/lxc-net start
+ExecStop=@LIBEXECDIR@/lxc/lxc-net stop
diff --git a/config/init/sysvinit/Makefile.am b/config/init/sysvinit/Makefile.am
index 66c190d..d8722ab 100644
--- a/config/init/sysvinit/Makefile.am
+++ b/config/init/sysvinit/Makefile.am
@@ -1,12 +1,14 @@
-EXTRA_DIST = lxc
+EXTRA_DIST = lxc lxc-net
 
 if INIT_SCRIPT_SYSV
 install-sysvinit: lxc
$(MKDIR_P) $(DESTDIR)$(sysconfdir)/rc.d/init.d
$(INSTALL_SCRIPT) lxc $(DESTDIR)$(sysconfdir)/rc.d/init.d/lxc
+   $(INSTALL_SCRIPT) lxc-net $(DESTDIR)$(sysconfdir)/rc.d/init.d/lxc-net
 
 uninstall-sysvinit:
rm -f $(DESTDIR)$(sysconfdir)/rc.d/init.d/lxc
+   rm -f $(DESTDIR)$(sysconfdir)/rc.d/init.d/lxc-net
rmdir $(DESTDIR)$(sysconfdir)/rc.d/init.d || :
 
 install-data-local: install-sysvinit
diff --git a/config/init/sysvinit/lxc-net.in b/config/init/sysvinit/lxc-net.in
new file mode 100644
index 000..e31fbac
--- /dev/null
+++ b/config/init/sysvinit/lxc-net.in
@@ -0,0 +1,134 @@
+#!/bin/sh -
+#
+# lxc-net Start/Stop LXC Networking
+#
+# chkconfig: 345 99 01
+# description: Starts/Stops LXC Network Bridge
+#
+### BEGIN INIT INFO
+# Provides: lxc-net
+# Default-Start: 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: Bring up/down LXC Network Bridge
+# Description: Bring up/down LXC Network Bridge
+### END INIT INFO
+
+# Programmers Note:  The chkconfig information above is largely

Re: [lxc-devel] Starting lxc via systemd on openSUSE: action: command not found

On Wed, 2014-08-13 at 21:22 +0200, Johannes Kastl wrote:
 Hi everyone,
 
 I tried to get some lxc containers to start on openSUSE, but could not
 get the systemd-service to start:
 
  sudo systemctl status lxc.service lxc.service - LXC Container
  Initialization and Autoboot Code Loaded: loaded
  (/usr/lib/systemd/system/lxc.service; disabled) Active: failed
  (Result: exit-code) since Di 2014-08-12 10:41:47 CEST; 5s ago 
  Process: 2792 ExecStart=/usr/lib/lxc/lxc-autostart-helper start
  (code=exited, status=1/FAILURE) Process: 2790
  ExecStartPre=/usr/lib/lxc/lxc-devsetup (code=exited,
  status=0/SUCCESS) Main PID: 2792 (code=exited, status=1/FAILURE)
  
  Aug 12 10:41:47 XXX lxc-autostart-helper[2792]:
  /usr/lib/lxc/lxc-autostart-helper: line 101: action: command not
  found Aug 12 10:41:47 XXX lxc-autostart-helper[2792]: [73B blob
  data] Aug 12 10:41:47 XXX systemd[1]: lxc.service: main process
  exited, code=exited, status=1/FAILURE Aug 12 10:41:47 XXX
  systemd[1]: Failed to start LXC Container Initialization and
  Autoboot Code. Aug 12 10:41:47 XXX systemd[1]: Unit lxc.service
  entered failed state.
 
 The reason seem to be lines containing 'action' in
 /usr/lib/lxc-autostart-helper:
 
  $ grep -C 2 action /usr/lib/lxc/lxc-autostart-helper 
  wait_for_bridge # Start autoboot containers first then the NULL
  group onboot,. action $Starting LXC autoboot containers: 
  /usr/bin/lxc-autostart $OPTIONS $BOOTGROUPS touch
  $localstatedir/lock/subsys/lxc ;; -- # delaying the system
  shutdown / reboot as much as we can since it's not #
  parallelized...  Even 5 second timout may be too long. action
  $Stopping LXC containers:  $bindir/lxc-autostart $STOPOPTS
  $SHUTDOWNDELAY rm -f $localstatedir/lock/subsys/lxc ;;
 
 I have never seen a shell command action before, so maybe this is some
 systemd/sysvinit-related thing? Why does this not work on openSUSE?
 Maybe the rc-file is not sourced (I remember there is a file being
 sourced, I just do not have the autostart-helper script right here...)?

The action command is a sysvinit'ism.  It's actually a function that's
picked up out of $sysconfdir/rc.d/init.d/functions which I'm guessing
you're missing.  That helper is actually the sysvinit script run when
running under Sysvinit.  This could be a problem that'll fall in
Dwight's or my lap.  I'll see what can be done to eliminate that
dependency as I'm already up to my eyeballs in the init scripts as it is
right now.  If all we need is action we may be able to replace it with
a more neutral expression.

 Any openSUSE-users out there?

 Regards,
 Johannes

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Starting lxc via systemd on openSUSE: action: command not found

On Wed, 2014-08-13 at 21:53 +0200, Johannes Kastl wrote:
 On 13.08.2014 21:38 Michael H. Warfield wrote:

  The action command is a sysvinit'ism.  It's actually a function
  that's picked up out of $sysconfdir/rc.d/init.d/functions which
  I'm guessing you're missing.

 Right, that one does not exist on my openSUSE machine. Actually,
 neither does /etc/rc.d/init.d. And /etc/rc.d is a link to /etc/init.d/.

 I adjusted the lines like this:
  echo ... /usr/bin/lxc-autostart $OPTIONS $BOOTGROUPS

 And now I get an error, as the touch in the next lines does not find
 /var/lock/subsys/...

Well...  You've got /var/lock and tmpfs is mounted on it (OpenSuse
13.1).  Looks like it's empty for me though.  Guess it needs a mkdir -p
subsys unless the subsystem lock should go somewhere else.  Maybe just
fall back to using /var/lock.  Looks at the other init scripts in that
directory, I'm not seeing much in the way of subsystem lockfile use.

 Regards,
 Johannes

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Starting lxc via systemd on openSUSE: action: command not found

On Wed, 2014-08-13 at 17:14 -0400, Dwight Engen wrote:
 On Wed, 13 Aug 2014 15:38:10 -0400
 Michael H. Warfield m...@wittsend.com wrote:
 
  On Wed, 2014-08-13 at 21:22 +0200, Johannes Kastl wrote:
   Hi everyone,
   
   I tried to get some lxc containers to start on openSUSE, but could
   not get the systemd-service to start:
   
sudo systemctl status lxc.service lxc.service - LXC Container
Initialization and Autoboot Code Loaded: loaded
(/usr/lib/systemd/system/lxc.service; disabled) Active: failed
(Result: exit-code) since Di 2014-08-12 10:41:47 CEST; 5s ago 
Process: 2792 ExecStart=/usr/lib/lxc/lxc-autostart-helper start
(code=exited, status=1/FAILURE) Process: 2790
ExecStartPre=/usr/lib/lxc/lxc-devsetup (code=exited,
status=0/SUCCESS) Main PID: 2792 (code=exited, status=1/FAILURE)

Aug 12 10:41:47 XXX lxc-autostart-helper[2792]:
/usr/lib/lxc/lxc-autostart-helper: line 101: action: command not
found Aug 12 10:41:47 XXX lxc-autostart-helper[2792]: [73B blob
data] Aug 12 10:41:47 XXX systemd[1]: lxc.service: main process
exited, code=exited, status=1/FAILURE Aug 12 10:41:47 XXX
systemd[1]: Failed to start LXC Container Initialization and
Autoboot Code. Aug 12 10:41:47 XXX systemd[1]: Unit lxc.service
entered failed state.
   
   The reason seem to be lines containing 'action' in
   /usr/lib/lxc-autostart-helper:
   
$ grep -C 2 action /usr/lib/lxc/lxc-autostart-helper 
wait_for_bridge # Start autoboot containers first then the NULL
group onboot,. action $Starting LXC autoboot containers: 
/usr/bin/lxc-autostart $OPTIONS $BOOTGROUPS touch
$localstatedir/lock/subsys/lxc ;; -- # delaying the system
shutdown / reboot as much as we can since it's not #
parallelized...  Even 5 second timout may be too long. action
$Stopping LXC containers:  $bindir/lxc-autostart $STOPOPTS
$SHUTDOWNDELAY rm -f $localstatedir/lock/subsys/lxc ;;
   
   I have never seen a shell command action before, so maybe this is
   some systemd/sysvinit-related thing? Why does this not work on
   openSUSE? Maybe the rc-file is not sourced (I remember there is a
   file being sourced, I just do not have the autostart-helper script
   right here...)?
  
  The action command is a sysvinit'ism.  It's actually a function
  that's picked up out of $sysconfdir/rc.d/init.d/functions which I'm
  guessing you're missing.  That helper is actually the sysvinit
  script run when running under Sysvinit.  This could be a problem
  that'll fall in Dwight's or my lap.  I'll see what can be done to
  eliminate that dependency as I'm already up to my eyeballs in the

 Martin Pitt's recent patch titled [lxc-devel] [PATCH 4/6] systemd:
 Ensure action() is defined should fix this.

Nice...  I'll run that down.

Now I just gotta do something about the lock dir.  I think I'll just
fall back and drop the subsys part.

  init scripts as it is right now.  If all we need is action we may
  be able to replace it with a more neutral expression.
  
   Any openSUSE-users out there?
  
   Regards,
   Johannes

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Starting lxc via systemd on openSUSE: action: command not found

On Wed, 2014-08-13 at 19:03 -0400, Dwight Engen wrote:
 On Wed, 13 Aug 2014 17:48:59 -0400
 Michael H. Warfield m...@wittsend.com wrote:
 
  On Wed, 2014-08-13 at 17:14 -0400, Dwight Engen wrote:
   On Wed, 13 Aug 2014 15:38:10 -0400
   Michael H. Warfield m...@wittsend.com wrote:
   
On Wed, 2014-08-13 at 21:22 +0200, Johannes Kastl wrote:
 Hi everyone,
 
 I tried to get some lxc containers to start on openSUSE, but
 could not get the systemd-service to start:
 
  sudo systemctl status lxc.service lxc.service - LXC Container
  Initialization and Autoboot Code Loaded: loaded
  (/usr/lib/systemd/system/lxc.service; disabled) Active: failed
  (Result: exit-code) since Di 2014-08-12 10:41:47 CEST; 5s ago 
  Process: 2792 ExecStart=/usr/lib/lxc/lxc-autostart-helper
  start (code=exited, status=1/FAILURE) Process: 2790
  ExecStartPre=/usr/lib/lxc/lxc-devsetup (code=exited,
  status=0/SUCCESS) Main PID: 2792 (code=exited,
  status=1/FAILURE)
  
  Aug 12 10:41:47 XXX lxc-autostart-helper[2792]:
  /usr/lib/lxc/lxc-autostart-helper: line 101: action: command
  not found Aug 12 10:41:47 XXX lxc-autostart-helper[2792]:
  [73B blob data] Aug 12 10:41:47 XXX systemd[1]: lxc.service:
  main process exited, code=exited, status=1/FAILURE Aug 12
  10:41:47 XXX systemd[1]: Failed to start LXC Container
  Initialization and Autoboot Code. Aug 12 10:41:47 XXX
  systemd[1]: Unit lxc.service entered failed state.
 
 The reason seem to be lines containing 'action' in
 /usr/lib/lxc-autostart-helper:
 
  $ grep -C 2 action /usr/lib/lxc/lxc-autostart-helper 
  wait_for_bridge # Start autoboot containers first then the
  NULL group onboot,. action $Starting LXC autoboot
  containers:  /usr/bin/lxc-autostart $OPTIONS $BOOTGROUPS
  touch $localstatedir/lock/subsys/lxc ;; -- # delaying the
  system shutdown / reboot as much as we can since it's not #
  parallelized...  Even 5 second timout may be too long. action
  $Stopping LXC containers:  $bindir/lxc-autostart $STOPOPTS
  $SHUTDOWNDELAY rm -f $localstatedir/lock/subsys/lxc ;;
 
 I have never seen a shell command action before, so maybe this
 is some systemd/sysvinit-related thing? Why does this not work
 on openSUSE? Maybe the rc-file is not sourced (I remember there
 is a file being sourced, I just do not have the
 autostart-helper script right here...)?

The action command is a sysvinit'ism.  It's actually a function
that's picked up out of $sysconfdir/rc.d/init.d/functions which
I'm guessing you're missing.  That helper is actually the
sysvinit script run when running under Sysvinit.  This could be a
problem that'll fall in Dwight's or my lap.  I'll see what can be
done to eliminate that dependency as I'm already up to my
eyeballs in the
  
   Martin Pitt's recent patch titled [lxc-devel] [PATCH 4/6] systemd:
   Ensure action() is defined should fix this.
  
  Nice...  I'll run that down.
  
  Now I just gotta do something about the lock dir.  I think I'll just
  fall back and drop the subsys part.

 Just a word of warning that that won't work on Fedora derived distros.
 It has to be there or the shutdown K symlinks won't work. See the loop
 in /etc/rc.d/rc that has /var/lock/subsys/$subsys hardcoded.

That won't be a problem.  It would fall back only if subsys didn't
exist.  I already figured that.  I'm not saying totally drop back.  If
the subsys subdirectory doesn't already exist, then drop back.

init scripts as it is right now.  If all we need is action we
may be able to replace it with a more neutral expression.

 Any openSUSE-users out there?

 Regards,
 Johannes

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 1/6] Move lxcbr0 setup logic into lxc.net script

2014-08-11 Thread Michael H. Warfield

On Mon, 2014-08-11 at 15:37 +, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@wittsend.com):
  On Thu, 2014-07-31 at 08:53 +0200, Martin Pitt wrote:
   Factor this out of the lxc-net.conf upstart job, so that it can be used by
   init.d scripts and systemd units, too.
  
  Crap.  Never fails.  I was in Europe when this came out.
  
  Looking at lxc.net, I would say it's going to break some existing setups
  (notably mine) where lxcbr0 is already setup.  Yes, we can set
  LXC_BRIDGE to no but we should also include some autodetect logic such
  that, if lxcbr0 already exists, this doesn't commit random acts of
  terrorism.

 That logic should already be there.  If /sys/class/net/lxcbr0 already
 exists, then start will do nothing;  if /run/lxc/network_up does not
 exist then stop will do nothing.

Yeah, I traced through that logic and finally realized that.  I'm a
little nudgey about even calling stop from start in the case where
the bridge already exists or when USE_LXC_BRIDGE is not true and then
relying on stop to rely on the non-existence of network_up to exit
without doing anything to the bridge.  If that's the case, why even call
stop in the start function at all?  That had me confused.

I don't see the need for this logic at all in start:

-- 
if [ -d /sys/class/net/${LXC_BRIDGE} ]; then
if [ ! -f ${varrun}/network_up ]; then
# bridge exists, but we didn't start it
stop;
fi
exit 0;
fi
-- 

If this bridge exists and we didn't start it, why even attempt to stop
it?  Yeah, that will hit the same check in stop and then exit but it
seems like an overly convoluted logic (which includes
loading /etc/default/lxc twice) where both paths logically end up in an
exit.  Why have that inner if stanza at all?  Just exit 0?  Just
this:

-- 
if [ -d /sys/class/net/${LXC_BRIDGE} ]; then
exit 0;
fi
-- 

I'm still unsure about the default configs and handling discrepancies
between what's in /etc/lxc/default.conf that the sysvinit references for
lxc.network.link (virbr0 in the case of Oracle, CentOS, and Fedora) and
what's in /etc/default/lxc for LXC_BRIDGE.  What's the corner cases
where those two definitions disagree?

That file raises another question.  That file should
be /etc/sysconfig/lxc on the RH derived distributions as well (not so
sure about Suse).  That's going to need to be fixed as well.  That will
probably need to be autoconfigured somehow.

The config/init/sysvinit/lxc.in file references @SYSCONFDIR@/sysconfig
for that, which expands to /etc/sysconfig for us as the parent directory
containing the lxc init configuration file.  That makes it a bit
problematical on Ubuntu (and that script is used by the lxc.service
systemd unit file as well as the sysvinit lxc script).  So we've got the
reverse situation in there and I don't think we want two lxc init
configuration files.

I don't, right off the top of my head, see a clean way to handle that
unless we check both locations, since both conventions are based off of
@SYSCONFDIR@ in autoconf.  If we don't, we're going to be prone to
inconsistencies there as well.

I'm also curious why that particular helper ended up in /usr/share/lxc
instead of /usr/libexec/lxc where we have the other pieces of the
autostart helpers like the sysvinit script Dwight stuffed over there.
This seems to be a parallel init setup (lxc-net).  Not a critical point
but another inconsistency.

Looking at those firewall rules, I do still have some heartburn there.
They don't look very configurable the way they're set up.  That would
screw me up by blocking ssh from a container into the host, wouldn't it?
Only allow dhcp and dns with no provision for user defined rules?  When
I was doing similar things with IPSec and Openswan, we did all of our
changes in a specific chain we set up and then only added a single -j
jump into that chain.  That way, if someone modified the chain, we could
just arbitrarily flush our chain and drop the link into the chain, all
the while preserving an atomic add and removal of the chain
functionality.

I'll send in a patch for the lxc.spec.in problem shortly.  I have that
one pinned at least.  Minor patch, I just had to find it.

Regards,
Mike

  For example, my lxcbr0 on Fedora 20 is a bridge bridge (I happen to have
  LOTS of IPv4 address space so eth0 or whatever is bridged to the bridge
  in static networking), not a nat bridge.  I'm also not real sure how
  this use of iptables is going to play with firewalld on Fedora or CentOS
  7 either (or maybe Oracle 7 if they're using firewalld).  I have to
  examine that (and I'm not a big fan of firewalld).
  
  This also potentially impacts the default lxc.confg for Fedora, CentOS,
  Oracle, and possibly others, that had been depending on libvirt for
  setting up virbr0 as a natted bridge.  That's in configure with this:
  
  redhat|centos|fedora|oracle|oracleserver

Re: [lxc-devel] [PATCH 1/6] Move lxcbr0 setup logic into lxc.net script

2014-08-11 Thread Michael H. Warfield

On Mon, 2014-08-11 at 18:30 +, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@wittsend.com):
  On Mon, 2014-08-11 at 15:37 +, Serge Hallyn wrote:
   Quoting Michael H. Warfield (m...@wittsend.com):
On Thu, 2014-07-31 at 08:53 +0200, Martin Pitt wrote:
 Factor this out of the lxc-net.conf upstart job, so that it can be 
 used by
 init.d scripts and systemd units, too.

Crap.  Never fails.  I was in Europe when this came out.

Looking at lxc.net, I would say it's going to break some existing setups
(notably mine) where lxcbr0 is already setup.  Yes, we can set
LXC_BRIDGE to no but we should also include some autodetect logic such
that, if lxcbr0 already exists, this doesn't commit random acts of
terrorism.
  
   That logic should already be there.  If /sys/class/net/lxcbr0 already
   exists, then start will do nothing;  if /run/lxc/network_up does not
   exist then stop will do nothing.
  
  Yeah, I traced through that logic and finally realized that.  I'm a
  little nudgey about even calling stop from start in the case where
  the bridge already exists or when USE_LXC_BRIDGE is not true and then
  relying on stop to rely on the non-existence of network_up to exit
  without doing anything to the bridge.  If that's the case, why even call
  stop in the start function at all?  That had me confused.
 
 Yeah, that's an upstart-ism which doesn't belong in the script (and
 must continue to be done in upstart)
 
  I don't see the need for this logic at all in start:
  
  -- 
  if [ -d /sys/class/net/${LXC_BRIDGE} ]; then
  if [ ! -f ${varrun}/network_up ]; then
  # bridge exists, but we didn't start it
  stop;
  fi
  exit 0;
  fi
  -- 
  
  If this bridge exists and we didn't start it, why even attempt to stop

 We don't - the stop is to tell upstart not to continue running the
 job.  It doesn't belong in this script.

Interesting.  Many thanks for clarifying that.  If there are no
objections, then, I'll clean that up with the patch I'm working on now.

 -serge

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 1/6] Move lxcbr0 setup logic into lxc.net script

2014-08-11 Thread Michael H. Warfield

On Mon, 2014-08-11 at 18:57 +, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@wittsend.com):
  On Mon, 2014-08-11 at 18:30 +, Serge Hallyn wrote:
   Quoting Michael H. Warfield (m...@wittsend.com):
On Mon, 2014-08-11 at 15:37 +, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@wittsend.com):
  On Thu, 2014-07-31 at 08:53 +0200, Martin Pitt wrote:
   Factor this out of the lxc-net.conf upstart job, so that it can 
   be used by
   init.d scripts and systemd units, too.
  
  Crap.  Never fails.  I was in Europe when this came out.
  
  Looking at lxc.net, I would say it's going to break some existing 
  setups
  (notably mine) where lxcbr0 is already setup.  Yes, we can set
  LXC_BRIDGE to no but we should also include some autodetect logic 
  such
  that, if lxcbr0 already exists, this doesn't commit random acts of
  terrorism.

 That logic should already be there.  If /sys/class/net/lxcbr0 already
 exists, then start will do nothing;  if /run/lxc/network_up does not
 exist then stop will do nothing.

Yeah, I traced through that logic and finally realized that.  I'm a
little nudgey about even calling stop from start in the case where
the bridge already exists or when USE_LXC_BRIDGE is not true and then
relying on stop to rely on the non-existence of network_up to exit
without doing anything to the bridge.  If that's the case, why even call
stop in the start function at all?  That had me confused.
   
   Yeah, that's an upstart-ism which doesn't belong in the script (and
   must continue to be done in upstart)
   
I don't see the need for this logic at all in start:

-- 
if [ -d /sys/class/net/${LXC_BRIDGE} ]; then
if [ ! -f ${varrun}/network_up ]; then
# bridge exists, but we didn't start it
stop;
fi
exit 0;
fi
-- 

If this bridge exists and we didn't start it, why even attempt to stop
  
   We don't - the stop is to tell upstart not to continue running the
   job.  It doesn't belong in this script.
  
  Interesting.  Many thanks for clarifying that.  If there are no
  objections, then, I'll clean that up with the patch I'm working on now.

 That'd be great, thanks.  Indeed I think we want the actual script to
 do the minimal start/stop, and as you suggested perhaps make the
 iptables rules more configurable (though that may be biting off more
 than we can chew for now).

Yeah, I'll defer any iptables stuff for later.  Like I mentioned in my
earlier message, that will take looking at how that interacts with
firewalld.  I've also got to get back on that CentOS template and get
teh systemd stuff added to it.  That'll be in a couple of days.

 BTW - will you be at the lxc sprint in chicago next week?  That might be
 a good place to discuss making the network stuff more configurable.

I'm afraid not.  I'm still catching up from spending two weeks in Europe
and June has me committed to a few things.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH 3/6] Add systemd unit for lxc.net

2014-08-09 Thread Michael H. Warfield

On Thu, 2014-07-31 at 08:53 +0200, Martin Pitt wrote:
 This is the equivalent of the upstart lxc-net.conf to set up the LXC bridge.

 This also drops lxc.service from tarballs. It is built source which depends
 on configure options, so the statically shipped file will not work on most
 systems.

Looks like this patch missed adding lxc.net to lxc.spec for rpm
builds.  :-P  make rpm for 1.1.0-alpha1 is failing on Fedora 20.
Looking into this now.

 https://launchpad.net/bugs/1312532
 ---
  .gitignore |  1 +
  config/init/systemd/Makefile.am| 11 +++
  config/init/systemd/lxc-net.service.in | 10 ++
  config/init/systemd/lxc.service.in |  1 +
  configure.ac   |  1 +
  5 files changed, 20 insertions(+), 4 deletions(-)
  create mode 100644 config/init/systemd/lxc-net.service.in
 
 diff --git a/.gitignore b/.gitignore
 index 26011e4..e6de18f 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -114,6 +114,7 @@ config/lt*.m4
  config/bash/lxc
  config/init/systemd/lxc-autostart-helper
  config/init/systemd/lxc.service
 +config/init/systemd/lxc-net.service
  config/init/sysvinit/lxc
  
  doc/*.1
 diff --git a/config/init/systemd/Makefile.am b/config/init/systemd/Makefile.am
 index 3bd221f..ed1e4ef 100644
 --- a/config/init/systemd/Makefile.am
 +++ b/config/init/systemd/Makefile.am
 @@ -1,6 +1,8 @@
  EXTRA_DIST = \
   lxc-devsetup \
 - lxc.service
 + lxc.service.in \
 + lxc-net.service.in \
 + $(NULL)
  
  if INIT_SCRIPT_SYSTEMD
  lxc-autostart-helper: ../sysvinit/lxc.in $(top_builddir)/config.status
 @@ -11,14 +13,15 @@ lxc-autostart-helper: ../sysvinit/lxc.in 
 $(top_builddir)/config.status
$  $@-t   \
   chmod a+x $@-t\
   mv $@-t $@
 -BUILT_SOURCES = lxc-autostart-helper
 +BUILT_SOURCES = lxc-autostart-helper lxc.service lxc-net.service
  
 -install-systemd: lxc.service lxc-devsetup lxc-autostart-helper
 +install-systemd: lxc.service lxc-net.service lxc-devsetup 
 lxc-autostart-helper
   $(MKDIR_P) $(DESTDIR)$(SYSTEMD_UNIT_DIR)
 - $(INSTALL_DATA) lxc.service $(DESTDIR)$(SYSTEMD_UNIT_DIR)/
 + $(INSTALL_DATA) lxc.service lxc-net.service 
 $(DESTDIR)$(SYSTEMD_UNIT_DIR)/
  
  uninstall-systemd:
   rm -f $(DESTDIR)$(SYSTEMD_UNIT_DIR)/lxc.service
 + rm -f $(DESTDIR)$(SYSTEMD_UNIT_DIR)/lxc-net.service
   rmdir $(DESTDIR)$(SYSTEMD_UNIT_DIR) || :
  
  pkglibexec_SCRIPTS = lxc-devsetup lxc-autostart-helper
 diff --git a/config/init/systemd/lxc-net.service.in 
 b/config/init/systemd/lxc-net.service.in
 new file mode 100644
 index 000..37d1d69
 --- /dev/null
 +++ b/config/init/systemd/lxc-net.service.in
 @@ -0,0 +1,10 @@
 +[Unit]
 +Description=LXC network bridge setup
 +After=network.target
 +Before=lxc.service
 +
 +[Service]
 +Type=oneshot
 +RemainAfterExit=yes
 +ExecStart=@DATADIR@/lxc/lxc.net start
 +ExecStop=@DATADIR@/lxc/lxc.net stop
 diff --git a/config/init/systemd/lxc.service.in 
 b/config/init/systemd/lxc.service.in
 index 0a428a3..c7f2813 100644
 --- a/config/init/systemd/lxc.service.in
 +++ b/config/init/systemd/lxc.service.in
 @@ -1,6 +1,7 @@
  [Unit]
  Description=LXC Container Initialization and Autoboot Code
  After=syslog.target network.target
 +Wants=lxc-net.service
  
  [Service]
  Type=oneshot
 diff --git a/configure.ac b/configure.ac
 index ded4c48..c0d7015 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -613,6 +613,7 @@ AC_CONFIG_FILES([
   config/init/sysvinit/lxc
   config/init/systemd/Makefile
   config/init/systemd/lxc.service
 + config/init/systemd/lxc-net.service
   config/init/upstart/Makefile
   config/etc/Makefile
   config/templates/Makefile
 -- 
 2.0.1
 
 ___
 lxc-devel mailing list
 lxc-devel@lists.linuxcontainers.org
 http://lists.linuxcontainers.org/listinfo/lxc-devel
 

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [lxc-users] Compilation fails under Fedora 20

2014-08-09 Thread Michael H. Warfield

On Sat, 2014-08-09 at 09:26 -0400, Michael H. Warfield wrote:
 On Sat, 2014-08-09 at 02:39 -0400, CDR wrote:
  make rpm fails.

 Point of order...  Things like this should be reported to the lxc-devel
 list.  This is not a user issue but a development issue.

Ignore the above remark.  Now I see it was cross posted to lxc-devel.  I
just hadn't seen the cross post already.

Mike

 Looks like a patch Martin Pitt submitted back on July 31 missed adding
 lxc.net to lxc.spec.in.  His refactoring of the systemd logic needs
 careful checking out on Fedora as his work seems to primarily from the
 standpoint of systemd on Ubuntu, hence this problem where he missed a
 file.  I missed it when I built it because I have this in my .rpmmacros
 file:
 
 %_unpackaged_files_terminate_build 0
 
 Probably not a good idea with checking files for packaging but
 unfortunately necessary with working with development packages at times.
 
 Looking into it.
 
 Regards,
 Mike
 
  Processing files: lxc-debuginfo-1.1.0-0.1.alpha1.fc20.x86_64
  Provides: lxc-debuginfo = 1.1.0-0.1.alpha1.fc20 lxc-debuginfo(x86-64)
  = 1.1.0-0.1.alpha1.fc20
  Requires(rpmlib): rpmlib(FileDigests) = 4.6.0-1
  rpmlib(PayloadFilesHavePrefix) = 4.0-1 rpmlib(CompressedFileNames) =
  3.0.4-1
  Checking for unpackaged file(s): /usr/lib/rpm/check-files
  /root/rpmbuild/BUILDROOT/lxc-1.1.0-0.1.alpha1.fc20.x86_64
  error: Installed (but unpackaged) file(s) found:
 /usr/lib/systemd/system/lxc-net.service
  
  
  RPM build errors:
  File listed twice:
  /usr/lib64/python3.3/site-packages/_lxc-0.1-py3.3.egg-info
  File listed twice: 
  /usr/lib64/python3.3/site-packages/_lxc.cpython-33m.so
  File listed twice: /usr/lib64/python3.3/site-packages/lxc/__init__.py
  File listed twice: /usr/lib64/python3.3/site-packages/lxc/__pycache__
  File listed twice:
  /usr/lib64/python3.3/site-packages/lxc/__pycache__/__init__.cpython-33.pyc
  File listed twice:
  /usr/lib64/python3.3/site-packages/lxc/__pycache__/__init__.cpython-33.pyo
  File listed twice: /usr/libexec/lxc/lxc-autostart-helper
  File listed twice: /usr/libexec/lxc/lxc-devsetup
  File listed twice: /usr/libexec/lxc/lxc-user-nic
  Installed (but unpackaged) file(s) found:
 /usr/lib/systemd/system/lxc-net.service
  make: *** [rpm] Error 1
  ___
  lxc-users mailing list
  lxc-us...@lists.linuxcontainers.org
  http://lists.linuxcontainers.org/listinfo/lxc-users
  
 

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] clean autodev dir on container exit

2014-08-08 Thread Michael H. Warfield

 = MAXPATHLEN)
  return NULL;
   
  if ( 0 != access(tmp_path, F_OK) || 0 != stat(tmp_path, s) || 0 == 
  S_ISDIR(s.st_mode) ) {
  ret = mkdir(tmp_path, S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | 
  S_IXOTH);
  if ( ret ) {
  -   /* Something must have failed with the base_path...
  -* Maybe unpriv user.  Try user_path now... */
  +   /* Something must have failed with the dev_base_path...
  +* Maybe unpriv user.  Try dev_user_path now... */
  INFO(Setup in /dev/.lxc failed.  Trying 
  /dev/.lxc/user. );
   
  -   ret = snprintf(tmp_path, MAXPATHLEN, %s/%s.%016 
  PRIx64, user_path, name, hash);
  +   ret = snprintf(tmp_path, MAXPATHLEN, %s/%s.%016 
  PRIx64, dev_user_path, name, hash);
  if (ret  0 || ret = MAXPATHLEN)
  return NULL;
   
  @@ -1355,7 +1356,6 @@ static char *mk_devtmpfs(const char *name, char 
  *path, const char *lxcpath)
  return path;
   }
   
  -
   /*
* Do we want to add options for max size of /dev and a file to
* specify which devices to create?
  @@ -1482,6 +1482,60 @@ static int setup_autodev(const char *root)
   }
   
   /*
  + * Locate allocated devtmpfs mount and purge it.
  + * path lookup mostly taken from mk_devtmpfs
  + */
  +int lxc_delete_autodev(struct lxc_handler *handler)
  +{
  +   int ret;
  +   struct stat s;
  +   struct lxc_conf *lxc_conf = handler-conf;
  +   const char *name = handler-name;
  +   const char *lxcpath = handler-lxcpath;
  +   char tmp_path[MAXPATHLEN];
  +   uint64_t hash;
  +
  +   if ( lxc_conf-autodev = 0 )
  +   return 0;
  +
  +/*
  + * Use the same logic as mk_devtmpfs to compute condidate
  + * path for cleanup.
  + */
  +
  +   ret = snprintf(tmp_path, MAXPATHLEN, %s/%s, lxcpath, name);
  +   if (ret  0 || ret = MAXPATHLEN)
  +   return -1;
  +
  +   hash = fnv_64a_buf(tmp_path, ret, FNV1A_64_INIT);
  +
  +   /* Probe /dev/.lxc/container name.hash */
  +   ret = snprintf(tmp_path, MAXPATHLEN, %s/%s.%016 PRIx64, 
  dev_base_path, name, hash);
  +   if (ret  0 || ret = MAXPATHLEN)
  +   return -1;
  +
  +   if ( 0 != access(tmp_path, F_OK) || 0 != stat(tmp_path, s) || 0 == 
  S_ISDIR(s.st_mode) ) {
  +   /* Probe /dev/.lxc/user/container name.hash */
  +   ret = snprintf(tmp_path, MAXPATHLEN, %s/%s.%016 PRIx64, 
  dev_user_path, name, hash);
  +   if (ret  0 || ret = MAXPATHLEN)
  +   return -1;
  +
  +   if ( 0 != access(tmp_path, F_OK) || 0 != stat(tmp_path, s) || 
  0 == S_ISDIR(s.st_mode) ) {
  +   WARN(Failed to locate autodev /dev/.lxc and 
  /dev/.lxc/user. );
  +   return -1;
  +   }
  +}
  +
  +   /* Do the cleanup */
  +   INFO(Cleaning %s, tmp_path );
  +   if ( 0 != lxc_rmdir_onedev(tmp_path, NULL) ) {
  +   ERROR(Failed to cleanup autodev );
  +   }
  +
  +   return 0;
  +}
  +
  +/*
* I'll forgive you for asking whether all of this is needed :)  The
* answer is yes.
* pivot_root will fail if the new root, the put_old dir, or the parent
  diff --git a/src/lxc/conf.h b/src/lxc/conf.h
  index 615f276..99495f8 100644
  --- a/src/lxc/conf.h
  +++ b/src/lxc/conf.h
  @@ -388,6 +388,7 @@ extern int lxc_clear_hooks(struct lxc_conf *c, const 
  char *key);
   extern int lxc_clear_idmaps(struct lxc_conf *c);
   extern int lxc_clear_groups(struct lxc_conf *c);
   extern int lxc_clear_environment(struct lxc_conf *c);
  +extern int lxc_delete_autodev(struct lxc_handler *handler);
   
   extern int do_rootfs_setup(struct lxc_conf *conf, const char *name,
 const char *lxcpath);
  diff --git a/src/lxc/start.c b/src/lxc/start.c
  index bb136af..e1ee1ca 100644
  --- a/src/lxc/start.c
  +++ b/src/lxc/start.c
  @@ -477,6 +477,7 @@ static void lxc_fini(const char *name, struct 
  lxc_handler *handler)
   
  lxc_console_delete(handler-conf-console);
  lxc_delete_tty(handler-conf-tty_info);
  +   lxc_delete_autodev(handler);
  close(handler-conf-maincmd_fd);
  handler-conf-maincmd_fd = -1;
  free(handler-name);
  -- 
  2.0.3
 
 
 
 
  ___
  lxc-devel mailing list
  lxc-devel@lists.linuxcontainers.org
  http://lists.linuxcontainers.org/listinfo/lxc-devel
 

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] setpcap

2014-07-10 Thread Michael H. Warfield

Hey Serge,

On Thu, 2014-07-10 at 14:13 +, Serge Hallyn wrote:
 Hi Michael,

 https://bugs.launchpad.net/bugs/1339781 claims that

 creating a centos 7 container mostly worked using the template, but when
 it was launched, it was really slow to run through most of the sysinit
 tasks, and neither systemd-journald nor systemd-logind could start. The
 error was something like Error at step CAPABILITIES.

 and that allowing setpcap fixes it.  Two questions:

 1. Why is setpcap being dropped?  It only allows moving caps from bounding
 set to pI and dropping more caps from bounding set.  It actually seems less
 safe to disable it than to keep it enabled, as privileged tasks will be
 unable to set things up right and run under a bad config - a la sendmail
 capabilities bug.

 2. Would disabling the systemd journal service also fix this?

Right now, the biggest problem with the CentOS template is that it has
not been adapted for systemd yet.  There is some preliminary stuff in
there but I just got done downloading the CentOS 7 images and haven't
had time to even look at it yet and won't really have a chance over the
next couple of weeks.  I'm not surprised at all that there have been
gotcha's.  I'll have to merge some of Dwight's work with the Oracle
template and my stuff with the Fedora template into the CentOS template
for CentOS 7.

 -serge

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] LXC 1.0.4 has been released!

2014-07-05 Thread Michael H. Warfield

On Sat, 2014-07-05 at 10:04 +0200, Johannes Kastl wrote:
 On 18.06.2014 19:15 Michael H. Warfield wrote:
 
  I'd really like to look at your changes for lxc.spec but I may not
  be able to do much with it over the next week.  With luck, we may
  soon see OpenSUSE images for the download template.

 Forgot to mention:

 I had to fumble around with lua and lxc-top, as two lua-requirements
 are not available for openSUSE (I only found them for arch linux).

Yeah, I had noticed that I could get the lua components to build but
then they wouldn't run.  That's going to be similar to the situation on
RHEL / CentOS where certain dependencies aren't available.

 Regards,
 Johannes

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] LXC 1.0.4 has been released!

2014-07-05 Thread Michael H. Warfield

On Sat, 2014-07-05 at 10:09 -0400, Michael H. Warfield wrote:
 On Sat, 2014-07-05 at 10:03 +0200, Johannes Kastl wrote:
  Hi Michael,
  
  sorry for the delay, I was kinda busy...
  
  On 18.06.2014 19:15 Michael H. Warfield wrote:
  
   I'd really like to look at your changes for lxc.spec but I may not
   be able to do much with it over the next week.  With luck, we may
   soon see OpenSUSE images for the download template.
  
  You can find my working version here:
  
   https://build.opensuse.org/package/view_file/home:ojkastl_buildservice:LXC/lxc-vanilla/lxc.spec?expand=1
  
  I
   
  wanted to split up the changes into
  - needed for opensuse (different package names, etc.)
  and
  - unnecessary / wrong includes (at least according to the openSUSE
  build service).
 
 I'd like a little more detail about what you're referring to there.
 Specifically, if the openSUSE build service doesn't like something, I
 would like to see the specific errors that it's generating.
 
 In diffing your lxc.spec against the stock 1.0.4 build I see some
 changes that I would consider to be largely cosmetic like this:
 
 83c109,110
  Requires:   %{name} = %{version}-%{release}, pkgconfig
 ---
  Requires:   %{name} = %{version}-%{release}
  Requires:   pkgconfig
 
 and this:
 
 56,57c58,83
  Requires: openssl rsync
  BuildRequires: libcap libcap-devel docbook2X graphviz
 ---
  Requires: openssl 
  Requires: rsync
  
  %if 0%{?fedora} = 14 || 0%{?rhel} = 7
^^^

Testing builds for Oracle and CentOS 6 run fine without this restriction
on rhel level.  I'm lead to the conclusion that the above line is wrong.

I did have to install docbook2X and the lua components from EPEL for
both CentOS and Oracle, which may give some people some heartburn but
LXC is an EPEL component on those platforms anyways.  I was able to find
python3 for CentOS 6 from the SC (Software Collections) repository but
have not found it for Oracle yet.  That a significant source of
heartburn there but we loose too much functionality otherwise.

That was testing with the stock 1.0.4 lxc.spec file.  I'm continuing to
review your changes and seeing about integrating them.  Now that I've
regression tested my 4 rpm based test environments (Fedora, CentOS,
Oracle, openSUSE), I can start to look at integrating your changes.

  BuildRequires: libcap 
  BuildRequires: libcap-devel 
  BuildRequires: docbook2X 
  BuildRequires: graphviz
  %endif

Regards,
Mike

 Does that openSUSE build system require the BuildRequires be on unique
 individual lines?  I have no heartburn with breaking the lines into
 multiple BuildRequires but I am curious if it was necessary or merely a
 style issue.
 
 I'm also more than a little concerned about that later set of changes,
 since that materially impacts builds on CentOS 6 ({%rhel} == 6) and
 possibly Oracle 6 but I haven't tested those builds in a long while and
 I should probably test it.  It has known problems anyways due to lua and
 python3 missing.
 
 I have no problem with those changes and harmonizing the two in the
 sources would be fine.  Dwight should probably also review this as well
 as this could impact the Oracle builds.
 
  But atm I do not have time for this, I hope to come back to this issue
  in a few weeks. Sorry.
 
  Oh, and I have not updated the changelog (at the end of the file) to a
  recent version...
 
  Regards,
  Johannes
 
 Regards,
 Mike

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] LXC 1.0.4 has been released!

2014-07-05 Thread Michael H. Warfield

On Sat, 2014-07-05 at 10:03 +0200, Johannes Kastl wrote:
Hi Michael,

sorry for the delay, I was kinda busy...

On 18.06.2014 19:15 Michael H. Warfield wrote:

I'd really like to look at your changes for lxc.spec but I may not
be able to do much with it over the next week. With luck, we may
soon see OpenSUSE images for the download template.

You can find my working version here:

https://build.opensuse.org/package/view_file/home:ojkastl_buildservice:LXC/lxc-vanilla/lxc.spec?expand=1

we've definitely got some problems in there...

Why did you change the license from LGPLv2+ to LGPL-2.1. That change
would need to be justified and signed off on.

You've defined Source2 (lxc-createconfig.in) but then you don't do
anything with it. Having Source1 and Source2 is probably not going to
fly for the stock spec file since it's referencing files which are not
in the source tree. Are these files which should be added? If so, they
won't need additional Source definitions.

Some of your BuildRequire's look to be pretty generic (like
docbook-utils, libxslt, linux-glibc-devel, lsb-release). I'm looking
them over and, if they're valid under the other builds, maybe they
should be moved out of the Suse specific blocks and just be across the
board.

You disable building examples and then seem to copy examples
differently. Justification? Packaging differences on Suse? Necessary?
Is there some way to harmonize this?

Quite a few cosmetic changes (lxc - %{name}) which seem good. I have
no heartburn there.

You changed the mode on lxc-user-nic from 4111 to 0111 which seems bad
as it's suppose to be suid according to the man page.

I'm kinda confused about what you were doing with the lua stuff but, as
I didn't have that working, I'm looking deeper at that. You may have
fixed something in there, I just can't tell yet.

wanted to split up the changes into
- needed for opensuse (different package names, etc.)
and
- unnecessary / wrong includes (at least according to the openSUSE
build service).

But atm I do not have time for this, I hope to come back to this issue
in a few weeks. Sorry.

Oh, and I have not updated the changelog (at the end of the file) to a
recent version...

Regards,
Johannes

Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it!

signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] OpenSUSE seed containers...

2014-06-25 Thread Michael H. Warfield

On Wed, 2014-06-25 at 13:27 -0400, Stéphane Graber wrote:
 Thanks,

 I've been doing most of the required changes and I should have something
 sort-of working later today.

 However I've noticed a few things that probably should be fixed:
  - DHCP isn't starting automatically on eth0, I've got to call dhcpcd eth0

Hmmm...  Strange.  I thought I had fixed that in the template and had
tested it with a gen-3 container build under a gen-2 container build
from my gen-1 VM.  Check /etc/sysconfig/network-scripts/ifcfg-eth0 for
dhcp.  I'll look into that further.

  - The template doesn't allow you to specify the release or the architecture

That's something the SUSE gang needs to look at.  I'm not totally sure
zypper will support the cross arch option but, using a seed container
with an arch option set does work for building future containers of the
cross arch build.  Release should be doable, I just haven't looked at
it.

 The second point is the most important as I usually run the build
 environment on the native architecture of the host and then just pass
 the right architecture to the template.

Yeah, if that can be done, it would be great.  Most of my past
experience was with SUSE on a zLinux mainframe and not much help here.
Maybe Thorsten over at SUSE might have some input on this particular
aspect.

Thorsten?

Regards,
Mike

 On Wed, Jun 18, 2014 at 04:59:00PM -0400, Michael H. Warfield wrote:
  Stéphane (et al)...
  
  Here are the seed containers I promised you for OpenSUSE to go with that
  template update I shipped in a little bit ago.
  
  There are three sets of two tarballs (one each per arch i686 / x86_64).
  
  These two can be used to prime /var/cache/lxc
  
  opensuse-13.1-cache-i686.tgz
  opensuse-13.1-cache-x86_64.tgz
  
  These two are minimal OpenSUSE containers as created by lxc-create in an
  OpenSUSE container of the appropriate arch.  It includes the rootfs and
  config file.
  
  opensuse-13.1-i686.tgz
  opensuse-13.1-x86_64.tgz
  
  These two are beefed up containers with packages added that will allow
  these containers to build LXC rpms (they were used to create the
  lxc-1.0.4 rpm's I used to build these containers - some tinkering of
  lxc.spec was required), install the rpm's and use them to build
  additional opensuse containers from within the containers.
  
  opensuse-13.1-chainbuild-i686.tgz
  opensuse-13.1-chainbuild-x86_64.tgz
  
  The packages that were added to create the later two was as follows...
  
  zypper install sudo make rpmbuild libcap libcap-devel docbook2X graphviz 
  python3-devel lua-devel python3 vim yum /usr/bin/xsltproc build
  
  That will make rpm on a pre-autoconfed and pre-configured directory.
  I couldn't locate aclocal so autogen.sh hurled chunks on me.  But, I
  could do an autogen in the host and rsync the src directory to the
  containers so I really didn't care.
  
  The tarballs fairly large.  The first 4 are a little better than 110MB
  and the later two are just shy of 400MB each.
  
  A 3rd generation port run was performed on x86_64 confirming that the
  resulting containers would build containers identical to the containers
  from the 2nd generation port run.
  
  I'm copying them up to my web site now.  It's going to take some time so
  it may be hours before all 6 are present.  You can get a head start
  downloading as the cache set are there now.
  
  On IPv4:
  
  http://www.wittsend.com/lxc/
  
  On IPv6:
  
  http://www.ip6.wittsend.com/lxc/
  
  Regards,
  Mike
  -- 
  Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
 /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
 NIC whois: MHW9  | An optimist believes we live in the best of 
  all
   PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!
  
 
 
 
  ___
  lxc-devel mailing list
  lxc-devel@lists.linuxcontainers.org
  http://lists.linuxcontainers.org/listinfo/lxc-devel
 
 
 ___
 lxc-devel mailing list
 lxc-devel@lists.linuxcontainers.org
 http://lists.linuxcontainers.org/listinfo/lxc-devel

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

[lxc-devel] Getting back to the app armour profile subject...

Over on the users list was a thread started by Flo, Subject: Fedory 20
LXC fails to start on Ubuntu 14.04 host?

This gist of it was that systemd was segfaulting in a Fedora 20
container when run under Ubuntu 14.04 unless we set this:

lxc.aa_profile = unconfined

Thread got changed to Subject: apparmor profile for systemd containers
(WAS: Fedora container thinks it is not running)

Then someone tried some restricted profiles for systemd and had that
working.  There was also some discussion about working around the
problem using certain mount sets.  I think Serge expressed a reluctance
for using an unconfined profile but I also confirmed that setting an
aa_profile on a non-apparmour host will just be ignored and we could do
that with no harm done.

The gist of those threads is that the current app armour profile and
default configuration can lead to systemd segfaulting on container start
up.  Those threads did not seem to end with a resolution but a comment 
This appears to be a rather nasty bug... wrt lxc-attach.

My immediate inclination wrt system in Fedora, CentOS, and openSUSE
would be to unconditionally set lxc.aa_profile = unconfined until we
have a resolution, even though that's a (cough) suboptimal choice.  A
systemd aa_profile would be better albeit not best if it can be
handled with proper mounts.

Any thoughts on what direction and what solution we should opt for here?

As I'm running on a Fedora 20 host, I really can't test out these
choices, since I'm not experiencing these problems.

I AM, however, now experiencing an inverse problem running an Ubuntu
container on a Fedora host that I'll detail out in another thread.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

[lxc-devel] Problem with apt-get upgrade with Ubuntu container on Fedora host.

This feels like it's an app armour issue...  Posting to the -devel since
I don't think it's a user level problem.

I run an Ubuntu container on a Fedora 20 host and it's running fine.
The container was build on an Ubuntu host (really a container creating
a sub-container) with lxc-create ... -t ubuntu -- -r sid.

When I go to run apt-get update ; apt-get upgrade I get an error like
this:

root@Ubuntu-sid:~# apt-get upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
 libasn1-8-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but it 
is not installed
 libgssapi3-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but it 
is not installed
 libhcrypto4-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but 
it is not installed
 libheimntlm0-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but 
it is not installed
 libhx509-5-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but it 
is not installed
 libkrb5-26-heimdal : Depends: libroken18-heimdal (= 1.6~git20131117) but it 
is not installed
 libwind0-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but it 
is not installed
E: Unmet dependencies. Try using -f.

Ok...  So, I try that...

root@Ubuntu-sid:~# apt-get -f install
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Correcting dependencies... Done
The following extra packages will be installed:
  libroken18-heimdal
The following NEW packages will be installed:
  libroken18-heimdal
0 upgraded, 1 newly installed, 0 to remove and 22 not upgraded.
88 not fully installed or removed.
Need to get 0 B/40.0 kB of archives.
After this operation, 162 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
dpkg: error processing archive 
/var/cache/apt/archives/libroken18-heimdal_1.6~git20131207+dfsg-1ubuntu1_amd64.deb
 (--unpack):
 cannot get security labeling handle: No such file or directory
Errors were encountered while processing:
 
/var/cache/apt/archives/libroken18-heimdal_1.6~git20131207+dfsg-1ubuntu1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Ok...  Here's where I think it's an app armour thing.  That error
cannot get security labeling handle: No such file or directory can not
be good.

Any ideas what we have broken in here or what should be done about it to
make it work?

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Problem with apt-get upgrade with Ubuntu container on Fedora host.

On Thu, 2014-06-19 at 10:15 -0400, Michael H. Warfield wrote:
 This feels like it's an app armour issue...  Posting to the -devel since
 I don't think it's a user level problem.

 I run an Ubuntu container on a Fedora 20 host and it's running fine.
 The container was build on an Ubuntu host (really a container creating
 a sub-container) with lxc-create ... -t ubuntu -- -r sid.

Oh, correction...  That was mislabeled as sid.  I double checked the
os-release and I had build trusty and this particular one had been
built using the download template, not using a subcontainer after all.
I've got too many development and test containers and I'm starting to
get them mixed up.  My apologies.

 When I go to run apt-get update ; apt-get upgrade I get an error like
 this:
 
 root@Ubuntu-sid:~# apt-get upgrade
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 You might want to run 'apt-get -f install' to correct these.
 The following packages have unmet dependencies:
  libasn1-8-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but 
 it is not installed
  libgssapi3-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but 
 it is not installed
  libhcrypto4-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but 
 it is not installed
  libheimntlm0-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) 
 but it is not installed
  libhx509-5-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but 
 it is not installed
  libkrb5-26-heimdal : Depends: libroken18-heimdal (= 1.6~git20131117) but it 
 is not installed
  libwind0-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but it 
 is not installed
 E: Unmet dependencies. Try using -f.
 
 Ok...  So, I try that...
 
 root@Ubuntu-sid:~# apt-get -f install
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 Correcting dependencies... Done
 The following extra packages will be installed:
   libroken18-heimdal
 The following NEW packages will be installed:
   libroken18-heimdal
 0 upgraded, 1 newly installed, 0 to remove and 22 not upgraded.
 88 not fully installed or removed.
 Need to get 0 B/40.0 kB of archives.
 After this operation, 162 kB of additional disk space will be used.
 Do you want to continue? [Y/n] y
 dpkg: error processing archive 
 /var/cache/apt/archives/libroken18-heimdal_1.6~git20131207+dfsg-1ubuntu1_amd64.deb
  (--unpack):
  cannot get security labeling handle: No such file or directory
 Errors were encountered while processing:
  
 /var/cache/apt/archives/libroken18-heimdal_1.6~git20131207+dfsg-1ubuntu1_amd64.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 
 Ok...  Here's where I think it's an app armour thing.  That error
 cannot get security labeling handle: No such file or directory can not
 be good.
 
 Any ideas what we have broken in here or what should be done about it to
 make it work?
 
 Regards,
 Mike

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Problem with apt-get upgrade with Ubuntu container on Fedora host.

On Thu, 2014-06-19 at 10:19 -0400, Michael H. Warfield wrote:
 On Thu, 2014-06-19 at 10:15 -0400, Michael H. Warfield wrote:
  This feels like it's an app armour issue...  Posting to the -devel since
  I don't think it's a user level problem.
 
  I run an Ubuntu container on a Fedora 20 host and it's running fine.
  The container was build on an Ubuntu host (really a container creating
  a sub-container) with lxc-create ... -t ubuntu -- -r sid.
 
 Oh, correction...  That was mislabeled as sid.  I double checked the
 os-release and I had build trusty and this particular one had been
 built using the download template, not using a subcontainer after all.
 I've got too many development and test containers and I'm starting to
 get them mixed up.  My apologies.

More points on the curve.  When I shut the container down (over an ssh
connection) in order to rename it, I saw this error:

root@Ubuntu-sid:~# init 0
SELinux:  Could not open policy file = /etc/selinux/targeted/policy/policy.29: 
 No such file or directory
root@Ubuntu-sid:~# Connection to 2001:4830:3000:8200:207d:8eff:fe6f:3f79 closed 
by remote host.
Connection to 2001:4830:3000:8200:207d:8eff:fe6f:3f79 closed.

My host is in selinux permissive mode
and /etc/selinux/targeted/policy/policy.29 does exist in the host.
Ubuntu container trying to do something with selinux?

After the rename of the container I noticed this when I logged back
in...

[mhw@canyon ~]$ ssh ubuntu@2001:4830:3000:8200:7c32:63ff:fec2:24b
The authenticity of host '2001:4830:3000:8200:7c32:63ff:fec2:24b 
(2001:4830:3000:8200:7c32:63ff:fec2:24b)' can't be established.
ECDSA key fingerprint is c4:ee:a0:56:8d:f7:19:cb:10:b9:14:49:cf:da:46:6b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '2001:4830:3000:8200:7c32:63ff:fec2:24b' (ECDSA) to 
the list of known hosts.
ubuntu@2001:4830:3000:8200:7c32:63ff:fec2:24b's password: 
X11 forwarding request failed on channel 0
Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.14.5-200.fc20.x86_64 x86_64)

 * Documentation:  https://help.ubuntu.com/
Unable to get valid context for ubuntu
Last login: Thu Jun 19 14:25:07 2014 from canyon.ip6.wittsend.com
ubuntu@Ubuntu-trusty:~$ 

In addition to the fact that the download template didn't create the
container with persistent mac addresses (the reason for the ssh
authenticity warnings) I got an Unable to get valid context for ubuntu
error when logging in.

I'll probably try putting the host into selinux disabled mode and try
again.

Regards,
Mike

  When I go to run apt-get update ; apt-get upgrade I get an error like
  this:
  
  root@Ubuntu-sid:~# apt-get upgrade
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  You might want to run 'apt-get -f install' to correct these.
  The following packages have unmet dependencies:
   libasn1-8-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but 
  it is not installed
   libgssapi3-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) 
  but it is not installed
   libhcrypto4-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) 
  but it is not installed
   libheimntlm0-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) 
  but it is not installed
   libhx509-5-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) 
  but it is not installed
   libkrb5-26-heimdal : Depends: libroken18-heimdal (= 1.6~git20131117) but 
  it is not installed
   libwind0-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) but 
  it is not installed
  E: Unmet dependencies. Try using -f.
  
  Ok...  So, I try that...
  
  root@Ubuntu-sid:~# apt-get -f install
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Correcting dependencies... Done
  The following extra packages will be installed:
libroken18-heimdal
  The following NEW packages will be installed:
libroken18-heimdal
  0 upgraded, 1 newly installed, 0 to remove and 22 not upgraded.
  88 not fully installed or removed.
  Need to get 0 B/40.0 kB of archives.
  After this operation, 162 kB of additional disk space will be used.
  Do you want to continue? [Y/n] y
  dpkg: error processing archive 
  /var/cache/apt/archives/libroken18-heimdal_1.6~git20131207+dfsg-1ubuntu1_amd64.deb
   (--unpack):
   cannot get security labeling handle: No such file or directory
  Errors were encountered while processing:
   
  /var/cache/apt/archives/libroken18-heimdal_1.6~git20131207+dfsg-1ubuntu1_amd64.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  
  Ok...  Here's where I think it's an app armour thing.  That error
  cannot get security labeling handle: No such file or directory can not
  be good.
  
  Any ideas what we have broken in here or what should be done about it to
  make it work?
  
  Regards,
  Mike
 

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http

Re: [lxc-devel] Problem with apt-get upgrade with Ubuntu container on Fedora host.

On Thu, 2014-06-19 at 10:48 -0400, Stéphane Graber wrote:
 On Thu, Jun 19, 2014 at 10:35:50AM -0400, Michael H. Warfield wrote:
  On Thu, 2014-06-19 at 10:19 -0400, Michael H. Warfield wrote:
   On Thu, 2014-06-19 at 10:15 -0400, Michael H. Warfield wrote:
This feels like it's an app armour issue...  Posting to the -devel since
I don't think it's a user level problem.
   
I run an Ubuntu container on a Fedora 20 host and it's running fine.
The container was build on an Ubuntu host (really a container creating
a sub-container) with lxc-create ... -t ubuntu -- -r sid.
   
   Oh, correction...  That was mislabeled as sid.  I double checked the
   os-release and I had build trusty and this particular one had been
   built using the download template, not using a subcontainer after all.
   I've got too many development and test containers and I'm starting to
   get them mixed up.  My apologies.
 
 Oh, I should have read the whole thread before replying to the first e-mail :)
 
  More points on the curve.  When I shut the container down (over an ssh
  connection) in order to rename it, I saw this error:
  
  root@Ubuntu-sid:~# init 0
  SELinux:  Could not open policy file = 
  /etc/selinux/targeted/policy/policy.29:  No such file or directory
  root@Ubuntu-sid:~# Connection to 2001:4830:3000:8200:207d:8eff:fe6f:3f79 
  closed by remote host.
  Connection to 2001:4830:3000:8200:207d:8eff:fe6f:3f79 closed.
  
  My host is in selinux permissive mode
  and /etc/selinux/targeted/policy/policy.29 does exist in the host.
  Ubuntu container trying to do something with selinux?
  
  After the rename of the container I noticed this when I logged back
  in...
  
  [mhw@canyon ~]$ ssh ubuntu@2001:4830:3000:8200:7c32:63ff:fec2:24b
  The authenticity of host '2001:4830:3000:8200:7c32:63ff:fec2:24b 
  (2001:4830:3000:8200:7c32:63ff:fec2:24b)' can't be established.
  ECDSA key fingerprint is c4:ee:a0:56:8d:f7:19:cb:10:b9:14:49:cf:da:46:6b.
  Are you sure you want to continue connecting (yes/no)? yes
  Warning: Permanently added '2001:4830:3000:8200:7c32:63ff:fec2:24b' (ECDSA) 
  to the list of known hosts.
  ubuntu@2001:4830:3000:8200:7c32:63ff:fec2:24b's password: 
  X11 forwarding request failed on channel 0
  Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.14.5-200.fc20.x86_64 x86_64)
  
   * Documentation:  https://help.ubuntu.com/
  Unable to get valid context for ubuntu
  Last login: Thu Jun 19 14:25:07 2014 from canyon.ip6.wittsend.com
  ubuntu@Ubuntu-trusty:~$ 
  
  In addition to the fact that the download template didn't create the
  container with persistent mac addresses (the reason for the ssh
  authenticity warnings) I got an Unable to get valid context for ubuntu
  error when logging in.
  
  I'll probably try putting the host into selinux disabled mode and try
  again.

 Yeah, that'd be interesting as a test.

 Ubuntu doesn't use SELinux, though a lot of stuff we ship has some kind
 of support for it, so you may well be getting into odd corner cases,
 running Ubuntu on a SELinux enabled machine.

That does appear to be the case.  By putting the host into selinux
disabled mode, the login error disappears and the apt-get install -f
proceeded properly.

That's a nasty corner case.  Permissive mode has a policy loaded into
the kernel but is not enforcing anything.  Definitely a skew between
what the host has set up and what the apps in the container think they
should be doing.  Guess that makes it an selinux problem.

Thanks!

Regards,
Mike

  Regards,
  Mike
  
When I go to run apt-get update ; apt-get upgrade I get an error like
this:

root@Ubuntu-sid:~# apt-get upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
 libasn1-8-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) 
but it is not installed
 libgssapi3-heimdal : Depends: libroken18-heimdal (= 
1.4.0+git20110226) but it is not installed
 libhcrypto4-heimdal : Depends: libroken18-heimdal (= 
1.4.0+git20110226) but it is not installed
 libheimntlm0-heimdal : Depends: libroken18-heimdal (= 
1.4.0+git20110226) but it is not installed
 libhx509-5-heimdal : Depends: libroken18-heimdal (= 
1.4.0+git20110226) but it is not installed
 libkrb5-26-heimdal : Depends: libroken18-heimdal (= 1.6~git20131117) 
but it is not installed
 libwind0-heimdal : Depends: libroken18-heimdal (= 1.4.0+git20110226) 
but it is not installed
E: Unmet dependencies. Try using -f.

Ok...  So, I try that...

root@Ubuntu-sid:~# apt-get -f install
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Correcting dependencies... Done
The following extra packages will be installed:
  libroken18-heimdal
The following NEW packages

Re: [lxc-devel] Problem with apt-get upgrade with Ubuntu container on Fedora host.

On Thu, 2014-06-19 at 10:58 -0400, Michael H. Warfield wrote:
 On Thu, 2014-06-19 at 10:48 -0400, Stéphane Graber wrote:
  On Thu, Jun 19, 2014 at 10:35:50AM -0400, Michael H. Warfield wrote:
   On Thu, 2014-06-19 at 10:19 -0400, Michael H. Warfield wrote:
On Thu, 2014-06-19 at 10:15 -0400, Michael H. Warfield wrote:
 This feels like it's an app armour issue...  Posting to the -devel 
 since
 I don't think it's a user level problem.

 I run an Ubuntu container on a Fedora 20 host and it's running fine.
 The container was build on an Ubuntu host (really a container 
 creating
 a sub-container) with lxc-create ... -t ubuntu -- -r sid.

Oh, correction...  That was mislabeled as sid.  I double checked the
os-release and I had build trusty and this particular one had been
built using the download template, not using a subcontainer after all.
I've got too many development and test containers and I'm starting to
get them mixed up.  My apologies.
  
  Oh, I should have read the whole thread before replying to the first e-mail 
  :)
  
   More points on the curve.  When I shut the container down (over an ssh
   connection) in order to rename it, I saw this error:
   
   root@Ubuntu-sid:~# init 0
   SELinux:  Could not open policy file = 
   /etc/selinux/targeted/policy/policy.29:  No such file or directory
   root@Ubuntu-sid:~# Connection to 2001:4830:3000:8200:207d:8eff:fe6f:3f79 
   closed by remote host.
   Connection to 2001:4830:3000:8200:207d:8eff:fe6f:3f79 closed.
   
   My host is in selinux permissive mode
   and /etc/selinux/targeted/policy/policy.29 does exist in the host.
   Ubuntu container trying to do something with selinux?
   
   After the rename of the container I noticed this when I logged back
   in...
   
   [mhw@canyon ~]$ ssh ubuntu@2001:4830:3000:8200:7c32:63ff:fec2:24b
   The authenticity of host '2001:4830:3000:8200:7c32:63ff:fec2:24b 
   (2001:4830:3000:8200:7c32:63ff:fec2:24b)' can't be established.
   ECDSA key fingerprint is c4:ee:a0:56:8d:f7:19:cb:10:b9:14:49:cf:da:46:6b.
   Are you sure you want to continue connecting (yes/no)? yes
   Warning: Permanently added '2001:4830:3000:8200:7c32:63ff:fec2:24b' 
   (ECDSA) to the list of known hosts.
   ubuntu@2001:4830:3000:8200:7c32:63ff:fec2:24b's password: 
   X11 forwarding request failed on channel 0
   Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.14.5-200.fc20.x86_64 x86_64)
   
* Documentation:  https://help.ubuntu.com/
   Unable to get valid context for ubuntu
   Last login: Thu Jun 19 14:25:07 2014 from canyon.ip6.wittsend.com
   ubuntu@Ubuntu-trusty:~$ 
   
   In addition to the fact that the download template didn't create the
   container with persistent mac addresses (the reason for the ssh
   authenticity warnings) I got an Unable to get valid context for ubuntu
   error when logging in.
   
   I'll probably try putting the host into selinux disabled mode and try
   again.

  Yeah, that'd be interesting as a test.

  Ubuntu doesn't use SELinux, though a lot of stuff we ship has some kind
  of support for it, so you may well be getting into odd corner cases,
  running Ubuntu on a SELinux enabled machine.

 That does appear to be the case.  By putting the host into selinux
 disabled mode, the login error disappears and the apt-get install -f
 proceeded properly.

 That's a nasty corner case.  Permissive mode has a policy loaded into
 the kernel but is not enforcing anything.  Definitely a skew between
 what the host has set up and what the apps in the container think they
 should be doing.  Guess that makes it an selinux problem.

And what you DO NOT WANT TO DO is go the other way!  Trying to run a
double check, I put the host back in selinux permissive mode.  That
resulted in a 1 hour selinux filesystem relabel (Ok, it's a 5 TB file
system all totaled) but that relabel did something to that container and
it's no longer functional.  WTH?  It only comes up far enough to log in
from the lxc-start console (no sshd and no lxc-console).

I was going to try setting /etc/selinux/configure in the container to
disabled to see if that helps (we disable it in Fedora containers) but
never got that far.

Burned it down and build a new one and the host is back in selinux
disabled mode.  Everything looking good.  That was nasty.

Regards,
Mike

   Regards,
   Mike
   
 When I go to run apt-get update ; apt-get upgrade I get an error 
 like
 this:
 
 root@Ubuntu-sid:~# apt-get upgrade
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 You might want to run 'apt-get -f install' to correct these.
 The following packages have unmet dependencies:
  libasn1-8-heimdal : Depends: libroken18-heimdal (= 
 1.4.0+git20110226) but it is not installed
  libgssapi3-heimdal : Depends: libroken18-heimdal (= 
 1.4.0+git20110226) but it is not installed
  libhcrypto4-heimdal : Depends: libroken18

Re: [lxc-devel] LXC 1.0.4 has been released!

On Sat, 2014-06-14 at 20:12 +0200, Johannes Kastl wrote:
 On 14.06.2014 15:58 Michael H. Warfield wrote:

  I assume you mean the LXC upstream, meaning the lxc.spec.in file we
  have in under our source control as opposed to the one Fedora uses
  in their project.  So why not submit those changes for openSUSE to
  us for incorporation, maintenance and comment?

 Actually, that's my plan, but therefore I wanted to check that the
 spec including my modifications does still build on other
 distributions. And Fedora was easyily available on the openSUSE Build
 Service... ;-)

In addition to Fedora and CentOS, I'm now building rpms under SUSE 13.1,
both i686 and x86_64.  As you noted, some minor changes to the lxc.spec
file where required and I'm sure I didn't get all of them.  I had to
delete one BuildRequires: systemd-units and a couple of lua-requires
but lxc-top is not working, so that needs some work.  Seems to be a
missing module somewhere but is not needed for my purposes.  This gets
me to the point where I can run lxc-create from 1.0.4+ on SUSE for
building more SUSE containers, which I should be feeding over to
Stéphane in the next day or so along with some patches to the
lxc-opensuse template.

What I've done was to build two VirtualBox VM's (yes I could have used
KVM but I already had VirtualBox on this system) for the two openSUSE
13.1 arch's.  In them, I built them up with all the build pieces needed
and built the LXC 1.0.4 rpms and installed them.  From that, I built
openSUSE containers, which I transported to the host system.

At that point, I no longer needed the VirtualBox VMs.  The openSUSE
containers run just fine with some network fine tuning and I've been
able to reproduce the process of building the LXC rpms and building
OpenSUSE containers within containers which can then be immediately
accessed from the host.  Boostrap complete.

I'd really like to look at your changes for lxc.spec but I may not be
able to do much with it over the next week.  With luck, we may soon see
OpenSUSE images for the download template.

 Regards,
 Johannes

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

[lxc-devel] [PATCH] Updated lxc-opensuse for common configuration changes.

Updated lxc-opensuse for common configuration changes.

Updated the lxc-opensuse template for the changes for the common
configuration used by the download template.  Changed the default
network mode in the container to dhcp.

Signed-off-by: Michael H. Warfield m...@wittsend.com
---
 config/templates/Makefile.am |   2 +
 config/templates/opensuse.common.conf.in |  47 
 config/templates/opensuse.userns.conf.in |  20 ++
 configure.ac |   2 +
 templates/lxc-opensuse.in| 119 ++-
 5 files changed, 141 insertions(+), 49 deletions(-)
 create mode 100644 config/templates/opensuse.common.conf.in
 create mode 100644 config/templates/opensuse.userns.conf.in

diff --git a/config/templates/Makefile.am b/config/templates/Makefile.am
index 47969a9..d0b1c87 100644
--- a/config/templates/Makefile.am
+++ b/config/templates/Makefile.am
@@ -10,6 +10,8 @@ templatesconfig_DATA = \
gentoo.common.conf \
gentoo.moresecure.conf \
gentoo.userns.conf \
+   opensuse.common.conf \
+   opensuse.userns.conf \
oracle.common.conf \
oracle.userns.conf \
plamo.common.conf \
diff --git a/config/templates/opensuse.common.conf.in 
b/config/templates/opensuse.common.conf.in
new file mode 100644
index 000..1585fb8
--- /dev/null
+++ b/config/templates/opensuse.common.conf.in
@@ -0,0 +1,47 @@
+lxc.autodev = 1
+lxc.devttydir = lxc
+lxc.tty = 4
+lxc.pts = 1024
+
+# Mount entries
+# lxc.mount.auto = proc:mixed sys:ro
+
+# Ensure hostname is changed on clone
+lxc.hook.clone = @LXCHOOKDIR@/clonehostname
+
+# Capabilities
+# Uncomment these if you don't run anything that needs the capability, and
+# would like the container to run with less privilege.
+#
+# Dropping sys_admin disables container root from doing a lot of things
+# that could be bad like re-mounting lxc fstab entries rw for example,
+# but also disables some useful things like being able to nfs mount, and
+# things that are already namespaced with ns_capable() kernel checks, like
+# hostname(1).
+# lxc.cap.drop = sys_admin
+# lxc.cap.drop = net_raw  # breaks dhcp/ping
+# lxc.cap.drop = setgid   # breaks login (initgroups/setgroups)
+# lxc.cap.drop = dac_read_search  # breaks login (pam unix_chkpwd)
+# lxc.cap.drop = setuid   # breaks sshd,nfs statd
+# lxc.cap.drop = audit_control# breaks sshd (set_loginuid failed)
+# lxc.cap.drop = audit_write
+# lxc.cap.drop = setpcap  # big big login delays in Fedora 20 systemd
+# lxc.cap.drop = setfcap
+#
+lxc.cap.drop = mac_admin mac_override
+lxc.cap.drop = sys_module sys_nice sys_pacct
+lxc.cap.drop = sys_rawio sys_time
+
+# Control Group devices: all denied except those whitelisted
+lxc.cgroup.devices.deny = a
+# Allow any mknod (but not reading/writing the node)
+lxc.cgroup.devices.allow = c *:* m
+lxc.cgroup.devices.allow = b *:* m
+lxc.cgroup.devices.allow = c 1:3 rwm   # /dev/null
+lxc.cgroup.devices.allow = c 1:5 rwm   # /dev/zero
+lxc.cgroup.devices.allow = c 1:7 rwm   # /dev/full
+lxc.cgroup.devices.allow = c 5:0 rwm   # /dev/tty
+lxc.cgroup.devices.allow = c 1:8 rwm   # /dev/random
+lxc.cgroup.devices.allow = c 1:9 rwm   # /dev/urandom
+lxc.cgroup.devices.allow = c 136:* rwm # /dev/tty[1-4] ptys and lxc console
+lxc.cgroup.devices.allow = c 5:2 rwm   # /dev/ptmx pty master
diff --git a/config/templates/opensuse.userns.conf.in 
b/config/templates/opensuse.userns.conf.in
new file mode 100644
index 000..f6de0e9
--- /dev/null
+++ b/config/templates/opensuse.userns.conf.in
@@ -0,0 +1,20 @@
+# Taken from the oracle.userns.conf.in
+# CAP_SYS_ADMIN in init-user-ns is required for cgroup.devices
+lxc.cgroup.devices.deny =
+lxc.cgroup.devices.allow =
+
+# We can't move bind-mounts, so don't use /dev/lxc/
+lxc.devttydir =
+
+# Extra bind-mounts for userns
+lxc.mount.entry = /dev/console dev/console none bind,create=file 0 0
+lxc.mount.entry = /dev/full dev/full none bind,create=file 0 0
+lxc.mount.entry = /dev/null dev/null none bind,create=file 0 0
+lxc.mount.entry = /dev/random dev/random none bind,create=file 0 0
+lxc.mount.entry = /dev/tty dev/tty none bind,create=file 0 0
+lxc.mount.entry = /dev/urandom dev/urandom none bind,create=file 0 0
+lxc.mount.entry = /dev/zero dev/zero none bind,create=file 0 0
+
+# Extra fstab entries as mountall can't mount those by itself
+lxc.mount.entry = /sys/firmware/efi/efivars sys/firmware/efi/efivars none 
bind,optional 0 0
+lxc.mount.entry = /proc/sys/fs/binfmt_misc proc/sys/fs/binfmt_misc none 
bind,optional 0 0
diff --git a/configure.ac b/configure.ac
index ab6c481..be54043 100644
--- a/configure.ac
+++ b/configure.ac
@@ -590,6 +590,8 @@ AC_CONFIG_FILES([
config/templates/gentoo.common.conf
config/templates/gentoo.moresecure.conf
config/templates/gentoo.userns.conf
+   config/templates/opensuse.common.conf
+   config/templates/opensuse.userns.conf
config/templates

[lxc-devel] OpenSUSE seed containers...

Stéphane (et al)...

Here are the seed containers I promised you for OpenSUSE to go with that
template update I shipped in a little bit ago.

There are three sets of two tarballs (one each per arch i686 / x86_64).

These two can be used to prime /var/cache/lxc

opensuse-13.1-cache-i686.tgz
opensuse-13.1-cache-x86_64.tgz

These two are minimal OpenSUSE containers as created by lxc-create in an
OpenSUSE container of the appropriate arch.  It includes the rootfs and
config file.

opensuse-13.1-i686.tgz
opensuse-13.1-x86_64.tgz

These two are beefed up containers with packages added that will allow
these containers to build LXC rpms (they were used to create the
lxc-1.0.4 rpm's I used to build these containers - some tinkering of
lxc.spec was required), install the rpm's and use them to build
additional opensuse containers from within the containers.

opensuse-13.1-chainbuild-i686.tgz
opensuse-13.1-chainbuild-x86_64.tgz

The packages that were added to create the later two was as follows...

zypper install sudo make rpmbuild libcap libcap-devel docbook2X graphviz 
python3-devel lua-devel python3 vim yum /usr/bin/xsltproc build

That will make rpm on a pre-autoconfed and pre-configured directory.
I couldn't locate aclocal so autogen.sh hurled chunks on me.  But, I
could do an autogen in the host and rsync the src directory to the
containers so I really didn't care.

The tarballs fairly large.  The first 4 are a little better than 110MB
and the later two are just shy of 400MB each.

A 3rd generation port run was performed on x86_64 confirming that the
resulting containers would build containers identical to the containers
from the 2nd generation port run.

I'm copying them up to my web site now.  It's going to take some time so
it may be hours before all 6 are present.  You can get a head start
downloading as the cache set are there now.

On IPv4:

http://www.wittsend.com/lxc/

On IPv6:

http://www.ip6.wittsend.com/lxc/

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] Updated lxc-opensuse for common configuration changes.

On Wed, 2014-06-18 at 16:48 -0400, Stéphane Graber wrote:
 On Wed, Jun 18, 2014 at 03:31:44PM -0400, Michael H. Warfield wrote:
  Updated lxc-opensuse for common configuration changes.
  
  Updated the lxc-opensuse template for the changes for the common
  configuration used by the download template.  Changed the default
  network mode in the container to dhcp.
  
  Signed-off-by: Michael H. Warfield m...@wittsend.com

 Acked-by: Stéphane Graber stgra...@ubuntu.com

 When applying I'll bump the lxc-download compat level to 2 since
 existing LXC 1.0.x installs will be lacking the opensuse.*.conf files
 and so won't be able to create OpenSUSE containers.

Cool.

 I also really wish we could get rid of all that network stuff in the
 templates and just rely on distros shipping a reasonable default.conf
 using the template-based hwaddr setting...

I know.  Concur.  We can dream and we can wish.

Regards,
Mike

  ---
   config/templates/Makefile.am |   2 +
   config/templates/opensuse.common.conf.in |  47 
   config/templates/opensuse.userns.conf.in |  20 ++
   configure.ac |   2 +
   templates/lxc-opensuse.in| 119 
  ++-
   5 files changed, 141 insertions(+), 49 deletions(-)
   create mode 100644 config/templates/opensuse.common.conf.in
   create mode 100644 config/templates/opensuse.userns.conf.in
  
  diff --git a/config/templates/Makefile.am b/config/templates/Makefile.am
  index 47969a9..d0b1c87 100644
  --- a/config/templates/Makefile.am
  +++ b/config/templates/Makefile.am
  @@ -10,6 +10,8 @@ templatesconfig_DATA = \
  gentoo.common.conf \
  gentoo.moresecure.conf \
  gentoo.userns.conf \
  +   opensuse.common.conf \
  +   opensuse.userns.conf \
  oracle.common.conf \
  oracle.userns.conf \
  plamo.common.conf \
  diff --git a/config/templates/opensuse.common.conf.in 
  b/config/templates/opensuse.common.conf.in
  new file mode 100644
  index 000..1585fb8
  --- /dev/null
  +++ b/config/templates/opensuse.common.conf.in
  @@ -0,0 +1,47 @@
  +lxc.autodev = 1
  +lxc.devttydir = lxc
  +lxc.tty = 4
  +lxc.pts = 1024
  +
  +# Mount entries
  +# lxc.mount.auto = proc:mixed sys:ro
  +
  +# Ensure hostname is changed on clone
  +lxc.hook.clone = @LXCHOOKDIR@/clonehostname
  +
  +# Capabilities
  +# Uncomment these if you don't run anything that needs the capability, and
  +# would like the container to run with less privilege.
  +#
  +# Dropping sys_admin disables container root from doing a lot of things
  +# that could be bad like re-mounting lxc fstab entries rw for example,
  +# but also disables some useful things like being able to nfs mount, and
  +# things that are already namespaced with ns_capable() kernel checks, like
  +# hostname(1).
  +# lxc.cap.drop = sys_admin
  +# lxc.cap.drop = net_raw  # breaks dhcp/ping
  +# lxc.cap.drop = setgid   # breaks login (initgroups/setgroups)
  +# lxc.cap.drop = dac_read_search  # breaks login (pam unix_chkpwd)
  +# lxc.cap.drop = setuid   # breaks sshd,nfs statd
  +# lxc.cap.drop = audit_control# breaks sshd (set_loginuid failed)
  +# lxc.cap.drop = audit_write
  +# lxc.cap.drop = setpcap  # big big login delays in Fedora 20 
  systemd
  +# lxc.cap.drop = setfcap
  +#
  +lxc.cap.drop = mac_admin mac_override
  +lxc.cap.drop = sys_module sys_nice sys_pacct
  +lxc.cap.drop = sys_rawio sys_time
  +
  +# Control Group devices: all denied except those whitelisted
  +lxc.cgroup.devices.deny = a
  +# Allow any mknod (but not reading/writing the node)
  +lxc.cgroup.devices.allow = c *:* m
  +lxc.cgroup.devices.allow = b *:* m
  +lxc.cgroup.devices.allow = c 1:3 rwm   # /dev/null
  +lxc.cgroup.devices.allow = c 1:5 rwm   # /dev/zero
  +lxc.cgroup.devices.allow = c 1:7 rwm   # /dev/full
  +lxc.cgroup.devices.allow = c 5:0 rwm   # /dev/tty
  +lxc.cgroup.devices.allow = c 1:8 rwm   # /dev/random
  +lxc.cgroup.devices.allow = c 1:9 rwm   # /dev/urandom
  +lxc.cgroup.devices.allow = c 136:* rwm # /dev/tty[1-4] ptys and lxc 
  console
  +lxc.cgroup.devices.allow = c 5:2 rwm   # /dev/ptmx pty master
  diff --git a/config/templates/opensuse.userns.conf.in 
  b/config/templates/opensuse.userns.conf.in
  new file mode 100644
  index 000..f6de0e9
  --- /dev/null
  +++ b/config/templates/opensuse.userns.conf.in
  @@ -0,0 +1,20 @@
  +# Taken from the oracle.userns.conf.in
  +# CAP_SYS_ADMIN in init-user-ns is required for cgroup.devices
  +lxc.cgroup.devices.deny =
  +lxc.cgroup.devices.allow =
  +
  +# We can't move bind-mounts, so don't use /dev/lxc/
  +lxc.devttydir =
  +
  +# Extra bind-mounts for userns
  +lxc.mount.entry = /dev/console dev/console none bind,create=file 0 0
  +lxc.mount.entry = /dev/full dev/full none bind,create=file 0 0
  +lxc.mount.entry = /dev/null dev/null none bind,create=file 0 0
  +lxc.mount.entry = /dev/random dev/random none bind,create=file 0 0

Re: [lxc-devel] [PATCH] lxc-autostart: Respect -P

2014-06-17 Thread Michael H. Warfield

On Tue, 2014-06-17 at 11:31 -0400, Stéphane Graber wrote:
 -P was only used for log setup and not when retrieving the container list.
 
 Signed-off-by: Stéphane Graber stgra...@ubuntu.com
Acked-by: Michael H. Warfield m...@wittsend.com

 ---
  src/lxc/lxc_autostart.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/lxc/lxc_autostart.c b/src/lxc/lxc_autostart.c
 index 920de67..d0e3bfa 100644
 --- a/src/lxc/lxc_autostart.c
 +++ b/src/lxc/lxc_autostart.c
 @@ -343,7 +343,7 @@ int main(int argc, char *argv[])
   return 1;
   lxc_log_options_no_override();
  
 - count = list_defined_containers(NULL, NULL, containers);
 + count = list_defined_containers(my_args.lxcpath[0], NULL, containers);
  
   if (count  0)
   return 1;
 -- 
 1.9.1
 
 ___
 lxc-devel mailing list
 lxc-devel@lists.linuxcontainers.org
 http://lists.linuxcontainers.org/listinfo/lxc-devel
 

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] LXC 1.0.4 has been released!

2014-06-13 Thread Michael H. Warfield

On Fri, 2014-06-13 at 21:05 +0200, Johannes Kastl wrote:
Hi everyone,

On 13.06.2014 19:23 Stéphane Graber wrote:
On Fri, Jun 13, 2014 at 01:17:50PM -0400, Stéphane Graber wrote:
The fourth LXC 1.0 bugfix release is now out!

I am still trying to get lxc 1.0.4 to build for Fedora on the openSUSE

I'm confused on what you're trying to do. You're trying to build the
Fedora installation RPM's on openSUSE? Or are you trying to build a
Fedora Container on openSUSE?

Buildservice:

This is the build-log:
https://build.opensuse.org/package/live_build_log/home:ojkastl_buildservice:LXC/lxc-vanilla/Fedora_19/x86_64

The

error message is:
/bin/mkdir -p '/usr/share/lxc/config' /bin/mkdir: cannot create
directory '/usr/share/lxc': Permission denied

Ok... That sounds like a problem in the build system. That error
message is pretty specific. OTOH, if you're building the packages,
that's a reasonable install path but it should be pointing to your
package build install directory and that looks like it's trying to
install into the system root directory, but I really don't know how that
build system works.

The same spec (with some adjustments for openSUSE) builds fine for
openSUSE, so I guess I must have missed something for the Fedora
builds. I had a similar issue with 1.0.3 some time ago (thread lxc on
openSUSE: lxc-top not working due to lua?)

Any Fedora cracks reading this?

Without knowing what that build system is doing, it's hard to say.

Are you using the lxc.spec file from the LXC project or the lxc.spec
file from Fedora? For one reason or another, they have their own
lxc.spec file and a slightly different packaging.

Regards,
Johannes

signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] multiple lxc container path directories?

2014-06-12 Thread Michael H. Warfield

On Thu, 2014-06-12 at 08:10 +0200, Harald Dunkel wrote:
 Hi Michael,
 
 On 06/08/14 18:59, Michael H. Warfield wrote:
  
  I see, reviewing my notes now, that you were the one who brought it up
  back in December last year.  Funny too that I just got done doing
  something very very similar for lxc-autostart and the -g/--groups
  parameter (which is a comma separated string with multiple invocations).
  

 Of course I remember. That was about extending the -P option.

 This thread is about changing the lxcpath config option, keeping
 -P as it is. The difference is: Some wrapper functionality could
 loop over all lxc config dirs, to run an lxc-* -P /somdir command
 either for all affected containers (e.g. to start or stop a set of
 containers), or for the first container with a matching name.

 AFAICS this would have a much smaller impact on the lxc-* commands,
 making it more easy to implement (hopefully). Probably I do not see
 all problems of this approach yet, so I started a sample implemen-
 tation (a bash wrapper script). Its not complete yet; stay tuned.

It's really the same thing as it feeds into the same area of code.
Also, it seems that some of the code already exists as the processing
logic for -P can handing multiple invocations and it's up to the calling
command to allow for it.  If no -P options are specified, then the
global lxcpath config variable is loaded in place of the -P option.  So
they're intimately linked.

  Doing lxc_path as multiple elements is much more involved that just the
  mere parser as that variable is deeply embedded throughout the code.
  Given Stéphane's reluctance to incorporate the lxc-autostart patches
  into the stable-1.0 branch, I can pretty much foresee this not making it
  into that branch due to its complexity, so it probably wouldn't show up
  in a release until 1.1 time frame or later.

 Of course new functionality should not go to the stable branch.
 1.1 would be fine.

 Regards
 Harri
 
 
 ___
 lxc-devel mailing list
 lxc-devel@lists.linuxcontainers.org
 http://lists.linuxcontainers.org/listinfo/lxc-devel

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

[lxc-devel] Article in Linux Journal

2014-06-11 Thread Michael H. Warfield

Yes, I'm cross posting this.

This article on LXC and Docker (heavy on the LXC) is up on Linux
Journal.

Disclaimer: I was on of the article reviewers.

http://www.linuxjournal.com/content/linux-containers-and-future-cloud

Enjoy.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] LXC 1.0.4 approaching

2014-06-10 Thread Michael H. Warfield

On Tue, 2014-06-10 at 07:18 -0400, Dwight Engen wrote:
 On Mon, 9 Jun 2014 11:06:03 -0400
 Stéphane Graber stgra...@ubuntu.com wrote:
 
  Hey there,
  
  I just pushed Mike's lxc-autostart change to 1.0.4 as it was requested
  by both him (for Fedora) and Dwight (for Oracle).
  
  There's one more crasher in the python3 binding I'd like to sort out
  and then I think I'll be good for 1.0.4 on my side.
  
  My current plan is for a release in the early afternoon US eastern
  time on Thursday. It'd be great if distro maintainers planning on
  using 1.0.4 could spend some time testing the current stable-1.0
  branch to make sure it didn't regress in some ways and that the bugs
  you care about have been fixed.

 Hey Stéphane,

 The stable branch did fine in my testing here. I did explicitly test
 the autostart stuff on both OL6.x (sysvinit) and OL7 (systemd). Thanks!

Yeah, stable branch is running fine here on Fedora 20.

  Thanks!

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] my fedora container and the host time/date are different.

2014-06-09 Thread Michael H. Warfield

On Mon, 2014-06-09 at 14:55 -0700, Steven Howe wrote:
 The container is at 
 Mon Jun  9 21:51:44 UTC 2014

 while the host is at
 Mon Jun  9 14:52:14 PDT 2014

Date and time look about the same to me, just the TZ is off.

 I have set the /etc/localtime to the same value as the host, then
 restarted, but nothing changed.

Make sure it's set as a symlink to the appropriate file
in /usr/share/zoneinfo/ and don't just copy it.

-- 
[root@hydra ~]# ls -l /etc/localtime 
lrwxrwxrwx. 1 root root 36 Oct 13  2013 /etc/localtime - 
/usr/share/zoneinfo/America/New_York
-- 

 Any suggestions?

What version LXC are you running?  The old (0.9.0) Fedora template use
to not set this.  The newer template does, upon container creation.  It
does work.  I've done this and you do not need to restart the container
(just any affected applications).
 
If it didn't work, then you must have done something wrong in
setting /etc/localtime because it does work.

 Steven
 
Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] multiple lxc container path directories?

2014-06-08 Thread Michael H. Warfield

On Sun, 2014-06-08 at 12:38 +0200, Harald Dunkel wrote:
 Hi folks

 currently I've got 3 container paths on some hosts:

   /var/lib/lxclocal containers
   /data1/lxc  network services
   /data2/lxc  network services

 /data1 and /data2 are part of a high availability setup
 (using drbd or iscsi). They might not be available, but
 bound to another host.

 The problem is: Having to use the correct -P flag for each
 and every lxc command is apita, not to mention that I have
 to run many commands thrice.

 Do you think it would be possible for lxc to manage n  1
 container paths?

   lxcpath=/var/lib/lxc:/data1/lxc:/data2/lxc

This exact topic has come up before and the discussion really never came
to a firm conclusion.  I don't think Serge and Stéphane were overly
enthused by the idea and there was some concerns over ambiguities (same
container name in two paths and path ordering) and having a : being a
reserved character and no longer allowed in a directory name (but the
PATH variable is the exact same syntax).  I personally liked the idea
and volunteered to do the parser for it and had been looking at the
parsers in bash and busybox.  Serge seemed to be receptive if someone
submitted a patch.  At that point, the discussion just kinda faded away
without a yea or nay and I got busy working on other things and other
projects and forgot about it.  I'm willing to revisit this.

I see, reviewing my notes now, that you were the one who brought it up
back in December last year.  Funny too that I just got done doing
something very very similar for lxc-autostart and the -g/--groups
parameter (which is a comma separated string with multiple invocations).

Doing lxc_path as multiple elements is much more involved that just the
mere parser as that variable is deeply embedded throughout the code.
Given Stéphane's reluctance to incorporate the lxc-autostart patches
into the stable-1.0 branch, I can pretty much foresee this not making it
into that branch due to its complexity, so it probably wouldn't show up
in a release until 1.1 time frame or later.

I'll give it a look again.

 Regards
 Harri

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Cherry-picking to stable-1.0

2014-06-05 Thread Michael H. Warfield

On Thu, 2014-06-05 at 15:09 -0400, Stéphane Graber wrote:
 On Thu, Jun 05, 2014 at 10:10:39AM -0400, Dwight Engen wrote:
  On Wed, 04 Jun 2014 19:04:03 -0400
  Michael H. Warfield m...@wittsend.com wrote:
  
   On Wed, 2014-06-04 at 17:41 -0400, Stéphane Graber wrote:
On Wed, Jun 04, 2014 at 05:32:37PM -0400, Michael H. Warfield wrote:
 On Wed, 2014-04-30 at 15:47 -0400, Stéphane Graber wrote:
  Hello,
 
  I intend to release 1.0.4 next week and am currently going
  through all the commits in master which should be included in
  the bugfix release.
 
 Next week came and passed but we've all been busy (especially
 you). Any time frame on this?  I'm trying to position the Fedora
 Project to move on 1.0.4 as soon as it releases and I'm walking
 down their bugzilla list now.
   
I'm slowly going through
https://github.com/lxc/lxc/issues?milestone=7page=1state=open
figuring out what we actually want fixed and what should be
postponed.
   
But things are starting to look good, I'm back home and so there's a
good chance we'll have this out the door in the next week or so.
   
 Will the startup initscript and lxc-autostarat changes that
 Dwight and I worked out make it into 1.0.4 at this point?
   
I didn't plan on including it as it felt a bit much for a stable
release update though I didn't spend much time thinking about it
and maybe it's fine after all. If you'd like it, I can give it some
more thoughts and see exactly what bits may be controversial in
there (potential breakage to existing setups mostly).
  
  I understand about not wanting to break existing stuff, and I haven't
  thought hard about that but I would like to point out that the systemd
  unit file we shipped before was broken as what it pointed to didn't
  exist, so that part certainly seems like a worthwhile fix for stable.

 Ok, so I just had a quick look and the change from master won't apply
 cleanly anyway because we don't have the --ignore-auto/-A option in
 stable's lxc-autostart.

Ewww...  That affects the init scripts since they use -a -A in the
shutdown stanza.

I've just been working from master.  What branch do you want this
against (since most of the relevant code is mine)?

Mike

 I agree that in systemd's case, things can't really be much worse
 compared to what we currently have in stable, so I'm fine with applying
 the change in that regard. On the sysvinit/upstart side, the change
 won't cause any user visible change of behaviour unless the user was
 using onboot already for something else (doubtful).

 So while I'm not thrilled getting that kind of big changeset into
 stable, it's doable and I'll apply it if someone can get me a version of
 the change which actually applies.
 
   I tried pretty much to go out of my way to insure it wouldn't break
   any pre-existing setup.  The only thing where that might be
   questionable is if someone was already doing something weird with
   groups but, even then, the startup behavior had been only the NULL
   group before and now is configurable.
   
   I'm pretty happy with it and Dwight seems pretty happy with it.  I
   have it in production now.  I'd personally like to see it show up in
   the next iteration of the Fedora package, which I may now have a hand
   in...
   
 Regards,
 Mike
   
   Regards,
   Mike
   
  Most of them applied cleanly except for two:
   - [PATCH] Convert punctuation marks in Japanese man pages
 This one we thought was identical for both branches, this
  turned out to be wrong, so instead of cherry-picking from
  master, I applied the one from the stable-1.0 pull request I
  was sent.
   - [PATCH] lxc-oracle: fix warnings/errors from some rpm
  scriptlets This one fails to apply on current stable-1.0,
  probably because of the changes done to the Oracle template to
  support installing from media. If those fixes should be
  backported to stable, I'd appreciate receiving a separate patch
  for that.
  
  
  I've also gone through all the patches that have been stacking
  in my mailbox, at the moment, the only unreviewed patches in
  there are the menuconfig change. If you submitted something
  else and it's not in master now, please re-send.
  
  Thanks!
  
  ___
  lxc-devel mailing list
  lxc-devel@lists.linuxcontainers.org
  http://lists.linuxcontainers.org/listinfo/lxc-devel
 
 -- 
 Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
/\/\|=mhw=|\/\/  | (678) 463-0932 |
 http://www.wittsend.com/mhw/ NIC whois: MHW9  | An
 optimist believes we live in the best of all PGP Key:
 0x674627FF| possible worlds.  A pessimist is sure of it!
 



 ___
 lxc-devel mailing list

Re: [lxc-devel] Cherry-picking to stable-1.0

2014-06-05 Thread Michael H. Warfield

On Thu, 2014-06-05 at 15:09 -0400, Stéphane Graber wrote:
 On Thu, Jun 05, 2014 at 10:10:39AM -0400, Dwight Engen wrote:
  On Wed, 04 Jun 2014 19:04:03 -0400
  Michael H. Warfield m...@wittsend.com wrote:
  
   On Wed, 2014-06-04 at 17:41 -0400, Stéphane Graber wrote:
On Wed, Jun 04, 2014 at 05:32:37PM -0400, Michael H. Warfield wrote:
 On Wed, 2014-04-30 at 15:47 -0400, Stéphane Graber wrote:
  Hello,
 
  I intend to release 1.0.4 next week and am currently going
  through all the commits in master which should be included in
  the bugfix release.
 
 Next week came and passed but we've all been busy (especially
 you). Any time frame on this?  I'm trying to position the Fedora
 Project to move on 1.0.4 as soon as it releases and I'm walking
 down their bugzilla list now.
   
I'm slowly going through
https://github.com/lxc/lxc/issues?milestone=7page=1state=open
figuring out what we actually want fixed and what should be
postponed.
   
But things are starting to look good, I'm back home and so there's a
good chance we'll have this out the door in the next week or so.
   
 Will the startup initscript and lxc-autostarat changes that
 Dwight and I worked out make it into 1.0.4 at this point?
   
I didn't plan on including it as it felt a bit much for a stable
release update though I didn't spend much time thinking about it
and maybe it's fine after all. If you'd like it, I can give it some
more thoughts and see exactly what bits may be controversial in
there (potential breakage to existing setups mostly).
  
  I understand about not wanting to break existing stuff, and I haven't
  thought hard about that but I would like to point out that the systemd
  unit file we shipped before was broken as what it pointed to didn't
  exist, so that part certainly seems like a worthwhile fix for stable.

 Ok, so I just had a quick look and the change from master won't apply
 cleanly anyway because we don't have the --ignore-auto/-A option in
 stable's lxc-autostart.

Yeah, that was kinda ugly.  It actually probably would have been easier
to add the -A option and patch forward.  One stinking line in the middle
of hunk 6 of the lxc_autostart.c patch and I had to go over every line
in the main loop to be sure I got it right.  Hunk 6 covered about 80% of
main.  :-P

There was also a failed hunk in the upstart init case that was easy
enough to deal with.  I cleaned up the sysvinit script as well to avoid
the -A.

IAC...

 I agree that in systemd's case, things can't really be much worse
 compared to what we currently have in stable, so I'm fine with applying
 the change in that regard. On the sysvinit/upstart side, the change
 won't cause any user visible change of behaviour unless the user was
 using onboot already for something else (doubtful).

/me biting my tongue about systemd...

Ask and ye shall receive.  The backported autoboot rollup patch with all
the little gotchas, including the speeling eroor that KATOH had caught.
It's after the jump.  Patch against stable-1.0.

 So while I'm not thrilled getting that kind of big changeset into
 stable, it's doable and I'll apply it if someone can get me a version of
 the change which actually applies.
 
   I tried pretty much to go out of my way to insure it wouldn't break
   any pre-existing setup.  The only thing where that might be
   questionable is if someone was already doing something weird with
   groups but, even then, the startup behavior had been only the NULL
   group before and now is configurable.
   
   I'm pretty happy with it and Dwight seems pretty happy with it.  I
   have it in production now.  I'd personally like to see it show up in
   the next iteration of the Fedora package, which I may now have a hand
   in...
   
 Regards,
 Mike
   
   Regards,
   Mike
   
  Most of them applied cleanly except for two:
   - [PATCH] Convert punctuation marks in Japanese man pages
 This one we thought was identical for both branches, this
  turned out to be wrong, so instead of cherry-picking from
  master, I applied the one from the stable-1.0 pull request I
  was sent.
   - [PATCH] lxc-oracle: fix warnings/errors from some rpm
  scriptlets This one fails to apply on current stable-1.0,
  probably because of the changes done to the Oracle template to
  support installing from media. If those fixes should be
  backported to stable, I'd appreciate receiving a separate patch
  for that.
  
  
  I've also gone through all the patches that have been stacking
  in my mailbox, at the moment, the only unreviewed patches in
  there are the menuconfig change. If you submitted something
  else and it's not in master now, please re-send.
  
  Thanks!

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http

[lxc-devel] [PATCH] lxc-fedora.in: Correct some systemd target setups.

2014-06-03 Thread Michael H. Warfield

lxc-fedora.in: Correct some systemd target setups.

Set the halt.target action to be sigpwr.target.  This allows
SIGPWR to properly shut the container down from lxc-stop.

Renable the systemd-journald.service.

Signed-off-by: Michael H. Warfield m...@wittsend.com
---
 templates/lxc-fedora.in | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/templates/lxc-fedora.in b/templates/lxc-fedora.in
index 2e14cc8..b9741ac 100644
--- a/templates/lxc-fedora.in
+++ b/templates/lxc-fedora.in
@@ -369,10 +369,9 @@ configure_fedora_systemd()
 rm -f ${rootfs_path}/etc/systemd/system/default.target
 touch ${rootfs_path}/etc/fstab
 chroot ${rootfs_path} ln -s /dev/null /etc/systemd/system/udev.service
-chroot ${rootfs_path} ln -s /dev/null 
/etc/systemd/system/systemd-journald.service
 chroot ${rootfs_path} ln -s /lib/systemd/system/multi-user.target 
/etc/systemd/system/default.target
 # Make systemd honor SIGPWR
-chroot ${rootfs_path} ln -s /usr/lib/systemd/system/halt.target 
/etc/systemd/system/
+chroot ${rootfs_path} ln -s /usr/lib/systemd/system/halt.target 
/etc/systemd/system/sigpwr.target
 #dependency on a device unit fails it specially that we disabled udev
 # sed -i 's/After=dev-%i.device/After=/' 
${rootfs_path}/lib/systemd/system/getty\@.service
 #
-- 
1.9.3


-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [RFC PATCH 0/2] Loop device psuedo filesystem

2014-05-28 Thread Michael H. Warfield

 ignoring the fact that just doing this for
  loop seems to be almost entirely useless right now: you still can't
  mount the things.)

  You could also argue that it's useless to be able to mount things if you
  have no block device on which to mount them. We have to start somewhere.

 True.

 But if we take this particular route, then I can imagine a real mess
 when someone wants to mount a non-loop device, and we get stuck on how
 to expose the device node.  Sigh.

Then we deal with that horse when we have to make him sing.  One way or
the other, we're trying to moving forward.

 --Andy

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device

2014-05-26 Thread Michael H. Warfield

On Mon, 2014-05-26 at 11:16 +0200, Seth Forshee wrote:
 On Fri, May 23, 2014 at 08:48:25AM +0300, Marian Marinov wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  One question about this patch.
  
  Why don't you use the devices cgroup check if the root user in that 
  namespace is allowed to use this device?
  
  This way you can be sure that the root in that namespace can not access 
  devices to which the host system did not gave
  him access to.

 That might be possible, but I don't want to require something on the
 host to whitelist the device for the container. Then loop would need to
 automatically add the device to devices.allow, which doesn't seem
 desirable to me. But I'm not entirely opposed to the idea if others
 think this is a better way to go.

I don't see any safe way to avoid it.  The host has to be in control of
what devices can and can not be accessed by the container.

 Seth

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] v2 Refactoring lxc-autostart boot process and group handling.

2014-05-25 Thread Michael H. Warfield

On Sun, 2014-05-25 at 08:51 -0400, Stéphane Graber wrote:

 lxc-test-autostart is failing on all arches:

 FAIL: lxc-tests: /usr/bin/lxc-test-autostart
 ---
 Setting up the GPG keyring
 Downloading the image index
 Downloading the rootfs
 Downloading the metadata
 The image cache is now ready
 Unpacking the rootfs
 
 ---
 You just created an Ubuntu container (release=trusty, arch=amd64, 
 variant=default)
 The default username/password is: ubuntu / ubuntu
 To gain root privileges, please use sudo.
 
 *** Error in `lxc-autostart': double free or corruption (fasttop): 
 0x008df5a0 ***
 Aborted (core dumped)
 *** Error in `lxc-autostart': double free or corruption (fasttop): 
 0x01dfa5a0 ***
 Aborted (core dumped)
 *** Error in `lxc-autostart': double free or corruption (fasttop): 
 0x01835c80 ***
 Aborted (core dumped)
 *** Error in `lxc-autostart': double free or corruption (fasttop): 
 0x02118c80 ***
 Aborted (core dumped)
 FAIL
 ---

Just sent a patch in to fix it.

Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] -L option with lxc-start

2014-05-24 Thread Michael H. Warfield

On Sat, 2014-05-24 at 22:15 +, Serge Hallyn wrote:
 Quoting William Dauchy (wdau...@gmail.com):
  Hello,
  
  lxc1 did a modification in the lxc.console behaviour (compared to the
  previous version)
  Indeed, in the config file lxc.console now accept a tty and not a file.
  I now need to use -L with lxc-start to get logs in a file.
  
  The problem raised is now I don't have a -L equivalent in config like
  before. Correct me if I'm wrong.
  
  lxc.console in config file:
  % git grep -F console.path
  lxc/conf.c: new-console.path = NULL;
  lxc/conf.c: if (conf-console.path)
  lxc/conf.c: free(conf-console.path);
  lxc/confile.c:  return config_path_item(lxc_conf-console.path, value);
  lxc/confile.c:  v = c-console.path;
  lxc/confile.c:  if (c-console.path)
  lxc/confile.c:  fprintf(fout, lxc.console = %s\n, 
  c-console.path);
  lxc/lxc_start.c:if (ensure_path(conf-console.path,
  my_args.console)  0) {
  lxc/start.c:if (conf-console.path  setenv(LXC_CONSOLE,
  conf-console.path, 1)) {
  
  -L with lxc-start, no equivalent in config file:
  % git grep -F console.log_path
  lxc/conf.c: new-console.log_path = NULL;
  lxc/lxc_start.c:if (ensure_path(conf-console.log_path,
  my_args.console_log)  0) {
  lxc/start.c:if (conf-console.log_path 
  setenv(LXC_CONSOLE_LOGPATH, conf-console.log_path, 1)) {
 
 Indeed, it looks like we need a patch to confile.c to add a
 config_console_logfile() helper to set that.  Would you be
 interested in writing that patch?

Wait a second.  I recall something along these lines being discussed
years ago and, iirc, you pointed out to us that there's a chicken and
egg situation in there that there are logging calls in the options
parsing and processing and there was some problem with switching log
file mid-stream or initializing or stuff.  Seems like I remember those
log files and consoles being sensitive to when they were initialized...

We may want to be very careful there.

Regards,
Mike

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] v2 Refactoring lxc-autostart boot process and group handling.

2014-05-20 Thread Michael H. Warfield

On Tue, 2014-05-20 at 11:56 +0200, Stéphane Graber wrote:
 On Mon, May 19, 2014 at 03:57:26PM -0400, Michael H. Warfield wrote:
  On Mon, 2014-05-19 at 17:22 +0200, Stéphane Graber wrote:
   On Fri, May 16, 2014 at 02:07:31PM -0400, Michael H. Warfield wrote:
Before anyone else spots it...  I did miss one spot where I failed to
toss a list (cmd_group_lists) on exit.  So, some memory checkers will
complain about orphaned memory or leaks (even though it's on exit).
I'll fix that and add some doco once this has been reviewed further.
  
   Hi,
  
   I took a quick look at the proposed patch and don't have any issue with
   it, so please resend with those updates done and I'll do some proper
   testing and apply it.
  
   Thanks!
  
  Ok...  Ask and yea shall receive.  Version 2 of the refactoring
  autostart patch with Dwight's patch and my other patches adding now the
  fix for the minor cleanup gotcha I spotted plus I enhanced the
  documentation in lxc-autostart.sgml.in for group handling.
  
  While this was going on, I also pinged Dwight about parameterizing the
  bootup groups and other options in the startup scripts.  Consequently,
  with his concurrence, I've added some boot time configuration options to
  the sysvinit/systemd init script and the upstart configuration file for
  BOOTGROUPS, SHUTDOWNDELAY, OPTIONS, and STOPOPTS.  For the former
  (Oracle, RHEL Fedora, CentOS, et al), it's in /etc/sysconfig/lxc and the
  later (Ubuntu, Debian, etc) in /etc/default/lxc.  I've tested the
  sysvinit/systemd init script.  Someone needs to verify the upstart
  changes.
  
  Attached below the jump.
  
  Thanks!
  
  Regards,
  Mike
 
  == Executing: ./autogen.sh in /build/git/
 + test -d autom4te.cache
 + aclocal -I config
 + autoheader
 + autoconf
 + automake --add-missing --copy
 configure.ac:31: installing 'config/compile'
 configure.ac:30: installing 'config/config.guess'
 configure.ac:30: installing 'config/config.sub'
 configure.ac:29: installing 'config/install-sh'
 configure.ac:29: installing 'config/missing'
 configure.ac:565: error: required file 'config/init/systemd/lxc.service.in' 
 not found
 configure.ac:565: error: required file 'config/init/sysvinit/lxc.in' not found
 src/lua-lxc/Makefile.am: installing 'config/depcomp'
 + exit 1
  == Cleaning up the environment
  == Exitting with status FAIL

 Seems like make dist is missing a bunch of files...

Crud.  Missed them when I did the add and commit.  Redoing.  Sorry about
that...

Below the jump...

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!

-- 

Added missing files...

Accidentally overlooked two new files when building patch set.

Signed-off-by: Michael H. Warfield m...@wittsend.com
---
 config/init/systemd/lxc.service.in |  17 +
 config/init/sysvinit/lxc.in| 124 +
 2 files changed, 141 insertions(+)
 create mode 100644 config/init/systemd/lxc.service.in
 create mode 100644 config/init/sysvinit/lxc.in

diff --git a/config/init/systemd/lxc.service.in 
b/config/init/systemd/lxc.service.in
new file mode 100644
index 000..5f155b6
--- /dev/null
+++ b/config/init/systemd/lxc.service.in
@@ -0,0 +1,17 @@
+[Unit]
+Description=LXC Container Initialization and Autoboot Code
+After=syslog.target network.target
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStartPre=@libexecdir@/lxc/lxc-devsetup
+ExecStart=@libexecdir@/lxc/lxc-autostart-helper start
+ExecStop=@libexecdir@/lxc/lxc-autostart-helper stop
+# Environment=BOOTUP=serial
+# Environment=CONSOLETYPE=serial
+StandardOutput=syslog
+StandardError=syslog
+
+[Install]
+WantedBy=multi-user.target
diff --git a/config/init/sysvinit/lxc.in b/config/init/sysvinit/lxc.in
new file mode 100644
index 000..1a876a2
--- /dev/null
+++ b/config/init/sysvinit/lxc.in
@@ -0,0 +1,124 @@
+#!/bin/sh
+#
+# lxc Start/Stop LXC autoboot containers
+#
+# chkconfig: 345 99 01
+# description: Starts/Stops all LXC containers configured for autostart.
+#
+### BEGIN INIT INFO
+# Provides: lxc
+# Default-Start: 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: Bring up/down LXC autostart containers
+# Description: Bring up/down LXC autostart containers
+### END INIT INFO
+
+sysconfdir=@SYSCONFDIR@
+bindir=@BINDIR@
+localstatedir=@LOCALSTATEDIR@
+
+# These can be overridden in @SYSCONFDIR@/sysconfig/lxc
+
+# BOOTGROUPS - What groups should start on bootup?
+#  Comma separated list of groups.
+#  Leading comma, trailing comma or embedded double
+#  comma indicates when the NULL group should be run.
+# Example (default): boot the onboot group first then the NULL group
+BOOTGROUPS=onboot,
+
+# SHUTDOWNDELAY - Wait time for a container to shut down.
+#  ner shutdown can result

Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces

2014-05-19 Thread Michael H. Warfield

On Mon, 2014-05-19 at 17:04 -0700, Eric W. Biederman wrote:
 Seth Forshee seth.fors...@canonical.com writes:
 
  What I set out for was feature parity between loop devices in a secure
  container and loop devices on the host. Since some operations currently
  check for system-wide CAP_SYS_ADMIN, the only way I see to accomplish
  this is to push knowledge of the user namespace farther down into the
  driver stack so the check can instead be for CAP_SYS_ADMIN in the user
  namespace associated with the device.
 
  That said, I suspect our current use cases can get by without these
  capabilities. Really though I suspect this is just deferring the
  discussion rather than settling it, and what we'll end up with is little
  more than a fancy way for userspace to ask the kernel to run mknod on
  its behalf.

 A fancy way to ask the kernel to run mknod on its behalf is what
 /dev/pts is.

 When I suggested this I did not mean you should forgo making changes to
 allow partitions and the like.  What I itended is that you should find a
 way to make this safe for users who don't have root capabilities.

I like to think in terms of the rootless configurations where root
per se is not absolute and everything is framed in terms of
capabilities.

 Which possibly means that mount needs to learn how to keep a more
 privileged user from using your new loop devices.

Not sure I got that one.  As user with more privileges may or may not
have access dependent on the congruence of the privileges.  They're not
heiarchial.  If someone has that priv then they have access.  If they
do not, they do not.

 To get to the point where this is really and truly usable I expect to be
 technically daunting.

Most technically non-trivial problems generally are.

 Ultimately the technical challenge is how do we create a block device
 that is safe for a user who does not have any capabilities to use, and
 what can we do with that block device to make it useful.

Concur.  It boils down to privilege management and access.  Absolutely
concur.

 Only when the question is can this kernel functionality which is
 otherwise safe confuse a preexisting setuid application do namespace
 or container bits significantly come into play.

Ah...  Admittedly it's not as late as our conversation at LinuxPlumbers
last year in NOLA but...  Maybe late at night but I failed to parse the
above.

 Eric

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] lxc on openSUSE: lxc-top not working due to lua?

2014-05-18 Thread Michael H. Warfield

On Sun, 2014-05-18 at 14:07 +0200, Johannes Kastl wrote:
 On 17.05.2014 21:10 Michael H. Warfield wrote:

  Ok...  I'm primarily a Fedora / CentOS / RHEL / SL / NST guy.  All
  rpm and yum based.  I dabble in SUSE once in a while, or I use to.
  If they used the LXC project's lxc.spec file then the lua stuff is
  in the lxc-lua package.  It's broken out separately but, if lxc-top
  depends on lua, maybe there's a missing dependency.  But...  Maybe
  they're not using our lxc.spec file (HELL even Fedora is not using
  our stock lxc.spec file...  Sigh...).

 I added a --enable-lua to the spec and compiled it, but I got the same
 error. Is there a way to check which options have been used to compile
 lxc? I.e. to see if this has actually been used correctly?

You wrote: I added a --enable-lua to the spec and compiled it

Wait...  Let's refine that statement a bit...

You say you added it to the spec, you mean the lxc.spec.in file?  Then
ran autogen.sh and ran configure to generate the appropriate lxc.spec
file?  When you compiled it, was it by running make rpm or just make?
Or did you do like I use to do, tar the whole thing up and run rpmbuild
on the resulting tarball?  The spec file only applies to building rpms
and using the tarball method misses a couple of options.

If you're using the lxc.spec file you should not be adding (do not have
to add) the --enable-lua option (it's auto detected in any case).
Running make rpm will pick up on both perl and lua but be sure you
have the corresponding development packages in place first.

 At the moment I am working on a duplicate package of the lxc from the
 Virtualization:-Repository, where I try to use the spec I got from
 inside the 1.0.3.-tarball. I had to make some changes, to get it to
 build at all. When all is settled down, I will sent these changes
 upstream.

 Regards,
 Johannes
 ___
 lxc-devel mailing list
 lxc-devel@lists.linuxcontainers.org
 http://lists.linuxcontainers.org/listinfo/lxc-devel
 

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] lxc on openSUSE: lxc-top not working due to lua?

2014-05-18 Thread Michael H. Warfield

On Sun, 2014-05-18 at 15:20 +0200, Johannes Kastl wrote:
 On 18.05.2014 15:10 Michael H. Warfield wrote:
 
  You wrote: I added a --enable-lua to the spec and compiled it
  
  Wait...  Let's refine that statement a bit...

 I clarify: I added this option to the configure call used in spec,
 which is used to build the existing package in the openSUSE build
 service, which I took as a starting point. One reason is, that this is
 the package I have installed, and which gave me the lua error in the
 first place.

Ah.  Thank you.  That clarifies it a lot.  I'll check it out but I
strongly suspect the SUSE guys will have to chime in on that, now.  I
pinged Thorsten a couple of days ago but probably missed him before the
weekend started for him.

 Virtualization-project:
 https://build.opensuse.org/project/show/Virtualization
 lxc-package:
 https://build.opensuse.org/package/show/Virtualization/lxc

 (For those of you who do not know the obs, you can build packages for
 various linux distributions and version with it, and have them hosted
 for easy installation. Used mostly for SUSE/openSUSE-stuff, but you
 can build for fedora, rhel, arch, etc. as well.)

Definitely going to check that out.

 Regards,
 Johannes

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] lxc on openSUSE: lxc-top not working due to lua?

2014-05-17 Thread Michael H. Warfield

On Sat, 2014-05-17 at 20:43 +0200, Johannes Kastl wrote:
 On 17.05.2014 15:44 Michael H. Warfield wrote:

  ITMT, what version of LXC do you have installed?

 I installed the 1.0.3 package, which I had asked the maintainer to
 update some time again ago.

  All those lxc* files would have (should have) come from the LXC
  package.  The only non-lxc file (loadall.so) is complaining about
  lxc.so not being there.  Looks like LXC was not built with lua
  support to begin with.

 I'll have to look at the spec in the rpm, to see if there is something
 related to lua.

Ok...  I'm primarily a Fedora / CentOS / RHEL / SL / NST guy.  All rpm
and yum based.  I dabble in SUSE once in a while, or I use to.  If they
used the LXC project's lxc.spec file then the lua stuff is in the
lxc-lua package.  It's broken out separately but, if lxc-top depends on
lua, maybe there's a missing dependency.  But...  Maybe they're not
using our lxc.spec file (HELL even Fedora is not using our stock
lxc.spec file...  Sigh...).

 To answer Natanaels question, lua version is lua-5.2.2-2.1.2.x86_64.

 Regards,
 Johannes

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces

On Fri, 2014-05-16 at 09:06 -0500, Seth Forshee wrote:
 On Thu, May 15, 2014 at 09:35:32PM -0700, Greg Kroah-Hartman wrote:
  On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote:
I think having to pick and choose what device nodes you want in a
container is a good thing.  Becides, you would have to do the same thing
in the kernel anyway, what's wrong with userspace making the decision
here, especially as it knows exactly what it wants to do much more so
than the kernel ever can.
   
   For 'real' devices that sounds sensible.  The thing about loop devices
   is that we simply want to allow a container to say give me a loop
   device to use and have it receive a unique loop device (or 3), without
   having to pre-assign them.  I think that would be cleaner to do using
   a pseudofs and loop-control device, rather than having to have a
   daemon in userspace on the host farming those out in response to
   some, I don't know, dbus request?
  
  I agree that loop devices would be nice to have in a container, and that
  the existing loop interface doesn't really lend itself to that.  So
  create a new type of thing that acts like a loop device in a container.
  But don't try to mess with the whole driver core just for a single type
  of device.

 No matter what I don't think we get out of this without driver core
 changes, whether this was done in loop or by creating something new.
 Not unless the whole thing is punted to userspace, anyway.

 The first problem is that many block device ioctls check for
 CAP_SYS_ADMIN. Most of these might not ever be used on loop devices, I'm
 not really sure. But loop does at minimum support partitions, and to get
 that functionality in an unprivileged container at least the block layer
 needs to know the namespace which has privileges for that device.

Woa!  Time out...  Sorry, this will be an off topic aside.

Loop devices support partitions?  I'd love to know how that works.  I've
tried several times in the past to do that but it's failed every time.
I haven't been able to find any how-to in the past.  This article was
just a couple of years ago (after the last time I tried this):

http://madduck.net/blog/2006.10.20:loop-mounting-partitions-from-a-disk-image/

This guy didn't use partitions directly but used the offset to the
mount, which is what I had to use.  Everything I found always referred
to using mount offsets in order to mount partitions within a loop
device.

Regards,
Mike

 The second is that all block devices automatically appear in devtmpfs.
 The scenario I'm concerned about is that the host could unknowingly use
 a loop device exposed to a container, then the container could see data
 from the host. So we either need a flag to tell the driver core not to
 create a node in devtmpfs, or we need a privileged manager in userspace
 to remove them (which kind of defeats the purpose). And it gets more
 complicated when partition block devs are mixed in, because they can be
 created without involvement from the driver - they would need to inherit
 the no devtmpfs node property from their parent, and if the driver
 uses a psuedo fs to create device nodes for userspace then it needs to
 be informed about the partitions too so it can create those nodes.
 
 So maybe we could get by without the privileged ioctls, as long as it
 was understood that unprivileged containers can't do partitioning. But I
 do think the devtmpfs problem would need to be addressed.
 
 Thanks,
 Seth
 ___
 lxc-devel mailing list
 lxc-devel@lists.linuxcontainers.org
 http://lists.linuxcontainers.org/listinfo/lxc-devel
 

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] Refactoring lxc-autostart boot process and group handling.

Before anyone else spots it...  I did miss one spot where I failed to
toss a list (cmd_group_lists) on exit.  So, some memory checkers will
complain about orphaned memory or leaks (even though it's on exit).
I'll fix that and add some doco once this has been reviewed further.

Mike

On Thu, 2014-05-15 at 16:51 -0400, Michael H. Warfield wrote:
 Ok...
 
 Here it is.  The roll up of Dwight's earlier patch, my previous 3
 patches plus, now, the rework to lxc-autostart to support multiple
 invocations of the -g option, allow ordinal inclusion of the NULL group,
 and process containers first in order of the groups specified on the
 command line and their membership in those groups, subject to all other
 constraints (lxc.start.auto) and orderings (lxc.start.order).
 
 I have also noticed that host shutdown time can be very exhorbatently
 long.  I added parameters to set a shutdown time of -t 5 seconds to
 speed that process up (may still not be fast enough).  Problem here is
 that while startup returns quickly while a container initializes and we
 need a delay, shutdown is largely serial and not parallelized at all.
 We may need to address that in some way moving forward.
 
 Here's the grand patch:
 
 -- 
 Refactoring lxc-autostart boot process and group handling.
 
 This is a rollup of 4 earlier patches patching the systemd
 init to use the sysvinit script, adding an onboot group to the
 boot set, updating upstart to include the onboot group, and adding
 documentation for the special boot groups.
 
 This also adds new functionality to lxc-autostart.
 
 *) The -g / --groups option is multiple cummulative entry.
   This may be mixed freely with the previous comma separated
   group list convention.  Groups are processed in the
   order they first appear in the aggregated group list.
 
 *) The NULL group may be specified in the group list using either a
   leading comma, a trailing comma, or an embedded comma.
 
 *) Booting proceeds in order of the groups specified on the command line
   then ordered by lxc.start.org and name collalating sequence.
 
 *) Default host bootup is now specified as -g onboot, meaning that first
   the onboot group is booted and then any remaining enabled
   containers in the NULL group are booted.
 
 From the previous 4 individual patches:
 
 Reported-by: CDR vene...@gmail.com
 Signed-off-by: Dwight Engen dwight.en...@oracle.com
 
 - reuse the sysvinit script to ensure that if the lxc is configured to use
   a bridge setup by libvirt, the bridge will be available before starting
   the container
 
 - made the sysvinit script check for the existance of ifconfig, and fall
   back to ip link list if available
 
 - made the lxc service also dependant on the network.target
 
 - autoconfized the paths in the service file and sysvinit script
 
 - v2: rename script lxc-autostart to lxc-autostart-helper to avoid confusion
 
 From: Michael H. Warfield m...@wittsend.com
 
 - This adds a non-null group (onboot) to the sysvinit startup script
 for autobooting containers.  This allows for containers which are
 in other groups to be included in the autoboot process.
 
 This script is used by both the sysvinit systems and the systemd
 systems.
 
 From: Michael H. Warfield m...@wittsend.com
 
 - Add the feature to the Upstart init script to boot the onboot
 group dependent on the start.auto = 1 flag.  This brings the
 the Upstart behavior into congruence with the sysvinit script
 for SysV Init and Systemd.
 
 From: Michael H. Warfield m...@wittsend.com
 
 Added sections to lxc-autostart and lxc.container.config to document
 the behavior of the LXC service at host system boot time with regards
 to the lxc.group and lxc.start.auto parameters.
 
 Signed-off-by: Michael H. Warfield m...@wittsend.com
 ---
  .gitignore |   3 +
  config/init/systemd/Makefile.am|  14 +-
  config/init/systemd/lxc.service|  17 --
  config/init/systemd/lxc.service.in |  17 ++
  config/init/sysvinit/lxc   |  66 
  config/init/sysvinit/lxc.in|  86 ++
  config/init/upstart/lxc.conf   |   8 +-
  configure.ac   |   2 +
  doc/lxc-autostart.sgml.in  |  30 
  doc/lxc.container.conf.sgml.in |  23 +++
  lxc.spec.in|   1 +
  src/lxc/lxc_autostart.c| 331 
 +++--
  12 files changed, 427 insertions(+), 171 deletions(-)
  delete mode 100644 config/init/systemd/lxc.service
  create mode 100644 config/init/systemd/lxc.service.in
  delete mode 100755 config/init/sysvinit/lxc
  create mode 100644 config/init/sysvinit/lxc.in
 
 diff --git a/.gitignore b/.gitignore
 index 8145f81..2b478cd 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -111,6 +111,9 @@ config/missing
  config/libtool.m4
  config/lt*.m4
  config/bash/lxc
 +config/init/systemd/lxc-autostart-helper
 +config/init/systemd/lxc.service
 +config/init/sysvinit/lxc
  
  doc/*.1
  doc/*.5
 diff

Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces

On Fri, 2014-05-16 at 12:20 -0700, James Bottomley wrote:
 On Thu, 2014-05-15 at 21:42 -0400, Michael H. Warfield wrote:
  On Thu, 2014-05-15 at 15:15 -0700, Greg Kroah-Hartman wrote:
PS - Apparently both parallels and Michael independently
project devices which are hot-plugged on the host into containers.
That also seems like something worth talking about (best practices,
shortcomings, use cases not met by it, any ways tha the kernel can
help out) at ksummit/linuxcon.
  
   I was told that containers would never want devices hotplugged into
   them.
  
  Interesting.  You were told they (who they?) would never want them?  Who
  said that?  I would have never thought that given that other
  implementations can provide that.  I would certainly want them.  Seems
  strange to explicitly relegate LXC containers to being second class
  citizens behind OpenVZ, Parallels, BSD Gaols, and Solaris Zones.

 That would probably be me.  Running hotplug inside a container is a
 security problem and, since containers are easily entered by the host,
 it's very easy to listen for the hotplug in the host and inject it into
 the container using nsenter.

In all virtualization...  The host, particularly root on the host,
exists as deus ex machina, the god outside the machine.  They are at
my mercy.  Even hardware virtualization can not protect you from the
host.  You wanna hear some frightening talks on virtualization, catch
Joanna (miss little blue pill) Rutkowska some time.  I'm particularly
interesting in her takes on the anti evil-maid attacks and I sat in on
her talks on the north bridge and south bridge malware evasion
techniques.  She's a good speaker who makes powerful points that makes
you sweat but is pleasant in face to face conversation.  I've played
with her Qubes distribution a couple of times and the way it works with
the TPM to insure a secure boot is interesting.  But that's a completely
different topic on trusted computing.

OTOH, there are plenty of other things to worry about in all forms of
virtualization.  At Internet Security Systems, where I was a founder,
fellow, and X-Force Senior Wizard, we were looking at the ability to
leak information through the USB subsystem.  No isolation is perfect,
especially when you have USB enabled.

But that's my turf.

 I don't think the intention is to label anyone's implementation as
 preferred.  What this shows, I think, is that we all have different
 practises when it comes to setting up containers.  Some are necessary
 because our containers are different.  Some could do with serious
 examination to see if there's really a best way to do the action which
 we would then all use.

And I hope to contribute to the discussion of said actions.

  I might believe you were never told they would need them, but that's a
  totally different sense.  Are we going to tell RedHat and the Docker
  people that LXC is an inferior technology that is complex and unreliable
  (to quote another poster) compared to these others?  They're saying this
  will be enterprise technology.  If I go to Amazon AWS or other VPS
  services and compare, are we not going to stand on a level playing
  field?  Admittedly, I don't expect Amazon AWS to provide me with serial
  consoles, but I do expect to be able to mount file system images within
  my VPS.

 Well, that's another nasty, isn't it.  We all have different ways of
 coping with mount in the container.  I think at plumbers we need to sit
 down with some of this plumbing and work out which pipes carry the same
 fluids and whether we could unify them.

Concur

 As an aside (probably requiring a new thread) we were wondering about
 some type of notifier on the mount call that we could vector into the
 host to perform the action.  The main issue for us is mount of procfs,
 which really needs to be a bind mount in a container.  All of this led
 me to speculate that we could use some type of syscall notifier
 mechanism to manage capabilities in the host and even intercept and
 complete the syscall action within the host rather than having to keep
 evolving more an more complex kernel drivers to do this.

Interesting.  That could be very useful.  That might even help with the
loop device case where the mounts have to go through loop devices for
things like file system images and builds.  Very interesting...

 James

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Mount and other notifiers, was: [RFC PATCH 00/11] Add support for devtmpfs in user namespaces

On Fri, 2014-05-16 at 12:52 -0700, James Bottomley wrote:
 On Fri, 2014-05-16 at 15:42 -0400, Michael H. Warfield wrote:
   As an aside (probably requiring a new thread) we were wondering about
   some type of notifier on the mount call that we could vector into the
   host to perform the action.  The main issue for us is mount of procfs,
   which really needs to be a bind mount in a container.  All of this led
   me to speculate that we could use some type of syscall notifier
   mechanism to manage capabilities in the host and even intercept and
   complete the syscall action within the host rather than having to keep
   evolving more an more complex kernel drivers to do this.
  
  Interesting.  That could be very useful.  That might even help with the
  loop device case where the mounts have to go through loop devices for
  things like file system images and builds.  Very interesting...

 Right, it might even make the loop case go away because now we can
 present a dummy device in the container and when the host sees and
 attempted mount on this, it just projects a bind mount into the
 container and says I've *wink* mounted your device for you.

Nice.  That idea has prospects.  I like the concept.

 This idea is extremely rough, it came from a conversation I had with
 Pavel (cc'd) just before OpenStack about how we might go about
 eliminating our OpenVZ interception of the mount system call which
 currently does all of this in kernel, so we have no code and no proof
 that it's actually feasible (yet).

K.  I look forward to hearing more.

I switched from OpenVZ years ago to LXC because OpenVZ was falling too
far behind in kernel support and patches for the leading edge kernels.
At the time, I was working on the MD5 signature code for the Quagga
routing suite for BGP and couldn't maintain my hosts with OpenVZ and
maintain my BGP connections (I have a public ASN and peer on both IPv4
and IPv6) with MD5 signatures at the same time.  At the time LXC had
just matured enough to serve my needs.  That's interesting to note that
OpenVZ did this by intercepting the mount call.  Very interesting...

 James

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  m...@wittsend.com
   /\/\|=mhw=|\/\/  | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9  | An optimist believes we live in the best of all
 PGP Key: 0x674627FF| possible worlds.  A pessimist is sure of it!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces