[zeromq-dev] [RFC] systemd socket activation for libzmq

[Michal Vyskocil]

Hi,

if you want to hide the socket from global namespace, there are at
least two options (before using containers) on Linux

Call unshare (2) and CLONE_NEWIPC/CLONE_NEWNET to create your private
network namespace in a broker, so the ipc or tcp sockets won't be
globally visible. You must exec the child plugins from the main
process.
http://man7.org/linux/man-pages/man2/unshare.2.html

Alternatively you can use systemd's features
PrivateNetwork/JoinsNamespaceOf to perform the same. But then broker
and plugins must be managed using systemd
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateNetwork=

I am not aware about anything portable to other platforms.

On Tue, May 31, 2016 at 8:06 PM, Jim Garlick <garlick at llnl.gov> wrote:
> On Tue, May 31, 2016 at 05:47:24PM +0100, Luca Boccassi wrote:
>> On Tue, 2016-05-31 at 08:52 -0700, Jim Garlick wrote:
>> > On Mon, May 30, 2016 at 09:57:00PM +0200, Michal Vyskocil wrote:
>> > > Hi,
>> > >
>> > > Awesome, the fact czmq handles that is good enough for me. Closed the
>> > > request.
>> > > On Mon, 2016-05-30 at 21:14 +0200, Michal Vyskocil wrote:
>> > > > Hi,
>> > > >
>> > > > Ale's thread about Setting privileges on a UNIX socket inspired me to
>> > > > create small patch to libzmq adding automatic systemd socket
>> > > > activation support.
>> > > > https://github.com/zeromq/libzmq/pull/2015
>> > > >
>> > > > Right now the feature is fairly minimal - limited to ipc transport -
>> > > > and tested manually using malamute broker. I would like to hear any
>> > > > feedback. If you consider it as useful (or want to avoid dependency on
>> > > > the most hated OSS software on the planet ;-)), please say so.
>> > >
>> > > Hi,
>> > >
>> > > That functionality is already implemented for both IPC and TCP sockets.
>> > >
>> > > The low level library has the ZMQ_USE_FD socket option to pass a file
>> > > descriptor, and the high level CZMQ has ZSYS_AUTO_USE_FD env var or
>> > > zsys_set_auto_use_fd(1) function to let zmq automatically match
>> > > endpoints to the corresponding sockets managed by systemd. As long as
>> > > the metadata matches (eg: file path for IPC, address + port for TCP), it
>> > > will just work out of the box.
>> > >
>> > > Kind regards,
>> > > Luca Boccassi
>> >
>> > Somehow I missed that - sounds useful!
>> >
>> > Is the usual reconnect behavior disabled when this option is present,
>> > or is that what the aforementioned metadata is used for?  I couldn't
>> > find the answer in
>> >   http://api.zeromq.org/4-2:zmq-setsockopt
>> >
>> > or in the note about reconnect exceptions in
>> >   http://api.zeromq.org/4-2:zmq-connect
>> >
>> > Thanks,
>> >
>> > Jim Garlick
>>
>> Hi,
>>
>> This is used only for server-ish sockets - ie, all those that do any
>> sort of bind and you would use with zmq_bind, so it does not affect
>> zmq_connect (or re-connect).
>>
>> I thought about adding it for the connect side too, but IMHO it wouldn't
>> make much sense. The purpose of systemd-managed sockets is to let
>> servers be started only when a client attempts to connect, and to
>> disentangle dependencies between services and allow them to start in
>> parallel at boot, while having systemd manage the FD buffer so that no
>> messages are lost in either scenario.
>> Neither of these would apply for client-ish sockets.
>>
>> But we can of course look into it, do you have a use case where it would
>> be useful to have?
>>
>> Kind regards,
>> Luca Boccassi
>
> Ah, thanks for the clarification.
>
> Well, there are probably other ways to accomplish my use case.
> We have a broker that loads "plugins" as threads communicating with
> the broker over a per-plugin ZMQ_PAIR inproc:// socket.
> We'd like to be able to launch plugins as processes with fork/exec.
> What I had in mind when I heard about ZMQ_USE_FD was something like
> ZMQ_PAIR over file descriptors obtained with socketpair(), one end
> passed to plugin, one end retained by broker.
>
> Having an endpoint that doesn't appear in any namespace simplifies
> life a bit compared to ipc:// or tcp:// - it wouldn't need to be
> protected against unauthorized access for example.
>
> Jim
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



-- 
best regards
     Michal Vyskocil