[lxc-users] debian jessie && ro bind mounts...
Hi, I'm experiencing issues while trying to share an host path or filesystem as read only to guests (read only bind-mounts). Host: Debian 8 Jessie Linux deb 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux LXC: stock, 1.0.6-6 Guest: Debian 8 (no systemd) Filesystem on host: ext4 I'm sharing the host: - /system by using a custom entry in fstab-like file loaded via the container config file, i.e.: /system system none ro,bind,create=dir 0 0 NB: as my "/system" path I've tested a subdirectory and even a mount point. And I've also dome some tests by using an entry in the config file with lxc.mount.entry, but with the same issues. Well, the guest correctly bind-mounts the host path, but mounts it as read-write. By simply issuing on the guest: mount -o remount,ro /system does the job... but ... as I understood it has to work out of the box. An excerpt of the log obtained while starting the guest: lxc-start 1425989871.658 DEBUGlxc_conf - remounting /system on /usr/lib/x86_64-linux-gnu/lxc/rootfs/system to respect bind or remount options lxc-start 1425989871.658 DEBUGlxc_conf - (at remount) flags for /system was 4096, required extra flags are 0 lxc-start 1425989871.658 DEBUGlxc_conf - mountflags already was 4097, skipping remount lxc-start 1425989871.658 DEBUGlxc_conf - mounted '/system' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs/system', type 'none' lxc-start 1425989871.658 INFO lxc_conf - mount points have been setup Regards, -- Marco ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] Syscall auditing via auditd for lxc-guests
Hello List, It seems that auditd cannot be started in guest: # augenrules --load The audit system is disabled The host system seems to miss the audit events from the guest, so no host audit either. Is there a way to audit guest syscalls, e.g. execve? There is no need to have the guest doing that, it could be also on host for guest. In fact I would even appreciate later solution where the host audits the guest without any means by the guest to escape the audit. Could some namespace trickery make it work? Kind Regards, Roman DI Roman Fiedler Scientist Digital Safety & Security Department Assistive Healthcare Information Technology AIT Austrian Institute of Technology GmbH Reininghausstraße 13/1 | 8020 Graz | Austria T +43(0) 50550 2957 | M +43(0) 664 8561599 | F +43(0) 50550 2950 roman.fied...@ait.ac.at | http://www.ait.ac.at/ FN: 115980 i HG Wien | UID: ATU14703506 http://www.ait.ac.at/Email-Disclaimer smime.p7s Description: S/MIME cryptographic signature ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] Warning message when creating a container inside an Ubuntu Guest VM
Hi, This is the setup, I am running Virtual Box and installed Ubuntu Server 14.10. I am then trying to create an LXC container (-t ubuntu) on that VM. The creation process appears to have succeeded except for the cryptic message: initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused invoke-rc.d: policy-rc.d denied execution of start. In fact, I am able to start the container and it appears to work (as i can log in and run some commands). But, I am wondering what the message was about and I would like to get some information about it. Of course i browsed the Internet for some explanation and saw bits and pieces information regarding chroots and most information tell get rid of that problem. Sadly, no explanation as to what is happening here. I also tried to make lxc-create spit out some debug information (--logpriority DEBUG) but, there was only 3 lines and not much info: lxc-create 1425997939.900 WARN lxc_log - log.c:lxc_log_init:316 - lxc_log_init called with log already initialized lxc-create 1425997945.188 WARN lxc_confile - confile.c:config_pivotdir:1685 - lxc.pivotdir is ignored. It will soon become an error. lxc-create 1425997945.189 INFO lxc_create_ui - lxc_create.c:main:284 - container Buntu created In fact based on the message it would appear that it is trying to "use" upstart (at least trying to connect to it) and then when i checked the /var/log/syslog on the VM (i.e. host to the LXC container), i notice that systemd is being employed: Mar 10 16:27:27 Ubuntu-VM systemd[807]: Starting Default. Mar 10 16:27:27 Ubuntu-VM systemd[807]: Reached target Default. Mar 10 16:27:27 Ubuntu-VM systemd[807]: Startup finished in 32ms. Mar 10 16:27:27 Ubuntu-VM systemd[1]: Started User Manager for 1000. Could that be the issue here: "something" is trying to use upstart but, host is using "systemd"? Would someone have an idea and also know is the "something" is it lxc-create? More importantly, any kind of advice on how to perform some detective work on this type of issue would be most welcome. It will certainly help me understand things better. Thanks in advance and hear from you ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged Lxc won't start on Debian Sid
Hi, Sorry for this late reply, I never received any mail to warn me that I got an answer. I was looking on the web for similar issues, when I saw that you answered to me. Well, I removed : * cgroup-bin * cgroup-tools Then I reboot the machine, and I get this (lxc-start -n test --logpriority DEBUG --logfile /tmp/lxc.log) : lxc-start 1425995573.760 INFO lxc_start_ui - lxc_start.c:main:265 - using rcfile /home/huraira/.local/share/lxc/test/config lxc-start 1425995573.762 INFO lxc_confile - confile.c:config_idmap:1325 - read uid map: type u nsid 0 hostid 1214112 range 65536 lxc-start 1425995573.762 INFO lxc_confile - confile.c:config_idmap:1325 - read uid map: type g nsid 0 hostid 1214112 range 65536 lxc-start 1425995573.762 WARN lxc_log - log.c:lxc_log_init:316 - lxc_log_init called with log already initialized lxc-start 1425995573.763 WARN lxc_cgfs - cgfs.c:lxc_cgroup_get_container_info:1100 - Not attaching to cgroup perf_event unknown to /home/huraira/.local/share/lxc test lxc-start 1425995573.763 WARN lxc_cgfs - cgfs.c:lxc_cgroup_get_container_info:1100 - Not attaching to cgroup devices unknown to /home/huraira/.local/share/lxc test lxc-start 1425995573.763 WARN lxc_cgfs - cgfs.c:lxc_cgroup_get_container_info:1100 - Not attaching to cgroup cpu unknown to /home/huraira/.local/share/lxc test lxc-start 1425995573.763 WARN lxc_cgfs - cgfs.c:lxc_cgroup_get_container_info:1100 - Not attaching to cgroup memory unknown to /home/huraira/.local/share/lxc test lxc-start 1425995573.763 WARN lxc_cgfs - cgfs.c:lxc_cgroup_get_container_info:1100 - Not attaching to cgroup freezer unknown to /home/huraira/.local/share/lxc test lxc-start 1425995573.763 WARN lxc_cgfs - cgfs.c:lxc_cgroup_get_container_info:1100 - Not attaching to cgroup net_cls unknown to /home/huraira/.local/share/lxc test lxc-start 1425995573.763 WARN lxc_cgfs - cgfs.c:lxc_cgroup_get_container_info:1100 - Not attaching to cgroup blkio unknown to /home/huraira/.local/share/lxc test lxc-start 1425995573.763 WARN lxc_cgfs - cgfs.c:lxc_cgroup_get_container_info:1100 - Not attaching to cgroup cpuset unknown to /home/huraira/.local/share/lxc test lxc-start 1425995573.763 INFO lxc_lsm - lsm/lsm.c:lsm_init:48 - LSM security driver nop lxc-start 1425995573.763 DEBUGlxc_conf - conf.c:lxc_create_tty:3665 - allocated pty '/dev/pts/1' (5/6) lxc-start 1425995573.763 DEBUGlxc_conf - conf.c:lxc_create_tty:3665 - allocated pty '/dev/pts/2' (7/8) lxc-start 1425995573.763 DEBUGlxc_conf - conf.c:lxc_create_tty:3665 - allocated pty '/dev/pts/3' (9/10) lxc-start 1425995573.763 DEBUGlxc_conf - conf.c:lxc_create_tty:3665 - allocated pty '/dev/pts/4' (11/12) lxc-start 1425995573.763 INFO lxc_conf - conf.c:lxc_create_tty:3676 - tty's configured lxc-start 1425995573.763 DEBUGlxc_start - start.c:setup_signal_fd:247 - sigchild handler set lxc-start 1425995573.763 DEBUGlxc_console - console.c:lxc_console_peer_default:500 - opening /dev/tty for console peer lxc-start 1425995573.763 INFO lxc_caps - caps.c:lxc_caps_up:101 - Last supported cap was 36 lxc-start 1425995573.764 DEBUGlxc_console - console.c:lxc_console_peer_default:506 - using '/dev/tty' as console lxc-start 1425995573.764 DEBUGlxc_console - console.c:lxc_console_sigwinch_init:179 - 2325 got SIGWINCH fd 17 lxc-start 1425995573.764 DEBUGlxc_console - console.c:lxc_console_winsz:88 - set winsz dstfd:14 cols:80 rows:24 lxc-start 1425995574.362 INFO lxc_start - start.c:lxc_init:443 - 'test' is initialized lxc-start 1425995574.394 DEBUGlxc_start - start.c:__lxc_start:1058 - Not dropping cap_sys_boot or watching utmp lxc-start 1425995574.394 INFO lxc_start - start.c:lxc_spawn:802 - Cloning a new user namespace lxc-start 1425995574.394 INFO lxc_cgroup - cgroup.c:cgroup_init:62 - cgroup driver cgroupfs initing for test lxc-start 1425995574.394 ERRORlxc_cgfs - cgfs.c:lxc_cgroupfs_create:956 - Permission denied - Could not create cgroup '/test' in '/sys/fs/cgroup/cpuset'. lxc-start 1425995574.394 ERRORlxc_cgfs - cgfs.c:cgroup_rmdir:207 - Permission denied - cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset/ lxc-start 1425995574.394 ERRORlxc_cgfs - cgfs.c:cgroup_rmdir:207 - Permission denied - cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio/ lxc-start 1425995574.394 ERRORlxc_cgfs - cgfs.c:cgroup_rmdir:207 - Permission denied - cgroup_rmdir: failed to delete /sys/fs/cgroup/net_cls,net_prio/ lxc-start 1425995574.395 ERRORlxc_cgfs - cgfs.c:cgroup_rmdir:207 - Permission denied - cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer/ lxc-start 1425995574.395 ERRORlxc_cgfs - cgfs.c:cgroup_rmdir:207 - Permission denied - cgroup_rmdir: failed
Re: [lxc-users] lxc bridge setup
Do you want your containers to use public IPs direcly, or do you want to use local IPs and then forward whole traffic for certain IP towards particular container? In first case, just set lxc.network.link = br0 and configure public IP as you have described it. Container uses the same GW as your host does. In second case you need to create new bridge with internal network. Containers need to use host as GW, and host must configure iptables to forward traffic destined to IP X to container x, and masquerade outgoing traffic from container x to IP X. Rinse and repeat for IP/container X/x+1. b. On 8 March 2015 at 19:52, Joe McDonald wrote: > I have 5 public IPs (/29) and would like to make them available to lxc > containers. I am on ubuntu 14.04. > > What is the procedure? I tried to duplicate br0 with br1, etc and > incrementing the IP#, but it didn't like it. I'd like to make 1 IP > for the host system, and the other 4 IP's each go to a container. > > I have this in /etc/network/interfaces: > > # The loopback network interface > auto lo p4p1 > iface lo inet loopback > iface p4p1 inet manual > > > auto br0 > iface br0 inet static > bridge_ports p4p1 > bridge_stp off > bridge_fd 0 > bridge_maxwait 0 > > address 104.250.x.x > netmask 255.255.255.248 > gateway 104.250.x.x > dns-nameservers 8.8.8.8 > ___ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] ubuntu utopic (14.10) permission problems?
Hello, I upgraded my main box to ubuntu 14.10 and now my containers are failing with weird permission problems. A simple test is this: $ sudo lxc-create -t ubuntu -n testing -- -r trusty In the containter install postfix (sudo apt-get install postfix). After a basic postfix configuration, run mailq: $ mailq postqueue: warning: close: Permission denied $ sudo mailq postqueue: warning: close: Permission denied Others containters are also failing with pam (?) related issues. For example: $ ssh dana Connection closed by 10.11.101.3 Now this one is more interesting for me because "dana" uses kerberos and ldap. When I attach to the container, auth.log says: Mar 11 00:20:15 dana sshd[1503]: Authorized to zoolook, krb5 principal zool...@bensa.ar (krb5_kuserok) Mar 11 00:20:15 dana sshd[1503]: fatal: Access denied for user zoolook by PAM account configuration [preauth] This container was working with ubuntu trusty on the host BUT it also failed when I tried utopic kernels on the host (linux-image-generic-lts-utopic). Does anyone have any idea what it's going on? Thanks in advance, Norberto ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
