Re: [lxc-users] lxc container rootfs dev folder permission are changing from ro to rw inside container

[Tomasz Chmielewski]

On 2019-02-26 13:02, Yasoda Padala wrote:

Hi Tomasz,
Please find below the output of mount & cat /proc/mounts
container config is also attached with this mail

yasoda@yasoda-HP-Z600-Workstation:~/.local/share/lxc/busybox$
lxc-attach -n busybox

BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/ # mount
/dev/loop0 on / type squashfs (ro,relatime)
none on /dev type tmpfs


This.

You have tmpfs mounted over /dev in your container.

Why is it an issue for you? I'd say it's perfectly normal behaviour.

Tomasz Chmielewski
https://lxadm.com
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] lxc container rootfs dev folder permission are changing from ro to rw inside container

[Yasoda Padala]

Hi Tomasz,
Please find below the output of mount & cat /proc/mounts
container config is also attached with this mail

yasoda@yasoda-HP-Z600-Workstation:~/.local/share/lxc/busybox$ lxc-attach -n
busybox


BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/ # mount
/dev/loop0 on / type squashfs (ro,relatime)
none on /dev type tmpfs
(rw,relatime,size=492k,mode=755,uid=10,gid=10)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
proc on /proc/sys/net type proc (rw,nosuid,nodev,noexec,relatime)
proc on /proc/sys type proc (ro,nosuid,nodev,noexec,relatime)
proc on /proc/sysrq-trigger type proc (ro,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
sysfs on /sys/devices/virtual/net type sysfs (rw,relatime)
sysfs on /sys/devices/virtual/net type sysfs
(rw,nosuid,nodev,noexec,relatime)
udev on /dev/full type devtmpfs
(rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755)
udev on /dev/null type devtmpfs
(rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755)
udev on /dev/random type devtmpfs
(rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755)
udev on /dev/tty type devtmpfs
(rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755)
udev on /dev/urandom type devtmpfs
(rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755)
udev on /dev/zero type devtmpfs
(rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755)
udev on /dev/tty0 type devtmpfs
(rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755)
udev on /dev/tty1 type devtmpfs
(rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755)
udev on /dev/null type devtmpfs
(rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755)
udev on /dev/urandom type devtmpfs
(rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755)
/dev/sda1 on /lib type ext4 (ro,relatime,errors=remount-ro,data=ordered)
/dev/sda1 on /usr/lib type ext4 (ro,relatime,errors=remount-ro,data=ordered)
/dev/sda1 on /lib64 type ext4 (ro,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs
(ro,nosuid,nodev,noexec,relatime)
devpts on /dev/console type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=15,mode=620,ptmxmode=666,max=1)
devpts on /dev/ptmx type devpts
(rw,nosuid,noexec,relatime,gid=15,mode=620,ptmxmode=666,max=1)
devpts on /dev/tty1 type devpts
(rw,nosuid,noexec,relatime,gid=15,mode=620,ptmxmode=666,max=1)
/ #
/ #
/ #
/ #
/ # cat /proc/mounts
/dev/loop0 / squashfs ro,relatime 0 0
none /dev tmpfs rw,relatime,size=492k,mode=755,uid=10,gid=10 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 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
udev /dev/full devtmpfs
rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755 0 0
udev /dev/null devtmpfs
rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755 0 0
udev /dev/random devtmpfs
rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755 0 0
udev /dev/tty devtmpfs
rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755 0 0
udev /dev/urandom devtmpfs
rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755 0 0
udev /dev/zero devtmpfs
rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755 0 0
udev /dev/tty0 devtmpfs
rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755 0 0
udev /dev/tty1 devtmpfs
rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755 0 0
udev /dev/null devtmpfs
rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755 0 0
udev /dev/urandom devtmpfs
rw,nosuid,relatime,size=3011264k,nr_inodes=752816,mode=755 0 0
/dev/sda1 /lib ext4 ro,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda1 /usr/lib ext4 ro,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda1 /lib64 ext4 ro,relatime,errors=remount-ro,data=ordered 0 0
securityfs /sys/kernel/security securityfs ro,nosuid,nodev,noexec,relatime
0 0
devpts /dev/console devpts
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
devpts /dev/pts devpts
rw,nosuid,noexec,relatime,gid=15,mode=620,ptmxmode=666,max=1 0 0
devpts /dev/ptmx devpts
rw,nosuid,noexec,relatime,gid=15,mode=620,ptmxmode=666,max=1 0 0
devpts /dev/tty1 devpts
rw,nosuid,noexec,relatime,gid=15,mode=620,ptmxmode=666,max=1 0 0
/ #
/ #


On Mon, Feb 25, 2019 at 2:07 PM Yasoda Padala 
wrote:

> yasoda@yasoda-HP-Z600-Workstation:~/.local/share/lxc/busybox$ lxc-attach
> -n busybox
> lxc-attach: busybox: utils.c: get_ns_uid: 548 No such file or directory -
> Failed to open uid_map
> lxc-attach: busybox: utils.c: get_ns_gid: 579 No such file or directory -
> Failed to open gid_map
>
> BusyBox 

[lxc-users] Failure in "lxc copy" and in "lxc delete"

[Pierre Couderc]

root@server:~# lxc copy  rmote:nginx nginx
Transferring container: nginx-s1: 414.76MB (11.87MB/s)

transfer stops after 414.76M and "lxc copy" never returns.


This is maybe because there is a problem on the source container. It 
seems ok but I had tried (before) to delete snapshot nginx-s1 and got an 
error :


root@rmote:~# lxc delete  nginx/nginx-s1
Error: Failed to run: btrfs subvolume delete 
/var/snap/lxd/common/lxd/storage-pools/default/containers-snapshots/nginx/nginx-s1: 
ERROR: cannot delete 
'/var/snap/lxd/common/lxd/storage-pools/default/containers-snapshots/nginx/nginx-s1': 
Operation not permitted
Delete subvolume (no-commit): 
'/var/snap/lxd/common/lxd/storage-pools/default/containers-snapshots/nginx/nginx-s1'


Anayway the source nginx container seems to run ok.

Thanks for any help



___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] future of lxc/lxd? snap?

[Fajar A. Nugraha]

On Mon, Feb 25, 2019 at 5:20 PM Stéphane Graber 
wrote:

> snapd + LXD work fine on CentOS 7, it's even in our CI environment, so
> presumably the same steps should work on RHEL 7.
>
>
Awesome !

> In the past I've built private RPMs for lxd on centos. It became a hassle
> though as (for example) I need to port additional packages as well. And I
> needed to change the kernel to a newer one, unsupported by centos. But it
> works.
> >
> > So if you're willing to build from source, it should still work.
>

I forgot to mention that this was on an ancient centos 6, not 7 :)

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] future of lxc/lxd? snap?

[Stéphane Graber]

snapd + LXD work fine on CentOS 7, it's even in our CI environment, so
presumably the same steps should work on RHEL 7.

On Mon, Feb 25, 2019 at 10:54 AM Fajar A. Nugraha  wrote:
>
> On Mon, Feb 25, 2019 at 3:15 PM Harald Dunkel  wrote:
>>
>> On 2/25/19 4:52 AM, Fajar A. Nugraha wrote:
>> >
>> > snapcraft.io  is also owned by Canonical.
>> >
>> > By using lxd snap, they can easly have lxd running on any distro that 
>> > already support snaps, without having to maintain separate packages.
>> >
>>
>> The problem is that there is no standard for all "major" distros,
>> as this discussion shows:
>>
>> https://www.reddit.com/r/redhat/comments/9lbm0c/snapd_for_rhel/
>>
>
> You mean "RHEL doesn't have snapd"? You'd have to ask redhat then.
>
>>
>> Debian already has an excellent packaging scheme.
>
>
> Sure.
>
> The question now is "is anybody willing to maintain debian lxd packages"
>
>>
>> The RPM world
>> doesn't follow snapd, as it seems.
>
>
> Really?
> https://docs.snapcraft.io/installing-snap-on-fedora/6755
>
>>
>> And if you prefer your favorite
>> tool inside a container you can find docker images everywhere.
>>
>> A few years ago compatibility was achieved on source code level.
>> Sorry to say, but you lost that for lxd. And snaps are not a
>> replacement.
>>
>
> In the past I've built private RPMs for lxd on centos. It became a hassle 
> though as (for example) I need to port additional packages as well. And I 
> needed to change the kernel to a newer one, unsupported by centos. But it 
> works.
>
> So if you're willing to build from source, it should still work.
>
> --
> Fajar
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users



-- 
Stéphane
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] future of lxc/lxd? snap?

[Fajar A. Nugraha]

On Mon, Feb 25, 2019 at 3:15 PM Harald Dunkel 
wrote:

> On 2/25/19 4:52 AM, Fajar A. Nugraha wrote:
> >
> > snapcraft.io  is also owned by Canonical.
> >
> > By using lxd snap, they can easly have lxd running on any distro that
> already support snaps, without having to maintain separate packages.
> >
>
> The problem is that there is no standard for all "major" distros,
> as this discussion shows:
>
> https://www.reddit.com/r/redhat/comments/9lbm0c/snapd_for_rhel/
>
>
You mean "RHEL doesn't have snapd"? You'd have to ask redhat then.


> Debian already has an excellent packaging scheme.


Sure.

The question now is "is anybody willing to maintain debian lxd packages"


> The RPM world
> doesn't follow snapd, as it seems.


Really?
https://docs.snapcraft.io/installing-snap-on-fedora/6755


> And if you prefer your favorite
> tool inside a container you can find docker images everywhere.
>
> A few years ago compatibility was achieved on source code level.
> Sorry to say, but you lost that for lxd. And snaps are not a
> replacement.
>
>
In the past I've built private RPMs for lxd on centos. It became a hassle
though as (for example) I need to port additional packages as well. And I
needed to change the kernel to a newer one, unsupported by centos. But it
works.

So if you're willing to build from source, it should still work.

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] why does ssh + lxc hang? (used to work)

[Stéphane Graber]

This is https://github.com/lxc/lxd/issues/5519

On Sun, Feb 24, 2019 at 1:34 PM Tomasz Chmielewski  wrote:
>
> This works (executed on a host):
>
> host# lxc exec container -- date
> Sun Feb 24 12:25:21 UTC 2019
> host#
>
> This however hangs and doesn't return (executed from a remote system,
> i.e. your laptop or a different server):
>
> laptop$ ssh root@host "export PATH=$PATH:/snap/bin ; lxc exec container
> -- date"
> Sun Feb 24 12:28:04 UTC 2019
> (...command does not return...)
>
> Or a direct path to lxc binary - also hangs:
>
> laptop$ ssh root@host "/snap/bin/lxc exec container -- date"
> Sun Feb 24 12:29:54 UTC 2019
> (...command does not return...)
>
>
> Of course a simple "date" execution via ssh on the host does not hang:
>
> laptop$ ssh root@host date
> Sun Feb 24 12:31:33 UTC 2019
> laptop$
>
>
> Why do commands executed via ssh and lxc hang? It used to work some 1-2
> months ago, not sure with which lxd version it regressed like this.
>
>
> Tomasz Chmielewski
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users



-- 
Stéphane
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] lxc container rootfs dev folder permission are changing from ro to rw inside container

[Tomasz Chmielewski]

Please note these are two separate commands:

mount

cat /proc/mounts


Tomasz Chmielewski
https://lxadm.com


On 2019-02-25 17:37, Yasoda Padala wrote:

yasoda@yasoda-HP-Z600-Workstation:~/.local/share/lxc/busybox$
lxc-attach -n busybox
lxc-attach: busybox: utils.c: get_ns_uid: 548 No such file or
directory - Failed to open uid_map
 lxc-attach: busybox: utils.c: get_ns_gid: 579 No such file or
directory - Failed to open gid_map

BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/ # mount cat /proc/mounts
mount: mounting cat on /proc/mounts failed: No such file or directory
/ #
/ #

Please find attached container config

On Mon, Feb 25, 2019 at 2:01 PM Tomasz Chmielewski 
wrote:


On 2019-02-25 17:27, Yasoda Padala wrote:


Actual results: dev folder of container rootfs is read-only on

host

machine but inside container, it is writable.

Please help with inputs on why the dev folder permissions are

changed

on lxc-attach.


Can you paste the output of:

mount
cat /proc/mounts

from the container?

Tomasz Chmielewski
https://lxadm.com

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] lxc container rootfs dev folder permission are changing from ro to rw inside container

[Yasoda Padala]

yasoda@yasoda-HP-Z600-Workstation:~/.local/share/lxc/busybox$ lxc-attach -n
busybox
lxc-attach: busybox: utils.c: get_ns_uid: 548 No such file or directory -
Failed to open uid_map
lxc-attach: busybox: utils.c: get_ns_gid: 579 No such file or directory -
Failed to open gid_map

BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.


*/ # mount cat /proc/mountsmount: mounting cat on /proc/mounts failed: No
such file or directory*
/ #
/ #

Please find attached container config

On Mon, Feb 25, 2019 at 2:01 PM Tomasz Chmielewski  wrote:

> On 2019-02-25 17:27, Yasoda Padala wrote:
>
> > Actual results: dev folder of container rootfs is read-only on host
> > machine but inside container, it is writable.
> >
> > Please help with inputs on why the dev folder permissions are changed
> > on lxc-attach.
>
> Can you paste the output of:
>
> mount
> cat /proc/mounts
>
> from the container?
>
>
> Tomasz Chmielewski
> https://lxadm.com
>


busybox-config
Description: Binary data
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] lxc container rootfs dev folder permission are changing from ro to rw inside container

[Yasoda Padala]

Hi All,
I have created lxc container based out of busybox template
Our requirement is to start the container with squashed rootfs.

Below are the steps followed to create lxc container, squash rootfs and
start

1. lxc-create -n b01 -t busybox
2. mksquashfs rootfs rootfs.sq
3. mv rootfs rootfs.org  //take backup of original rootfs
4. mkdir rootfs && sudo mount -o loop -t squashfs rootfs.sq rootfs  //mount
squashed rootfs to rootfs folder
5. lxc-start -n b01

Container starts successfully and all the folders/files of rootfs on host
machine is read-only.
 Expectation is on start and logging into container, the permissions of
rootfs files should remain intact

Actual results: dev folder of container rootfs is read-only on host machine
but inside container, it is writable.

Please help with inputs on why the dev folder permissions are changed on
lxc-attach.

Thanks for the help,
Yasoda
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] future of lxc/lxd? snap?

[Harald Dunkel]

On 2/25/19 4:52 AM, Fajar A. Nugraha wrote:


snapcraft.io  is also owned by Canonical.

By using lxd snap, they can easly have lxd running on any distro that already 
support snaps, without having to maintain separate packages.



The problem is that there is no standard for all "major" distros,
as this discussion shows:

https://www.reddit.com/r/redhat/comments/9lbm0c/snapd_for_rhel/

Debian already has an excellent packaging scheme. The RPM world
doesn't follow snapd, as it seems. And if you prefer your favorite
tool inside a container you can find docker images everywhere.

A few years ago compatibility was achieved on source code level.
Sorry to say, but you lost that for lxd. And snaps are not a
replacement.


Just my own $0.02. Regards
Harri
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users