Re: [systemd-devel] systemd-nspawn: starting multiple shells
On Mo, 02.07.18 17:25, Nikolaus Rath (nikol...@rath.org) wrote: > On Jul 02 2018, Lennart Poettering wrote: > >> Still not quite working, now there seems to be a problem with > >> /proc/self/fd in the new shell: > >> > >> $ sudo systemd-nspawn -M $MACHINE \ > >> --private-users=1379532800:65536 --private-network \ > >> --as-pid2 > [...] > >> > >> What's happening here? > > > > the stdin/stdout/stderr fds of the nsenter process reference pipes > > that belong to the host side, and the kernel doesn't allow them to be > > reopened if user namespacing is used, for security reasons. > > > > "systemd-run -M $MACHINE -t /bin/sh" should generally be the better > > choice than "nsenter", > > Yeah, but: > > $ sudo systemd-run -M iofabric -t /bin/sh > [sudo] password for nikratio: > Failed to create bus connection: No such file or directory > > Does this maybe require a systemd instance running in the container? Yes, "systemd-run" talks to a systemd instance to create a service on-the-fly. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: starting multiple shells
On Jul 02 2018, Lennart Poettering wrote: >> Still not quite working, now there seems to be a problem with >> /proc/self/fd in the new shell: >> >> $ sudo systemd-nspawn -M $MACHINE \ >> --private-users=1379532800:65536 --private-network \ >> --as-pid2 [...] >> >> What's happening here? > > the stdin/stdout/stderr fds of the nsenter process reference pipes > that belong to the host side, and the kernel doesn't allow them to be > reopened if user namespacing is used, for security reasons. > > "systemd-run -M $MACHINE -t /bin/sh" should generally be the better > choice than "nsenter", Yeah, but: $ sudo systemd-run -M iofabric -t /bin/sh [sudo] password for nikratio: Failed to create bus connection: No such file or directory Does this maybe require a systemd instance running in the container? My problem was that I can't run "machinectl shell" because the systemd version in the container is too old.. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: starting multiple shells
On Fr, 29.06.18 21:24, Nikolaus Rath (nikol...@rath.org) wrote:
> >> The 'nsenter' approach seems to work so far, but I don't see a generally
> >> applicable way to figure out the right PID. Is there a trick for
> >> that?
> >
> > machinectl show --value $MACHINE -p Leader
>
> Still not quite working, now there seems to be a problem with
> /proc/self/fd in the new shell:
>
> $ sudo systemd-nspawn -M $MACHINE \
> --private-users=1379532800:65536 --private-network \
> --as-pid2
>
> # Other terminal
>
> $ pid=$(machinectl show --value $MACHINE -p Leader 2> /dev/null)
> $ sudo nsenter -t ${pid} --mount --uts --ipc --net --pid --cgroup --user
> [root@iofabric /]# echo $UID
> 0
> [root@iofabric /]# echo 1 > /dev/stderr
> -bash: /dev/stderr: Permission denied
> [root@iofabric /]# ll /dev/stderr
> lrwxrwxrwx 1 root root 15 Jun 29 21:13 /dev/stderr -> /proc/self/fd/2
> [root@iofabric /]# ll /proc/self/fd/2
> lrwx-- 1 root root 64 Jun 29 21:22 /proc/self/fd/2 -> /dev/pts/0
> [root@iofabric /]# ll /dev/pts/
> total 0
> crw-rw-rw- 1 root root 5, 2 Jun 29 21:13 ptmx
> [root@iofabric /]#
>
>
> What's happening here?
the stdin/stdout/stderr fds of the nsenter process reference pipes
that belong to the host side, and the kernel doesn't allow them to be
reopened if user namespacing is used, for security reasons.
"systemd-run -M $MACHINE -t /bin/sh" should generally be the better
choice than "nsenter", as it will instantiate a shell originating
inside the container and will allocate a pty for it that it will proxy
to the caller's TTYs. This means you get much safer and correct
behaviour as the container will only run container code and the host
only host code, and the connection between them is limited to the pty
transport between them. Since the pty is allocated in the container
/dev/stderr and friends should work fine.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: starting multiple shells
On Jun 25 2018, Lennart Poettering wrote:
> On Sa, 23.06.18 21:57, Nikolaus Rath (nikol...@rath.org) wrote:
>
>> On Jun 23 2018, Nikolaus Rath wrote:
>> > On Jun 23 2018, aleivag wrote:
>> >> short answer, yes, `machinectl login` is only suppported for systemd-init
>> >> ,
>> >> and `machinectl shell` `systemd-run` will try to talk to the container via
>> >> dbus, so i dont think you are force to have systemd runing inside the
>> >> container (i may be wrong) but you do need to have dbus (and its easy to
>> >> just have systemd). if you dont need it, you can always use nsenter to
>> >> access a namespace on your machine
>> >
>> > Still not working:
>> [..]
>> > $ sudo machinectl shell root@iofabric
>> > [sudo] password for nikratio:
>> > Failed to get shell PTY: Cannot set property
>> > StandardInputFileDescriptor, or unknown property.
>>
>> So this seems to be caused by systemd in the container being too old,
>> and is therefore not available here.
>>
>> The 'nsenter' approach seems to work so far, but I don't see a generally
>> applicable way to figure out the right PID. Is there a trick for
>> that?
>
> machinectl show --value $MACHINE -p Leader
Still not quite working, now there seems to be a problem with
/proc/self/fd in the new shell:
$ sudo systemd-nspawn -M $MACHINE \
--private-users=1379532800:65536 --private-network \
--as-pid2
# Other terminal
$ pid=$(machinectl show --value $MACHINE -p Leader 2> /dev/null)
$ sudo nsenter -t ${pid} --mount --uts --ipc --net --pid --cgroup --user
[root@iofabric /]# echo $UID
0
[root@iofabric /]# echo 1 > /dev/stderr
-bash: /dev/stderr: Permission denied
[root@iofabric /]# ll /dev/stderr
lrwxrwxrwx 1 root root 15 Jun 29 21:13 /dev/stderr -> /proc/self/fd/2
[root@iofabric /]# ll /proc/self/fd/2
lrwx-- 1 root root 64 Jun 29 21:22 /proc/self/fd/2 -> /dev/pts/0
[root@iofabric /]# ll /dev/pts/
total 0
crw-rw-rw- 1 root root 5, 2 Jun 29 21:13 ptmx
[root@iofabric /]#
What's happening here?
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: starting multiple shells
On Sa, 23.06.18 21:57, Nikolaus Rath (nikol...@rath.org) wrote: > On Jun 23 2018, Nikolaus Rath wrote: > > On Jun 23 2018, aleivag wrote: > >> short answer, yes, `machinectl login` is only suppported for systemd-init , > >> and `machinectl shell` `systemd-run` will try to talk to the container via > >> dbus, so i dont think you are force to have systemd runing inside the > >> container (i may be wrong) but you do need to have dbus (and its easy to > >> just have systemd). if you dont need it, you can always use nsenter to > >> access a namespace on your machine > > > > Still not working: > [..] > > $ sudo machinectl shell root@iofabric > > [sudo] password for nikratio: > > Failed to get shell PTY: Cannot set property > > StandardInputFileDescriptor, or unknown property. > > So this seems to be caused by systemd in the container being too old, > and is therefore not available here. > > The 'nsenter' approach seems to work so far, but I don't see a generally > applicable way to figure out the right PID. Is there a trick for > that? machinectl show --value $MACHINE -p Leader Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: starting multiple shells
hi: so for finding the pid the solution its (big surprise :D ) using systemd, instead of just executing you systemd-nspawn in bash you start it as a systemd-unit (you can even do this as ephemeral unit with `sytemd-run --unit myspawn.service systemd-nspawn bla...`) then to get the ip of the nspawn process no need to ps aux you just do `systemctl show -pMainPID myspawn.service`, that will give you the mainpid, and your child you can get it with `pgrep -P`. as personal oprinion... i much like `tail -f /dev/null` better than `sleep ` as a wait to "wait for ever" Alvaro Leiva On Sat, Jun 23, 2018 at 2:02 PM Nikolaus Rath wrote: > On Jun 23 2018, Nikolaus Rath wrote: > > On Jun 23 2018, aleivag wrote: > >> short answer, yes, `machinectl login` is only suppported for > systemd-init , > >> and `machinectl shell` `systemd-run` will try to talk to the container > via > >> dbus, so i dont think you are force to have systemd runing inside the > >> container (i may be wrong) but you do need to have dbus (and its easy to > >> just have systemd). if you dont need it, you can always use nsenter to > >> access a namespace on your machine > > > > Still not working: > [..] > > $ sudo machinectl shell root@iofabric > > [sudo] password for nikratio: > > Failed to get shell PTY: Cannot set property > > StandardInputFileDescriptor, or unknown property. > > So this seems to be caused by systemd in the container being too old, > and is therefore not available here. > > The 'nsenter' approach seems to work so far, but I don't see a generally > applicable way to figure out the right PID. Is there a trick for that? > > (I ran a "sleep " in the container and grepped "ps > ax" for the number in the host). > > Best, > -Nikolaus > > -- > GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > »Time flies like an arrow, fruit flies like a Banana.« > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: starting multiple shells
On Jun 23 2018, Nikolaus Rath wrote: > On Jun 23 2018, aleivag wrote: >> short answer, yes, `machinectl login` is only suppported for systemd-init , >> and `machinectl shell` `systemd-run` will try to talk to the container via >> dbus, so i dont think you are force to have systemd runing inside the >> container (i may be wrong) but you do need to have dbus (and its easy to >> just have systemd). if you dont need it, you can always use nsenter to >> access a namespace on your machine > > Still not working: [..] > $ sudo machinectl shell root@iofabric > [sudo] password for nikratio: > Failed to get shell PTY: Cannot set property > StandardInputFileDescriptor, or unknown property. So this seems to be caused by systemd in the container being too old, and is therefore not available here. The 'nsenter' approach seems to work so far, but I don't see a generally applicable way to figure out the right PID. Is there a trick for that? (I ran a "sleep " in the container and grepped "ps ax" for the number in the host). Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: starting multiple shells
On Jun 23 2018, aleivag wrote: > short answer, yes, `machinectl login` is only suppported for systemd-init , > and `machinectl shell` `systemd-run` will try to talk to the container via > dbus, so i dont think you are force to have systemd runing inside the > container (i may be wrong) but you do need to have dbus (and its easy to > just have systemd). if you dont need it, you can always use nsenter to > access a namespace on your machine Still not working: $ sudo systemd-nspawn -M $MACHINE --private-users=1379532800:65536 --private-network -network-macvlan=eth0 --boot # Other console $ sudo machinectl list MACHINE CLASS SERVICEOS VERSION ADDRESSES iofabric container systemd-nspawn centos 7 192.168.0.26... 1 machines listed. $ sudo machinectl shell root@iofabric [sudo] password for nikratio: Failed to get shell PTY: Cannot set property StandardInputFileDescriptor, or unknown property. $ machinectl --version systemd 232 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN Any idea? Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: starting multiple shells
short answer, yes, `machinectl login` is only suppported for systemd-init , and `machinectl shell` `systemd-run` will try to talk to the container via dbus, so i dont think you are force to have systemd runing inside the container (i may be wrong) but you do need to have dbus (and its easy to just have systemd). if you dont need it, you can always use nsenter to access a namespace on your machine ``` nsenter -t --all /bin/bash ``` where is the process that is runing on your container Alvaro Leiva Alvaro Leiva On Sat, Jun 23, 2018 at 7:38 AM Nikolaus Rath wrote: > Hi, > > On Sat, 23 Jun 2018, at 15:31, Vito Caputo wrote: > > On Sat, Jun 23, 2018 at 03:09:04PM +0100, Nikolaus Rath wrote: > > > How would I go about starting an additional shell in an existing > > > container? I am starting the container with: > > > > > > $ systemd-nspawn -M foo --as-pid2 --register=no > > > > > > "foo" is a raw image retrieved with machinectl. If I simply execute the > > > above command again, I am getting a "Disk image > > > /var/lib/machines/foo.raw is currently busy." error. > > > > > > I've looked into the systemd-nspawn manpage, but couldn't find anything > > > appropriate. > > > > > > What am I missing? > > > > > Take a look at the machinectl man page, the "shell" and "login" > > subcommands in particular. > > `man systemd-nspawn` says that when not running an init system in the > container, > I should specify `--register=no`. But without that, `machinectl` doesn't do > anything. Does this mean I need to run an init system to support multiple > shells? > > Best, > -Nikolaus > > -- > GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > »Time flies like an arrow, fruit flies like a Banana.« > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: starting multiple shells
Hi, On Sat, 23 Jun 2018, at 15:31, Vito Caputo wrote: > On Sat, Jun 23, 2018 at 03:09:04PM +0100, Nikolaus Rath wrote: > > How would I go about starting an additional shell in an existing > > container? I am starting the container with: > > > > $ systemd-nspawn -M foo --as-pid2 --register=no > > > > "foo" is a raw image retrieved with machinectl. If I simply execute the > > above command again, I am getting a "Disk image > > /var/lib/machines/foo.raw is currently busy." error. > > > > I've looked into the systemd-nspawn manpage, but couldn't find anything > > appropriate. > > > > What am I missing? > > > Take a look at the machinectl man page, the "shell" and "login" > subcommands in particular. `man systemd-nspawn` says that when not running an init system in the container, I should specify `--register=no`. But without that, `machinectl` doesn't do anything. Does this mean I need to run an init system to support multiple shells? Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: starting multiple shells
On Sat, Jun 23, 2018 at 03:09:04PM +0100, Nikolaus Rath wrote: > Hello, > > How would I go about starting an additional shell in an existing > container? I am starting the container with: > > $ systemd-nspawn -M foo --as-pid2 --register=no > > "foo" is a raw image retrieved with machinectl. If I simply execute the > above command again, I am getting a "Disk image > /var/lib/machines/foo.raw is currently busy." error. > > I've looked into the systemd-nspawn manpage, but couldn't find anything > appropriate. > > What am I missing? > Take a look at the machinectl man page, the "shell" and "login" subcommands in particular. Regards, Vito Caputo ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: starting multiple shells
Hi: to get a shell on your running container , you need to get it's name (execute `machinectl` to get a list of containers) and then if you just want a shell you can run `systemd-run --machine= --pty /bin/bash` or `machinectl shell /bin/bash` and if you want a real login promp machinectl login is your best bet hope it helps Alvaro Leiva Geisse On Sat, Jun 23, 2018 at 7:13 AM Nikolaus Rath wrote: > Hello, > > How would I go about starting an additional shell in an existing > container? I am starting the container with: > > $ systemd-nspawn -M foo --as-pid2 --register=no > > "foo" is a raw image retrieved with machinectl. If I simply execute the > above command again, I am getting a "Disk image > /var/lib/machines/foo.raw is currently busy." error. > > I've looked into the systemd-nspawn manpage, but couldn't find anything > appropriate. > > What am I missing? > > > Thanks! > -Nikolaus > > -- > GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > »Time flies like an arrow, fruit flies like a Banana.« > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
