On 03/17/2012 02:19 AM, Lennart Poettering wrote:
On Fri, 16.03.12 15:55, Michal Hlavinka ([email protected]) wrote:
For example, lets have dovecot configured to listen for imap(s) and lets
have systemd dovecot socket configured to listen for all protocols -
pop3(s) and imap(s). When dovecot is configured to start on boot,
systemd will start it and dovecot will listen on imap(s) ports. But when
dovecot.socket is enabled, it'll listen on pop3(s) too and when new pop3
connection comes, it'll pass it to dovecot and dovecot will serve it.
The question is: Should this happen? What exactly should happen when
dovecot.conf does not match dovecot.socket configuration?
Michal
Dovecot's systemd code was written by one of you Redhat guys. I had some
similar thoughts when I applied the patch, but didn't really know what
to do about it, so I didn't do anything. So: I don't know. Maybe some
other project has solved this somehow already?
Dovecot anyway needs its own internal UNIX listeners. Should all
internal inet listeners be disabled? Could Dovecot somehow talk to
systemd and ask what listeners it's using for Dovecot and log warnings
if they don't match?
So here's what I recommend in cases where the configuration file of the
service itself and the systemd sockets passed do not match up: honour
both. i.e. go through the list of sockets passed and match them up with
the configuration as good as possible, but also listen on all sockets
which are configured in the config file but not passed and on all
sockets passed that are not configured in the config file.
This is what we do in CUPS and what I think is a nice approach since it
basically means that any user configuration is always taken into
account.
Unfortunately, this can't be used here. CUPS offers only one service, so
it always know what to expect on any connection. Dovecot, on the other
hand, provides five services (imap, imaps, pop3, pop3s, managesieve) and
when it gets connection on port that is not configured in it's config
files, it can't know what to do with the connection.
So if the connection comes to extra port, it won't be served. There are
three possibilities what can happen next:
1) just log message that configuration does not match, do nothing
2) log message and close socket that listens on port dovecot won't serve
3) log message and terminate dovecot
I think the 2nd option is the best one here. Does systemd provide any
API to close those sockets?
Michal
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
