Re: [systemd-devel] [Question]: About systemctl and its related commands

2017-11-28 Thread 千葉幹正
Thank you.

I know have a deeper understanding of the this topic :)

Regards.
Chiba

2017年11月28日(火) 23:32 Lennart Poettering :

> f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 (chib...@klab.com) wrote:
>
> > We have a few questions about systemctl and -H option.
> >
> > It looks like systemctl is communicating with /run/systemd/private in
> order
> > to interact with systemd.
> >
> > However, after you log in the connected computer via ssh, it looks like
> > it's trying to control systemd by going through systemd-stdio-bridge when
> > you use systemctl's -H option.
> >
> > Instead of going through /run/systemd/private, it looks like
> > systemd-stdio-bridge is going through /run/dbus/system_bus_socket (which
> is
> > usually created by dbus daemon) in order to control systemd.
> >
> > This where we run into the following 2 questions:
> >
> > 1. Is it necessary to start up dbus daemon on the computer we're
> connecting
> > to in order to control systemd by using the systemctl -H option?
>
> Currently, yes. And I doubt this will change anytime soon.
>
> D-Bus is designed around a bus concept: all services are available on
> the same IPC bus. That's usually a good thing, as that means systemctl
> can talk to all services it needs to through a single IPC
> connection. systemctl talks to a number of daemons actually, not just
> PID 1: for example, it also talks to logind and policykit.
>
> If the private IPC socket is used a very limited way of IPC is
> available only: since the other side is PID 1 and PID 1 only, there's
> no hookup with polkit, and communication with logind is not
> available. Moreover a couple of peer tracking concepts in PID 1 are
> disabled for such "direct" connections, as a peer concept is not
> really existing for such connections that do not involve a bus.
>
> systemctl currently contains some logic to use the private socket
> (i.e. a direct connection) automatically in a number of cases,
> preferring it over the bus. It does that so that systemctl can talk to
> systemd during early boot too (when dbus-daemon is not up yet, hence
> the proper bus is not available), as well as when the system is really
> hosed (so that you can still debug things and shut things down). The
> direct connections however are a very specific hack in systemctl
> ultimately, done under very specific conditions, in order to deal with
> a very specific set of problems. When PK or logind involvement is
> needed, when the caller is not privileged and so on, the direct
> connections are not used. Now, the ssh transport (i.e. -H) doesn't
> know about all this, and cannot possibly guess what systemctl actually
> wants to do, hence it is exclusively a gateway to the full bus, it
> contains no special hookup with the private socket. Moreover, ssh is
> a late boot service anyway, i.e. dbus is already up at that moment,
> hence the early-boot reason for the private socket doesn't even apply
> to remote connections at all..
>
> > 2. Are we correct in our understanding that /run/systemd/private exists
> to
> > control systemctl though the local systemd?
>
> the private socket is an implementation detail between systemctl and
> systemd, to support the aforementioned usecases. It's not a public
> API (which is the reason btw, why it is called 'private'…), it's not
> fully featured, and it should not be used except under very well
> defined conditions, and remote access does not fall under that.
>
> > Why does systemctl use the specialized interface called
> > /run/systemd/private to control systemd?
> > Why doesn't systemd-stdio-bridge control systemd via /run/systemd/private
> > like systemctl does?
>
> Besides the fact that systemctl talks to logind and so on, the stdio
> bridge is also used by the various other tools in systemd, including
> machinectl, loginctl, busctl, systemd-run, … Since they generally talk
> to other daemons than just PID 1 a full ybus connection is required.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
-- 
KLab株式会社 インフラマネジメント部
千葉 幹正 chib...@klab.com

 [東京本社]
  〒106-6122 東京都港区六本木6-10-1 六本木ヒルズ森タワー22F
  TEL:03-5771-1818  / FAX:03-3403-8520
 [地方・海外拠点]
仙台/大阪/福岡/シンガポール/上海
 [弊社HP]
  http://www.klab.com/jp/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [Question]: About systemctl and its related commands

2017-11-28 Thread Lennart Poettering
f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 (chib...@klab.com) wrote:

> We have a few questions about systemctl and -H option.
> 
> It looks like systemctl is communicating with /run/systemd/private in order
> to interact with systemd.
> 
> However, after you log in the connected computer via ssh, it looks like
> it's trying to control systemd by going through systemd-stdio-bridge when
> you use systemctl's -H option.
> 
> Instead of going through /run/systemd/private, it looks like
> systemd-stdio-bridge is going through /run/dbus/system_bus_socket (which is
> usually created by dbus daemon) in order to control systemd.
> 
> This where we run into the following 2 questions:
> 
> 1. Is it necessary to start up dbus daemon on the computer we're connecting
> to in order to control systemd by using the systemctl -H option?

Currently, yes. And I doubt this will change anytime soon.

D-Bus is designed around a bus concept: all services are available on
the same IPC bus. That's usually a good thing, as that means systemctl
can talk to all services it needs to through a single IPC
connection. systemctl talks to a number of daemons actually, not just
PID 1: for example, it also talks to logind and policykit.

If the private IPC socket is used a very limited way of IPC is
available only: since the other side is PID 1 and PID 1 only, there's
no hookup with polkit, and communication with logind is not
available. Moreover a couple of peer tracking concepts in PID 1 are
disabled for such "direct" connections, as a peer concept is not
really existing for such connections that do not involve a bus.

systemctl currently contains some logic to use the private socket
(i.e. a direct connection) automatically in a number of cases,
preferring it over the bus. It does that so that systemctl can talk to
systemd during early boot too (when dbus-daemon is not up yet, hence
the proper bus is not available), as well as when the system is really
hosed (so that you can still debug things and shut things down). The
direct connections however are a very specific hack in systemctl
ultimately, done under very specific conditions, in order to deal with
a very specific set of problems. When PK or logind involvement is
needed, when the caller is not privileged and so on, the direct
connections are not used. Now, the ssh transport (i.e. -H) doesn't
know about all this, and cannot possibly guess what systemctl actually
wants to do, hence it is exclusively a gateway to the full bus, it
contains no special hookup with the private socket. Moreover, ssh is
a late boot service anyway, i.e. dbus is already up at that moment,
hence the early-boot reason for the private socket doesn't even apply
to remote connections at all..

> 2. Are we correct in our understanding that /run/systemd/private exists to
> control systemctl though the local systemd?

the private socket is an implementation detail between systemctl and
systemd, to support the aforementioned usecases. It's not a public
API (which is the reason btw, why it is called 'private'…), it's not
fully featured, and it should not be used except under very well
defined conditions, and remote access does not fall under that.

> Why does systemctl use the specialized interface called
> /run/systemd/private to control systemd?
> Why doesn't systemd-stdio-bridge control systemd via /run/systemd/private
> like systemctl does?

Besides the fact that systemctl talks to logind and so on, the stdio
bridge is also used by the various other tools in systemd, including
machinectl, loginctl, busctl, systemd-run, … Since they generally talk
to other daemons than just PID 1 a full ybus connection is required.

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] [Question]: About systemctl and its related commands

2017-11-28 Thread aleivag
Hi, i asked similar question a few weeks ago, and you probably will get a
oficial answer soon :P, but in a nutshell would be:

/run/systemd/private is a private socket and its meant for systemd tools to
communicate with systemd even if dbus daemon is down. this is specially
true during boot and shutdown, but you should never try to use the private
sockets for anything, always use dbus sockets, because (in Lennard's words,
not mine) "systemd sucks as a bus replacement". if posible, even forget
that /run/systemd/private exists :P.

after playing around a lot with servers i agree with previous statements,
and always prefere dbus over private.

hope that helps.


Alvaro

On Mon, Nov 27, 2017 at 11:16 PM, 千葉幹正  wrote:

> We have a few questions about systemctl and -H option.
>
> It looks like systemctl is communicating with /run/systemd/private in
> order to interact with systemd.
>
> However, after you log in the connected computer via ssh, it looks like
> it's trying to control systemd by going through systemd-stdio-bridge when
> you use systemctl's -H option.
>
> Instead of going through /run/systemd/private, it looks like
> systemd-stdio-bridge is going through /run/dbus/system_bus_socket (which is
> usually created by dbus daemon) in order to control systemd.
>
> This where we run into the following 2 questions:
>
> 1. Is it necessary to start up dbus daemon on the computer we're
> connecting to in order to control systemd by using the systemctl -H option?
>
> 2. Are we correct in our understanding that /run/systemd/private exists to
> control systemctl though the local systemd?
>
> Why does systemctl use the specialized interface called
> /run/systemd/private to control systemd?
> Why doesn't systemd-stdio-bridge control systemd via /run/systemd/private
> like systemctl does?
>
> Any information you can provide about the above would be much appreciated!
> Thanks in advance for your time and all your help.
>
> All the best,
>
> Chiba
> KLab Inc.
>
> ___
> 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


[systemd-devel] [Question]: About systemctl and its related commands

2017-11-27 Thread 千葉幹正
We have a few questions about systemctl and -H option.

It looks like systemctl is communicating with /run/systemd/private in order
to interact with systemd.

However, after you log in the connected computer via ssh, it looks like
it's trying to control systemd by going through systemd-stdio-bridge when
you use systemctl's -H option.

Instead of going through /run/systemd/private, it looks like
systemd-stdio-bridge is going through /run/dbus/system_bus_socket (which is
usually created by dbus daemon) in order to control systemd.

This where we run into the following 2 questions:

1. Is it necessary to start up dbus daemon on the computer we're connecting
to in order to control systemd by using the systemctl -H option?

2. Are we correct in our understanding that /run/systemd/private exists to
control systemctl though the local systemd?

Why does systemctl use the specialized interface called
/run/systemd/private to control systemd?
Why doesn't systemd-stdio-bridge control systemd via /run/systemd/private
like systemctl does?

Any information you can provide about the above would be much appreciated!
Thanks in advance for your time and all your help.

All the best,

Chiba
KLab Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel