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

[Lennart Poettering]

On Sun, 24.11.13 16:47, David Strauss (straussd at kemper.freedesktop.org) wrote:

>  TODO                             |    1 
>  man/systemd-socket-proxyd.xml    |   80 ++++++++++++++++++++++++++++++++++++++-
>  src/socket-proxy/socket-proxyd.c |   63 ++++++++++++++++++++----------
>  3 files changed, 121 insertions(+), 23 deletions(-)
> 
> New commits:
> commit adcf4c81c58511b67644e17fa743d1729d3c9ccf
> Author: David Strauss <david at davidstrauss.net>
> Date:   Mon Nov 25 10:44:48 2013 +1000
> 
>     socket-proxyd: Add --listener option for listener/destination
>     pairs.

Could you please explain what the usecase here is? Why is this better
than having two socket units with two proxy services?

> +/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.

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. 

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?


Lennart

-- 
Lennart Poettering, Red Hat