[lxc-devel] new tag on stable-3.0 to mark CVE-2019-5736 as resolved?
Hi folks, AFAICS stable-2.0 has got a new tag 2.0.11, including a fix for CVE-2019-5736. There is no new tag on stable-3.0, even though the fix appears to be in, too. Wouldn't it be reasonable to introduce new tags, esp. if a CVE has been fixed on a LTS branch? Is there something missing on stable-3.0 that should be fixed first? Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] improving compatibility with RHEL 7.4 in templates/lxc-centos.in
Hi folks,
attached you can find a patch for the lxc-centos template
script, making it more compatible with RHEL 7.4.
Issues fixed:
- lxc-centos died about a missing /run directory
- lxc-centos complained about some config files it couldn't modify
- the new container got stuck at startup time for a minute
(literally), waiting for systemd-remount-fs startup script
Of course it still works for RHEL6, CentOS 6 and 7 as well. I did
not verify earlier CentOS or RHEL releases.
Would you mind to include it into git for a future lxc release
(for stable-2.0, stable-2.1 and master, please)?
Thanx in advance
Harri
Patch for templates/lxc-centos.in, making it more compatible with RHEL 7.4
Issues fixed:
- lxc-centos died about a missing /run directory
- lxc-centos complained about some config files it couldn't modify
- the new container got stuck at startup time for a minute
(literally), waiting for systemd-remount-fs startup script
Of course it still works for RHEL 6, CentOS 6 and 7 as well. I did
not verify earlier CentOS or RHEL releases.
Signed-off-by: Harald Dunkel
Index: lxc-2.0.9/templates/lxc-centos.in
===
--- lxc-2.0.9.orig/templates/lxc-centos.in
+++ lxc-2.0.9/templates/lxc-centos.in
@@ -351,7 +351,7 @@ EOF
# prevent mingetty from calling vhangup(2) since it fails with userns.
# Same issue as oracle template: prevent mingetty from calling vhangup(2)
# commit 2e83f7201c5d402478b9849f0a85c62d5b9f1589.
-sed -i 's|mingetty|mingetty --nohangup|' $rootfs_path/etc/init/tty.conf
+test -f $rootfs_path/etc/init/tty.conf && sed -i 's|mingetty|mingetty --nohangup|' $rootfs_path/etc/init/tty.conf
if [ ${root_display_password} = "yes" ]
then
@@ -381,13 +381,18 @@ EOF
configure_centos_init()
{
-sed -i 's|.sbin.start_udev||' ${rootfs_path}/etc/rc.sysinit
-sed -i 's|.sbin.start_udev||' ${rootfs_path}/etc/rc.d/rc.sysinit
+test -f ${rootfs_path}/etc/rc.sysinit && sed -i 's|.sbin.start_udev||' ${rootfs_path}/etc/rc.sysinit
+test -f ${rootfs_path}/etc/rc.d/rc.sysinit && sed -i 's|.sbin.start_udev||' ${rootfs_path}/etc/rc.d/rc.sysinit
if [ "$release" = "6" ]; then
chroot ${rootfs_path} chkconfig udev-post off
fi
chroot ${rootfs_path} chkconfig network on
+if [ "$release" = "7" ]; then
+ # don't wait for the timeout
+ chroot ${rootfs_path} chkconfig systemd-remount-fs off
+fi
+
if [ -d ${rootfs_path}/etc/init ]
then
# This is to make upstart honor SIGPWR
@@ -462,6 +467,9 @@ EOF
force_mknod 666 $INSTALL_ROOT/dev/null c 1 3
force_mknod 666 $INSTALL_ROOT/dev/urandom c 1 9
+# create /run directory, just in case it is missing (e.g. RHEL7)
+mkdir -p $INSTALL_ROOT/run
+
$YUM install $PKG_LIST
# create symlink for /var/run -> ../run
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-stop: umount issue?
Hi Christian,
On 12/11/17 4:17 PM, Christian Brauner wrote:
What is the container's config file? liblxc itself does not know what
drbd devices are and cannot create such containers. So I expect your
container's config file to contain a line like:
lxc.rootfs = /data1//rootfs
Here is a sample config file:
lxc.network.type = veth
lxc.network.link = br5
lxc.network.flags = up
lxc.network.hwaddr = 00:16:66:bd:77:7b
lxc.network.ipv4 = 192.168.142.xxx/26
lxc.network.ipv4.gateway = 192.168.142.yyy
lxc.network.type = veth
lxc.network.link = br4
lxc.network.flags = up
lxc.network.hwaddr = 00:16:49:2f:f3:ae
lxc.network.ipv4 = 10.111.111.xxx/24
lxc.rootfs = /data2/lxc/lxc01/rootfs
lxc.rootfs.backend = dir
# Common configuration
lxc.include = /usr/share/lxc/config/debian.common.conf
# Container specific configuration
lxc.mount = /data2/lxc/lxc01/fstab
lxc.tty = 4
lxc.utsname = lxc01
lxc.arch = amd64
lxc.start.auto = 1
lxc.group = auto
The fstab file is empty.
without a storage type prefix and without lxc.rootfs.backend (for old
liblxc versions) set. In this case liblxc will use the dir storage
driver. So liblxc itself should never try to unmount anything on the
host on shutdown especially not /data1. The only interesting thing
liblxc does when the dir storage driver is used is to give itself a bind
mount for the root filesystem in the container's mount namespace. Are
you using any ({post-}stop) hooks?
No hooks, AFAICT. What about all these /proc and /sys filesystems,
tmpfs and all that other stuff? Inside the container (config file
shown above) I see
# cat /proc/self/mounts
/dev/drbd2 / ext4 rw,noatime,stripe=256,data=ordered 0 0
none /dev tmpfs rw,relatime,size=492k,mode=755 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
proc /proc/sys/net proc rw,nosuid,nodev,noexec,relatime 0 0
proc /proc/sys proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/sysrq-trigger proc ro,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs ro,nosuid,nodev,noexec,relatime 0 0
sysfs /sys/devices/virtual/net sysfs rw,relatime 0 0
sysfs /sys/devices/virtual/net sysfs rw,nosuid,nodev,noexec,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
devpts /dev/console devpts
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=666 0 0
devpts /dev/ptmx devpts rw,relatime,gid=5,mode=620,ptmxmode=666 0 0
devpts /dev/tty1 devpts rw,relatime,gid=5,mode=620,ptmxmode=666 0 0
devpts /dev/tty2 devpts rw,relatime,gid=5,mode=620,ptmxmode=666 0 0
devpts /dev/tty3 devpts rw,relatime,gid=5,mode=620,ptmxmode=666 0 0
devpts /dev/tty4 devpts rw,relatime,gid=5,mode=620,ptmxmode=666 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup
rw,nosuid,nodev,noexec,relatime,release_agent=/run/cgmanager/agents/cgm-release-agent.systemd,name=systemd
0 0
cgroup /sys/fs/cgroup/cpuset cgroup
rw,nosuid,nodev,noexec,relatime,cpuset,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuset,clone_children
0 0
cgroup /sys/fs/cgroup/blkio cgroup
rw,nosuid,nodev,noexec,relatime,blkio,release_agent=/run/cgmanager/agents/cgm-release-agent.blkio
0 0
cgroup /sys/fs/cgroup/memory cgroup
rw,nosuid,nodev,noexec,relatime,memory,release_agent=/run/cgmanager/agents/cgm-release-agent.memory
0 0
cgroup /sys/fs/cgroup/devices cgroup
rw,nosuid,nodev,noexec,relatime,devices,release_agent=/run/cgmanager/agents/cgm-release-agent.devices
0 0
cgroup /sys/fs/cgroup/freezer cgroup
rw,nosuid,nodev,noexec,relatime,freezer,release_agent=/run/cgmanager/agents/cgm-release-agent.freezer
0 0
cgroup /sys/fs/cgroup/perf_event cgroup
rw,nosuid,nodev,noexec,relatime,perf_event,release_agent=/run/cgmanager/agents/cgm-release-agent.perf_event
0 0
cgroup /sys/fs/cgroup/pids cgroup
rw,nosuid,nodev,noexec,relatime,pids,release_agent=/run/cgmanager/agents/cgm-release-agent.pids
0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
tmpfs /run/user/402 tmpfs
rw,nosuid,nodev,relatime,size=26406048k,mode=700,uid=402,gid=402 0 0
tmpfs /run/user/0 tmpfs rw,nosuid,nodev,relatime,size=26406048k,mode=700 0 0
Does this look OK?
Regards
Harri
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-stop: umount issue?
Hi Serge, On 12/11/17 4:40 AM, Serge E. Hallyn wrote: Quoting Harald Dunkel (ha...@afaics.de): On 12/07/17 22:30, Serge E. Hallyn wrote: What filesystem are you using? ext4 on a drbd block device: /dev/drbd1 /data1 ext4 rw,noatime,stripe=256,data=ordered 0 0 I have to think drbd would be the problem. But I assume you haven't seen any other issues with it other than lxc? The cluster does only LXC, DRBD, and it forwards the network communication between the containers and the outside world. Each container has its own firewall rules for access control. The cluster sits behind a big openBSD firewall controlling access from and to the internet. I have 7 drbd clusters running LXC (Debian 8 or newer, sysvinit). Some are much more complex, but only this one cluster has this problem (on both hosts). The funny part is, if it ran into this problem and recovered from it, then the problem doesn't come back. I can stop other LXCs without problem. It appears to me that something got woken up. I am not sure if this is still the case after a few additional weeks of runtime, though. Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-stop: umount issue?
On 12/07/17 22:30, Serge E. Hallyn wrote: > > What filesystem are you using? ext4 on a drbd block device: /dev/drbd1 /data1 ext4 rw,noatime,stripe=256,data=ordered 0 0 Regards Harri signature.asc Description: OpenPGP digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] lxc-stop: umount issue?
Hi folks, If a LXC server ran for several weeks and if I try to stop a container, then the server gets stuck for a few minutes (see attachment). Please note the : [8541088.226013] Task dump for CPU 31: [8541088.226015] mount R : This might be common for all incidents of this kind, but I lost some logfiles, so I am not 100% sure. Is this a known issue? Any recommendations for a workaround? The host runs Debian Jessie with kernel 4.9.30-2~bpo8+1. LXC is version 2.0.8. Every helpful comment is highly appreciated. Harri : : [7699680.691003] br5: port 14(vethMQFEFK) entered forwarding state [7699680.752888] cgroup: new mount options do not match the existing superblock, will be ignored [8107259.663902] perf: interrupt took too long (4948 > 4912), lowering kernel.perf_event_max_sample_rate to 40250 [8541088.217956] INFO: rcu_sched self-detected stall on CPU [8541088.226003] INFO: rcu_sched detected stalls on CPUs/tasks: [8541088.226008] 31-...: (5249 ticks this GP) idle=629/141/0 softirq=409754810/409754810 fqs=2905 [8541088.226009] [8541088.226012] (detected by 21, t=5252 jiffies, g=365563379, c=365563378, q=18871608) [8541088.226013] Task dump for CPU 31: [8541088.226015] mount R [8541088.226015] running task [8541088.226017] 0 21694 21690 0x0108 [8541088.226020] 9bf231e8cb40 [8541088.226020] ff10 [8541088.226021] 8381a732 [8541088.226022] 0010 [8541088.226023] 0a02 [8541088.226023] a8f3323efd88 [8541088.226024] 0018 [8541088.226025] 0010 [8541088.226026] 8381b6fa [8541088.226026] 9c23e8e9e600 [8541088.226027] 9bf231e8cbc0 [8541088.226027] 9bf231e8cb98 [8541088.226028] Call Trace: [8541088.226037] [] ? __d_drop+0x32/0x90 [8541088.226040] [] ? __dentry_kill+0x4a/0x150 [8541088.226042] [] ? shrink_dentry_list+0xca/0x2e0 [8541088.226045] [] ? shrink_dcache_sb+0xd2/0x120 [8541088.226048] [] ? do_remount_sb+0x15c/0x1d0 [8541088.226051] [] ? do_mount+0x709/0xc70 [8541088.226056] [] ? memdup_user+0x4a/0x70 [8541088.226058] [] ? SyS_mount+0x84/0xc0 [8541088.226062] [] ? do_syscall_64+0x81/0x190 [8541088.226066] [] ? entry_SYSCALL64_slow_path+0x25/0x25 [8541088.485916] 31-...: (5249 ticks this GP) idle=629/141/0 softirq=409754810/409754810 fqs=2935 [8541088.603637] (t=5351 jiffies g=365563379 c=365563378 q=18872108) [8541088.678791] Task dump for CPU 31: [8541088.678793] mount R running task0 21694 21690 0x0108 [8541088.678797] 0087 836a4f83 001f 0087 [8541088.678799] 8377c501 9c23ff5d9540 8424e3c0 [8541088.678800] 9c1bc35af000 836e145e 9c23ff5d87c0 000187c0 [8541088.678802] Call Trace: [8541088.678804] [8541088.678811] [] ? sched_show_task+0xd3/0x140 [8541088.678816] [] ? rcu_dump_cpu_stacks+0x7b/0xb4 [8541088.678821] [] ? rcu_check_callbacks+0x6be/0x800 [8541088.678825] [] ? tick_sched_do_timer+0x30/0x30 [8541088.678827] [] ? update_process_times+0x28/0x50 [8541088.678828] [] ? tick_sched_handle.isra.13+0x20/0x50 [8541088.678829] [] ? tick_sched_timer+0x38/0x70 [8541088.678830] [] ? __hrtimer_run_queues+0xdc/0x250 [8541088.678831] [] ? hrtimer_interrupt+0x99/0x190 [8541088.678837] [] ? smp_apic_timer_interrupt+0x39/0x50 [8541088.678838] [] ? apic_timer_interrupt+0x82/0x90 [8541088.678839] [8541088.678843] [] ? __d_drop+0x32/0x90 [8541088.678845] [] ? __dentry_kill+0x4a/0x150 [8541088.678846] [] ? shrink_dentry_list+0xca/0x2e0 [8541088.678847] [] ? shrink_dcache_sb+0xd2/0x120 [8541088.678850] [] ? do_remount_sb+0x15c/0x1d0 [8541088.678853] [] ? do_mount+0x709/0xc70 [8541088.678857] [] ? memdup_user+0x4a/0x70 [8541088.678859] [] ? SyS_mount+0x84/0xc0 [8541088.678862] [] ? do_syscall_64+0x81/0x190 [8541088.678864] [] ? entry_SYSCALL64_slow_path+0x25/0x25 [8541098.554005] [ cut here ] [8541098.554030] WARNING: CPU: 21 PID: 0 at /build/linux-PrKZyy/linux-4.9.30/net/sched/sch_generic.c:316 dev_watchdog+0x220/0x230 [8541098.554032] NETDEV WATCHDOG: eth2 (igb): transmit queue 3 timed out [8541098.554033] Modules linked in: tcp_diag inet_diag 8021q garp mrp xt_multiport xt_REDIRECT nf_nat_redirect nf_log_ipv6 nf_log_ipv4 nf_log_common xt_LOG xt_limit ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_conntrack veth bonding bridge stp llc iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_mangle iptable_filter ip_tables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 nf_nat nf_conntrack ip6table_mangle ip6table_filter ip6_tables x_tables fuse drbd lru_cache libcrc32c crc32c_generic dm_crypt intel_rapl sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate joydev evdev intel_uncore mxm_wmi ipmi_devintf mei_me iTCO_wdt iTCO_v
Re: [lxc-devel] lxc-create: file-based capabilities are lost
On Sat, 29 Jul 2017 14:06:17 +0200 Christian Brauner wrote: > Merged the patch today. Thanks guys! > Would it be possible to merge this change into the 2.0 branch as well? Thanx very much Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-create: file-based capabilities are lost
PS: On Thu, 27 Jul 2017 08:45:49 -0500 "Serge E. Hallyn" wrote: > > It looks like these were done by commit > 44d397891e691ab994a69766cc72e57265b62da1, > and lxc-2.0.0 does have that commit. > 44d397891e691ab994a69766cc72e57265b62da1 was created on Mon Dec 3 09:53:10 2012, i.e. about 18 months before I posted my fix. This is pretty unlikely. Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-create: file-based capabilities are lost
I verified this on github:
% cd /tmp
% git clone git://github.com/lxc/lxc
Cloning into 'lxc'...
remote: Counting objects: 38059, done.
remote: Compressing objects: 100% (30/30), done.
remote: Total 38059 (delta 19), reused 31 (delta 14), pack-reused 38015
Receiving objects: 100% (38059/38059), 13.15 MiB | 2.62 MiB/s, done.
Resolving deltas: 100% (28288/28288), done.
% cd lxc/
% git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/stable-0.7.4
remotes/origin/stable-1.0
remotes/origin/stable-1.1
remotes/origin/stable-2.0
% git checkout stable-2.0
Branch stable-2.0 set up to track remote branch stable-2.0 from origin.
Switched to a new branch 'stable-2.0'
% git log -n 1
commit c1922c2cdb3910b9d0347d17972f3594ec966750 (HEAD -> stable-2.0,
origin/stable-2.0)
Author: KATOH Yasufumi
Date: Tue Jun 20 17:36:30 2017 +0900
doc: Untabify Japanese lxc.container.conf(5)
Tab and white space is mixed in Japanese lxc.container.conf(5), so
unify into the white space.
Signed-off-by: KATOH Yasufumi
% grep rsync templates/* | grep rootfs
templates/lxc-altlinux.in:rsync -Ha $cache/rootfs/ $rootfs_path/
templates/lxc-centos.in:rsync -a $cache/rootfs/ $rootfs_path/
templates/lxc-debian.in:rsync -Ha "$cache/rootfs-$release-$arch"/
"$rootfs"/ || return 1
templates/lxc-fedora.in:rsync -Ha $cache/rootfs/ $rootfs_path/
templates/lxc-openmandriva.in:rsync -Ha $cache/rootfs/ $rootfs_path/
templates/lxc-opensuse.in:rsync -Ha $cache/rootfs-$arch/ $rootfs/ || return
1
templates/lxc-ubuntu.in: rsync -Ha $cache/rootfs-$arch/ $rootfs/ || return
1
Same on the master branch:
% git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
% grep rsync templates/* | grep rootfs
templates/lxc-altlinux.in:rsync -Ha $cache/rootfs/ $rootfs_path/
templates/lxc-centos.in:rsync -a $cache/rootfs/ $rootfs_path/
templates/lxc-debian.in:rsync -Ha "$cache/rootfs-$release-$arch"/
"$rootfs"/ || return 1
templates/lxc-fedora-legacy.in:rsync -Ha $cache/rootfs/ $rootfs_path/
templates/lxc-fedora.in:rsync --archive --hard-links --sparse "${cache}/"
"${rootfs}/" &&
templates/lxc-fedora.in:options=$(getopt -o a:hp:n:cR:dP:M: -l
help,path:,rootfs:,name:,clean,release:,arch:,debug,fqdn:,mask-tmp,mirror:,packages:,rsync
-- "$@")
templates/lxc-openmandriva.in:rsync -Ha $cache/rootfs/ $rootfs_path/
templates/lxc-opensuse.in:rsync -Ha $cache/rootfs-$arch/ $rootfs/ || return
1
templates/lxc-ubuntu.in: rsync -Ha $cache/rootfs-$arch/ $rootfs/ || return
1
Regards
Harri
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-create: file-based capabilities are lost
Hi Serge,
apparently all these fixes have been lost on the 2.0 branch:
{hdunkel@dpcl082:lxc (stable-2.0) 507} grep rsync templates/* | grep rootfs
templates/lxc-altlinux.in:rsync -Ha $cache/rootfs/ $rootfs_path/
templates/lxc-centos.in:rsync -a $cache/rootfs/ $rootfs_path/
templates/lxc-debian.in:rsync -Ha "$cache/rootfs-$release-$arch"/
"$rootfs"/ || return 1
templates/lxc-fedora.in:rsync -Ha $cache/rootfs/ $rootfs_path/
templates/lxc-openmandriva.in:rsync -Ha $cache/rootfs/ $rootfs_path/
templates/lxc-opensuse.in:rsync -Ha $cache/rootfs-$arch/ $rootfs/ || return
1
templates/lxc-ubuntu.in: rsync -Ha $cache/rootfs-$arch/ $rootfs/ || return
1
Would you mind to merge?
Thanx in advance
Harri
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] config/init/common/lxc-containers.in broken if number of bridges > 1, patch included
Is there anything missing? Some feedback would be highly appreciated. Harri On 02/21/2017 04:29 PM, Harald Dunkel wrote: > Hi folks, > > if /etc/lxc/default.conf defines 2 or more bridges, then > I get a ton of warnings: > > # service lxc restart > [] Stopping LXC containers: :[] Starting LXC autoboot containers: > :/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > /usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0: > unexpected operator > > AFAICS $BRNAME (set in /usr/lib/x86_64-linux-gnu/lxc/lxc-containers:57) > contains all bridge names seperated by space, which breaks the test > in line 63. > > Attached is a suggested fix. Surely not beautiful, but it seems to > work better. > > > Hope this helps. Regards > Harri > > > > ___ > 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
[lxc-devel] config/init/common/lxc-containers.in broken if number of bridges > 1, patch included
Hi folks,
if /etc/lxc/default.conf defines 2 or more bridges, then
I get a ton of warnings:
# service lxc restart
[] Stopping LXC containers: :[] Starting LXC autoboot containers:
:/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers: 63: [: /sys/class/net/br0:
unexpected operator
AFAICS $BRNAME (set in /usr/lib/x86_64-linux-gnu/lxc/lxc-containers:57)
contains all bridge names seperated by space, which breaks the test
in line 63.
Attached is a suggested fix. Surely not beautiful, but it seems to
work better.
Hope this helps. Regards
Harri
--
aixigo AG, Karl-Friedrich-Strasse 68, 52072 Aachen, Germany
phone: +49 241 559709-79, fax: +49 241 559709-99
eMail: harald.dun...@aixigo.de, web: http://www.aixigo.de
Amtsgericht Aachen - HRB 8057, Vorstand: Erich Borsch, Christian Friedrich,
Tobias Haustein, Vors. des Aufsichtsrates: Prof. Dr. Ruediger von Nitzsch
Signed-off-by: Harald Dunkel
Index: lxc-1.1.5.1/config/init/common/lxc-containers.in
===
--- lxc-1.1.5.1.orig/config/init/common/lxc-containers.in
+++ lxc-1.1.5.1/config/init/common/lxc-containers.in
@@ -51,7 +51,7 @@ fi
# to start
wait_for_bridge()
{
-local BRNAME try flags
+local BRNAME try flags br
[ -f "$sysconfdir"/lxc/default.conf ] || { return 0; }
BRNAME=`grep '^[ ]*lxc.network.link' "$sysconfdir"/lxc/default.conf | sed 's/^.*=[ ]*//'`
@@ -60,11 +60,12 @@ wait_for_bridge()
fi
for try in `seq 1 30`; do
-if [ -r /sys/class/net/$BRNAME/flags ]; then
-read flags < /sys/class/net/$BRNAME/flags
-[ $((flags & 0x1)) -eq 1 ] && { return 0; }
-fi
-sleep 1
+ for br in ${BRNAME}; do
+ [ -r /sys/class/net/${br}/flags ] || { sleep 1; continue 2; }
+ read flags < /sys/class/net/${br}/flags
+ [ $((flags & 0x1)) -eq 1 ] || { sleep 1; continue 2; }
+ done
+ return 0
done
}
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] please open lxc-cgroup for unprivileged monitoring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Serge, On 10/21/16 16:56, Serge E. Hallyn wrote: > Quoting Harald Dunkel (harald.dun...@aixigo.de): >> On 10/20/2016 03:39 PM, Serge E. Hallyn wrote: >>> On Wed, Oct 19, 2016 at 02:10:59PM +0200, Harald Dunkel wrote: >>>> >>>> Following the api I am forced to use root permission or some >>>> hard-to-configure sudo constructs for monitoring. This is pretty painful. >>>> >>>> Do you think this could be improved? >>> >>> Not easily, because you won't be allowed to talk to the container control >>> socket to ask it its cgroup. >> >> I am not sure if I got this correctly, but don't you already need this >> string to talk with the container? > > lxc-cgroup talks to the container to find out the cgroup it is running in. > There could for instance be several containers called 'c1' (in different > lxcpaths), which could be running in cgroups c1, c1.0, and c1.1. And for each > controller the cgroup name could be different. Are there news about this? Monitoring is highly important in my environment. I am desperate. Regards Harri -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJYIWXvAAoJEAqeKp5m04HLb9wH/3yyOp+OZuyCQO1klj5jOyAl 8Ff/EIGJX+JcZktVfCA1bA7oKM9hdeqXJLT8xDiNbV0GA/B2Nsmfts/xKZcknBYs l9rIhMRhxuF1a+XgXnJ1tp++9mOPyiW2vmyzkmMDGXF0PyayY7t4X9cTFOBGUPGA cw/jAMnxY9Pc/YXJQC0nhm6Vp17TzidGW5tf5EMrMmVuR2Y7VqV+WCXhuwOhHUOE XAjTEgvvbezZbZAADKeZFzPXYUoveFm/PMMWN6VzEup0GAnPxYNW1kUXF12/zTyL m+/Oc81AUIUP4NskeNU1V/dEoersS05/uuNrLeYWgPls+3DMF43d45fjy7ZyyUQ= =tJbI -END PGP SIGNATURE- ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] please open lxc-cgroup for unprivileged monitoring
Hi Serge, On 10/21/2016 04:56 PM, Serge E. Hallyn wrote: > > lxc-cgroup talks to the container to find out the cgroup it is running > in. There could for instance be several containers called 'c1' (in > different lxcpaths), which could be running in cgroups c1, c1.0, and c1.1. > And for each controller the cgroup name could be different. I understand that naming collisions must be taken care of, but the current implementation just moves the problem to somewhere else: Now everybody interested needs access to the mapping between the container name and the cgroup path. Apparently this became a write operation, even though a read operation should do. sysctl performs a similar task as lxc-cgroup, and yet I don't have to be root to run "sysctl -a". Do you think lxc-cgroup could be modified accordingly? Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] please open lxc-cgroup for unprivileged monitoring
On 10/20/2016 03:39 PM, Serge E. Hallyn wrote: > On Wed, Oct 19, 2016 at 02:10:59PM +0200, Harald Dunkel wrote: >> >> Following the api I am forced to use root permission or some >> hard-to-configure sudo constructs for monitoring. This is >> pretty painful. >> >> Do you think this could be improved? > > Not easily, because you won't be allowed to talk to the container > control socket to ask it its cgroup. I am not sure if I got this correctly, but don't you already need this string to talk with the container? ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] please open lxc-cgroup for unprivileged monitoring
Hi folks, using an unprivileged account for monitoring lxc-cgroup returns a "permission denied" messages for something that is world readable in the /cgroup directory. Sample: % lxc-cgroup -P /data1/lxc -n jerry1 memory.usage_in_bytes lxc-cgroup: tools/lxc_cgroup.c: main: 104 Insufficent privileges to control /data1/lxc:jerry1 % cat /cgroup/lxc/jerry1/memory.usage_in_bytes 286883840 Following the api I am forced to use root permission or some hard-to-configure sudo constructs for monitoring. This is pretty painful. Do you think this could be improved? lxc is version 2.0.5. Thanx in advance Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-create: file-based capabilities are lost
Hi Serge, On 06/15/16 19:00, Serge E. Hallyn wrote: > Quoting Harald Dunkel (harald.dun...@aixigo.de): >> >> Using "rsync -SHaAX" in lxc-debian it works (on Jessie). >> Attached you can find a suggested patch for all (lxc 1.1.5). > > Thanks this looks good. Do you mind sending a signed-off-by? > See attachment. This change is based upon the stable-1.1 branch. I kicked out one of the changes of my previous post, though. The fedora template uses rsync on squashfs. This is too hot for me to touch. Regards Harri From b6c4371f038013121a753080ad9062f1896566f8 Mon Sep 17 00:00:00 2001 From: Harald Dunkel Date: Thu, 16 Jun 2016 11:26:03 +0200 Subject: [PATCH] use "rsync -SHaAX" to copy the cached rootfs into place Signed-off-by: Harald Dunkel --- templates/lxc-altlinux.in | 2 +- templates/lxc-centos.in | 2 +- templates/lxc-debian.in | 2 +- templates/lxc-fedora.in | 2 +- templates/lxc-openmandriva.in | 2 +- templates/lxc-opensuse.in | 2 +- templates/lxc-ubuntu.in | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/templates/lxc-altlinux.in b/templates/lxc-altlinux.in index 8b4168c..3412772 100644 --- a/templates/lxc-altlinux.in +++ b/templates/lxc-altlinux.in @@ -208,7 +208,7 @@ copy_altlinux() #cp -a $cache/rootfs-$arch $rootfs_path || return 1 # i prefer rsync (no reason really) mkdir -p $rootfs_path -rsync -Ha $cache/rootfs/ $rootfs_path/ +rsync -SHaAX $cache/rootfs/ $rootfs_path/ return 0 } diff --git a/templates/lxc-centos.in b/templates/lxc-centos.in index 1a27cd3..1e04b10 100644 --- a/templates/lxc-centos.in +++ b/templates/lxc-centos.in @@ -512,7 +512,7 @@ copy_centos() #cp -a $cache/rootfs-$arch $rootfs_path || return 1 # i prefer rsync (no reason really) mkdir -p $rootfs_path -rsync -a $cache/rootfs/ $rootfs_path/ +rsync -SHaAX $cache/rootfs/ $rootfs_path/ echo return 0 } diff --git a/templates/lxc-debian.in b/templates/lxc-debian.in index 54393ca..33fe1ec 100644 --- a/templates/lxc-debian.in +++ b/templates/lxc-debian.in @@ -283,7 +283,7 @@ copy_debian() # make a local copy of the minidebian echo -n "Copying rootfs to $rootfs..." mkdir -p $rootfs -rsync -Ha "$cache/rootfs-$release-$arch"/ $rootfs/ || return 1 +rsync -SHaAX "$cache/rootfs-$release-$arch"/ $rootfs/ || return 1 return 0 } diff --git a/templates/lxc-fedora.in b/templates/lxc-fedora.in index f6e5be5..624e755 100644 --- a/templates/lxc-fedora.in +++ b/templates/lxc-fedora.in @@ -1015,7 +1015,7 @@ copy_fedora() #cp -a $cache/rootfs-$basearch $rootfs_path || return 1 # i prefer rsync (no reason really) mkdir -p $rootfs_path -rsync -Ha $cache/rootfs/ $rootfs_path/ +rsync -SHaAX $cache/rootfs/ $rootfs_path/ echo return 0 } diff --git a/templates/lxc-openmandriva.in b/templates/lxc-openmandriva.in index 6123c5e..2b690b6 100644 --- a/templates/lxc-openmandriva.in +++ b/templates/lxc-openmandriva.in @@ -155,7 +155,7 @@ copy_openmandriva() echo -n "Copying rootfs to $rootfs_path ..." mkdir -p $rootfs_path -rsync -Ha $cache/rootfs/ $rootfs_path/ +rsync -SHaAX $cache/rootfs/ $rootfs_path/ return 0 } diff --git a/templates/lxc-opensuse.in b/templates/lxc-opensuse.in index d4e2b28..a69c451 100644 --- a/templates/lxc-opensuse.in +++ b/templates/lxc-opensuse.in @@ -221,7 +221,7 @@ copy_opensuse() # make a local copy of the mini opensuse echo "Copying rootfs to $rootfs ..." mkdir -p $rootfs -rsync -Ha $cache/rootfs-$arch/ $rootfs/ || return 1 +rsync -SHaAX $cache/rootfs-$arch/ $rootfs/ || return 1 return 0 } diff --git a/templates/lxc-ubuntu.in b/templates/lxc-ubuntu.in index 55199dc..5085bf9 100644 --- a/templates/lxc-ubuntu.in +++ b/templates/lxc-ubuntu.in @@ -413,7 +413,7 @@ copy_ubuntu() btrfs subvolume snapshot $cache/rootfs-$arch $realrootfs || return 1 [ "$rootfs" = "$realrootfs" ] || mount --bind $realrootfs $rootfs || return 1 else - rsync -Ha $cache/rootfs-$arch/ $rootfs/ || return 1 + rsync -SHaAX $cache/rootfs-$arch/ $rootfs/ || return 1 fi return 0 } -- 2.8.1 signature.asc Description: OpenPGP digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-create: file-based capabilities are lost
Hi Serge, On 06/14/16 17:10, Serge E. Hallyn wrote: > > Well I notice that copy_debian() rsyncs without -X. Does > adding -X fix it for you? Using "rsync -SHaAX" in lxc-debian it works (on Jessie). Attached you can find a suggested patch for all (lxc 1.1.5). Thanx for your help Harri Index: lxc-1.1.5.1/templates/lxc-altlinux.in === --- lxc-1.1.5.1.orig/templates/lxc-altlinux.in +++ lxc-1.1.5.1/templates/lxc-altlinux.in @@ -208,7 +208,7 @@ copy_altlinux() #cp -a $cache/rootfs-$arch $rootfs_path || return 1 # i prefer rsync (no reason really) mkdir -p $rootfs_path -rsync -Ha $cache/rootfs/ $rootfs_path/ +rsync -SHaAX $cache/rootfs/ $rootfs_path/ return 0 } Index: lxc-1.1.5.1/templates/lxc-centos.in === --- lxc-1.1.5.1.orig/templates/lxc-centos.in +++ lxc-1.1.5.1/templates/lxc-centos.in @@ -512,7 +512,7 @@ copy_centos() #cp -a $cache/rootfs-$arch $rootfs_path || return 1 # i prefer rsync (no reason really) mkdir -p $rootfs_path -rsync -a $cache/rootfs/ $rootfs_path/ +rsync -SHaAX $cache/rootfs/ $rootfs_path/ echo return 0 } Index: lxc-1.1.5.1/templates/lxc-debian.in === --- lxc-1.1.5.1.orig/templates/lxc-debian.in +++ lxc-1.1.5.1/templates/lxc-debian.in @@ -283,7 +283,7 @@ copy_debian() # make a local copy of the minidebian echo -n "Copying rootfs to $rootfs..." mkdir -p $rootfs -rsync -Ha "$cache/rootfs-$release-$arch"/ $rootfs/ || return 1 +rsync -SHaAX "$cache/rootfs-$release-$arch"/ $rootfs/ || return 1 return 0 } Index: lxc-1.1.5.1/templates/lxc-fedora.in === --- lxc-1.1.5.1.orig/templates/lxc-fedora.in +++ lxc-1.1.5.1/templates/lxc-fedora.in @@ -641,7 +641,7 @@ This will take a couple of minutes. Pat echo "Creating Stage 1 r/w copy of r/o Stage 0 squashfs image from LiveOS." -rsync -aAHS stage0/. stage1/ +rsync -aAHSX stage0/. stage1/ umount stage0 umount squashfs @@ -1015,7 +1015,7 @@ copy_fedora() #cp -a $cache/rootfs-$basearch $rootfs_path || return 1 # i prefer rsync (no reason really) mkdir -p $rootfs_path -rsync -Ha $cache/rootfs/ $rootfs_path/ +rsync -SHaAX $cache/rootfs/ $rootfs_path/ echo return 0 } Index: lxc-1.1.5.1/templates/lxc-openmandriva.in === --- lxc-1.1.5.1.orig/templates/lxc-openmandriva.in +++ lxc-1.1.5.1/templates/lxc-openmandriva.in @@ -155,7 +155,7 @@ copy_openmandriva() echo -n "Copying rootfs to $rootfs_path ..." mkdir -p $rootfs_path -rsync -Ha $cache/rootfs/ $rootfs_path/ +rsync -SHaAX $cache/rootfs/ $rootfs_path/ return 0 } Index: lxc-1.1.5.1/templates/lxc-opensuse.in === --- lxc-1.1.5.1.orig/templates/lxc-opensuse.in +++ lxc-1.1.5.1/templates/lxc-opensuse.in @@ -221,7 +221,7 @@ copy_opensuse() # make a local copy of the mini opensuse echo "Copying rootfs to $rootfs ..." mkdir -p $rootfs -rsync -Ha $cache/rootfs-$arch/ $rootfs/ || return 1 +rsync -SHaAX $cache/rootfs-$arch/ $rootfs/ || return 1 return 0 } Index: lxc-1.1.5.1/templates/lxc-ubuntu.in === --- lxc-1.1.5.1.orig/templates/lxc-ubuntu.in +++ lxc-1.1.5.1/templates/lxc-ubuntu.in @@ -413,7 +413,7 @@ copy_ubuntu() btrfs subvolume snapshot $cache/rootfs-$arch $realrootfs || return 1 [ "$rootfs" = "$realrootfs" ] || mount --bind $realrootfs $rootfs || return 1 else - rsync -Ha $cache/rootfs-$arch/ $rootfs/ || return 1 + rsync -SHaAX $cache/rootfs-$arch/ $rootfs/ || return 1 fi return 0 } ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] lxc-create: file-based capabilities are lost
Hi folks, Problem: A container setup with "lxc-create -t debian" has lost its file-based capabilities (used by systemd, ping, iputils, ...). I didn't check other template scripts, but since the major suspect is tar (used for creating a cache) I would assume that this problem is not restricted to Debian. The workaround on Debian is obvious but painful: Rerun the postinst scripts of the affected packages. It would be very nice to get a real (platform independent) solution for this problem, though. An option to avoid the cache, for example. Every helpful comment is highly appreciated. Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] lxc.device instead of lxc-device?
Hi folks, would it be possible to have an option "lxc.device" in the config file, e.g. lxc.autodev = 1 lxc.device = /dev/vg00/lv01 lxc.device = /dev/vg00/lv02 It should make the block devices available to the client, similar to the lxc-device script, but before init and the services have been started. All descriptions and howtos I found on google on this topic seem to ignore that the lxc-device script might be run too late (container services are already up). The block device numbers given with lxc.cgroup.devices.allow might be invalid after the next hardware reboot, making the config file a risk for others. I found lxc.hook.pre-start, of course. I could live with a hook as a painful makeshift, but If I got this right it appears to be run *before* the container's /dev directory is setup. Just a suggestion, of course. Every helpful feedback is welcome. Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] automatic user id mapping?
Hi folks, I need local resource limits inside each container. Problem: UID conflicts between containers. Setting lxc.id_map is *highly* painful, because it just moves the burden to the admin. An automatic solution to avoid UID and GID conflicts between containers would be very helpful. Is there hope? Did I miss something in the documentation? Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] symbolic link for /var/lib/lxc
Hi Serge, On 07/23/15 15:12, Serge Hallyn wrote: > Quoting Harald Dunkel (harald.dun...@aixigo.de): >> >> My suggestion would be to use the "real" lxcpath (resolving >> all the symlinks and .. and .) for constructing the abstract >> socket name. > > Well that's true, perhaps lxc should do a realpath on the lxcpath. > Patch for that would be welcome. Note though that if realpath > fails, then you should simply take what was given - because it is > not required that lxcpath actually exist. > I never tried that. If the target for lxcpath is optional, then what is $lxcpath needed for, besides creating the abstract socket name? >>> Since a container named 'lxchost01' could exist and be running >>> in 5 different lxcpaths at the same time, we can't really avoid >>> this. (that is, it has to be the case that the lxcpath matters) >>> >> >> I am not sure if I got this correctly, but afaics you can specify >> only one lxcpath for running lxc-create. At least 4 of the 5 >> lxcpaths you mentioned include symbolic links or constructs like > > Sorry - 5 lxcpaths that I mentioned where? > A few lines above: "5 different lxcpaths at the same time". This is just a single container "lxchost01", right? >> "subdir1/./..", etc., but don't they all point to the same inode >> under the same mount point? > > No, I have containers named t1 under /var/lib/lxc, /var/lib/lxd/lxc, > ~/.local/share/lxc, and maybe /usr/local/var/lib/lxc - they're all > different containers. > Sure, but these are *several* containers, each with their own socket. Very important feature. > But yeah, regarding symlinks you're right that we could readlink > to fix that a bit. That would solve a part of your problem - > but it won't help if you do > > lxc-start -n t1 > mv /var/lib/lxc /var/lib/lxcc > ln -s /var/lib/lxcc /var/lib/lxc > I wouldn't dare to do this. Another problem not mentioned before is a bind mount of an lxcpath to another point in the filesystem. This would be very hard to detect. Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] symbolic link for /var/lib/lxc
Hi Serge, On 07/22/15 22:55, Serge Hallyn wrote: > Quoting Harald Dunkel (harald.dun...@aixigo.de): >> >> This looks pretty fragile to me. Shouldn't lxc report the same >> state for both paths, no matter what? > > No, because when you start the container, it listens on a > abstract unix socket, i.e. @/var/lib/lxc/rootw1/command, for > things like 'what is your init pid'. The lxcpath is a part of > that path. So when you callously do lxc-ls using a different > lxcpath than you used for lxc-start, you end up looking for > a command socket which doesn't exist. > Sorry, but this looks like a self-made problem to me. I wonder if the abstract socket name needs to contain the "/var/lib/lxc/" at all? unix(7) states about abstract sockets "The name has no connection with filesystem pathnames." My suggestion would be to use the "real" lxcpath (resolving all the symlinks and .. and .) for constructing the abstract socket name. > Since a container named 'lxchost01' could exist and be running > in 5 different lxcpaths at the same time, we can't really avoid > this. (that is, it has to be the case that the lxcpath matters) > I am not sure if I got this correctly, but afaics you can specify only one lxcpath for running lxc-create. At least 4 of the 5 lxcpaths you mentioned include symbolic links or constructs like "subdir1/./..", etc., but don't they all point to the same inode under the same mount point? Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] symbolic link for /var/lib/lxc
Hi folks, please consider this: # ls -al /var/lib/lxc lrwxrwxrwx 1 root root 11 Aug 11 2014 /var/lib/lxc -> /export/lxc # lxc-ls --fancy NAME STATEIPV4 IPV6 GROUPS AUTOSTART - lxchost01 RUNNING 10.123.96.134 - autoBY-GROUP lxchost02 RUNNING 10.123.99.37 - autoBY-GROUP lxchost03 RUNNING 10.123.96.51 - autoBY-GROUP lxchost04 STOPPED - - autoNO lxchost05 RUNNING 10.123.96.46 - autoBY-GROUP lxchost06 RUNNING 10.123.96.55 - autoBY-GROUP lxchost07 RUNNING 10.123.99.219 - autoBY-GROUP lxchost08 RUNNING 10.123.96.53 - autoBY-GROUP lxchost09 RUNNING 10.123.96.76 - autoBY-GROUP lxchost10 RUNNING 10.123.99.216 - autoBY-GROUP lxchost11 RUNNING 10.123.99.125 - autoBY-GROUP lxchost12 STOPPED - - - NO # lxc-ls -P /export/lxc --fancy NAME STATEIPV4 IPV6 GROUPS AUTOSTART lxchost01 STOPPED - - autoBY-GROUP lxchost02 STOPPED - - autoBY-GROUP lxchost03 STOPPED - - autoBY-GROUP lxchost04 STOPPED - - autoNO lxchost05 STOPPED - - autoBY-GROUP lxchost06 STOPPED - - autoBY-GROUP lxchost07 STOPPED - - autoBY-GROUP lxchost08 STOPPED - - autoBY-GROUP lxchost09 STOPPED - - autoBY-GROUP lxchost10 STOPPED - - autoBY-GROUP lxchost11 STOPPED - - autoBY-GROUP lxchost12 STOPPED - - - NO This looks pretty fragile to me. Shouldn't lxc report the same state for both paths, no matter what? Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] wishlist item: lxc-info --short?
Hi folks, to avoid postprocessing the output of lxc-info, it would be nice to have an option "--short", e.g. # lxc-info -n sample -c lxc.start.auto --short 1 My first guess was that '-q' did the trick, but it didn't. Just a suggestion, of course. Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc 1.1.2: "lxc-ls" vs "lxc-ls -P /var/lib/lxc"
On 04/14/15 15:41, Stéphane Graber wrote: > > Ever since LXC 1.0.0 (so over a year now), lxc-ls run as non-root lists > unprivileged containers stored in ~/.local/share/lxc/ > Sorry, I didn't know. Do you think a message like % lxc-ls ~/.local/share/lxc: no such directory or # lxc-ls -P /somepath /somepath: no such directory might be helpful? Thanx very much for your reply. Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] ignore hidden container directories?
On 04/13/15 14:54, Serge Hallyn wrote: > Can you give us an example? > Sure, here is a sample session: # lxc-create -P /data1/lxc -n sample42 -t debian -- -r jessie debootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-jessie-amd64 ... Copying rootfs to /data1/lxc/sample42/rootfs...Generating locales (this might take a while)... Generation complete. insserv: warning: current start runlevel(s) (empty) of script `checkroot.sh' overrides LSB defaults (S). insserv: warning: current stop runlevel(s) (S) of script `checkroot.sh' overrides LSB defaults (empty). insserv: warning: current start runlevel(s) (empty) of script `checkroot.sh' overrides LSB defaults (S). update-rc.d: error: umountfs Default-Start contains no runlevels, aborting. insserv: warning: current start runlevel(s) (empty) of script `hwclock.sh' overrides LSB defaults (S). insserv: warning: current stop runlevel(s) (0 6 S) of script `hwclock.sh' overrides LSB defaults (0 6). update-rc.d: error: cannot find a LSB script for hwclockfirst.sh Creating SSH2 RSA key; this may take some time ... 2048 c8:93:d2:92:46:43:eb:c3:bc:e7:63:cb:76:3a:ef:24 /etc/ssh/ssh_host_rsa_key.pub (RSA) Creating SSH2 DSA key; this may take some time ... 1024 ed:3c:f9:fd:2e:5c:00:92:04:f0:ca:f6:77:79:ed:2d /etc/ssh/ssh_host_dsa_key.pub (DSA) Creating SSH2 ECDSA key; this may take some time ... 256 d9:02:9b:3c:b5:a6:83:d1:3f:3b:72:05:80:1c:1a:eb /etc/ssh/ssh_host_ecdsa_key.pub (ECDSA) Creating SSH2 ED25519 key; this may take some time ... 256 51:4c:e7:ba:18:5b:5f:07:4b:fd:56:6f:d8:e3:4d:18 /etc/ssh/ssh_host_ed25519_key.pub (ED25519) Failed to read /proc/cmdline. Ignoring: No such file or directory invoke-rc.d: policy-rc.d denied execution of start. Current default time zone: 'Europe/Paris' Local time is now: Tue Apr 14 13:32:18 CEST 2015. Universal Time is now: Tue Apr 14 11:32:18 UTC 2015. Root password is 'root', please change ! # ls -l /data1/lxc total 52 drwxrwx--- 3 root root 4096 Mar 20 13:35 ldap0 drwxr-xr-x 3 root root 4096 Mar 12 16:07 ldap2 : : -rw-r--r-- 1 root root 15682 Apr 14 10:53 lxc-monitord.log -rwxr-xr-x 1 root root 2894 Sep 17 2014 new_container drwxrwx--- 3 root root 4096 Apr 14 13:32 sample42 # mv sample42 .sample42.template # lxc-ls -P /data1/lxc --fancy NAMESTATEIPV4 IPV6 GROUPS AUTOSTART --- .sample42.template STOPPED - - - NO ldap0 RUNNING 172.19.96.100 - autoBY-GROUP ldap2 STOPPED - - autoNO # ls -l /data1/lxc total 48 drwxrwx--- 3 root root 4096 Mar 20 13:35 ldap0 drwxr-xr-x 3 root root 4096 Mar 12 16:07 ldap2 : : -rw-r--r-- 1 root root 15682 Apr 14 10:53 lxc-monitord.log -rwxr-xr-x 1 root root 2894 Sep 17 2014 new_container ls -l doesn't show .sample42.template, lxc-ls does. Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] lxc 1.1.2: "lxc-ls" vs "lxc-ls -P /var/lib/lxc"
Hi folks,
I get a weird effect on running lxc-ls without root:
{hdunkel@dpcl082:~ 507} lxc-ls
{hdunkel@dpcl082:~ 508} echo $?
0
{hdunkel@dpcl082:~ 509} lxc-ls -P /var/lib/lxc
.jessiedebbuild template.blog
.mini lxc0
.squeeze oraclient
.wheezyp1
centos65 p2
{hdunkel@dpcl082:~ 510} echo $?
0
{hdunkel@dpcl082:~ 511} ls -l /var/lib/lxc
lrwxrwxrwx 1 root root 16 Aug 7 2014 /var/lib/lxc -> ../../export/lxc
{hdunkel@dpcl082:~ 512} ls -al /var/lib/../../export/lxc
total 180
drwxr-xr-x 32 rootroot 4096 Apr 13 13:03 .
drwxrwxrwt 22 rootroot 4096 Feb 2 09:52 ..
drwxr-xr-x 3 rootroot 4096 Aug 19 2014 .jessie
drwxr-xr-x 3 rootroot 4096 Nov 20 2013 .mini
drwxr-xr-x 3 rootroot 4096 Nov 20 2013 .squeeze
drwxr-xr-x 3 rootroot 4096 Aug 19 2014 .wheezy
-rw-r--r-- 1 rootroot781 Jul 2 2014 README
drwxr-xr-x 4 rootroot 4096 Jan 21 2014 centos65
drwxr-xr-x 3 rootroot 4096 Oct 17 07:46 debbuild
-rw-r--r-- 1 rootroot 19973 Jan 23 09:33 lxc-monitord.log
drwxrwxr-x 3 rootroot 4096 Mar 18 16:23 lxc0
drwxr-xr-x 3 rootroot 4096 Oct 14 11:38 oraclient
drwxr-xr-x 3 rootroot 4096 Aug 7 2014 p1
drwxr-xr-x 3 rootroot 4096 Aug 7 2014 p2
drwxrwxr-x 3 rootroot 4096 Apr 13 12:26 template.blog
drwxr-xr-x 3 rootroot 4096 Oct 14 11:36 tmp
Please note that the "-P /var/lib/lxc" makes lxc-ls work,
even though its the default path. For root there is no
such problem.
Regards
Harri
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] ignore hidden container directories?
Hi folks, "lxc-ls" implies a certain similarity to Unix' "ls" command, some releases ago lxc stopped to ignore hidden container directories. Did this happen on purpose? Is there a common config option for lxc to bring back the expected behavior wrt hidden directories? Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] LXC 1.1 rc1 has been released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/21/15 22:27, Stéphane Graber wrote: > Hey everyone, > > So after doing a fair amount of additional manual testing on it, I've just > released LXC 1.1 rc1. > > That means that from now on, we won't be taking new features and will instead > work on fixing any remaining rough edges with 1.1. > Do you have some preliminary release notes? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJUw7XDAAoJEAqeKp5m04HLK3QH/3bzf80Az+dV0rO/KaOV7dwY 7N+AjJDJXKJHHCBLkKWOT40WowEc5w7XlmCIC8HABNl/pthhvN9Xwr6MJ54zP0fT e36DLZRzap7lq3PZ16/394mt2/EajSP5mUJcLX+SCeLa8odd60QXYcKCatGMPQoi ObhcINUuagN5EEV6cOSNGq2mSyWs0N5yQRwDjaA8cb0u5sme7oPiV/MJtrxWFFVs zMTqwSIkouAToFvoiGOHKnRE7ZFbDHqRjj2zB0rCyKel6zUjP1sh6Ruq4rrxla12 XmR8he4Ktsf1cZQE6hSJnfl4h2IsVfroSjzcP//XDDz8hyqOkSiET7EVLSiI0nE= =O5l/ -END PGP SIGNATURE- ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] lxc-debian: support systemd as PID 1
On Fri, 21 Nov 2014 04:41:00 + Serge Hallyn wrote: > > Michael and/or Stéphane may have other comments , but as you say this > will not regress non-systemd hosts so looks like a step in the right > direction to me, thanks. > I wonder if this could go to the stable-1.0 branch, too? Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] fix the expansion of libexecdir when not explicitly passed to configure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi folks, The patch seems to work. Do you think it would be reasonable to include this fix on the stable-1.0 branch as well? Thanx anyway. Keep on your good work Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJTpmhGAAoJEAqeKp5m04HLkrQH/1d5zCEQ4IFyqaG4FG0Hpyk8 3LlS3B3vJcBEc36k8nb4IgRXdp+11iZiV+e1nN1tt9oIvYvIboagSjtJ5/WMnTqM Cj66wrekuo+Q77eW4dFIy81C+q5vP7WH/YmWvZsN7KucQOv+vB/re4ajREHK1o6c YtuHMweQbmtRk6VDQcGODUtX3KwEpmBjNSlDSk84rMOV71QF1OTQ3atVTzu/VDcO dk6FOOpNPwI0aonOgfAKwCEdJcfaTu/EqxauOt94Qd/pqV5ll8FFerniGXfYkqWd 8GueYWHR+cvZIHuZMChdHEyp2GRKGdeO3M9HWe3ZpyOLOg9bKEfmXabT2JBTAmM= =W66E -END PGP SIGNATURE- ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] systemd support: generated lxc.service file broken?
Hi folks,
if I build the top of the 1.0.4 branch on Debian, then the
generated lxc.service file contains bad ExecStart* and ExecStop
options:
% ./autogen.sh ; configure; make
:
:
% grep ^Exec config/init/systemd/lxc.service
ExecStartPre=${exec_prefix}/libexec/lxc/lxc-devsetup
ExecStart=${exec_prefix}/libexec/lxc/lxc-autostart-helper start
ExecStop=${exec_prefix}/libexec/lxc/lxc-autostart-helper stop
According to systemd.service(5) the first argument of the
ExecStart and ExecStop options "must be a literal and absolute
path name". Variables are not allowed here.
syslog (of a real life installation) says:
:
Jun 20 09:48:38 cecil systemd[1]: [/lib/systemd/system/lxc.service:8]
Executable path is not absolute, ignoring:
${prefix}/lib/x86_64-linux-gnu/lxc/lxc-devsetup
Jun 20 09:48:38 cecil systemd[1]: [/lib/systemd/system/lxc.service:9]
Executable path is not absolute, ignoring:
${prefix}/lib/x86_64-linux-gnu/lxc/lxc-autostart-helper start
Jun 20 09:48:38 cecil systemd[1]: [/lib/systemd/system/lxc.service:10]
Executable path is not absolute, ignoring:
${prefix}/lib/x86_64-linux-gnu/lxc/lxc-autostart-helper stop
:
Probably a bad substitution on processing lxc.service.in.
Regards
Harri
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] multiple lxc container path directories?
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. > 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 signature.asc Description: OpenPGP digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] multiple lxc container path directories?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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 Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJTlD02AAoJEAqeKp5m04HLAFIH/0TcgT+I2mjVl4EpFirv0r0t 45XHbGWYSeJOlcvw6L3Zby5KfEwUIkgR3Xa9BSLZQHYds4MvuP26xvgj3EabHbm9 BBNi4vGyHlQG2l6WQ05ECMdcCFZpZmdNWvaWOns5hHnf1kmgf3NCQvxzSaxcP24O UGrOsMliUDlJxYzqLi0PYak8iDwekrMvondx8YGD+KG8/WsTRx5caIYTujEZd1RX MAMmkBlugSPQwwwvh8MGF/Kef35xfz1G0lPWtBaxqjaBzpHeLNk/d4jfSyM7xwlQ GmQwUHrV9qnz4GltnMyiPCtQs9Mu0ihmtUNPI2JXTvS06UkYBce6crdblm6btp0= =lWFT -END PGP SIGNATURE- ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [RFC] lxc-start: daemonize by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/02/14 16:29, Serge Hallyn wrote: > > That won't show you the startup msgs as it will attach you to tty1, not > /dev/console. > Surely the alias was just a vague description. The point is being able to detach from the console, after the container was started. Forgetting the "-d" on the lxc-start command line wouldn't hurt so much. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJTZKhuAAoJEAqeKp5m04HL4uEH/2hfvaBdkiq35deEbj5ETWRX FzZzcptgjEnUR9eoQg5QKLzDu6FOPsvsoQj+rGNx/7Ozrdt9FkmhfwqhR4+Q9Nsk RULRYxhAeg8en3UtQKoNnqxrqwm+Fk3P8Jbhs5BFkHYB8K1tx6DBcqrBoRdxY0GD 0QnpHF4T7hHhSAfmZf8KmXbJk9a/ZBjBrN79UYFBjI2M1/+gtkVxjTKyKOgwgnxk nPs1QuUORoRX6eFbMkPSgieQ7m19GtNHZrLqjdMfqOKMmVujuAM0MS9YRC+LYhB1 b9vNck3WTKxNuwEf4D4Din7e4hzI3iKN+X8BgRqViUDIeReCtfL5HQnMuFy7GxQ= =OqLi -END PGP SIGNATURE- ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [RFC] lxc-start: daemonize by default
I haven't seen this suggested before: How about making lxc-start -n container an alias for lxc-start -n container -d lxc-console -n container ? This would allow me to detach from the container, if I forgot the "-d" for lxc-start. Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] Fedora20 container doesn't start
Hi folks, I tried the fedora template, but it seems the generated image (Fedora 19 or 20) doesn't start. lxc-start returns immediately without any message on stderr. Attached is the debug log file for Fedora 20. lxc is rc2 of this morning. Host is Debian (sid) with kernel 3.13.3. Creating and booting a Debian container worked without problems. Please mail if I can help to track this down. Regards Harri lxc-start 1392475606.398 INFO lxc_start_ui - using rcfile /var/lib/lxc/fed20/config lxc-start 1392475606.398 WARN lxc_log - lxc_log_init called with log already initialized lxc-start 1392475606.399 DEBUGlxc_conf - allocated pty '/dev/pts/5' (5/6) lxc-start 1392475606.399 DEBUGlxc_conf - allocated pty '/dev/pts/7' (7/8) lxc-start 1392475606.399 DEBUGlxc_conf - allocated pty '/dev/pts/8' (9/10) lxc-start 1392475606.399 DEBUGlxc_conf - allocated pty '/dev/pts/9' (11/12) lxc-start 1392475606.399 INFO lxc_conf - tty's configured lxc-start 1392475606.399 DEBUGlxc_start - sigchild handler set lxc-start 1392475606.399 DEBUGlxc_console - opening /dev/tty for console peer lxc-start 1392475606.399 DEBUGlxc_console - using '/dev/tty' as console lxc-start 1392475606.399 DEBUGlxc_console - 23891 got SIGWINCH fd 17 lxc-start 1392475606.399 DEBUGlxc_console - set winsz dstfd:14 cols:179 rows:59 lxc-start 1392475606.399 INFO lxc_start - 'fed20' is initialized lxc-start 1392475606.413 DEBUGlxc_start - Not dropping cap_sys_boot or watching utmp lxc-start 1392475606.413 INFO lxc_cgroup - cgroup driver cgroupfs initing for fed20 lxc-start 1392475606.415 DEBUGlxc_cgfs - cgroup 'devices.deny' set to 'a' lxc-start 1392475606.415 DEBUGlxc_cgfs - cgroup 'devices.allow' set to 'c *:* m' lxc-start 1392475606.415 DEBUGlxc_cgfs - cgroup 'devices.allow' set to 'b *:* m' lxc-start 1392475606.415 DEBUGlxc_cgfs - cgroup 'devices.allow' set to 'c 1:3 rwm # /dev/null' lxc-start 1392475606.415 DEBUGlxc_cgfs - cgroup 'devices.allow' set to 'c 1:5 rwm # /dev/zero' lxc-start 1392475606.415 DEBUGlxc_cgfs - cgroup 'devices.allow' set to 'c 1:7 rwm # /dev/full' lxc-start 1392475606.415 DEBUGlxc_cgfs - cgroup 'devices.allow' set to 'c 5:0 rwm # /dev/tty' lxc-start 1392475606.415 DEBUGlxc_cgfs - cgroup 'devices.allow' set to 'c 1:8 rwm # /dev/random' lxc-start 1392475606.415 DEBUGlxc_cgfs - cgroup 'devices.allow' set to 'c 1:9 rwm # /dev/urandom' lxc-start 1392475606.415 DEBUGlxc_cgfs - cgroup 'devices.allow' set to 'c 136:* rwm # /dev/tty[1-4] ptys and lxc console' lxc-start 1392475606.415 DEBUGlxc_cgfs - cgroup 'devices.allow' set to 'c 5:2 rwm # /dev/ptmx pty master' lxc-start 1392475606.415 INFO lxc_cgfs - cgroup has been setup lxc-start 1392475606.415 INFO lxc_conf - 'fed20.afaics.de' hostname has been setup lxc-start 1392475606.415 INFO lxc_conf - network has been setup lxc-start 1392475606.418 DEBUGlxc_conf - mounted '/var/lib/lxc/fed20/rootfs' on '/usr/lib/x86_64-linux-gnu/lxc' lxc-start 1392475606.418 INFO lxc_conf - Mounting /dev under /usr/lib/x86_64-linux-gnu/lxc lxc-start 1392475606.418 DEBUGlxc_conf - entering mount_check_fs for /dev lxc-start 1392475606.418 DEBUGlxc_conf - mount_check_fs returning 1 last devtmpfs lxc-start 1392475606.418 DEBUGlxc_conf - Bind mounting /dev/.lxc/fed20.4d9dd45989523cdf to /usr/lib/x86_64-linux-gnu/lxc/dev lxc-start 1392475606.418 INFO lxc_conf - Mounted /dev under /usr/lib/x86_64-linux-gnu/lxc lxc-start 1392475606.418 INFO lxc_conf - Creating initial consoles under /usr/lib/x86_64-linux-gnu/lxc/dev lxc-start 1392475606.418 INFO lxc_conf - Populating /dev under /usr/lib/x86_64-linux-gnu/lxc lxc-start 1392475606.418 INFO lxc_conf - Populated /dev under /usr/lib/x86_64-linux-gnu/lxc lxc-start 1392475606.418 INFO lxc_conf - created /usr/lib/x86_64-linux-gnu/lxc/dev/lxc lxc-start 1392475606.418 INFO lxc_conf - console has been setup on lxc/console lxc-start 1392475606.418 INFO lxc_conf - 4 tty(s) has been setup lxc-start 1392475606.418 INFO lxc_conf - I am 1, /proc/self points to '' lxc-start 1392475606.418 INFO lxc_conf - Mounted /proc in container for security transition lxc-start 1392475606.418 DEBUGlxc_conf - created '/usr/lib/x86_64-linux-gnu/lxc/lxc_putold' directory lxc-start 1392475606.418 DEBUGlxc_conf - mountpoint for old rootfs is '/usr/lib/x86_64-linux-gnu/lxc/lxc_putold' lxc-start 1392475606.419 DEBUGlxc_conf - pivot_root syscall to '/usr/lib/x86_64-linux-gnu/lxc' successful lxc-start 1392475606.429 DEBUGlxc_conf - umounted '/lxc_putold/dev/pts' lxc-start 1392475606.445 DEBUGlxc_conf - umounted '/lxc_putold/run/lock'
Re: [lxc-devel] [PATCH] create fd, stdin, stdout, stderr symlinks in /dev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I tried the patch on top of the current HEAD (for Centos): Success. [root@no3 ~]# ls -al /dev/fd /dev/std* lrwxrwxrwx 1 root root 13 Feb 14 14:37 /dev/fd -> /proc/self/fd lrwxrwxrwx 1 root root 15 Feb 14 14:37 /dev/stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 Feb 14 14:37 /dev/stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 Feb 14 14:37 /dev/stdout -> /proc/self/fd/1 It would be nice it it could be merged into the official sources. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJS/nMtAAoJEAqeKp5m04HLrngH/jhCxWVgA9WFEYemBVsaw8tY ZXmzCKyB76+skJb0i2VQy9WicylUmyXno9hsIesAZ2FHb25BCkFFZ4ByeyO60oMG IknD4W4wpcBEaaT0tHDMTuV8q2vz6p5w7O4UlkuCHl7LIGHarNm4G+fUpc+kL4BM EhNMZ+VTrVz5ERkocp+bao406DbcIEnGgcJRCWXEfGXemrdvTxtyD21KRa/NM8Ww 4m/4v70T20pYGrRezKhZpLaikd1a6hbN1uBNS21Xmq5WpFOwlGll2NzL9dp971kv vndqelUEaXOID0gIUp850mU7Qxe6NewbTwHAVqjAIibJeTKcMngH55jJQEz+b4E= =ySfJ -END PGP SIGNATURE- ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] create fd, stdin, stdout, stderr symlinks in /dev
That was fast. Thanx very much. Keep on your good work Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] Centos template: symlink for /dev/fd missing?
Hi folks, Problem in LXC (beta4) running a Centos 6.5 client: # cat <(echo hello) cat: /dev/fd/63: No such file or directory On a "real" host /dev/fd is a symlink pointing to /proc/self/fd. AFAICS only the altlinux template creates this symlink. Debian seems to provide the link on its own. lxc.autodev = 1 does not help. I tried, of course. Question: Should this symlink be added to the lxc-centos template, as it was done for altlinux? Every helpful comment would be highly appreciated Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] support a custom CentOS repository
On 02/04/14 14:53, Serge Hallyn wrote: > > Thanks everyone. I guess my main question was whether '--repo' would > conflict with the 'additional repos' interpretation (sort of like > proxy vs. ppa in ubuntu, where one is for fast local mirror while the > other is for testing upgraded packages before an upload) Eh, the > latter, if such is ever done, could always be done as --extra-repos. > Is there a naming scheme for the template options? I checked the oracle template (obviously too late, sorry): It uses "--url" for a very similar purpose. > Applied. :) > Thanx very much Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] support a custom CentOS repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi folks, On 02/04/14 02:18, Serge Hallyn wrote: > > It looks fine to me, but I'm not quite sure whether users ordinarily would > want such a repo to be an additional repo or a replacement for the centos > one. Michael, does this look good to you? > One important point in having a local repository is to make installations reproducible. I could take a snapshot of the currently available packages on the official mirrors to run my own frozen mirror, or I could loop mount the released DVD. This would not work if the official CentOS repository is still in the loop. Don't get me wrong, I highly appreciate the efforts of the CentOS folks to keep their distro up-to-date. But CentOS 6.3 cannot be installed anymore, since it has been wiped off the mirrors. Many thanx Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJS8Ii9AAoJEAqeKp5m04HLD/YH/163P20MVDFUztQkO3NfcNkK pBXLk4UMNt7Qu6gK9RT0YA+OV4NOXAa4Nnc4b7VvQhNQt0AU4928wMW/1Hq12zb/ t2iP2yb+/iv2qHwnSuax5bIR+LSYgvx5IAB7QF0AICSYPb/OAuJdoHfqEq55CF35 Ddr+QsoEKyWm4MMeR2hDq1OkR2PIOmT/5ZJSlbmh6ecGnJqKbj2vfkjGtcSa9GAF YnsD2NQC//SIBrexsU6YnQFXOt5iWHYjaeuOAG5EuUMbkDXrjhUCymz8Ol/DXayz DNWNAMSUnuIEZDI5aG2eiI6HlSB480BSi7lRFRfRV6M5vjhCtU2yG/+A3nkXgb8= =2vRW -END PGP SIGNATURE- ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH] support a custom CentOS repository
Hi folks, I would like to contribute a small patch to support a local repository in the CentOS template. Distributing git patches by EMail is still new to me. Please mail if I did not follow the guidelines. Many thanx Harri Harald Dunkel (1): support a custom CentOS repository templates/lxc-centos.in | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) -- 1.9.rc0.143.g6fd479e ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH] support a custom CentOS repository
This change introduces a flag --repo to the lxc-centos template to allow using a local repository (e.g. a loop mounted installer iso on your web server). Signed-off-by: Harald Dunkel --- templates/lxc-centos.in | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/templates/lxc-centos.in b/templates/lxc-centos.in index 2f0c796..f5f6e53 100644 --- a/templates/lxc-centos.in +++ b/templates/lxc-centos.in @@ -364,7 +364,14 @@ download_centos() # use temporary repository definition REPO_FILE=$INSTALL_ROOT/etc/yum.repos.d/lxc-centos-temp.repo mkdir -p $(dirname $REPO_FILE) -cat < $REPO_FILE +if [ -n "$repo" ]; then + cat < $REPO_FILE +[base] +name=local repository +baseurl="$repo" +EOF +else + cat < $REPO_FILE [base] name=CentOS-$release - Base mirrorlist=http://mirrorlist.centos.org/?release=$release&arch=$basearch&repo=os @@ -373,6 +380,7 @@ mirrorlist=http://mirrorlist.centos.org/?release=$release&arch=$basearch&repo=os name=CentOS-$release - Updates mirrorlist=http://mirrorlist.centos.org/?release=$release&arch=$basearch&repo=updates EOF +fi # create minimal device nodes, needed for "yum install" and "yum update" process mkdir -p $INSTALL_ROOT/dev @@ -615,13 +623,14 @@ Optional args: -c,--cleanclean the cache -R,--release Centos release for the new container. if the host is Centos, then it will defaultto the host's release. --fqdn fully qualified domain name (FQDN) for DNS and system naming + --repo repository to use (url) -a,--arch Define what arch the container will be [i686,x86_64] -h,--help print this help EOF return 0 } -options=$(getopt -o a:hp:n:cR: -l help,path:,rootfs:,name:,clean,release:,arch:,fqdn: -- "$@") +options=$(getopt -o a:hp:n:cR: -l help,path:,rootfs:,name:,clean,release:,repo:,arch:,fqdn: -- "$@") if [ $? -ne 0 ]; then usage $(basename $0) exit 1 @@ -638,6 +647,7 @@ do -n|--name) name=$2; shift 2;; -c|--clean) clean=$2; shift 2;; -R|--release) release=$2; shift 2;; + --repo) repo="$2"; shift 2;; -a|--arch) newarch=$2; shift 2;; --fqdn) utsname=$2; shift 2;; --) shift 1; break ;; -- 1.9.rc0.143.g6fd479e ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] is there a default group to stop all containers?
Hi folks, AFAICS lxc-autostart -s ignores all containers unless they match a group or are set to autostart or something. What would you suggest to stop the rest, e.g. at shutdown time of the server? Is there a default group without saying? Of course I tried "lxc-autostart -s -a". No luck. Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
