The mailwrapper(8) utility has been updated to use mailer.conf(5) from the LOCALBASE environment variable, which defaults to /usr/local if unset.
This sounds like a disaster in the making. Remember the post about TMPDIR getting reset such that emacs couldn’t connect? Imagine the fun when different scripts randomly use different mailers.
FreeBSD does not want any port/package touching the base system. Right now when you install an MTA you have to edit /etc/mailer.conf to make it the system default. Some come with hacky post-install scripts to edit it for you. This is lame.
Now in 11-RELEASE the MTA can install a mailer.conf in /usr/local/etc that will be honored. If it doesn’t exist the system falls back to /etc/mailer.conf preconfigured for sendmail (for now, hopefully dma long before 11-RELEASE)
In general I dislike when anything has multiple places to look for config files. it just causes confusion when the program picks up a config you didn’t intend.
Well, if ${LOCALBASE}/etc/mail/mailer.conf doesn’t exist, then wouldn’t this code (below) fall back to _PATH_MAILERCONF, which is apparently /etc/mail/mailer.conf?
Still seems odd though, but I guess if LOCALBASE isn’t set, then LOCALBASE gets set to “/usr/local”. Subsequently, if there is no file at the resulting path, then /etc/mail/mailer.conf is used as a last resort.
Maybe the goal was to allow sysadmins to supply an override in /usr/local without having to touch the base system? I guess in a similar fashion you can drop stuff in /usr/local/etc/rc.conf.d/ and they will be pulled in as if they were added to /etc/rc.conf.
Is there a reason why LibreSSL has not seen greater adoption? It would be nice to see FreeBSD move that into the base or at least see some hint on collaboration..
We’ve imported LibreSSL into a feature branch in HardenedBSD and are now providing a LibreSSL-based package repo. We’re hoping to pave the way for greater adoption of LibreSSL in FreeBSD.
A sneak-preview of features:
https://wiki.freebsd.org/WhatsNew/FreeBSD11 https://www.freebsd.org/relnotes/CURRENT/relnotes/article.html
(Of course, since they are not final, they may be incomplete/incorrect, but it gives a nice impression.)
This sounds like a disaster in the making. Remember the post about TMPDIR getting reset such that emacs couldn’t connect? Imagine the fun when different scripts randomly use different mailers.
FreeBSD does not want any port/package touching the base system. Right now when you install an MTA you have to edit /etc/mailer.conf to make it the system default. Some come with hacky post-install scripts to edit it for you. This is lame.
Now in 11-RELEASE the MTA can install a mailer.conf in /usr/local/etc that will be honored. If it doesn’t exist the system falls back to /etc/mailer.conf preconfigured for sendmail (for now, hopefully dma long before 11-RELEASE)
Hmm. I see the motivation, but I’ve never liked split /etc. It feels too much like /home/tedu for base files and /usr/local/home/tedu for ports files.
In general I dislike when anything has multiple places to look for config files. it just causes confusion when the program picks up a config you didn’t intend.
That does seem weird. The diff seems to imply that
/etc/mail/mailer.confis still the fallback. I wonder what the motivation was for this feature.Looks like a doc bug. The code uses /usr/local/ if LOCALBASE isn’t set and it doesn’t really “fallback”. It just fails.
Well, if
${LOCALBASE}/etc/mail/mailer.confdoesn’t exist, then wouldn’t this code (below) fall back to_PATH_MAILERCONF, which is apparently/etc/mail/mailer.conf?Still seems odd though, but I guess if LOCALBASE isn’t set, then LOCALBASE gets set to “/usr/local”. Subsequently, if there is no file at the resulting path, then
/etc/mail/mailer.confis used as a last resort.Maybe the goal was to allow sysadmins to supply an override in /usr/local without having to touch the base system? I guess in a similar fashion you can drop stuff in
/usr/local/etc/rc.conf.d/and they will be pulled in as if they were added to/etc/rc.conf.Oh! I looked right over those lines to the second fopen.
Is there a reason why LibreSSL has not seen greater adoption? It would be nice to see FreeBSD move that into the base or at least see some hint on collaboration..
We’ve imported LibreSSL into a feature branch in HardenedBSD and are now providing a LibreSSL-based package repo. We’re hoping to pave the way for greater adoption of LibreSSL in FreeBSD.