Solved Dovecot complains about its config, even when not used?

ShelLuser

ShelLuser

Hi guys,

I'm having a hard time deciding if this is a bug or if it could be considered normal behavior. Personally I suspect the first, but I figured I'd ask.

I have mail/dovecot installed on my FreeBSD 10.3 environment. However, I haven't configured it yet nor did I add anything to /etc/rc.conf. Much to my surprise Dovecot sends out plenty of errors when the server is rebooting. From console.log:

Code: 
Feb 20 07:54:23 macron kernel: Error: ssl_cert_file: Can't use /etc/ssl/certs/dovecot.pem: No such file or directory
Feb 20 07:54:23 macron kernel: Fatal: Invalid configuration in /usr/local/etc/dovecot.conf
Feb 20 07:54:23 macron kernel: Error: ssl_cert_file: Can't use /etc/ssl/certs/dovecot.pem: No such file or directory
Feb 20 07:54:23 macron kernel: Fatal: Invalid configuration in /usr/local/etc/dovecot.conf
Feb 20 07:54:23 macron kernel: Stopping mysql.
It seems like a clear case at first, but considering that I haven't even added it into /etc/rc.conf I fail to understand why it would complain like this. But it gets much more bizarre; as you can see it also complains about an invalid configuration in /usr/local/etc/dovecot.conf. Obviously I did something wrong here, didn't I? Well, about that....

Code: 
macron:/home/peter $ grep dovecot.pem /usr/local/etc/dovecot.conf
#ssl_cert_file = /etc/ssl/certs/dovecot.pem
#ssl_key_file = /etc/ssl/private/dovecot.pem
These options aren't even enabled as you can see, and still Dovecot complains. Even though it makes no sense it's doing so considering that I haven't even enabled anything yet. Not the options nor Dovecot itself.

So what do you think, does this count as a bug or would this be considered intended behavior?
 
Regarding the actual issue, I cannot tell very much, because I am using Dovecot v2 (mail/dovecot2), while you installed the outdated Dovecot v1. Do you have a certain reason why you want to use the old version which wasn't updated by the upstream since July 2011?

If not, I recommend, to # pkg delete dovecot and after this install mail/dovecot2. Then let's see, whether this error recurs.
 
It looks like dovecot can not find the certificate. (permissions??) I have not used dovecot 1.X for many years, so your best bet would be to use the 2.X version which is officially supported and gets alot of bug fixes and enhancements. In any case, in order to troubleshoot your problem you would need to post the output of: doveconf -n.
 
obsigna said:
If not, I recommend, to # pkg delete dovecot and after this install mail/dovecot2. Then let's see, whether this error recurs.
Click to expand...
Good question & suggestion indeed. I vaguely recall having a reason for this but I also somewhat forgot about it. Probably because this is being used in a restricted environment (LAN only), but it's something to look into. Thanks!

(edit) I'll check this out on my test server, that should raise some clues :)
 
Well, it seems to be that both ports were set up by the same maintainer (so I assume) because mail/dovecot2 behaves in the exact same illogical way. So after installing (and only installing, so no configuration has taken place, nor did I add Dovecot2 to /etc/rc.conf) this happens during boot:

Code: 
Feb 21 00:11:33 macron kernel: Starting sendmail.
Feb 21 00:11:34 macron kernel: Starting sendmail_msp_queue.
Feb 21 00:11:34 macron kernel: ==Error==
Feb 21 00:11:34 macron kernel: Config file /usr/local/etc/dovecot/dovecot.conf d
oes not exist. If this is
Feb 21 00:11:34 macron kernel: a new installation, please create the config file
s as outlined in
Feb 21 00:11:34 macron kernel: # pkg info -D dovecot2
Feb 21 00:11:34 macron kernel: Starting bsdstats.
I can trace these messages back to the start up script (/usr/local/etc/rc.d/dovecot) but I don't understand why it spits all this out when I haven't even configured Dovecot yet... Surely the system doesn't "just" start every script in /usr/local/etc/rc.d? (I suppose I should look this up though).

(edit): It does, from rc.d(8):

Code: 
     8.   Call each script in turn using run_rc_script() (from rc.subr(8)),
          which sets $1 to ``start'', and sources the script in a subshell.
          If the script has a .sh suffix then it is sourced directly into the
          current shell.  Stop processing when the script that is the value of
          the $early_late_divider has been run.

But I also got confirmation that what I'm experiencing is definitely unwanted behavior:

Code: 
     o   When a script is executed at boot time, it is passed the string
         ``start'' as its first and only argument.  At shutdown time, it is
         passed the string ``stop'' as its first and only argument.  All rc.d/
         scripts are expected to handle these arguments appropriately.  If no
         action needs to be taken at a given time (either boot time or shut-
         down time), the script should exit successfully and without producing
         an error message.
Time to mail the maintainer I guess.
 
ShelLuser said:
Surely the system doesn't "just" start every script in /usr/local/etc/rc.d?
Click to expand...
It does start all those scripts but the services should default to "off".

One thing I recently overlooked when debugging some Puppet scripts, we now have a /etc/rc.conf.d/ directory. Perhaps it's enabled there?

Also check /etc/mail/mailer.conf, it might be referenced from there.
 
Well, to keep you guys posted... I contacted the maintainer and he got back to me and managed to set up a patch, even though he wasn't behind his working computer. So he's now fully aware of this issue so I think we can look forward to a small change coming in a future release.
 
You must log in or register to reply here.
Back
Top