support systemd style socket activation

[calestyo]

Hey.

dcache has e.g. still the dcache.user setting to allow e.g. to set root for a webdav door to have that bind to a privileged port.

In the systemd-world this is in principle no business for the service (which should not decide as which user it runs), but rather that of systemd.

Along with that comes however the need for a way to allow processes to bind to privileged ports.

One way is via capabilities, which is however less good, as it gives the capability for all ports.

The preferred way is systemd style socket activation, as described here: http://0pointer.de/blog/projects/socket-activation.html

Not sure how well this is supported by Java (which is always a bit "special), but it seems to be:

• https://stackoverflow.com/questions/27176552/receiving-open-sockets-from-the-environment-in-java
• also found https://github.com/sswv/sd-daemon-java (but haven't look really into it)

Would be nice to have that in dCache. That would allow people to run dCache under dcache user but still have privileged ports. And it would allow you guys to drop dcache.user for good.

Cheers, Chris.

[paulmillar]

Yes, I think this should work. FWIW, here's a "should work" reference for Netty: https://stackoverflow.com/questions/50163786/netty-systemd-lazy-initialization

We would need a domain per door. The first connection really would be rather slow as it would involve creating a whole new domain (not just a new cell within dCache), starting the System cell, building the tunnels (over which dCache messages are sent) to all core domains, etc. Assuming systemd keeps the JVM alive, subsequent client connections would be at the regular speed.

I'm not sure it's an obvious "win". Supporting this would require development effort and there are alternatives (e.g., using iptables) that allow dCache to run unprivileged and listen on privileged ports.

Just to mention it, the dcache.user configuration property doesn't go away, even if this suggested change is made: that property is needed for tarball deployments.

[calestyo]

You use netty for webdav? Would be nice if that could be made working. I guess the webdav door would be the main use case (to get port 80/443)... but probably it would also be nice for the other door types.

We would need a domain per door. The first connection really would be rather slow as it would involve creating a whole new domain (not just a new cell within dCache), starting the System cell, building the tunnels (over which dCache messages are sent) to all core domains, etc. Assuming systemd keeps the JVM alive, subsequent client connections would be at the regular speed.

I had thought about that too.

In principle my idea is mainly about letting the door bind to a privileged port without giving it any privileges.
I'd still rather would want it start "right in the beginning" (because of monitoring/alerting), though I haven't really though to much yet about how systemd can be made do that (if at all).

I'm not sure it's an obvious "win". Supporting this would require development effort and there are alternatives (e.g., using iptables) that allow dCache to run unprivileged and listen on privileged ports.

Which may however have some performance impact (though I haven't tested it). I do however recall an example where a system that had fail2ban running and that hat a lot entries in that queue, caused really extreme breakdown of the network IO.
Of course, just one PREROUTING rule that does a NAT shouldn't be that costly.

Just to mention it, the dcache.user configuration property doesn't go away, even if this suggested change is made: that property is needed for tarball deployments.

Well at least for the packaged versions using systemd it would perhaps make sense then to have an empty default value meaning to take whatever it is started with by systemd.

[kofemann]

Well, .socket based solution will be broken for dCache for multiple reasons:

• monitoring
• publishing by SRM and SRR
• probably something else...

[calestyo]

As said, ... my main motivation was simply the permissions thing. One would probably need to think of a clean way, that the .socket related .service is still started right after the .socket. Maybe something like a "ping".