systemd-resolved in a container

[Nikos Mavrogiannopoulos]

Hi,
 I realized my fedora-based containers have an /etc/resolv.conf which
claims it is managed by resolved, and nsswitch.conf has "resolve" in
hosts. However, doing something like
# systemd-resolve  --status

results to:
sd_bus_open_system: No such file or directory

Trying to start dbus claims that systemd is not the init:
# systemctl start dbus
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down


Is there a way to use systemd resolved in a container?

regards,
Nikos

[Alexander Bokovoy]

On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote:
> Hi,
>  I realized my fedora-based containers have an /etc/resolv.conf which
> claims it is managed by resolved, and nsswitch.conf has "resolve" in
> hosts. However, doing something like
> # systemd-resolve  --status
>
> results to:
> sd_bus_open_system: No such file or directory
>
> Trying to start dbus claims that systemd is not the init:
> # systemctl start dbus
> System has not been booted with systemd as init system (PID 1). Can't operate.
> Failed to connect to bus: Host is down
>
>
> Is there a way to use systemd resolved in a container? 
I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
replaced by dbus-broker which is not active by default.

So you need

  systemctl enable --now dbus-broker

Without it even hostnamectl doesn't work, not just systemd-resolve.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Paul Wouters]

On Wed, 18 Nov 2020, Alexander Bokovoy wrote:

> > Is there a way to use systemd resolved in a container?
>
>  I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
>  replaced by dbus-broker which is not active by default.
>
>  So you need
>
>  systemctl enable --now dbus-broker
>
>  Without it even hostnamectl doesn't work, not just systemd-resolve. 
What is the advantage of running systemd-resolved in a container?

Is that container doing mDNS or LLMNR or a split-dns VPN ?

The whole point of containers is isolation and minimal setups. Pulling
in Base OS components into each container seems a waste of resources?

Paul

[Nikos Mavrogiannopoulos]

On Wed, Nov 18, 2020 at 6:37 PM Paul Wouters <paul(a)nohats.ca&gt; wrote:
>  On Wed, 18 Nov 2020, Alexander Bokovoy wrote:
>
>  >> Is there a way to use systemd resolved in a container?
>  >
>  > I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
>  > replaced by dbus-broker which is not active by default.
>  >
>  > So you need
>  >
>  > systemctl enable --now dbus-broker
>  >
>  > Without it even hostnamectl doesn't work, not just systemd-resolve.
>
>  What is the advantage of running systemd-resolved in a container? 
I do not know, but as I said the fedora container is set up with it
already there. What I am actually trying to do is to test the resolved
support in an application via the gitlab CI.

regards,
Nikos

[Alexander Bokovoy]

On ke, 18 marras 2020, Paul Wouters wrote:
> On Wed, 18 Nov 2020, Alexander Bokovoy wrote:
>
> >>Is there a way to use systemd resolved in a container?
> >
> >I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
> >replaced by dbus-broker which is not active by default.
> >
> >So you need
> >
> >systemctl enable --now dbus-broker
> >
> >Without it even hostnamectl doesn't work, not just systemd-resolve.
>
> What is the advantage of running systemd-resolved in a container?
>
> Is that container doing mDNS or LLMNR or a split-dns VPN ?
>
> The whole point of containers is isolation and minimal setups. Pulling
> in Base OS components into each container seems a waste of resources? 
It is part of systemd packaging and gets pulled in with that if you need
systemd -- like we need for FreeIPA CIs or FreeIPA container
deployments.

# rpm -qf /usr/lib/systemd/systemd-resolved
systemd-246.6-3.fc34.x86_64


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Nikos Mavrogiannopoulos]

On Wed, Nov 18, 2020 at 2:23 PM Alexander Bokovoy <abokovoy(a)redhat.com&gt; wrote:
>  On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote:
>  >Hi,
>  > I realized my fedora-based containers have an /etc/resolv.conf which
>  >claims it is managed by resolved, and nsswitch.conf has "resolve" in
>  >hosts. However, doing something like
>  ># systemd-resolve  --status
>  >
>  >results to:
>  >sd_bus_open_system: No such file or directory
>  >
>  >Trying to start dbus claims that systemd is not the init:
>  ># systemctl start dbus
>  >System has not been booted with systemd as init system (PID 1). Can't operate.
>  >Failed to connect to bus: Host is down
>  >
>  >
>  >Is there a way to use systemd resolved in a container?
>
>  I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
>  replaced by dbus-broker which is not active by default.
>
>  So you need
>
>    systemctl enable --now dbus-broker
>
>  Without it even hostnamectl doesn't work, not just systemd-resolve. 
Is that on the "default" fedora container, or do you use something
else? On fedora33 I get the same message about dbus and systemd not
being pid 1.

regards,
Nikos

[Daniel Walsh]

On 11/19/20 03:06, Nikos Mavrogiannopoulos wrote:
>  On Wed, Nov 18, 2020 at 2:23 PM Alexander Bokovoy
> <abokovoy(a)redhat.com&gt; wrote:
> > On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote:
> >> Hi,
> >> I realized my fedora-based containers have an /etc/resolv.conf which
> >> claims it is managed by resolved, and nsswitch.conf has "resolve" in
> >> hosts. However, doing something like
> >> # systemd-resolve  --status
> >>
> >> results to:
> >> sd_bus_open_system: No such file or directory
> >>
> >> Trying to start dbus claims that systemd is not the init:
> >> # systemctl start dbus
> >> System has not been booted with systemd as init system (PID 1). Can't
> operate.
> >> Failed to connect to bus: Host is down
> >>
> >>
> >> Is there a way to use systemd resolved in a container?
> > I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
> > replaced by dbus-broker which is not active by default.
> >
> > So you need
> >
> >    systemctl enable --now dbus-broker
> >
> > Without it even hostnamectl doesn't work, not just systemd-resolve.
>  Is that on the "default" fedora container, or do you use something
>  else? On fedora33 I get the same message about dbus and systemd not
>  being pid 1. 
fedora-init container runs with systemd, fedora container does NOT.
>  regards,
>  Nikos
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Alexander Bokovoy]

On to, 19 marras 2020, Nikos Mavrogiannopoulos wrote:
> On Wed, Nov 18, 2020 at 2:23 PM Alexander Bokovoy
> <abokovoy(a)redhat.com&gt; wrote:
> >
> > On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote:
> > >Hi,
> > > I realized my fedora-based containers have an /etc/resolv.conf which
> > >claims it is managed by resolved, and nsswitch.conf has "resolve" in
> > >hosts. However, doing something like
> > ># systemd-resolve  --status
> > >
> > >results to:
> > >sd_bus_open_system: No such file or directory
> > >
> > >Trying to start dbus claims that systemd is not the init:
> > ># systemctl start dbus
> > >System has not been booted with systemd as init system (PID 1). Can't
> operate.
> > >Failed to connect to bus: Host is down
> > >
> > >
> > >Is there a way to use systemd resolved in a container?
> >
> > I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
> > replaced by dbus-broker which is not active by default.
> >
> > So you need
> >
> >   systemctl enable --now dbus-broker
> >
> > Without it even hostnamectl doesn't work, not just systemd-resolve.
>
> Is that on the "default" fedora container, or do you use something
> else? On fedora33 I get the same message about dbus and systemd not
> being pid 1. 
We build our own Fedora container with systemd based on the 'default' one.
I haven't tried 'fedora-init' variant as Dan suggested.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Daniel Walsh]

On 11/19/20 03:06, Nikos Mavrogiannopoulos wrote:
>  On Wed, Nov 18, 2020 at 2:23 PM Alexander Bokovoy
> <abokovoy(a)redhat.com&gt; wrote:
> > On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote:
> >> Hi,
> >> I realized my fedora-based containers have an /etc/resolv.conf which
> >> claims it is managed by resolved, and nsswitch.conf has "resolve" in
> >> hosts. However, doing something like
> >> # systemd-resolve  --status
> >>
> >> results to:
> >> sd_bus_open_system: No such file or directory
> >>
> >> Trying to start dbus claims that systemd is not the init:
> >> # systemctl start dbus
> >> System has not been booted with systemd as init system (PID 1). Can't
> operate.
> >> Failed to connect to bus: Host is down
> >>
> >>
> >> Is there a way to use systemd resolved in a container?
> > I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
> > replaced by dbus-broker which is not active by default.
> >
> > So you need
> >
> >    systemctl enable --now dbus-broker
> >
> > Without it even hostnamectl doesn't work, not just systemd-resolve.
>  Is that on the "default" fedora container, or do you use something
>  else? On fedora33 I get the same message about dbus and systemd not
>  being pid 1.
>
>  regards,
>  Nikos
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 
I was mistaken, there is no fedora-init image. There is a ubi8-init image.