Re: [lxc-users] "failed to create lock" error inside a tox virtual env
I got around the issue, just replying to myself if this happens to someone
else.
The solution is simply to add passenv = * in tox.ini so that now the
installation of lxc has the needed env parameters.
What is annoying though is that without passing it there's absolutely no
way to know the lxc bindings installation wasn't done "properly".
dev-requirements.txt
pytest
click
git+git://github.com/lxc/lxc.git@master#subdirectory=src/python-lxc
tox.ini
[tox]
envlist = py35
[testenv]
passenv =
*
deps = -rdev-requirements.txt
commands = python -m pytest {posargs} -s -vv
On Tue, Apr 25, 2017 at 11:40 AM, Benoit Barthelet <
benoit.barthe...@gmail.com> wrote:
> I'm trying to run python tests in virtualenv with tox and got this error:
>
> failed to create lock
> RuntimeError: Container_init:lxc.c:542: error during init for container
> '47a1e552-299a-11e7-a6f1-f832e4beeab7'.
>
> however my tests run fine with "pytest tests -s -v"
>
> I'm not sure that is the root of my issue, but the difference i see
> between the working setup and the failing automatized one using tox, is
> that lxc_global_config_value is not set to the correct value when I use
> tox.
>
> If I add this little print debug in the __init__ line 31 (
> https://github.com/lxc/lxc/blob/master/src/python-lxc/lxc/__init__.py#L31)
>
> default_config_path = _lxc.get_global_config_item("lxc.lxcpath")
> print('LXCPATH: {}'.format(default_config_path))
>
> then I got when I run pytest tests/ -s -v
> LXCPATH: /home/lotso/.local/share/lxc
>
> but when I run tox I have
> LXCPATH: //.local/share/lxc
>
> I dont know if it's because of a failed installation of lxc within tox or
> if that means the get_global_config_item function has an issue.
>
> I'm no tox pro, but if anyone would have an idea or pointers at where to
> look at I'd be interested.
>
>
> --
> benoit barthelet
> http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE
>
--
benoit barthelet
http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] "failed to create lock" error inside a tox virtual env
I'm trying to run python tests in virtualenv with tox and got this error:
failed to create lock
RuntimeError: Container_init:lxc.c:542: error during init for container
'47a1e552-299a-11e7-a6f1-f832e4beeab7'.
however my tests run fine with "pytest tests -s -v"
I'm not sure that is the root of my issue, but the difference i see between
the working setup and the failing automatized one using tox, is that
lxc_global_config_value
is not set to the correct value when I use tox.
If I add this little print debug in the __init__ line 31 (
https://github.com/lxc/lxc/blob/master/src/python-lxc/lxc/__init__.py#L31)
default_config_path = _lxc.get_global_config_item("lxc.lxcpath")
print('LXCPATH: {}'.format(default_config_path))
then I got when I run pytest tests/ -s -v
LXCPATH: /home/lotso/.local/share/lxc
but when I run tox I have
LXCPATH: //.local/share/lxc
I dont know if it's because of a failed installation of lxc within tox or
if that means the get_global_config_item function has an issue.
I'm no tox pro, but if anyone would have an idea or pointers at where to
look at I'd be interested.
--
benoit barthelet
http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] [python-lxc] Store attach_wait in variable
I wrote this little snippet, it might give you an idea of how I "got
around" it...
import lxc
c = lxc.Container('tmp_container')
import tempfile
def run(container, command):
with tempfile.NamedTemporaryFile() as t:
container.attach_wait(lxc.attach_run_command, command,
stdout=t.file)
t.seek(0)
output = t.readlines()
print(output)
return output
hostname = run(c, ['cat', '/etc/hostname'])
[b'tmp_container\n']
id = run(c, ['id'])
[b'uid=0(root) gid=0(root) groups=0(root)\n']
On Wed, Mar 22, 2017 at 6:28 PM, Stéphane Graber
wrote:
> On Wed, Mar 08, 2017 at 10:08:29PM +, Élie Deloumeau-Prigent wrote:
> > Hello everyone,
> >
> > Is there any way to store attach_wait output into a variable?
> >
> > Thanks in advance!
> >
> > Élie.
>
> There is, but it's not exactly trivial. attach_wait spawns a subprocess
> through fork(), so the python process memory space isn't shared and the
> output therefore goes to stdout/stderr.
>
> What we did in the past for lxc-ls which needed something like that was
> have the main python process create a temporary file with
> tempfile.mkstemp(), then pass the fd as an argument to the function run
> by attach_wait, have the function redirect the output towards that fd
> and finally having the main process rewind and read from the fd after
> attach_wait returns.
>
>
> --
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
--
benoit barthelet
http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] applying a patch in an unprivileged lxc container with python
I managed to do it, but I find the whole process ugly, so I wondered if
there might be something I'm missing or if I'm trying to reinvent the
wheel...
I see lxd has some built-in file transfer, unfortunately lxd still isn't
available on debian :)
So I managed the file transfer this way:
cat settings.patch | lxc-attach - n lxcws -- sudo -u guest sh -c 'exec cat
> /home/guest/settings.patch'
which translates in python to:
def run_command(container, command, env={}, uid=None, gid=None, **kwargs):
env['LANG'] = "C.UTF-8"
env['TERM'] = "xterm"
env = ["%s=%s" % (key, value) for key, value in env.items()]
if uid is not None and gid is not None:
return container.attach_wait(
lxc.attach_run_command, command,
extra_env_vars=env, env_policy=lxc.LXC_ATTACH_CLEAR_ENV,
uid=uid, gid=gid, **kwargs)
else:
return container.attach_wait(
lxc.attach_run_command, command,
extra_env_vars=env, env_policy=lxc.LXC_ATTACH_CLEAR_ENV,
**kwargs)
def transfer_file(container, hostfile, destfile, uid=None, gid=None,
**kwargs):
catfile = subprocess.Popen(['cat', hostfile], stdout=subprocess.PIPE)
exec_command = 'exec cat > ' + destfile
return run_command(container, ['sh', '-c', exec_command], uid=uid,
gid=gid, stdin=catfile.stdout, **kwargs)
patchfile = '/home/host/PycharmProjects/lxcws/settings.patch'
transfer_file(container, patchfile, '/home/guest/settings.patch', uid=1000,
gid=1000)
The patching now:
lxc-attach -n lxcws -- sudo -u guest sh -c 'patch -p1 -b <
/home/toto/settings.patch'
the below "python translation" works, but I wondered if there was a nicest
way to implement it, using stdout in the attach_wait kwargs, but I couldn't
wrap my head around it.
patch_command = 'patch -p1 -b < /home/guest/settings.patch'
run_command(container, ['sh', '-c', patch_command], uid=1000, gid=1000,
initial_cwd='/home/guest')
In fact the whole use of "sh -c" in both commands is bizarre to me, would
there be something more elegant ?
--
benoit barthelet
http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] why some keys in my config are said to be invalid ?
I don't understand why some keys in my config aren't accessible through
python while they are in the config file.
So I wrote this little snippet that shows the lines present in my config
that aren't accessible through python.
See the lines with the >>> in the output:
I discovered that because I wanted to get the value of lxc.id_map mostly,
and the MAC address too.
Is this accessible differently ?
thanks
import re
import lxc
container = lxc.Container('lxcws')
with open(container.config_file_name) as conf_file:
options = conf_file.readlines()
f_config = {}
for op in options:
m = re.match('^(.*) = (.*)$', op)
if m is not None:
f_key = m.group(1)
f_value = m.group(2)
f_config[f_key] = f_value
for k in container.get_keys():
try:
print(k in f_config.keys(), k , container.get_config_item(k))
except Exception as e:
if k in f_config.keys():
print('>>>', k in f_config.keys(), k, e)
else:
print(k in f_config.keys(), k, e)
True lxc.arch x86_64
False lxc.pts 1024
False lxc.tty 4
False lxc.devttydir
False lxc.kmsg 'Invalid configuration key'
False lxc.aa_profile
False lxc.aa_allow_incomplete 0
False lxc.se_context
False lxc.cgroup
>>> True lxc.id_map 'Invalid configuration key'
False lxc.loglevel NOTSET
False lxc.logfile
False lxc.mount.entry ['/sys/fs/fuse/connections sys/fs/fuse/connections
none bind,optional 0 0', '/sys/kernel/debug sys/kernel/debug none
bind,optional 0 0', '/sys/kernel/security sys/kernel/security none
bind,optional 0 0', '/sys/fs/pstore sys/fs/pstore none bind,optional 0 0',
'mqueue dev/mqueue mqueue rw,relatime,create=dir,optional 0 0',
'/dev/console dev/console none bind,create=file 0 0', '/dev/full dev/full
none bind,create=file 0 0', '/dev/null dev/null none bind,create=file 0 0',
'/dev/random dev/random none bind,create=file 0 0', '/dev/tty dev/tty none
bind,create=file 0 0', '/dev/urandom dev/urandom none bind,create=file 0
0', '/dev/zero dev/zero none bind,create=file 0 0',
'/sys/firmware/efi/efivars sys/firmware/efi/efivars none bind,optional 0
0', '/proc/sys/fs/binfmt_misc proc/sys/fs/binfmt_misc none bind,optional 0
0']
True lxc.mount.auto proc:mixed sys:ro cgroup:mixed
False lxc.mount
False lxc.rootfs.mount /usr/lib/x86_64-linux-gnu/lxc/rootfs
False lxc.rootfs.options
True lxc.rootfs.backend dir
True lxc.rootfs /home/lotso/.local/share/lxc/lxcws/rootfs
False lxc.pivotdir 'Invalid configuration key'
True lxc.utsname lxcws
False lxc.hook.pre-start
False lxc.hook.pre-mount
False lxc.hook.mount ['/usr/share/lxcfs/lxc.mount.hook']
False lxc.hook.autodev
False lxc.hook.start
False lxc.hook.stop
False lxc.hook.post-stop ['/usr/share/lxcfs/lxc.reboot.hook']
False lxc.hook.clone ['/usr/share/lxc/hooks/clonehostname']
False lxc.hook.destroy
False lxc.hook 'Invalid configuration key'
>>> True lxc.network.type 'Invalid configuration key'
>>> True lxc.network.flags 'Invalid configuration key'
>>> True lxc.network.link 'Invalid configuration key'
False lxc.network.name 'Invalid configuration key'
False lxc.network.macvlan.mode 'Invalid configuration key'
False lxc.network.veth.pair 'Invalid configuration key'
False lxc.network.script.up 'Invalid configuration key'
False lxc.network.script.down 'Invalid configuration key'
>>> True lxc.network.hwaddr 'Invalid configuration key'
False lxc.network.mtu 'Invalid configuration key'
False lxc.network.vlan.id 'Invalid configuration key'
False lxc.network.ipv4.gateway 'Invalid configuration key'
False lxc.network.ipv4 'Invalid configuration key'
False lxc.network.ipv6.gateway 'Invalid configuration key'
False lxc.network.ipv6 'Invalid configuration key'
False lxc.network ['empty', 'veth']
False lxc.cap.drop ['mac_admin', 'mac_override', 'sys_time', 'sys_module',
'sys_rawio']
False lxc.cap.keep
False lxc.console.logfile
False lxc.console
False lxc.seccomp /usr/share/lxc/config/common.seccomp
>>> True lxc.include 'Invalid configuration key'
False lxc.autodev 'Invalid configuration key'
False lxc.haltsignal 'Invalid configuration key'
False lxc.rebootsignal 'Invalid configuration key'
False lxc.stopsignal 'Invalid configuration key'
False lxc.start.auto 0
False lxc.start.delay 0
False lxc.start.order 0
False lxc.monitor.unshare 0
False lxc.group
False lxc.environment
False lxc.init_cmd
False lxc.init_uid 0
False lxc.init_gid 0
False lxc.ephemeral 0
--
benoit barthelet
http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] is there a lxc-attach -v switch equivalent in lxc python bindings ?
apologies, this was well described here :
https://lists.linuxcontainers.org/pipermail/lxc-devel/2013-August/004898.html
On Wed, Mar 15, 2017 at 9:15 AM, Benoit Barthelet <
benoit.barthe...@gmail.com> wrote:
> it seems like there's a built-in kwarg, extra_env_vars, that does the -v
> switch job of lxc-attach in fact, I wrapped it in a function here but it
> could be written without :
>
> def run_command(container, command, env={}):
> env['LANG'] = "C.UTF-8"
> env['TERM'] = "xterm"
> return container.attach_wait(
> lxc.attach_run_command, command,
> extra_env_vars=env, env_policy=lxc.LXC_ATTACH_CLEAR_ENV)
>
> run_command(container, ["env", ])
>
> returns :
>
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> container=lxc
> TERM=xterm
> LANG=C.UTF-8
>
> I managed to find it thanks to its use in http://bazaar.launchpad.net/~
> ubuntu-lxc/lxc/steam-lxc/view/head:/steam-lxc
>
> I couldn't find it documented, have I bad googling skills or is there a
> place where I could have found it ?
> If there isn't I'm ok to try document it, is there a dedicated place, wiki
> for that or it's not worth the effort ?
>
>
>
> On Tue, Mar 14, 2017 at 6:32 PM, Benoit Barthelet <
> benoit.barthe...@gmail.com> wrote:
>
>> thanks, that is exactly what I wanted !
>>
>> On Tue, Mar 14, 2017 at 1:37 PM, Stéphane Graber
>> wrote:
>>
>>> On Tue, Mar 14, 2017 at 11:22:26AM +0100, Benoit Barthelet wrote:
>>> > ultimately I'd like to do this in python:
>>> >
>>> > lxc-attach --clear-env -n lxcws -v TERM=xterm
>>> >
>>> > So far I managed to clear the env variables doing the following, but I
>>> > didn't find a way to pass the TERM env variable.
>>> >
>>> > container.attach_wait(lxc.attach_run_command,
>>> > ["apt-get", "dist-upgrade", "-y"],
>>> > env_policy=lxc.LXC_ATTACH_CLEAR_ENV)
>>>
>>> Easiest I think is to use your own attach function instead of the
>>> generic lxc.attach_run_command. In that function you can then set
>>> os.environ as you want and call subprocess to run the command you want.
>>>
>>> In the lxc-ci code we have something like this:
>>>
>>> def execute(self, cmd, cwd="/"):
>>> def run_command(args):
>>> cmd, cwd = args
>>>
>>> os.environ['PATH'] = '/usr/sbin:/usr/bin:/sbin:/bin'
>>> os.environ['HOME'] = '/root'
>>> if "env" in config and "proxy" in config['env']:
>>> os.environ["DEBIAN_FRONTEND"] = "noninteractive"
>>> os.environ['http_proxy'] = config['env']['proxy']
>>> os.environ['https_proxy'] = config['env']['proxy']
>>>
>>> return subprocess.call(cmd, cwd=cwd)
>>>
>>> if isinstance(cmd, str):
>>> pid = self.container.init_pid
>>> cmdpath = "/proc/%d/root/tmp/exec_script" % pid
>>> with open(cmdpath, "w+") as fd:
>>> fd.write(cmd)
>>> os.chmod(cmdpath, 0o755)
>>> cmd = ["/tmp/exec_script"]
>>>
>>> print(" ==> Executing: \"%s\" in %s" % (" ".join(cmd), cwd))
>>> return self.container.attach_wait(run_command,
>>> (cmd, cwd),
>>> env_policy=lxc.LXC_ATTACH_CLEA
>>> R_ENV)
>>>
>>>
>>>
>>> --
>>> Stéphane Graber
>>> Ubuntu developer
>>> http://www.ubuntu.com
>>>
>>> ___
>>> lxc-users mailing list
>>> lxc-users@lists.linuxcontainers.org
>>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>>
>>
>>
>>
>> --
>> benoit barthelet
>> http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE
>>
>
>
>
> --
> benoit barthelet
> http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE
>
--
benoit barthelet
http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] is there a lxc-attach -v switch equivalent in lxc python bindings ?
it seems like there's a built-in kwarg, extra_env_vars, that does the -v
switch job of lxc-attach in fact, I wrapped it in a function here but it
could be written without :
def run_command(container, command, env={}):
env['LANG'] = "C.UTF-8"
env['TERM'] = "xterm"
return container.attach_wait(
lxc.attach_run_command, command,
extra_env_vars=env, env_policy=lxc.LXC_ATTACH_CLEAR_ENV)
run_command(container, ["env", ])
returns :
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
container=lxc
TERM=xterm
LANG=C.UTF-8
I managed to find it thanks to its use in
http://bazaar.launchpad.net/~ubuntu-lxc/lxc/steam-lxc/view/head:/steam-lxc
I couldn't find it documented, have I bad googling skills or is there a
place where I could have found it ?
If there isn't I'm ok to try document it, is there a dedicated place, wiki
for that or it's not worth the effort ?
On Tue, Mar 14, 2017 at 6:32 PM, Benoit Barthelet <
benoit.barthe...@gmail.com> wrote:
> thanks, that is exactly what I wanted !
>
> On Tue, Mar 14, 2017 at 1:37 PM, Stéphane Graber
> wrote:
>
>> On Tue, Mar 14, 2017 at 11:22:26AM +0100, Benoit Barthelet wrote:
>> > ultimately I'd like to do this in python:
>> >
>> > lxc-attach --clear-env -n lxcws -v TERM=xterm
>> >
>> > So far I managed to clear the env variables doing the following, but I
>> > didn't find a way to pass the TERM env variable.
>> >
>> > container.attach_wait(lxc.attach_run_command,
>> > ["apt-get", "dist-upgrade", "-y"],
>> > env_policy=lxc.LXC_ATTACH_CLEAR_ENV)
>>
>> Easiest I think is to use your own attach function instead of the
>> generic lxc.attach_run_command. In that function you can then set
>> os.environ as you want and call subprocess to run the command you want.
>>
>> In the lxc-ci code we have something like this:
>>
>> def execute(self, cmd, cwd="/"):
>> def run_command(args):
>> cmd, cwd = args
>>
>> os.environ['PATH'] = '/usr/sbin:/usr/bin:/sbin:/bin'
>> os.environ['HOME'] = '/root'
>> if "env" in config and "proxy" in config['env']:
>> os.environ["DEBIAN_FRONTEND"] = "noninteractive"
>> os.environ['http_proxy'] = config['env']['proxy']
>> os.environ['https_proxy'] = config['env']['proxy']
>>
>> return subprocess.call(cmd, cwd=cwd)
>>
>> if isinstance(cmd, str):
>> pid = self.container.init_pid
>> cmdpath = "/proc/%d/root/tmp/exec_script" % pid
>> with open(cmdpath, "w+") as fd:
>> fd.write(cmd)
>> os.chmod(cmdpath, 0o755)
>> cmd = ["/tmp/exec_script"]
>>
>> print(" ==> Executing: \"%s\" in %s" % (" ".join(cmd), cwd))
>> return self.container.attach_wait(run_command,
>> (cmd, cwd),
>> env_policy=lxc.LXC_ATTACH_CLEA
>> R_ENV)
>>
>>
>>
>> --
>> Stéphane Graber
>> Ubuntu developer
>> http://www.ubuntu.com
>>
>> ___
>> lxc-users mailing list
>> lxc-users@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>
>
>
>
> --
> benoit barthelet
> http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE
>
--
benoit barthelet
http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] is there a lxc-attach -v switch equivalent in lxc python bindings ?
thanks, that is exactly what I wanted !
On Tue, Mar 14, 2017 at 1:37 PM, Stéphane Graber
wrote:
> On Tue, Mar 14, 2017 at 11:22:26AM +0100, Benoit Barthelet wrote:
> > ultimately I'd like to do this in python:
> >
> > lxc-attach --clear-env -n lxcws -v TERM=xterm
> >
> > So far I managed to clear the env variables doing the following, but I
> > didn't find a way to pass the TERM env variable.
> >
> > container.attach_wait(lxc.attach_run_command,
> > ["apt-get", "dist-upgrade", "-y"],
> > env_policy=lxc.LXC_ATTACH_CLEAR_ENV)
>
> Easiest I think is to use your own attach function instead of the
> generic lxc.attach_run_command. In that function you can then set
> os.environ as you want and call subprocess to run the command you want.
>
> In the lxc-ci code we have something like this:
>
> def execute(self, cmd, cwd="/"):
> def run_command(args):
> cmd, cwd = args
>
> os.environ['PATH'] = '/usr/sbin:/usr/bin:/sbin:/bin'
> os.environ['HOME'] = '/root'
> if "env" in config and "proxy" in config['env']:
> os.environ["DEBIAN_FRONTEND"] = "noninteractive"
> os.environ['http_proxy'] = config['env']['proxy']
> os.environ['https_proxy'] = config['env']['proxy']
>
> return subprocess.call(cmd, cwd=cwd)
>
> if isinstance(cmd, str):
> pid = self.container.init_pid
> cmdpath = "/proc/%d/root/tmp/exec_script" % pid
> with open(cmdpath, "w+") as fd:
> fd.write(cmd)
> os.chmod(cmdpath, 0o755)
> cmd = ["/tmp/exec_script"]
>
> print(" ==> Executing: \"%s\" in %s" % (" ".join(cmd), cwd))
> return self.container.attach_wait(run_command,
> (cmd, cwd),
> env_policy=lxc.LXC_ATTACH_
> CLEAR_ENV)
>
>
>
> --
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
--
benoit barthelet
http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] is there a lxc-attach -v switch equivalent in lxc python bindings ?
ultimately I'd like to do this in python: lxc-attach --clear-env -n lxcws -v TERM=xterm So far I managed to clear the env variables doing the following, but I didn't find a way to pass the TERM env variable. container.attach_wait(lxc.attach_run_command, ["apt-get", "dist-upgrade", "-y"], env_policy=lxc.LXC_ATTACH_CLEAR_ENV) -- benoit barthelet http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] PATH set weirdly in an unprivileged container ?
mmm *--clear-env *indeed looks like what I was looking for, using it leads to a "clean" PATH Now shouldn't that be the default ? This looks so weird to me to have a PATH with stuff from the host by default, but again all this is new to me so that's just a comment like that :) thanks for the tip ! On Fri, Mar 3, 2017 at 5:39 PM, Stéphane Graber wrote: > On Fri, Mar 03, 2017 at 05:27:25PM +0100, Benoit Barthelet wrote: > > Hello, > > > > It's my first few hours playing with containers so maybe there's > something > > I'm doing wrong or something I overlook, or both. > > > > I'm on debian stretch if that's relevant, using : > > > > ➜ ~ lxc-info --version > > 2.0.7 > > > > I set up an unprivileged container this way: > > > > ➜ ~ lxc-create -t download -n u1 -- -d ubuntu -r xenial -a amd64 > > Using image from local cache > > Unpacking the rootfs > > > > --- > > You just created an Ubuntu container (release=xenial, arch=amd64, > > variant=default) > > > > To enable sshd, run: apt-get install openssh-server > > > > For security reason, container images ship without user accounts > > and without a root password. > > > > Use lxc-attach or chroot directly into the rootfs to set a root password > > or create user accounts. > > > > I then start it and attach: > > > > ➜ ~ lxc-start -n u1 > > ➜ ~ lxc-attach -n u1 > > root@u1:/# echo $PATH > > /home/HOST_USER/bin:/usr/local/bin:/home/HOST_USER/ > Applications/.bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games > > lxc-attach uses its own environment inside the container. There are a > number of lxc-attach options to alter this behavior. > > > > > Now as you can see /sbin is not in the PATH, which means any apt-get > > install BLABLABLA ends up with the following error: > > > > dpkg: warning: 'ldconfig' not found in PATH or not executable > > dpkg: warning: 'start-stop-daemon' not found in PATH or not executable > > dpkg: error: 2 expected programs not found in PATH or not executable > > Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and > > /sbin > > E: Sub-process /usr/bin/dpkg returned an error code (2) > > > > If I do the exact same commands with sudo, thus creating a NOT > unprivileged > > container, if I got it correctly, well the PATH is "correctly" set up, at > > least /sbin is in it and I can apt-get install anything. > > > > When I say correctly I should say: the way I would expect it when I'm > root. > > That makes me think there's a subtlety about unprivileged container I > don't > > get. > > > > Asking in IRC, I got this answer, which works, I should use: > > > > ➜ ~ lxc-execute -n u1 -- /bin/bash --login > > > > > > Now reading both man pages for attach and execute, at first glance they > > seem to be doing the same except one spawn the instance while the other > > doesn't and uses the one that is running. > > > > Again it's been only a few hours I'm playing with it. > > > > I don't get why in the case of the container created with sudo the PATH > is > > "correct", and not in the case of the unprivileged container. > > > > Is it intended ? It's kind of weird to be root in a machine and unable to > > install a package because of the PATH, hence those questions. > > > > Looking at the templates, it seems they export that PATH > > > > ➜ ~ grep PATH /usr/share/lxc/templates/lxc-ubuntu > > # Make sure the usual locations are in PATH > > export PATH=$PATH:/usr/sbin:/usr/bin:/sbin:/bin > > > > So the -t download switch doesn't use that ? > > > > > > Thanks in advance > > > > > > -- > > benoit barthelet > > http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE > > > ___ > > lxc-users mailing list > > lxc-users@lists.linuxcontainers.org > > http://lists.linuxcontainers.org/listinfo/lxc-users > > > -- > Stéphane Graber > Ubuntu developer > http://www.ubuntu.com > > ___ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users > -- benoit barthelet http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] PATH set weirdly in an unprivileged container ?
Hello, It's my first few hours playing with containers so maybe there's something I'm doing wrong or something I overlook, or both. I'm on debian stretch if that's relevant, using : ➜ ~ lxc-info --version 2.0.7 I set up an unprivileged container this way: ➜ ~ lxc-create -t download -n u1 -- -d ubuntu -r xenial -a amd64 Using image from local cache Unpacking the rootfs --- You just created an Ubuntu container (release=xenial, arch=amd64, variant=default) To enable sshd, run: apt-get install openssh-server For security reason, container images ship without user accounts and without a root password. Use lxc-attach or chroot directly into the rootfs to set a root password or create user accounts. I then start it and attach: ➜ ~ lxc-start -n u1 ➜ ~ lxc-attach -n u1 root@u1:/# echo $PATH /home/HOST_USER/bin:/usr/local/bin:/home/HOST_USER/Applications/.bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games Now as you can see /sbin is not in the PATH, which means any apt-get install BLABLABLA ends up with the following error: dpkg: warning: 'ldconfig' not found in PATH or not executable dpkg: warning: 'start-stop-daemon' not found in PATH or not executable dpkg: error: 2 expected programs not found in PATH or not executable Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin E: Sub-process /usr/bin/dpkg returned an error code (2) If I do the exact same commands with sudo, thus creating a NOT unprivileged container, if I got it correctly, well the PATH is "correctly" set up, at least /sbin is in it and I can apt-get install anything. When I say correctly I should say: the way I would expect it when I'm root. That makes me think there's a subtlety about unprivileged container I don't get. Asking in IRC, I got this answer, which works, I should use: ➜ ~ lxc-execute -n u1 -- /bin/bash --login Now reading both man pages for attach and execute, at first glance they seem to be doing the same except one spawn the instance while the other doesn't and uses the one that is running. Again it's been only a few hours I'm playing with it. I don't get why in the case of the container created with sudo the PATH is "correct", and not in the case of the unprivileged container. Is it intended ? It's kind of weird to be root in a machine and unable to install a package because of the PATH, hence those questions. Looking at the templates, it seems they export that PATH ➜ ~ grep PATH /usr/share/lxc/templates/lxc-ubuntu # Make sure the usual locations are in PATH export PATH=$PATH:/usr/sbin:/usr/bin:/sbin:/bin So the -t download switch doesn't use that ? Thanks in advance -- benoit barthelet http://pgp.mit.edu/pks/lookup?op=get&search=0xF150E01A72F6D2EE ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
