[systemd-devel] [systemd-commits] man/systemd-socket-proxyd.xml src/socket-proxy TODO

[David Timothy Strauss]

On Wed, Nov 27, 2013 at 12:03 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> Could you please explain what the usecase here is? Why is this better
> than having two socket units with two proxy services?

Right now, it's because separate services cannot exist in the same
network namespace with another service. The main motivation for this
change was a desire within CoreOS to run etcd within a
network-namespaced service. With the need to only map one port in,
that would be equivalent to the network namespaced nginx example. But,
they need to map *two* ports in and to distinct destination ports
within the namespace. That was actually impossible before, where
socket-proxyd would map all inherited sockets to the same destination.

This change allows forcing a single socket-proxyd to inherit only one
socket each.

>> +/usr/bin/systemd-socket-proxyd --listener=3 localhost:8080 &
>> +/usr/bin/systemd-socket-proxyd --listener=4 localhost:8443 &
>> +wait]]>
>
> If our examples suggest that people should write shell scripts that fork
> things, then this is usually an indication that we need to rethink what
> we are doing here. In fact, running multiple manually forked off
> processes inside the same service already sounds very wrong. We should
> try to keep a 1:1 mapping between processes we fork and services they
> run it.

Agreed. I really don't want socket-proxyd directly involved in
exec'ing of things, either.

> What's the usecase here?
>
> If this is about running multiple things in the same Network namespace,
> then there are certainly other, better ways to achieve the same. For
> example, we could introduce JoinPrivateNetwork=$SERVICE or so which
> would allow one service to join the network namespace of another. That
> makes this much smoother and more powerful, too.

That would be wonderful. I'd love to shed the shell scripts.

> With that in place you could simply have three proxy instances, and make
> them join the private network of your nginx instance and you should be
> set?

I think that would do exactly the trick. I didn't know it was possible
to join into an existing namespace that way.

It would be my pleasure to update the documentation to use something
like that if it becomes available. I'd also enjoy dropping the
--listener option. :-)