Re: [lxc-users] Container startup hook arguments
I'm not using it, but do expect the extra args:
while [ {{ '${#@}' }} -gt 3 ] ; do
...
shift
done
It might be that some users will need the last extra argument (stage:
pre-start|start|post-stop). This is currently not available in the
environment.
I can live without these extra arguments, but will have to update my
scripts.
On di, 2017-10-03 at 14:22 -0500, Serge E. Hallyn wrote:
> Quoting Andrey Repin (anrdae...@yandex.ru):
> >
> > Greetings, Serge Hallyn!
> >
> > >
> > > Since the start, lxc container startup hooks have gotten some
> > > redundant
> > > information as command line arguments, which is also available as
> > > environment variables.
> > >
> > > Is anyone making use of that? I'm wondering whether any existing
> > > installations would have broken scripts if we get rid of those.
> > >
> > > https://github.com/lxc/lxc/issues/1766 is one sensible request to
> > > stsending
> > > these args, and I suspect that CNI binaries will also not like
> > > them.
> > >
> > > Removing them is probably 3.0 material, as even if noone replies
> > > saying
> > > they use them, our community doesn't exactly work like that...
> > > but it sure would be nice to drop them :)
> > Consider me +1 to that.
> > If your script needs to know its environment, it should make use of
> > it. Other
> > than that, the extra arguments unexpectedly passed to the hook are
> > always a
> > source for potential confusion.
> Thanks. "I've never used it" is also useful info :)
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Container startup hook arguments
Quoting Kees Bos (cornelis@gmail.com):
> I'm not using it, but do expect the extra args:
>
> while [ {{ '${#@}' }} -gt 3 ] ; do
> ...
> shift
> done
>
> It might be that some users will need the last extra argument (stage:
> pre-start|start|post-stop). This is currently not available in the
> environment.
>
> I can live without these extra arguments, but will have to update my
> scripts.
Ok, but this will hurt then. I certainly was going to keep the
extra args, but they would be shifted now. We can pass along an
environment variable saying something like LXC_SIMPLE_ARGS=1 or
something, but your unmodified script won't know to look for
that so will do the wrong thing. Any ideas?
This unfortunately basically means that you are in fact a "user",
and that makes this seem like at best 3.0 material then, unless
we can find a good solution.
Maybe a configuration key 'lxc.hooks.version=2' ?
Thanks for replying!
-serge
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Container startup hook arguments
On wo, 2017-10-04 at 09:35 -0500, Serge E. Hallyn wrote:
> Quoting Kees Bos (cornelis@gmail.com):
> >
> > I'm not using it, but do expect the extra args:
> >
> > while [ {{ '${#@}' }} -gt 3 ] ; do
> > ...
> > shift
> > done
> >
> > It might be that some users will need the last extra argument
> > (stage:
> > pre-start|start|post-stop). This is currently not available in the
> > environment.
> >
> > I can live without these extra arguments, but will have to update
> > my
> > scripts.
> Ok, but this will hurt then. I certainly was going to keep the
> extra args, but they would be shifted now. We can pass along an
> environment variable saying something like LXC_SIMPLE_ARGS=1 or
> something, but your unmodified script won't know to look for
> that so will do the wrong thing. Any ideas?
>
> This unfortunately basically means that you are in fact a "user",
> and that makes this seem like at best 3.0 material then, unless
> we can find a good solution.
>
> Maybe a configuration key 'lxc.hooks.version=2' ?
Yep. Or 'lxc.hook.version=2'. However, that would mean you've got to
support is for quite some time. I don't know if that's worth the
effort. It would also mean that you've got to update (lots?) of
container configs. I'm not sure what would be the most painful way to
go.
It would be nice if you define e.g. LXC_HOOK_STAGE=pre-start in the
environment (which is currently not available). Then it's possible to
use a single script to handle multiple stages (which I don't do, but is
currently possible based on the last argument).
This new environment variable can also be used to prepare scripts for
changing behaviour. Without that, my scripts can be prepared for this
with e.g.:
for lastarg; do true; done
if $lastarg = 'pre-start' ; then old-style ; etc; fi
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] LXC 2.1 and checkpointing using CRIU
Hi, I've been using ubuntu 16.04 and LXC 2.08 and checkpointing with CRIU 3.4, I've recently tried upgrading my setup to LXC 2.1 and since checkpointing fails. I see there are commits that include verifying the version of CRIU in 2.1 -- is this the problem or is there something else I'm missing? Thanks, Eytan ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] LXD iptables rules and iptables-persistent?
* Tomasz Chmielewski [2017-04-16 02:32]: > When there are other iptables rules applied on the system with > iptables-persistent [...] - this will basically > wipe the rules which LXD applies on startup. > > What's the recommended approach to deal with it? Very good question. I've hit by the same issue. I commented out the lxd rules when creating the file /etc/iptables/rules.v4 : -A INPUT -i lxdbr0 -p tcp -m tcp --dport 53 -m comment --comment "managed by lxd-bridge" -j ACCEPT -A INPUT -i lxdbr0 -p udp -m udp --dport 53 -m comment --comment "managed by lxd-bridge" -j ACCEPT -A INPUT -i lxdbr0 -p udp -m udp --dport 67 -m comment --comment "managed by lxd-bridge" -j ACCEPT -A FORWARD -o lxdbr0 -m comment --comment "managed by lxd-bridge" -j ACCEPT -A FORWARD -i lxdbr0 -m comment --comment "managed by lxd-bridge" -j ACCEPT I can add them to iptables-persistent, but wonder where are they documented. -- Ivan F. Villanueva B. https://timefyme.com -- Vorgründungsgesellschaft GridMind Ivan Fernando Villanueva Barrio EU -- Malmöer Str. 6 10439 Berlin Germany -- Tel: +49 30 398 20 596 Fax: +49 30 340 60 473 ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] Suggestions regarding (ultimately) LXC 2.1.0 lxc-update-config
Does mentioning lxc.pivotdir really need to be a fatal error? Currently it seems fatal to the degree that "lxc-ls -f" does not show the container at all, not RUNNING and not STOPPED. Or, at least, could the lxc-update-config command be modified to effectively delete mentions of lxc.pivotdir? (Comment out or delete it; I see lxc.rootfs.backend gets deleted by lxc-update-config; it might be nice if that also was done as commenting out, instead). It seems that "lxc-update-config" currently just leaves lxc.pivotdir alone. (In the following version). -rwxr-xr-x 1 root root 3791 Sep 21 14:35 /usr/bin/lxc-update-config (Ubuntu 16.04) The messages indicating the need to update the config should be improved to name the config file in question, and mention the lxc-update-config command. Perhaps... < The configuration file contains legacy configuration keys. < Please update your configuration file! --- > /var/lib/lxc/u1204-postfix-1/config contains legacy configuration keys. > "lxc-update-config" can be used to update most configuration files. Oh, and "lxc-update-config" does not accept "--version". Adrian Pepper arpep...@uwaterloo.ca Actual diagnostics associated with lxc.pivotdir... lxc-start: u1204-postfix-1: confile.c: parse_line: 1982 Unknown configuration key "lxc.pivotdir" lxc-start: u1204-postfix-1: parse.c: lxc_file_for_each_line: 58 Failed to parse config: lxc.pivotdir = lxc_putold lxc-start: u1204-postfix-1: tools/lxc_start.c: main: 286 Failed to create lxc_container ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Suggestions regarding (ultimately) LXC 2.1.0 lxc-update-config
agreed to both, lxc-update-config should delete it, and it should be (initially the only) member of a (new) group of keys to ignore, bc it cannot possibly hurt. Do you happen to have time to write one or both patches? thanks, -serge On Wed, Oct 04, 2017 at 03:35:08PM -0400, Adrian Pepper wrote: > Does mentioning lxc.pivotdir really need to be a fatal error? Currently > it seems fatal to the degree that "lxc-ls -f" does not show the > container at all, not RUNNING and not STOPPED. > > Or, at least, could the lxc-update-config command be modified to > effectively delete mentions of lxc.pivotdir? > (Comment out or delete it; I see lxc.rootfs.backend gets deleted by > lxc-update-config; it might be nice if that also was done as commenting > out, instead). > It seems that "lxc-update-config" currently just leaves lxc.pivotdir alone. > (In the following version). > > -rwxr-xr-x 1 root root 3791 Sep 21 14:35 /usr/bin/lxc-update-config > (Ubuntu 16.04) > > > The messages indicating the need to update the config should be > improved to name the config file in question, and mention the > lxc-update-config command. > > Perhaps... > > < The configuration file contains legacy configuration keys. > < Please update your configuration file! > --- > > /var/lib/lxc/u1204-postfix-1/config contains legacy configuration keys. > > "lxc-update-config" can be used to update most configuration files. > > > Oh, and "lxc-update-config" does not accept "--version". > > > Adrian Pepper > arpep...@uwaterloo.ca > > > Actual diagnostics associated with lxc.pivotdir... > > lxc-start: u1204-postfix-1: confile.c: parse_line: 1982 Unknown configuration > key "lxc.pivotdir" > lxc-start: u1204-postfix-1: parse.c: lxc_file_for_each_line: 58 Failed to > parse config: lxc.pivotdir = lxc_putold > > lxc-start: u1204-postfix-1: tools/lxc_start.c: main: 286 Failed to create > lxc_container > > > ___ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Container startup hook arguments
On Wed, Oct 04, 2017 at 05:02:27PM +0200, Kees Bos wrote:
> On wo, 2017-10-04 at 09:35 -0500, Serge E. Hallyn wrote:
> > Quoting Kees Bos (cornelis@gmail.com):
> > >
> > > I'm not using it, but do expect the extra args:
> > >
> > > while [ {{ '${#@}' }} -gt 3 ] ; do
> > > ...
> > > shift
> > > done
> > >
> > > It might be that some users will need the last extra argument
> > > (stage:
> > > pre-start|start|post-stop). This is currently not available in the
> > > environment.
> > >
> > > I can live without these extra arguments, but will have to update
> > > my
> > > scripts.
> > Ok, but this will hurt then. I certainly was going to keep the
> > extra args, but they would be shifted now. We can pass along an
> > environment variable saying something like LXC_SIMPLE_ARGS=1 or
> > something, but your unmodified script won't know to look for
> > that so will do the wrong thing. Any ideas?
> >
> > This unfortunately basically means that you are in fact a "user",
> > and that makes this seem like at best 3.0 material then, unless
> > we can find a good solution.
> >
> > Maybe a configuration key 'lxc.hooks.version=2' ?
>
> Yep. Or 'lxc.hook.version=2'. However, that would mean you've got to
> support is for quite some time. I don't know if that's worth the
> effort. It would also mean that you've got to update (lots?) of
> container configs. I'm not sure what would be the most painful way to
> go.
It might be a long time before we can be sure noone gets hit by this,
so supporting it a long time is fine.
Or, I suppose since renaming our config keys is all the rage we could
also just use 'lxc.hook2.*' as an indicator.
> It would be nice if you define e.g. LXC_HOOK_STAGE=pre-start in the
> environment (which is currently not available). Then it's possible to
Oh, ouch. I was thinking we had all the information in env, including
the section.
Indeed adding that will have to happen before we do this switch.
> use a single script to handle multiple stages (which I don't do, but is
> currently possible based on the last argument).
>
> This new environment variable can also be used to prepare scripts for
> changing behaviour. Without that, my scripts can be prepared for this
> with e.g.:
> for lastarg; do true; done
> if $lastarg = 'pre-start' ; then old-style ; etc; fi
-serge
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
