[Lxc-users] mknod inside systemd container

[John]

On 03/04/13 23:15, Michael H. Warfield wrote:
> On Wed, 2013-04-03 at 23:03 +0100, John wrote:
>> On 02/04/13 23:59, Michael H. Warfield wrote:
>>> On Tue, 2013-04-02 at 16:02 +0100, John wrote:
>>>> If my understanding is correctl, to stop systemd trying to launch udev
>>>> and generally make a mess of everything inside a container, you need to
>>>> remove the mknod capability from the container.
>>> Ah...  That's kind of old information and not really effective.
>>>
>>>> But what if I want
>>>> (need) to be able to use mknod inside a container, how can I do that
>>>> with a systemd container?
>>> 1) Get the latest lxc.  lxc 0.8 might suffice for systemd in a container
>>> but not with systemd in the host and I wouldn't recommend it.  0.9.0 is
>>> being pulled and bundled now.  It's not up yet but 0.9.0.rc1 is.
>>>
>>> 2) You'll have to add "lxc.autodev = 1" to your configuration file.
>> I already do that. I am running "lxc version: 0.9.0.alpha3"
> That's strange.  What stops systemd from mounting devtmpfs and firing up
> udev is having a tmpfs mounted on /dev.  That's part of what autodev = 1
> is doing.
I'm taking my understanding from here:
http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface
where it says "The udev unit files will check for CAP_SYS_MKNOD, and 
skip udev if that is not available."

But it sounds like you're saying that "lxc.autodev = 1" should prevent 
systemd from firing the udev systemd unit anyway.

>
> What distro is running in the container and what version of systemd?
> I've seen this with Fedora 16 but the latest systemd and Fedora 17 in
> the container are fine.
>
I am running Arch Linux on both host and container:
Linux 3.7.10-1-ARCH #1 SMP PREEMPT Thu Feb 28 09:50:17 CET 2013 x86_64 
GNU/Linux

On my host, "systemctl --version" reports:
systemd 197
+PAM -LIBWRAP -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ

And on the container, it's systemd 196

I've just checked and the latest version in the Arch repo is 198. I 
wonder if I should try and update to that?


>> I found that, without the removal of mknod capability, everything went
>> crazy. I have working containers with systemd both on host and inside
>> the container (I even run my full desktop inside a container). To get a
>> systemd container working I found I needed three things:
>> lxc.autodev = 1
>> lxc.cap.drop = mknod
> I'm not having to do that but I'm avoiding F15 and F16 because they
> don't seem to play nice and start reliably.  F17 is doing well for me.
>
>> lxc.pts = 1024
>>
>> It's alll working well except for the fact that I might need to allow a
>> container to have mknod capability. Are you saying that with 0.9.0 there
>> are changes that negate the requirement for "lxc.cap.drop = mknod"? The
>> way I understood it was that it was systemd that behaved differently
>> based on the availability of that capability...
>>
>>
>>> I have found that this works to get recent systemd containers (Fedora
>>> 17) to work but Fedora 15 and Fedora 16 (neither of which are supported
>>> any longer) work due to udev / systemd interaction.
>>>
>>> I would recommend waiting a couple of days until 0.9.0 is up and then
>>> pulling it down and building it.  That's your best shot with systemd.
>>>
>>>> I have this container that is a builder of system images for other nodes
>>>> (containers and/or metal boxes). In order to correctly do this it needs
>>>> to execute mknod inside the image as it builds it. (note, device nodes
>>>> created doesn't need to be usable in the context of the image being
>>>> built - the builder just needs to be able to create it).
>>>>
>>>> I've been doing this for ages under sysvinit and it's been fine. I have
>>>> just migrated this builder container to systemd and hit this problem...
>>>> Is there another way to keep systemd in line other than removing the
>>>> mknod capability ?
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Own the Future-Intel(R) Level Up Game Demo Contest 2013
>>>> Rise to greatness in Intel's independent game demo contest. Compete
>>>> for recognition, cash, and the chance to get your game on Steam.
>>>> $5K grand prize plus 10 genre and skill prizes. Submit your demo
>>>> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
>>>> _______________________________________________
>>>> Lxc-users mailing list
>>>> Lxc-users at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/lxc-users
>>>>
>>
>> ------------------------------------------------------------------------------
>> Minimize network downtime and maximize team effectiveness.
>> Reduce network management and security costs.Learn how to hire
>> the most talented Cisco Certified professionals. Visit the
>> Employer Resources Portal
>> http://www.cisco.com/web/learning/employer_resources/index.html
>> _______________________________________________
>> Lxc-users mailing list
>> Lxc-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/lxc-users
>>