Description of problem: The file /etc/imapd.conf is somehow wrongly tagged in the recent update rpm. When performing unattended nightly yum updates, instead of saving the new /etc/imapd.conf in /etc/imapd.conf.rpmnew, it saves the old file in /etc/imapd.conf.rpmsave and creates a new /etc/imapd.conf, rendering customized installations unusable (e.g: here, we use auxprop authentication, unixhierarchysep and more auth methods than just PLAIN). Thus, next morning, nobody could access their imap accounts. Version-Release number of selected component (if applicable): 2.2.10-1.fc2 How reproducible: always Steps to Reproduce: 1. Customize /etc/imapd.conf 2. Update cyrus-imapd to 2.2.10-1.fc2 3. Actual results: Previous customizations are not effective anymore. Which could lead to render imapd services unusable, until someone restores /etc/imapd.conf manually Expected results: New config file should be stored in /etc/imapd.conf.rpmnew Additional info:
Thank you for your bug report, this was brought to our attention yesterday in bug #141470, so I'm marking this bug as a duplicate of that. The fix has been applied to the spec files. It's not clear to me that pushing an update for this makes sense, if updates are applied in sequence as would be typical an update with the fix won't save them, I will evaluate the merit of that, as opposed to just having the config file fix appear when another issue forces an update. *** This bug has been marked as a duplicate of 141470 ***
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.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.