Re: [lxc-users] not allowed to change kernel parameters inside container
If your goal is this it sounds like you want to lose the container portion and put the app bare-metal onto the system so it can adjust things with sysctl. Containers aren't designed or even intended to have full host controls. Giving containers that is a bad idea. Sounds more to me like you want virtualization or bare metal app installs rather than containerization with LXC/LXD. Thomas > On May 23, 2019, at 18:41, Saint Michael wrote: > > It means that the container has, or it must have all the power and rights. > It seems to be impossible to achieve that. > >> On Thu, May 23, 2019 at 6:35 PM Andrey Repin wrote: >> Greetings, Saint Michael! >> >> > In my model, the host is unimportant, the container has the app, and I have >> > only one container per host. That way I can migrate the apps from server to >> > server in a few minutes. >> >> And? >> >> >> -- >> With best regards, >> Andrey Repin >> Friday, May 24, 2019 1:26:43 >> >> Sorry for my terrible english... >> >> ___ >> 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 mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
On Wed, May 29, 2019 at 10:44 AM Saint Michael wrote: > The Achilles' heel is the type of CPU. I had to recompile my app once I > moved it to an older CPU. Nothing is portable 100%. > I guess nothing allows you to get rid of the developer at the end of the > day. > If you compile it yourself, you should be able to pick the oldest cpu to support and use appropriate optimization options for that cpu: https://stackoverflow.com/a/10650010 If for whatever reason you can't modify the compile flag, I believe virt-manager/kvm has the option to choose what cpu to present to the host (it can pretend to be an older cpu). So you could probably set kvm to present the oldest cpu you want to support, and compile it there. -- Fajar ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
The Achilles' heel is the type of CPU. I had to recompile my app once I moved it to an older CPU. Nothing is portable 100%. I guess nothing allows you to get rid of the developer at the end of the day. On Tue, May 28, 2019 at 9:25 PM Fajar A. Nugraha wrote: > On Tue, May 28, 2019 at 8:18 PM Saint Michael wrote: > >> Thanks for the F grade. >> In telecommunications, there is a special kind of software apps called >> switches, which actually involve dozens of apps, scripts, etc. That kind of >> complexity is only packageable in a container. >> > > It's a matter of choice. AT&T seems to go with VMs and openstack: > https://www.theregister.co.uk/2016/01/08/att_expanding_sdn/ > > That being said, https://anbox.io/ does something similar with you: they > package complex apps using lxc. In their case, they use snaps for > distribution, and then use lxc internally. > > -- > Fajar > > ___ > 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] not allowed to change kernel parameters inside container
On Tue, May 28, 2019 at 8:18 PM Saint Michael wrote: > Thanks for the F grade. > In telecommunications, there is a special kind of software apps called > switches, which actually involve dozens of apps, scripts, etc. That kind of > complexity is only packageable in a container. > It's a matter of choice. AT&T seems to go with VMs and openstack: https://www.theregister.co.uk/2016/01/08/att_expanding_sdn/ That being said, https://anbox.io/ does something similar with you: they package complex apps using lxc. In their case, they use snaps for distribution, and then use lxc internally. -- Fajar ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
All the harsh criticism aside, the driving concern in business is getting it done. Many successful products have been kludges, which fulfilled a need. Jake On Tue, May 28, 2019 at 7:00 AM Scott Lopez wrote: > So? Doesn't matter if you're programming a switch or a heart monitor. > Learn how to properly package your application. Apparently it was done > before LXC came along, so it should still be possible today. What you want > is an easy way out of simply cloning an existing installation which is > never a good idea as operating environments are never exactly the same. Any > SA worth their salt would know this and package an application properly. > This is going to come back and bite you in the ass, hard, some day. > ___ > 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] not allowed to change kernel parameters inside container
So? Doesn't matter if you're programming a switch or a heart monitor. Learn how to properly package your application. Apparently it was done before LXC came along, so it should still be possible today. What you want is an easy way out of simply cloning an existing installation which is never a good idea as operating environments are never exactly the same. Any SA worth their salt would know this and package an application properly. This is going to come back and bite you in the ass, hard, some day. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
Thanks for the F grade. In telecommunications, there is a special kind of software apps called switches, which actually involve dozens of apps, scripts, etc. That kind of complexity is only packageable in a container. Other industries can get away with far simpler infrastructures. A switch is responsible for the whole business and handles literally millions of dollars in phone calls daily. On Tue, May 28, 2019 at 8:57 AM Scott Lopez wrote: > Wow, what a disaster of a thread. > > Wouldn't it be easier to learn how to properly package and distribute your > application suite using a tool such as Ansible than to learn how to break > LXC, deal with the quirks and figure out how to shoehorn it into doing what > it wasn't designed to do? > > You get a B- for creativity and a F for implementation. I'd never allow > this disaster in a production environment. Too many unforeseen consequences > of the implementation, any issues that pop up are going to be a joy to > track down. Is it the container, is it LXC, is it something else? > > Just because you can do something, doesn't mean you should. > > ___ > 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] not allowed to change kernel parameters inside container
Wow, what a disaster of a thread. Wouldn't it be easier to learn how to properly package and distribute your application suite using a tool such as Ansible than to learn how to break LXC, deal with the quirks and figure out how to shoehorn it into doing what it wasn't designed to do? You get a B- for creativity and a F for implementation. I'd never allow this disaster in a production environment. Too many unforeseen consequences of the implementation, any issues that pop up are going to be a joy to track down. Is it the container, is it LXC, is it something else? Just because you can do something, doesn't mean you should. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
I actually think that lxc.net.0.type = none is the solution to all my problems. All I need to access my host is to use a different SSH port. I didn't know this one. Thanks to all of you. On Tue, May 28, 2019 at 1:47 AM Fajar A. Nugraha wrote: > On Tue, May 28, 2019 at 12:39 PM Saint Michael wrote: > >> This >> "host and container can't have services run on the same port (e.g. if you >> want sshd on both host and container, you need to change the listening port >> for one of them)" >> is untrue. >> each container in my case has a different IP address, the host has >> another one, and I run SSHD inside each container just fine. >> >> > That is indeed the case for normal container setup. However you repeatedly > said you want to be able to set net.core.rmem_max (and friends) from inside > the container, which requires a not-normal setup. > > If you want to be able to do that from inside the container, you need the > container to share host networking (lxc.net.0.type = none). It comes with > its own consequences, thus the warnings above. > > If you want to keep having separate ip for the host and container, then > you can't set net.core.rmem_max from inside the container. However, as > someone point out earlier, you can simply setup passwordless ssh, and have > container set it using ssh to the host during boot time. > > -- > Fajar > ___ > 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] not allowed to change kernel parameters inside container
On Tue, May 28, 2019 at 12:39 PM Saint Michael wrote: > This > "host and container can't have services run on the same port (e.g. if you > want sshd on both host and container, you need to change the listening port > for one of them)" > is untrue. > each container in my case has a different IP address, the host has another > one, and I run SSHD inside each container just fine. > > That is indeed the case for normal container setup. However you repeatedly said you want to be able to set net.core.rmem_max (and friends) from inside the container, which requires a not-normal setup. If you want to be able to do that from inside the container, you need the container to share host networking (lxc.net.0.type = none). It comes with its own consequences, thus the warnings above. If you want to keep having separate ip for the host and container, then you can't set net.core.rmem_max from inside the container. However, as someone point out earlier, you can simply setup passwordless ssh, and have container set it using ssh to the host during boot time. -- Fajar ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
This
"host and container can't have services run on the same port (e.g. if you
want sshd on both host and container, you need to change the listening port
for one of them)"
is untrue.
each container in my case has a different IP address, the host has another
one, and I run SSHD inside each container just fine.
On Mon, May 27, 2019 at 10:00 PM Fajar A. Nugraha wrote:
> On Mon, May 27, 2019 at 8:11 PM Saint Michael wrote:
>
>> I thought I did start the containers as privileged:
>>
>> lxc.include = /usr/share/lxc/config/ubuntu.common.conf
>> lxc.mount.auto=
>> lxc.mount.auto=proc:rw sys:rw cgroup:rw
>> lxc.apparmor.profile=unconfined
>> lxc.tty.max = 10
>> lxc.pty.max = 1024
>> lxc.cgroup.devices.allow = c 1:3 rwm
>> lxc.cgroup.devices.allow = c 1:5 rwm
>> lxc.cgroup.devices.allow = c 5:1 rwm
>> lxc.cgroup.devices.allow = c 5:0 rwm
>> lxc.cgroup.devices.allow = c 4:0 rwm
>> lxc.cgroup.devices.allow = c 4:1 rwm
>> lxc.cgroup.devices.allow = c 1:9 rwm
>> lxc.cgroup.devices.allow = c 1:8 rwm
>> lxc.cgroup.devices.allow = c 136:* rwm
>> lxc.cgroup.devices.allow = c 5:2 rwm
>> lxc.cgroup.devices.allow = c 254:0 rwm
>> lxc.cgroup.devices.allow = c 10:137 rwm # loop-control
>> lxc.cgroup.devices.allow = b 7:* rwm# loop*
>> lxc.cgroup.devices.allow = c 10:229 rwm #fuse
>> lxc.cgroup.devices.allow = c 10:200 rwm #docker
>> lxc.cgroup.devices.allow= a
>> lxc.cap.drop=
>> lxc.cgroup.devices.deny=
>> lxc.autodev= 1
>> lxc.hook.autodev = sh -c 'mknod ${LXC_ROOTFS_MOUNT}/dev/fuse c 10 229'
>>
>
>
> Following Stephane's suggestion works on my test vm. You didn't do so,
> thus it didn't work.
>
> ###
> # Distribution configuration
> lxc.include = /usr/share/lxc/config/common.conf
> lxc.arch = x86_64
>
> # Container specific configuration
> lxc.rootfs.path = dir:/var/lib/lxc/c7-ul/rootfs
> lxc.uts.name = c7-ul
>
> lxc.net.0.type = none
> lxc.mount.auto=
> lxc.mount.auto=proc:rw sys:rw cgroup:rw
> lxc.apparmor.profile=unconfined
> ###
>
> ###
> c7-ul / # sysctl --system
> * Applying /usr/lib/sysctl.d/00-system.conf ...
> * Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
> kernel.yama.ptrace_scope = 0
> * Applying /usr/lib/sysctl.d/50-default.conf ...
> kernel.sysrq = 16
> kernel.core_uses_pid = 1
> net.ipv4.conf.default.rp_filter = 1
> net.ipv4.conf.all.rp_filter = 1
> net.ipv4.conf.default.accept_source_route = 0
> net.ipv4.conf.all.accept_source_route = 0
> net.ipv4.conf.default.promote_secondaries = 1
> net.ipv4.conf.all.promote_secondaries = 1
> fs.protected_hardlinks = 1
> fs.protected_symlinks = 1
> * Applying /etc/sysctl.d/99-sysctl.conf ...
> * Applying /etc/sysctl.d/net.conf ...
> net.core.rmem_max = 67108864
> net.core.wmem_max = 33554432
> net.core.rmem_default = 31457280
> net.core.wmem_default = 31457280
> * Applying /etc/sysctl.conf ...
>
> c7-ul / # cat /proc/sys/net/core/rmem_max
> 67108864
> ###
>
>
> Of course as warned earlier, host networking brings along some quirks. For
> instance:
> - host and container can't have services run on the same port (e.g. if you
> want sshd on both host and container, you need to change the listening port
> for one of them)
> - do not configure networking on the container (ONBOOT=no should be enough
> on your container's eth confi)
> - absolutely do not run "reboot", "init 6", or "poweroff" on the
> container. At the very least, it will cause hosts's eth0 to go down.
> "reboot -f" on the container should work nicely though.
>
> --
> Fajar
> ___
> 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] not allowed to change kernel parameters inside container
On Mon, May 27, 2019 at 8:11 PM Saint Michael wrote:
> I thought I did start the containers as privileged:
>
> lxc.include = /usr/share/lxc/config/ubuntu.common.conf
> lxc.mount.auto=
> lxc.mount.auto=proc:rw sys:rw cgroup:rw
> lxc.apparmor.profile=unconfined
> lxc.tty.max = 10
> lxc.pty.max = 1024
> lxc.cgroup.devices.allow = c 1:3 rwm
> lxc.cgroup.devices.allow = c 1:5 rwm
> lxc.cgroup.devices.allow = c 5:1 rwm
> lxc.cgroup.devices.allow = c 5:0 rwm
> lxc.cgroup.devices.allow = c 4:0 rwm
> lxc.cgroup.devices.allow = c 4:1 rwm
> lxc.cgroup.devices.allow = c 1:9 rwm
> lxc.cgroup.devices.allow = c 1:8 rwm
> lxc.cgroup.devices.allow = c 136:* rwm
> lxc.cgroup.devices.allow = c 5:2 rwm
> lxc.cgroup.devices.allow = c 254:0 rwm
> lxc.cgroup.devices.allow = c 10:137 rwm # loop-control
> lxc.cgroup.devices.allow = b 7:* rwm# loop*
> lxc.cgroup.devices.allow = c 10:229 rwm #fuse
> lxc.cgroup.devices.allow = c 10:200 rwm #docker
> lxc.cgroup.devices.allow= a
> lxc.cap.drop=
> lxc.cgroup.devices.deny=
> lxc.autodev= 1
> lxc.hook.autodev = sh -c 'mknod ${LXC_ROOTFS_MOUNT}/dev/fuse c 10 229'
>
Following Stephane's suggestion works on my test vm. You didn't do so, thus
it didn't work.
###
# Distribution configuration
lxc.include = /usr/share/lxc/config/common.conf
lxc.arch = x86_64
# Container specific configuration
lxc.rootfs.path = dir:/var/lib/lxc/c7-ul/rootfs
lxc.uts.name = c7-ul
lxc.net.0.type = none
lxc.mount.auto=
lxc.mount.auto=proc:rw sys:rw cgroup:rw
lxc.apparmor.profile=unconfined
###
###
c7-ul / # sysctl --system
* Applying /usr/lib/sysctl.d/00-system.conf ...
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
kernel.yama.ptrace_scope = 0
* Applying /usr/lib/sysctl.d/50-default.conf ...
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.d/net.conf ...
net.core.rmem_max = 67108864
net.core.wmem_max = 33554432
net.core.rmem_default = 31457280
net.core.wmem_default = 31457280
* Applying /etc/sysctl.conf ...
c7-ul / # cat /proc/sys/net/core/rmem_max
67108864
###
Of course as warned earlier, host networking brings along some quirks. For
instance:
- host and container can't have services run on the same port (e.g. if you
want sshd on both host and container, you need to change the listening port
for one of them)
- do not configure networking on the container (ONBOOT=no should be enough
on your container's eth confi)
- absolutely do not run "reboot", "init 6", or "poweroff" on the container.
At the very least, it will cause hosts's eth0 to go down. "reboot -f" on
the container should work nicely though.
--
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
I thought I did start the containers as privileged:
lxc.include = /usr/share/lxc/config/ubuntu.common.conf
lxc.mount.auto=
lxc.mount.auto=proc:rw sys:rw cgroup:rw
lxc.apparmor.profile=unconfined
lxc.tty.max = 10
lxc.pty.max = 1024
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
lxc.cgroup.devices.allow = c 4:0 rwm
lxc.cgroup.devices.allow = c 4:1 rwm
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
lxc.cgroup.devices.allow = c 254:0 rwm
lxc.cgroup.devices.allow = c 10:137 rwm # loop-control
lxc.cgroup.devices.allow = b 7:* rwm# loop*
lxc.cgroup.devices.allow = c 10:229 rwm #fuse
lxc.cgroup.devices.allow = c 10:200 rwm #docker
lxc.cgroup.devices.allow= a
lxc.cap.drop=
lxc.cgroup.devices.deny=
lxc.autodev= 1
lxc.hook.autodev = sh -c 'mknod ${LXC_ROOTFS_MOUNT}/dev/fuse c 10 229'
On Mon, May 27, 2019 at 9:03 AM Jäkel, Guido wrote:
> Because
>
> * your Container is not started as a privileged one?
> * you let bind-mount /sys readonly?
>
> Guido
>
> >-Original Message-
> >From: lxc-users [mailto:lxc-users-boun...@lists.linuxcontainers.org] On
> Behalf Of Saint Michael
> >Sent: Monday, May 27, 2019 1:49 PM
> >To: LXC users mailing-list
> >Subject: Re: [lxc-users] not allowed to change kernel parameters inside
> container
> >
> >The issue that kills me is why I can change some kernel parameters, but
> not for example
> >[...]
> >
> >Any idea?
> >
> ___
> 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] not allowed to change kernel parameters inside container
Because * your Container is not started as a privileged one? * you let bind-mount /sys readonly? Guido >-Original Message- >From: lxc-users [mailto:lxc-users-boun...@lists.linuxcontainers.org] On Behalf >Of Saint Michael >Sent: Monday, May 27, 2019 1:49 PM >To: LXC users mailing-list >Subject: Re: [lxc-users] not allowed to change kernel parameters inside >container > >The issue that kills me is why I can change some kernel parameters, but not >for example >[...] > >Any idea? > ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
cat /etc/*release* DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS" NAME="Ubuntu" VERSION="18.04.2 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.2 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL=" https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic prlimit -p 1 RESOURCE DESCRIPTION SOFT HARD UNITS AS address space limitunlimited unlimited bytes CORE max core file size 0 unlimited bytes CPUCPU time unlimited unlimited seconds DATA max data size unlimited unlimited bytes FSIZE max file size unlimited unlimited bytes LOCKS max number of file locks held unlimited unlimited locks MEMLOCKmax locked-in-memory address space 16777216 16777216 bytes MSGQUEUE max bytes in POSIX mqueues819200819200 bytes NICE max nice prio allowed to raise 0 0 NOFILE max number of open files 1048576 1048576 files NPROC max number of processes 503249503249 processes RSSmax resident set size unlimited unlimited bytes RTPRIO max real-time priority 0 0 RTTIME timeout for real-time tasksunlimited unlimited microsecs SIGPENDING max number of pending signals 503249503249 signals STACK max stack size 8388608 unlimited bytes On Mon, May 27, 2019 at 8:06 AM Kees Bos wrote: > I probably missed it, but which release are you using on the host? > > And what's the output of > prlimit -p 1 > ? > > On Mon, May 27, 2019, 1:52 PM Saint Michael wrote: > >> My applications are very complex and involved many applications in the >> traditional sense. It is a nightmare to install them. >> My application runs on Centos but I prefer to use Ubuntu as LXC host. >> I found that rsynching a container over the WAN is the only perfect way >> to deploy. >> The issue that kills me is why I can change some kernel parameters, but >> not for example >> net.core.rmem_max = 67108864 >> net.core.wmem_max = 33554432 >> net.core.rmem_default = 31457280 >> net.core.wmem_default = 31457280 >> Any idea? >> >> >> >> >> >> On Mon, May 27, 2019 at 2:57 AM Jäkel, Guido wrote: >> >>> Dear Michael, >>> >>> > For me, the single point of using LXC is to be able to >>> redeploy a complex >>> > app from host to host in a few minutes. I use >>> one-host->one-Container. So >>> > what is the issue of giving all power to the containers? >>> >>> I don't understand yet, why you want to use Containers, LXC or Dockers >>> at all: You need to have full access to the host and it hardware at low >>> level and don't want to use any isolation or virtualization aspects at all. >>> If you just want to redeploy a complex setup within minutes, you may just >>> need to use a prepared backup of your hosts, or an layered setup with an >>> read-only image and an writeable layer for the changes. >>> >>> Guido >>> >>> ___ >>> 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 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] not allowed to change kernel parameters inside container
I probably missed it, but which release are you using on the host? And what's the output of prlimit -p 1 ? On Mon, May 27, 2019, 1:52 PM Saint Michael wrote: > My applications are very complex and involved many applications in the > traditional sense. It is a nightmare to install them. > My application runs on Centos but I prefer to use Ubuntu as LXC host. > I found that rsynching a container over the WAN is the only perfect way to > deploy. > The issue that kills me is why I can change some kernel parameters, but > not for example > net.core.rmem_max = 67108864 > net.core.wmem_max = 33554432 > net.core.rmem_default = 31457280 > net.core.wmem_default = 31457280 > Any idea? > > > > > > On Mon, May 27, 2019 at 2:57 AM Jäkel, Guido wrote: > >> Dear Michael, >> >> > For me, the single point of using LXC is to be able to redeploy >> a complex >> > app from host to host in a few minutes. I use >> one-host->one-Container. So >> > what is the issue of giving all power to the containers? >> >> I don't understand yet, why you want to use Containers, LXC or Dockers at >> all: You need to have full access to the host and it hardware at low level >> and don't want to use any isolation or virtualization aspects at all. If >> you just want to redeploy a complex setup within minutes, you may just need >> to use a prepared backup of your hosts, or an layered setup with an >> read-only image and an writeable layer for the changes. >> >> Guido >> >> ___ >> 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 mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
My applications are very complex and involved many applications in the traditional sense. It is a nightmare to install them. My application runs on Centos but I prefer to use Ubuntu as LXC host. I found that rsynching a container over the WAN is the only perfect way to deploy. The issue that kills me is why I can change some kernel parameters, but not for example net.core.rmem_max = 67108864 net.core.wmem_max = 33554432 net.core.rmem_default = 31457280 net.core.wmem_default = 31457280 Any idea? On Mon, May 27, 2019 at 2:57 AM Jäkel, Guido wrote: > Dear Michael, > > > For me, the single point of using LXC is to be able to redeploy > a complex > > app from host to host in a few minutes. I use > one-host->one-Container. So > > what is the issue of giving all power to the containers? > > I don't understand yet, why you want to use Containers, LXC or Dockers at > all: You need to have full access to the host and it hardware at low level > and don't want to use any isolation or virtualization aspects at all. If > you just want to redeploy a complex setup within minutes, you may just need > to use a prepared backup of your hosts, or an layered setup with an > read-only image and an writeable layer for the changes. > > Guido > > ___ > 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] not allowed to change kernel parameters inside container
Dear Michael, > For me, the single point of using LXC is to be able to redeploy a complex > app from host to host in a few minutes. I use one-host->one-Container. So > what is the issue of giving all power to the containers? I don't understand yet, why you want to use Containers, LXC or Dockers at all: You need to have full access to the host and it hardware at low level and don't want to use any isolation or virtualization aspects at all. If you just want to redeploy a complex setup within minutes, you may just need to use a prepared backup of your hosts, or an layered setup with an read-only image and an writeable layer for the changes. Guido ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
On Sun, May 26, 2019 at 9:18 AM Saint Michael wrote: > I am fine with having full interaction with the host. The host does not do > anything, it is like a glove for my app, which uses UDP very intensely, > like 500 Mbits per second. I need to fine-tune all its parameters. > > > > On Sat, May 25, 2019 at 9:52 PM Stéphane Graber > wrote: > >> If your container doesn't need isolated networking, in theory using the >> host namespace for the network would cause those to show back up, but >> note that sharing network namespace with the host may have some very >> weird side effects (such as systemd in the container interacting with >> the host's). >> >> What distro are you using for the containers? If both container and host are using systemd, then as Stephane point out bad things might happen when you use host networking. If your container is using something different (e.g. devuan, which uses sysvinit), or if the container is using a custom init (e.g. init basically only runs your app like what is usually done with docker, or if you use supervisord), then it should be fine. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
I am fine with having full interaction with the host. The host does not do anything, it is like a glove for my app, which uses UDP very intensely, like 500 Mbits per second. I need to fine-tune all its parameters. On Sat, May 25, 2019 at 9:52 PM Stéphane Graber wrote: > So the missing ones there's really nothing you can do about, though > normally that shouldn't cause sysctl application to fail as it's > somewhat common for systems to have a different set of sysctls. > > In this case, it's because the network namespace is filtering some of them. > > If your container doesn't need isolated networking, in theory using the > host namespace for the network would cause those to show back up, but > note that sharing network namespace with the host may have some very > weird side effects (such as systemd in the container interacting with > the host's). > > On Sat, May 25, 2019 at 09:36:25PM -0400, Saint Michael wrote: > > some things do not work inside the container > > sysctl -p > > fs.aio-max-nr = 1048576 > > fs.aio-max-nr = 655360 > > fs.inotify.max_user_instances = 8192 > > kernel.pty.max = 16120 > > kernel.randomize_va_space = 1 > > kernel.shmall = 4294967296 > > kernel.shmmax = 990896795648 > > net.ipv4.conf.all.arp_announce = 2 > > net.ipv4.conf.all.arp_filter = 1 > > net.ipv4.conf.all.arp_ignore = 1 > > net.ipv4.conf.all.rp_filter = 1 > > net.ipv4.conf.default.accept_source_route = 0 > > net.ipv4.conf.default.arp_filter = 1 > > net.ipv4.conf.default.rp_filter = 1 > > net.ipv4.ip_forward = 1 > > net.ipv4.ip_local_port_range = 5000 65535 > > net.ipv4.ip_nonlocal_bind = 0 > > net.ipv4.ip_no_pmtu_disc = 0 > > net.ipv4.tcp_tw_reuse = 1 > > vm.hugepages_treat_as_movable = 0 > > vm.hugetlb_shm_group = 128 > > vm.nr_hugepages = 250 > > vm.nr_hugepages_mempolicy = 250 > > vm.overcommit_memory = 0 > > vm.swappiness = 0 > > vm.vfs_cache_pressure = 150 > > vm.dirty_ratio = 10 > > vm.dirty_background_ratio = 5 > > kernel.hung_task_timeout_secs = 0 > > sysctl: cannot stat /proc/sys/net/core/rmem_max: No such file or > directory > > sysctl: cannot stat /proc/sys/net/core/wmem_max: No such file or > directory > > sysctl: cannot stat /proc/sys/net/core/rmem_default: No such file or > > directory > > sysctl: cannot stat /proc/sys/net/core/wmem_default: No such file or > > directory > > net.ipv4.tcp_rmem = 10240 87380 10485760 > > net.ipv4.tcp_wmem = 10240 87380 10485760 > > sysctl: cannot stat /proc/sys/net/ipv4/udp_rmem_min: No such file or > > directory > > sysctl: cannot stat /proc/sys/net/ipv4/udp_wmem_min: No such file or > > directory > > sysctl: cannot stat /proc/sys/net/ipv4/udp_mem: No such file or directory > > sysctl: cannot stat /proc/sys/net/ipv4/tcp_mem: No such file or directory > > sysctl: cannot stat /proc/sys/net/core/optmem_max: No such file or > directory > > net.core.somaxconn = 65535 > > sysctl: cannot stat /proc/sys/net/core/netdev_max_backlog: No such file > or > > directory > > fs.file-max = 50 > > > > > > On Sat, May 25, 2019 at 9:28 PM Saint Michael wrote: > > > > > Thanks > > > Finally some help! > > > > > > On Sat, May 25, 2019 at 9:07 PM Stéphane Graber > > > wrote: > > > > > >> On Sat, May 25, 2019 at 02:02:59PM -0400, Saint Michael wrote: > > >> > Thanks to all. I am sorry I touched a heated point. For me using > > >> > hard-virtualization for Linux apps is dementia. It should be kept > only > > >> for > > >> > Windows VMs. > > >> > For me, the single point of using LXC is to be able to redeploy a > > >> complex > > >> > app from host to host in a few minutes. I use > one-host->one-Container. > > >> So > > >> > what is the issue of giving all power to the containers? > > >> > > > >> > On Sat, May 25, 2019 at 1:56 PM jjs - mainphrame < > j...@mainphrame.com> > > >> wrote: > > >> > > > >> > > Given the developers stance, perhaps a temporary workaround is in > > >> order, > > >> > > e.g. ssh-key root login to physical host e.g. "ssh sysctl > > >> > > key=value..." > > >> > > > > >> > > Jake > > >> > > > > >> > > On Mon, May 20, 2019 at 9:25 AM Saint Michael > > >> wrote: > > >> > > > > >> > >> I am trying to use sysctl -p inside an LXC container and it says > > >> > >> read only file system > > >> > >> how do I give my container all possible rights? > > >> > >> Right now I have > > >> > >> > > >> > >> lxc.mount.auto = cgroup:mixed > > >> > >> lxc.tty.max = 10 > > >> > >> lxc.pty.max = 1024 > > >> > >> lxc.cgroup.devices.allow = c 1:3 rwm > > >> > >> lxc.cgroup.devices.allow = c 1:5 rwm > > >> > >> lxc.cgroup.devices.allow = c 5:1 rwm > > >> > >> lxc.cgroup.devices.allow = c 5:0 rwm > > >> > >> lxc.cgroup.devices.allow = c 4:0 rwm > > >> > >> lxc.cgroup.devices.allow = c 4:1 rwm > > >> > >> lxc.cgroup.devices.allow = c 1:9 rwm > > >> > >> lxc.cgroup.devices.allow = c 1:8 rwm > > >> > >> lxc.cgroup.devices.allow = c 136:* rwm > > >> > >> lxc.cgroup.devices.allow = c 5:2 rwm > > >> > >> lxc.cgroup.devices.allow = c 254:0 rwm > > >> > >> lxc.cgroup.devices.allow = c 10:137 rwm # loop-
Re: [lxc-users] not allowed to change kernel parameters inside container
So the missing ones there's really nothing you can do about, though normally that shouldn't cause sysctl application to fail as it's somewhat common for systems to have a different set of sysctls. In this case, it's because the network namespace is filtering some of them. If your container doesn't need isolated networking, in theory using the host namespace for the network would cause those to show back up, but note that sharing network namespace with the host may have some very weird side effects (such as systemd in the container interacting with the host's). On Sat, May 25, 2019 at 09:36:25PM -0400, Saint Michael wrote: > some things do not work inside the container > sysctl -p > fs.aio-max-nr = 1048576 > fs.aio-max-nr = 655360 > fs.inotify.max_user_instances = 8192 > kernel.pty.max = 16120 > kernel.randomize_va_space = 1 > kernel.shmall = 4294967296 > kernel.shmmax = 990896795648 > net.ipv4.conf.all.arp_announce = 2 > net.ipv4.conf.all.arp_filter = 1 > net.ipv4.conf.all.arp_ignore = 1 > net.ipv4.conf.all.rp_filter = 1 > net.ipv4.conf.default.accept_source_route = 0 > net.ipv4.conf.default.arp_filter = 1 > net.ipv4.conf.default.rp_filter = 1 > net.ipv4.ip_forward = 1 > net.ipv4.ip_local_port_range = 5000 65535 > net.ipv4.ip_nonlocal_bind = 0 > net.ipv4.ip_no_pmtu_disc = 0 > net.ipv4.tcp_tw_reuse = 1 > vm.hugepages_treat_as_movable = 0 > vm.hugetlb_shm_group = 128 > vm.nr_hugepages = 250 > vm.nr_hugepages_mempolicy = 250 > vm.overcommit_memory = 0 > vm.swappiness = 0 > vm.vfs_cache_pressure = 150 > vm.dirty_ratio = 10 > vm.dirty_background_ratio = 5 > kernel.hung_task_timeout_secs = 0 > sysctl: cannot stat /proc/sys/net/core/rmem_max: No such file or directory > sysctl: cannot stat /proc/sys/net/core/wmem_max: No such file or directory > sysctl: cannot stat /proc/sys/net/core/rmem_default: No such file or > directory > sysctl: cannot stat /proc/sys/net/core/wmem_default: No such file or > directory > net.ipv4.tcp_rmem = 10240 87380 10485760 > net.ipv4.tcp_wmem = 10240 87380 10485760 > sysctl: cannot stat /proc/sys/net/ipv4/udp_rmem_min: No such file or > directory > sysctl: cannot stat /proc/sys/net/ipv4/udp_wmem_min: No such file or > directory > sysctl: cannot stat /proc/sys/net/ipv4/udp_mem: No such file or directory > sysctl: cannot stat /proc/sys/net/ipv4/tcp_mem: No such file or directory > sysctl: cannot stat /proc/sys/net/core/optmem_max: No such file or directory > net.core.somaxconn = 65535 > sysctl: cannot stat /proc/sys/net/core/netdev_max_backlog: No such file or > directory > fs.file-max = 50 > > > On Sat, May 25, 2019 at 9:28 PM Saint Michael wrote: > > > Thanks > > Finally some help! > > > > On Sat, May 25, 2019 at 9:07 PM Stéphane Graber > > wrote: > > > >> On Sat, May 25, 2019 at 02:02:59PM -0400, Saint Michael wrote: > >> > Thanks to all. I am sorry I touched a heated point. For me using > >> > hard-virtualization for Linux apps is dementia. It should be kept only > >> for > >> > Windows VMs. > >> > For me, the single point of using LXC is to be able to redeploy a > >> complex > >> > app from host to host in a few minutes. I use one-host->one-Container. > >> So > >> > what is the issue of giving all power to the containers? > >> > > >> > On Sat, May 25, 2019 at 1:56 PM jjs - mainphrame > >> wrote: > >> > > >> > > Given the developers stance, perhaps a temporary workaround is in > >> order, > >> > > e.g. ssh-key root login to physical host e.g. "ssh sysctl > >> > > key=value..." > >> > > > >> > > Jake > >> > > > >> > > On Mon, May 20, 2019 at 9:25 AM Saint Michael > >> wrote: > >> > > > >> > >> I am trying to use sysctl -p inside an LXC container and it says > >> > >> read only file system > >> > >> how do I give my container all possible rights? > >> > >> Right now I have > >> > >> > >> > >> lxc.mount.auto = cgroup:mixed > >> > >> lxc.tty.max = 10 > >> > >> lxc.pty.max = 1024 > >> > >> lxc.cgroup.devices.allow = c 1:3 rwm > >> > >> lxc.cgroup.devices.allow = c 1:5 rwm > >> > >> lxc.cgroup.devices.allow = c 5:1 rwm > >> > >> lxc.cgroup.devices.allow = c 5:0 rwm > >> > >> lxc.cgroup.devices.allow = c 4:0 rwm > >> > >> lxc.cgroup.devices.allow = c 4:1 rwm > >> > >> lxc.cgroup.devices.allow = c 1:9 rwm > >> > >> lxc.cgroup.devices.allow = c 1:8 rwm > >> > >> lxc.cgroup.devices.allow = c 136:* rwm > >> > >> lxc.cgroup.devices.allow = c 5:2 rwm > >> > >> lxc.cgroup.devices.allow = c 254:0 rwm > >> > >> lxc.cgroup.devices.allow = c 10:137 rwm # loop-control > >> > >> lxc.cgroup.devices.allow = b 7:* rwm# loop* > >> > >> lxc.cgroup.devices.allow = c 10:229 rwm #fuse > >> > >> lxc.cgroup.devices.allow = c 10:200 rwm #docker > >> > >> #lxc.cgroup.memory.limit_in_bytes = 92536870910 > >> > >> lxc.apparmor.profile= unconfined > >> > >> lxc.cgroup.devices.allow= a > >> > >> lxc.cap.drop= > >> > >> lxc.cgroup.devices.deny= > >> > >> #lxc.mount.auto= proc:rw sys:ro cgroup:ro > >> > >> lxc.autodev= 1 > >> > >> Set: > >> > >> lxc.mount.auto= > >> lxc.mount.auto=proc:rw sys:rw cgroup:
Re: [lxc-users] not allowed to change kernel parameters inside container
some things do not work inside the container sysctl -p fs.aio-max-nr = 1048576 fs.aio-max-nr = 655360 fs.inotify.max_user_instances = 8192 kernel.pty.max = 16120 kernel.randomize_va_space = 1 kernel.shmall = 4294967296 kernel.shmmax = 990896795648 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.all.arp_filter = 1 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.default.arp_filter = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.ip_forward = 1 net.ipv4.ip_local_port_range = 5000 65535 net.ipv4.ip_nonlocal_bind = 0 net.ipv4.ip_no_pmtu_disc = 0 net.ipv4.tcp_tw_reuse = 1 vm.hugepages_treat_as_movable = 0 vm.hugetlb_shm_group = 128 vm.nr_hugepages = 250 vm.nr_hugepages_mempolicy = 250 vm.overcommit_memory = 0 vm.swappiness = 0 vm.vfs_cache_pressure = 150 vm.dirty_ratio = 10 vm.dirty_background_ratio = 5 kernel.hung_task_timeout_secs = 0 sysctl: cannot stat /proc/sys/net/core/rmem_max: No such file or directory sysctl: cannot stat /proc/sys/net/core/wmem_max: No such file or directory sysctl: cannot stat /proc/sys/net/core/rmem_default: No such file or directory sysctl: cannot stat /proc/sys/net/core/wmem_default: No such file or directory net.ipv4.tcp_rmem = 10240 87380 10485760 net.ipv4.tcp_wmem = 10240 87380 10485760 sysctl: cannot stat /proc/sys/net/ipv4/udp_rmem_min: No such file or directory sysctl: cannot stat /proc/sys/net/ipv4/udp_wmem_min: No such file or directory sysctl: cannot stat /proc/sys/net/ipv4/udp_mem: No such file or directory sysctl: cannot stat /proc/sys/net/ipv4/tcp_mem: No such file or directory sysctl: cannot stat /proc/sys/net/core/optmem_max: No such file or directory net.core.somaxconn = 65535 sysctl: cannot stat /proc/sys/net/core/netdev_max_backlog: No such file or directory fs.file-max = 50 On Sat, May 25, 2019 at 9:28 PM Saint Michael wrote: > Thanks > Finally some help! > > On Sat, May 25, 2019 at 9:07 PM Stéphane Graber > wrote: > >> On Sat, May 25, 2019 at 02:02:59PM -0400, Saint Michael wrote: >> > Thanks to all. I am sorry I touched a heated point. For me using >> > hard-virtualization for Linux apps is dementia. It should be kept only >> for >> > Windows VMs. >> > For me, the single point of using LXC is to be able to redeploy a >> complex >> > app from host to host in a few minutes. I use one-host->one-Container. >> So >> > what is the issue of giving all power to the containers? >> > >> > On Sat, May 25, 2019 at 1:56 PM jjs - mainphrame >> wrote: >> > >> > > Given the developers stance, perhaps a temporary workaround is in >> order, >> > > e.g. ssh-key root login to physical host e.g. "ssh sysctl >> > > key=value..." >> > > >> > > Jake >> > > >> > > On Mon, May 20, 2019 at 9:25 AM Saint Michael >> wrote: >> > > >> > >> I am trying to use sysctl -p inside an LXC container and it says >> > >> read only file system >> > >> how do I give my container all possible rights? >> > >> Right now I have >> > >> >> > >> lxc.mount.auto = cgroup:mixed >> > >> lxc.tty.max = 10 >> > >> lxc.pty.max = 1024 >> > >> lxc.cgroup.devices.allow = c 1:3 rwm >> > >> lxc.cgroup.devices.allow = c 1:5 rwm >> > >> lxc.cgroup.devices.allow = c 5:1 rwm >> > >> lxc.cgroup.devices.allow = c 5:0 rwm >> > >> lxc.cgroup.devices.allow = c 4:0 rwm >> > >> lxc.cgroup.devices.allow = c 4:1 rwm >> > >> lxc.cgroup.devices.allow = c 1:9 rwm >> > >> lxc.cgroup.devices.allow = c 1:8 rwm >> > >> lxc.cgroup.devices.allow = c 136:* rwm >> > >> lxc.cgroup.devices.allow = c 5:2 rwm >> > >> lxc.cgroup.devices.allow = c 254:0 rwm >> > >> lxc.cgroup.devices.allow = c 10:137 rwm # loop-control >> > >> lxc.cgroup.devices.allow = b 7:* rwm# loop* >> > >> lxc.cgroup.devices.allow = c 10:229 rwm #fuse >> > >> lxc.cgroup.devices.allow = c 10:200 rwm #docker >> > >> #lxc.cgroup.memory.limit_in_bytes = 92536870910 >> > >> lxc.apparmor.profile= unconfined >> > >> lxc.cgroup.devices.allow= a >> > >> lxc.cap.drop= >> > >> lxc.cgroup.devices.deny= >> > >> #lxc.mount.auto= proc:rw sys:ro cgroup:ro >> > >> lxc.autodev= 1 >> >> Set: >> >> lxc.mount.auto= >> lxc.mount.auto=proc:rw sys:rw cgroup:rw >> lxc.apparmor.profile=unconfined >> >> >> This for a privileged container should allow all writes through /proc and >> /sys. >> As some pointed out, not usually a good idea for a container, but given >> it's the only thing on your system, that may be fine. >> >> -- >> Stéphane Graber >> Ubuntu developer >> http://www.ubuntu.com >> ___ >> lxc-users mailing list >> lxc-users@lists.linuxcontainers.org >> http://lists.linuxcontainers.org/listinfo/lxc-users >> > ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
Thanks Finally some help! On Sat, May 25, 2019 at 9:07 PM Stéphane Graber wrote: > On Sat, May 25, 2019 at 02:02:59PM -0400, Saint Michael wrote: > > Thanks to all. I am sorry I touched a heated point. For me using > > hard-virtualization for Linux apps is dementia. It should be kept only > for > > Windows VMs. > > For me, the single point of using LXC is to be able to redeploy a complex > > app from host to host in a few minutes. I use one-host->one-Container. So > > what is the issue of giving all power to the containers? > > > > On Sat, May 25, 2019 at 1:56 PM jjs - mainphrame > wrote: > > > > > Given the developers stance, perhaps a temporary workaround is in > order, > > > e.g. ssh-key root login to physical host e.g. "ssh sysctl > > > key=value..." > > > > > > Jake > > > > > > On Mon, May 20, 2019 at 9:25 AM Saint Michael > wrote: > > > > > >> I am trying to use sysctl -p inside an LXC container and it says > > >> read only file system > > >> how do I give my container all possible rights? > > >> Right now I have > > >> > > >> lxc.mount.auto = cgroup:mixed > > >> lxc.tty.max = 10 > > >> lxc.pty.max = 1024 > > >> lxc.cgroup.devices.allow = c 1:3 rwm > > >> lxc.cgroup.devices.allow = c 1:5 rwm > > >> lxc.cgroup.devices.allow = c 5:1 rwm > > >> lxc.cgroup.devices.allow = c 5:0 rwm > > >> lxc.cgroup.devices.allow = c 4:0 rwm > > >> lxc.cgroup.devices.allow = c 4:1 rwm > > >> lxc.cgroup.devices.allow = c 1:9 rwm > > >> lxc.cgroup.devices.allow = c 1:8 rwm > > >> lxc.cgroup.devices.allow = c 136:* rwm > > >> lxc.cgroup.devices.allow = c 5:2 rwm > > >> lxc.cgroup.devices.allow = c 254:0 rwm > > >> lxc.cgroup.devices.allow = c 10:137 rwm # loop-control > > >> lxc.cgroup.devices.allow = b 7:* rwm# loop* > > >> lxc.cgroup.devices.allow = c 10:229 rwm #fuse > > >> lxc.cgroup.devices.allow = c 10:200 rwm #docker > > >> #lxc.cgroup.memory.limit_in_bytes = 92536870910 > > >> lxc.apparmor.profile= unconfined > > >> lxc.cgroup.devices.allow= a > > >> lxc.cap.drop= > > >> lxc.cgroup.devices.deny= > > >> #lxc.mount.auto= proc:rw sys:ro cgroup:ro > > >> lxc.autodev= 1 > > Set: > > lxc.mount.auto= > lxc.mount.auto=proc:rw sys:rw cgroup:rw > lxc.apparmor.profile=unconfined > > > This for a privileged container should allow all writes through /proc and > /sys. > As some pointed out, not usually a good idea for a container, but given > it's the only thing on your system, that may be fine. > > -- > Stéphane Graber > Ubuntu developer > http://www.ubuntu.com > ___ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users > ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
On Sat, May 25, 2019 at 02:02:59PM -0400, Saint Michael wrote: > Thanks to all. I am sorry I touched a heated point. For me using > hard-virtualization for Linux apps is dementia. It should be kept only for > Windows VMs. > For me, the single point of using LXC is to be able to redeploy a complex > app from host to host in a few minutes. I use one-host->one-Container. So > what is the issue of giving all power to the containers? > > On Sat, May 25, 2019 at 1:56 PM jjs - mainphrame wrote: > > > Given the developers stance, perhaps a temporary workaround is in order, > > e.g. ssh-key root login to physical host e.g. "ssh sysctl > > key=value..." > > > > Jake > > > > On Mon, May 20, 2019 at 9:25 AM Saint Michael wrote: > > > >> I am trying to use sysctl -p inside an LXC container and it says > >> read only file system > >> how do I give my container all possible rights? > >> Right now I have > >> > >> lxc.mount.auto = cgroup:mixed > >> lxc.tty.max = 10 > >> lxc.pty.max = 1024 > >> lxc.cgroup.devices.allow = c 1:3 rwm > >> lxc.cgroup.devices.allow = c 1:5 rwm > >> lxc.cgroup.devices.allow = c 5:1 rwm > >> lxc.cgroup.devices.allow = c 5:0 rwm > >> lxc.cgroup.devices.allow = c 4:0 rwm > >> lxc.cgroup.devices.allow = c 4:1 rwm > >> lxc.cgroup.devices.allow = c 1:9 rwm > >> lxc.cgroup.devices.allow = c 1:8 rwm > >> lxc.cgroup.devices.allow = c 136:* rwm > >> lxc.cgroup.devices.allow = c 5:2 rwm > >> lxc.cgroup.devices.allow = c 254:0 rwm > >> lxc.cgroup.devices.allow = c 10:137 rwm # loop-control > >> lxc.cgroup.devices.allow = b 7:* rwm# loop* > >> lxc.cgroup.devices.allow = c 10:229 rwm #fuse > >> lxc.cgroup.devices.allow = c 10:200 rwm #docker > >> #lxc.cgroup.memory.limit_in_bytes = 92536870910 > >> lxc.apparmor.profile= unconfined > >> lxc.cgroup.devices.allow= a > >> lxc.cap.drop= > >> lxc.cgroup.devices.deny= > >> #lxc.mount.auto= proc:rw sys:ro cgroup:ro > >> lxc.autodev= 1 Set: lxc.mount.auto= lxc.mount.auto=proc:rw sys:rw cgroup:rw lxc.apparmor.profile=unconfined This for a privileged container should allow all writes through /proc and /sys. As some pointed out, not usually a good idea for a container, but given it's the only thing on your system, that may be fine. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: PGP signature ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
Greetings, Saint Michael! > Thanks to all. I am sorry I touched a heated point. For me using > hard-virtualization for Linux apps is dementia. It should be kept only for > Windows VMs. > For me, the single point of using LXC is to be able to redeploy a complex > app from host to host in a few minutes. I use one-host->one-Container. So > what is the issue of giving all power to the containers? Read the first reply to your first message. The answer did not change, even after your repeated questioning. And it will not change, no matter how many times you rephrase it. The applications in container do not need direct access to the hardware, thus do not need access to the related kernel facilities. If application requires direct access to the hardware, it needs a different kind of isolation. Perhaps, even virtualization. -- With best regards, Andrey Repin Saturday, May 25, 2019 21:48:18 Sorry for my terrible english... ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
Thanks to all. I am sorry I touched a heated point. For me using hard-virtualization for Linux apps is dementia. It should be kept only for Windows VMs. For me, the single point of using LXC is to be able to redeploy a complex app from host to host in a few minutes. I use one-host->one-Container. So what is the issue of giving all power to the containers? On Sat, May 25, 2019 at 1:56 PM jjs - mainphrame wrote: > Given the developers stance, perhaps a temporary workaround is in order, > e.g. ssh-key root login to physical host e.g. "ssh sysctl > key=value..." > > Jake > > On Mon, May 20, 2019 at 9:25 AM Saint Michael wrote: > >> I am trying to use sysctl -p inside an LXC container and it says >> read only file system >> how do I give my container all possible rights? >> Right now I have >> >> lxc.mount.auto = cgroup:mixed >> lxc.tty.max = 10 >> lxc.pty.max = 1024 >> lxc.cgroup.devices.allow = c 1:3 rwm >> lxc.cgroup.devices.allow = c 1:5 rwm >> lxc.cgroup.devices.allow = c 5:1 rwm >> lxc.cgroup.devices.allow = c 5:0 rwm >> lxc.cgroup.devices.allow = c 4:0 rwm >> lxc.cgroup.devices.allow = c 4:1 rwm >> lxc.cgroup.devices.allow = c 1:9 rwm >> lxc.cgroup.devices.allow = c 1:8 rwm >> lxc.cgroup.devices.allow = c 136:* rwm >> lxc.cgroup.devices.allow = c 5:2 rwm >> lxc.cgroup.devices.allow = c 254:0 rwm >> lxc.cgroup.devices.allow = c 10:137 rwm # loop-control >> lxc.cgroup.devices.allow = b 7:* rwm# loop* >> lxc.cgroup.devices.allow = c 10:229 rwm #fuse >> lxc.cgroup.devices.allow = c 10:200 rwm #docker >> #lxc.cgroup.memory.limit_in_bytes = 92536870910 >> lxc.apparmor.profile= unconfined >> lxc.cgroup.devices.allow= a >> lxc.cap.drop= >> lxc.cgroup.devices.deny= >> #lxc.mount.auto= proc:rw sys:ro cgroup:ro >> lxc.autodev= 1 >> >> >> ___ >> 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 mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
Given the developers stance, perhaps a temporary workaround is in order, e.g. ssh-key root login to physical host e.g. "ssh sysctl key=value..." Jake On Mon, May 20, 2019 at 9:25 AM Saint Michael wrote: > I am trying to use sysctl -p inside an LXC container and it says > read only file system > how do I give my container all possible rights? > Right now I have > > lxc.mount.auto = cgroup:mixed > lxc.tty.max = 10 > lxc.pty.max = 1024 > lxc.cgroup.devices.allow = c 1:3 rwm > lxc.cgroup.devices.allow = c 1:5 rwm > lxc.cgroup.devices.allow = c 5:1 rwm > lxc.cgroup.devices.allow = c 5:0 rwm > lxc.cgroup.devices.allow = c 4:0 rwm > lxc.cgroup.devices.allow = c 4:1 rwm > lxc.cgroup.devices.allow = c 1:9 rwm > lxc.cgroup.devices.allow = c 1:8 rwm > lxc.cgroup.devices.allow = c 136:* rwm > lxc.cgroup.devices.allow = c 5:2 rwm > lxc.cgroup.devices.allow = c 254:0 rwm > lxc.cgroup.devices.allow = c 10:137 rwm # loop-control > lxc.cgroup.devices.allow = b 7:* rwm# loop* > lxc.cgroup.devices.allow = c 10:229 rwm #fuse > lxc.cgroup.devices.allow = c 10:200 rwm #docker > #lxc.cgroup.memory.limit_in_bytes = 92536870910 > lxc.apparmor.profile= unconfined > lxc.cgroup.devices.allow= a > lxc.cap.drop= > lxc.cgroup.devices.deny= > #lxc.mount.auto= proc:rw sys:ro cgroup:ro > lxc.autodev= 1 > > > ___ > 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] not allowed to change kernel parameters inside container
Use KVM and problem solved. S. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
Greetings, Saint Michael! > This a political opinion, No, this is a consensual decision. > "Containers aren't designed or even intended to have full host controls" I > think they should have all the power, if the app needs it. Then the app is not intended to be run in the container (i.e. an application that works directly with hardware). > Can we move away from this congressional debate? Yes, you can move away. Just stop sending mails with such content to the list. -- With best regards, Andrey Repin Saturday, May 25, 2019 19:08:49 Sorry for my terrible english... ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
This a political opinion, "Containers aren't designed or even intended to have full host controls" I think they should have all the power, if the app needs it. Can we move away from this congressional debate? How do I configure my container to be on par with the host? Is it doable? On Fri, May 24, 2019 at 11:09 PM Thomas Ward wrote: > If your goal is this it sounds like you want to lose the container portion > and put the app bare-metal onto the system so it can adjust things with > sysctl. > > Containers aren't designed or even intended to have full host controls. > Giving containers that is a bad idea. > > Sounds more to me like you want virtualization or bare metal app installs > rather than containerization with LXC/LXD. > > > Thomas > > On May 23, 2019, at 18:41, Saint Michael wrote: > > It means that the container has, or it must have all the power and rights. > It seems to be impossible to achieve that. > > On Thu, May 23, 2019 at 6:35 PM Andrey Repin wrote: > >> Greetings, Saint Michael! >> >> > In my model, the host is unimportant, the container has the app, and I >> have >> > only one container per host. That way I can migrate the apps from >> server to >> > server in a few minutes. >> >> And? >> >> >> -- >> With best regards, >> Andrey Repin >> Friday, May 24, 2019 1:26:43 >> >> Sorry for my terrible english... >> >> ___ >> 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 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] not allowed to change kernel parameters inside container
If your goal is this it sounds like you want to lose the container portion and put the app bare-metal onto the system so it can adjust things with sysctl. Containers aren't designed or even intended to have full host controls. Giving containers that is a bad idea. Sounds more to me like you want virtualization or bare metal app installs rather than containerization with LXC/LXD. Thomas > On May 23, 2019, at 18:41, Saint Michael wrote: > > It means that the container has, or it must have all the power and rights. > It seems to be impossible to achieve that. > >> On Thu, May 23, 2019 at 6:35 PM Andrey Repin wrote: >> Greetings, Saint Michael! >> >> > In my model, the host is unimportant, the container has the app, and I have >> > only one container per host. That way I can migrate the apps from server to >> > server in a few minutes. >> >> And? >> >> >> -- >> With best regards, >> Andrey Repin >> Friday, May 24, 2019 1:26:43 >> >> Sorry for my terrible english... >> >> ___ >> 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 mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
Greetings, Saint Michael! > It means that the container has, or it must have all the power and rights. No. Container should have only enough rights to run the application. > It seems to be impossible to achieve that. It is not needed. -- With best regards, Andrey Repin Friday, May 24, 2019 10:24:07 Sorry for my terrible english... ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
It means that the container has, or it must have all the power and rights. It seems to be impossible to achieve that. On Thu, May 23, 2019 at 6:35 PM Andrey Repin wrote: > Greetings, Saint Michael! > > > In my model, the host is unimportant, the container has the app, and I > have > > only one container per host. That way I can migrate the apps from server > to > > server in a few minutes. > > And? > > > -- > With best regards, > Andrey Repin > Friday, May 24, 2019 1:26:43 > > Sorry for my terrible english... > > ___ > 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] not allowed to change kernel parameters inside container
Greetings, Saint Michael! > In my model, the host is unimportant, the container has the app, and I have > only one container per host. That way I can migrate the apps from server to > server in a few minutes. And? -- With best regards, Andrey Repin Friday, May 24, 2019 1:26:43 Sorry for my terrible english... ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] not allowed to change kernel parameters inside container
In my model, the host is unimportant, the container has the app, and I have only one container per host. That way I can migrate the apps from server to server in a few minutes. On Wed, May 22, 2019 at 6:50 PM Andrey Repin wrote: > Greetings, Saint Michael! > > > I am trying to use sysctl -p inside an LXC container and it says > > read only file system > > Of course. > > > how do I give my container all possible rights? > > Don't do that. > > > -- > With best regards, > Andrey Repin > Thursday, May 23, 2019 1:48:51 > > Sorry for my terrible english... > ___ > 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] not allowed to change kernel parameters inside container
Greetings, Saint Michael! > I am trying to use sysctl -p inside an LXC container and it says > read only file system Of course. > how do I give my container all possible rights? Don't do that. -- With best regards, Andrey Repin Thursday, May 23, 2019 1:48:51 Sorry for my terrible english... ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] not allowed to change kernel parameters inside container
I am trying to use sysctl -p inside an LXC container and it says read only file system how do I give my container all possible rights? Right now I have lxc.mount.auto = cgroup:mixed lxc.tty.max = 10 lxc.pty.max = 1024 lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 4:1 rwm lxc.cgroup.devices.allow = c 1:9 rwm lxc.cgroup.devices.allow = c 1:8 rwm lxc.cgroup.devices.allow = c 136:* rwm lxc.cgroup.devices.allow = c 5:2 rwm lxc.cgroup.devices.allow = c 254:0 rwm lxc.cgroup.devices.allow = c 10:137 rwm # loop-control lxc.cgroup.devices.allow = b 7:* rwm# loop* lxc.cgroup.devices.allow = c 10:229 rwm #fuse lxc.cgroup.devices.allow = c 10:200 rwm #docker #lxc.cgroup.memory.limit_in_bytes = 92536870910 lxc.apparmor.profile= unconfined lxc.cgroup.devices.allow= a lxc.cap.drop= lxc.cgroup.devices.deny= #lxc.mount.auto= proc:rw sys:ro cgroup:ro lxc.autodev= 1 ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
