Bug 141470 - Config gets overwritten on update
Config gets overwritten on update
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: cyrus-imapd (Show other bugs)
2
All Linux
medium Severity high
: ---
: ---
Assigned To: John Dennis
Brian Brock
:
: 141673 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-01 06:59 EST by Michael Bischof
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-01 15:14:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Bischof 2004-12-01 06:59:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:

/etc/imapd.conf should be marked as config file
so that it doesnt get overwritten on an update.


Version-Release number of selected component (if applicable):
cyrus-imapd-2.2.10-1.fc2

How reproducible:
Always

Steps to Reproduce:
1. ...
2.
3.
    

Additional info:
Comment 1 John Dennis 2004-12-01 15:14:23 EST
Good catch, thank you. Spec files are updated, however this particular
fix probably does not warrant pushing a new rpm with an announcement
so the fix will show up the next time a push is warranted.
Comment 2 Simon Matter 2004-12-02 12:59:30 EST
I don't agree here because:

- if you change this for imapd.conf, the same applies to cyrus.conf as
well.

- the files have never been overwritten by an update even if the
imapd.conf has been modified by the user. The reason is that until the
file has been changed between different rpm packages, the ondisk file is
not touched at all. If I change the default imapd.conf file, it may well
be because of a new parameter which is not compatible with the older
version - and then I don't want the old config file to stay there.

- even if you change to %config(noreplace) here, the %verify options are
wrong here. The %verify directive is only usefull to change for files that
_never_ work out of the box without modification. I just scanned some of
redhats spec file for a %verify directive and found them only in a few
packages where they are absolutely correct:
authd-1.4.2-8.src/authd.spec:%verify(not md5 size mtime user group)
%config %{_sysconfdir}/ident.key
bind-9.2.4-2.src/bind.spec:%verify(not size,not md5) %config(noreplace)
%attr(0640,root,named) /etc/rndc.conf
bind-9.2.4-2.src/bind.spec:%verify(not size,not md5) %config(noreplace)
%attr(0640,root,named) /etc/rndc.key
ntp-4.2.0.a.20040617-4.src/ntp.spec:%config(noreplace) %verify(not md5
size mtime) %{_sysconfdir}/ntp/step-tickers
ntp-4.2.0.a.20040617-4.src/ntp.spec:%config(noreplace) %attr(644,ntp,ntp)
%verify(not md5 size mtime) %{_var}/lib/ntp/drift

The only thing we may change is to add the noreplace option for both, the
imapd.conf and the cyrus.conf files. Another change could be to remove the
verify options from the pam.d/* file because they are also wrong here.
Comment 3 John Dennis 2004-12-02 16:30:41 EST
*** Bug 141673 has been marked as a duplicate of this bug. ***
Comment 4 John Dennis 2004-12-02 18:42:02 EST
FYI, new versions of cyrus-imapd have been built that set
    /etc/imapd.conf
    /etc/cyrus.conf
to be "noreplace". Packages are waiting for signature and push.

Also, the disabling of %verify on noreplace config files was removed,
we do want alterations of the config files to be visible when
validating, this is for security reasons so config file changes are
flagged.
Comment 5 Simon Matter 2004-12-03 02:29:05 EST
While reading Bug 141673 I have the impression that using yum doesn't
do the same than rpm directly. I have several servers runnning with
modified imapd.conf files and I'm updating the cyrus-imapd packages
frequently. I have never got a .rpmsave or .rpmnew file because the
packaged files in the rpm haven't been touched. If they don't change
in the rpm, the installed files are not touched on disk. Does updating
with yum do anything different that using rpm -F ? I'm a bit worried
right now.
Comment 6 John Dennis 2004-12-03 13:27:32 EST
I don't think yum comes into the equation. My understanding is that
yum simply marshals the set of rpms to install and then turns the
installation over to rpm. Thus with respect to .rpmsave,.rpmnew
behavior it should be identical because that operation is under the
control of rpm install in both instances.

I believe why some users are seeing the creation of .rpmsave files and
you're not is a consequence of the version being upgraded. In FC2 the
version of cyrus-imapd was 2.2.3-11. The version replacing it where
the issue was reported was 2.2.10-1. Looking at the MD5 sums for
/etc/cyrus.conf and /etc/imapd.conf between the two versions shows
that cyrus.conf is the same, but imapd.conf is different. Thus for FC2
installations a .rpmsave should have been generated for imapd.conf
which is what was reported.

I suspect the reason you're not seeing that with your yum installs is
that because you're much more current with the cyrus-imapd versions
your upgrades aren't seeing a difference in the files. Make sense?
Would that be the case
Comment 7 Simon Matter 2004-12-03 18:59:06 EST
Thanks John, now everything becomes clear. I'm not using yum myself
but was afraid something is handled different there. I expected that
yum just let rpm do the real work but was worried I'm missing
something here.
Now, the reason for the difference in imapd.conf is with the 2.2.3
RedHat package. While my own 2.2.3 package (the Invoca rpm) had the
imapd.conf file like all newer Invoca rpms, the RedHat 2.2.3 package
was based on a older Invoca rpm which contained a different
imapd.conf. I was assuming the the packaged imapd.conf file has always
been the same in all 2.2.x rpms, which is correct only for the Invoca
rpms but not for the RedHat rpms. Sorry for all the confusion.

Note You need to log in before you can comment on or make changes to this bug.