Bug 217270

Summary: Bad defaults in ssmtp.conf
Product: [Fedora] Fedora Reporter: Ville Skyttä <ville.skytta>
Component: ssmtpAssignee: manuel wolfshant <manuel.wolfshant>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: extras-qa
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: ssmtp-2.61-10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-29 17:55:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Better config defaults none

Description Ville Skyttä 2006-11-26 09:56:50 UTC
The default ssmtp.conf has uncommented "rewriteDomain=" and
"hostname=_HOSTNAME_" options, which makes the default config pretty certainly
not work anywhere without modifications.  Commenting both of them out and
removing the confusing _HOSTNAME_ would be better and more likely to work out of
the box on quite a few systems - (untested) patch attached.

Also, there is movement towards IPv6-enabling everything in Fedora (see eg
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=IPv6Blocker), so perhaps
enable it here too (configure --enable-inet6)?  Just a remark, I don't use and
can't test that at the moment.

Comment 1 Ville Skyttä 2006-11-26 09:56:51 UTC
Created attachment 142128 [details]
Better config defaults

Comment 2 Ville Skyttä 2006-11-26 10:00:06 UTC
Oops, ipv6 seems to be enabled already, sorry about the noise.

Comment 3 manuel wolfshant 2006-11-26 22:32:02 UTC
How about leaving the provided ssmtp.conf alone as in the source, but edit it in
%post?
I have just tested the following scriplet and it seems to behave in a reasonable
fashion:
if [ $1 -eq 1 ] ; then
        DOMAIN=$(hostname -d)
        HOSTNAME=$(hostname --fqdn)
        sed -ie "s/_HOSTNAME_/$HOSTNAME/;s/=$/=$DOMAIN/" /etc/ssmtp/ssmtp.conf
fi

Side effect is that it needs net-tools at install time.
What do you think ?

Comment 4 Ville Skyttä 2006-11-27 16:34:17 UTC
Editing at %post time has the annoyance that the config file will be immediately
modified from the packaged one, thus causing *.rpm(new|save) backups left behind
on packages upgrades/erases.  It is also possible that the suggested approach
would lead to breakage if the hostname or domain of the box changes if someone
doesn't remember to manually take care of ssmtp's config too.  Therefore I think
the approach from comment 1 is a better one.

Comment 5 manuel wolfshant 2006-11-27 17:21:41 UTC
Maybe I make an error, and if so please do correct me, but the file is marked
%config(noreplace) and the scriplet I suggest will only be active at install
(not upgrade), so a backup will only be left in case of erase (which I see as a
feature, not a bug). Nothing is touched at upgrade time.


I'll be back in a day or two, I want to perform more tests.

Comment 6 Ville Skyttä 2006-11-27 18:17:07 UTC
It doesn't matter when your scriptlet is active, it causes modification of a
file marked as config after the package has been installed.  rpm checks for
these things internally on package upgrades - if a new upstream release of ssmtp
comes out with some upstream changes to the config file compared to the previous
(unmodified) one, package upgrades will result in useless *.rpmnew.

And if on erase a package leaves a *.rpmsave behind for a config file that 1) I
have not modified personally, and 2) the package has done it itself probably for
no reason, it most certainly qualifies as a (small, but annoying) bug to me, not
a feature.

I fail to see any reason why doing the suggested modifications in %post would be
better than shipping commented out entries - it's more complex, the result is
arguably functionally worse, and the setup requires potentially more manual
maintenance when the hostname/domain of the box changes.  ssmtp can figure the
hostname out internally (and if it can't, I'm having problems believing
"hostname --fqdn" could do any better) and setting the domain to "hostname -d"
by default could be seen as unexpected and harmful.

Comment 7 manuel wolfshant 2006-11-28 03:57:15 UTC
Ville, thank you for clarifications.

Proposed patch included, rpm sucessfully built in devel.
If no objections within 24h, I will request building for the other branches and
close the bug (as CURRENTRELEASE ? ).


Comment 8 manuel wolfshant 2006-11-29 17:55:54 UTC
Sucessfully built on all branches.