Bug 643554

Summary: nss-sysinit: sysinit disabled on package upgrade
Product: Red Hat Enterprise Linux 6 Reporter: Elio Maldonado Batiz <emaldona>
Component: nssAssignee: Elio Maldonado Batiz <emaldona>
Status: CLOSED ERRATA QA Contact: Aleš Mareček <amarecek>
Severity: medium Docs Contact:
Priority: high    
Version: 6.1CC: amarecek, emaldona, kdudka, kengert, rrelyea, thoger
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: nss-3.12.9-1.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 636787 Environment:
Last Closed: 2011-05-19 14:03:45 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:
Bug Depends On: 636787    
Bug Blocks:    

Description Elio Maldonado Batiz 2010-10-15 23:15:50 UTC
+++ This bug was initially created as a clone of Bug #636787 +++

Description of problem:
It seems nss-sysinit is intended to be enabled by default in recent Fedora version, and it is enabled in F13 after install.  It is, however, disabled after first nss-sysinit package upgrade.  This problem is caused by incorrect rpm %pre / %post scripts.

Package calls 'setup-nsssysinit.sh on' in postinstall and 'setup-nsssysinit.sh off' in preuninstall.  They are run unconditionally, and given the order in which rpm scripts are executed (%pre %post %preun %postun), nss-sysinit end up being disabled after the first package upgrade.

If the intention is to have it enabled by default, 'setup-nsssysinit.sh off' should only be run on package erase.  This is similar to what's commonly done with initscripts / chkconfig, see e.g.:

http://fedoraproject.org/wiki/Packaging/Guidelines#Scriptlets


Version-Release number of selected component (if applicable):
nss-3.12.7-6.fc13

--- Additional comment from emaldona on 2010-09-27 15:30:56 EDT ---

Even if we ran setup-nsssyinit off on package erase only, say with a guard such as
%preun sysinit
if [ $1 -eq 0 ] ; then
%{_bindir}/setup-nsssysinit.sh off
fi
we would still have the problem on the first update. The erase is handled by the faulty scriptlet of the prior version of nss.spc still in the system at the cleanup phase and that will turn it off. Subsequent updates will be okay. 

Come to think about it, $1 can never be 0. Since 3.12.5 nss-sysinit is required by nss and can't never be removed entirely, otherwise nss would be totally erased as well with dire consequences. 

The proper long term solution is to change system-pkcs11.txt to have nsssysinit on and get rid of the {post|prein} sysinit scriptlets altogether. We must solve problem where the old scriptlet turned sysinit off. A %posttrans sysinit scriplet will allow us to undo the effects turning off done by the old scriplet. On a subsequent update we get rid of this '%posttrans sysinit' as well.

--- Additional comment from emaldona on 2010-09-27 15:34:49 EDT ---

Created attachment 450012 [details]
Fix the disabling of nss-sysinit on update

Change of system-pkcs11.txt would be permanent whereas the use of %posttrans scriptlet would be transitional.

--- Additional comment from rrelyea on 2010-09-28 15:16:17 EDT ---

Comment on attachment 450012 [details]
Fix the disabling of nss-sysinit on update

r+ You know this also turns off the user's preference of turning sysinit off...

--- Additional comment from thoger on 2010-09-29 05:45:43 EDT ---

Yeah, I realized the same thing Bob mentions above.  With current rpm scripts, sysinit gets disabled on each upgrade.  With new, it get enabled on each upgrade.  Both cases ignore user preference.

--- Additional comment from emaldona on 2010-09-29 11:31:10 EDT ---

The new way is the lesser of two evils as it upsets the less number of people but ignoring user's preferences isn't good. The problem is that there is no way to tell whether sysinit was disabled because the user wanted it or because the old faulty scriplet turned it off. Any ideas?

--- Additional comment from thoger on 2010-09-29 12:04:44 EDT ---

Right, if you assume that at the time you try to upgrade to fixed packages it can be disabled because of previous upgrade or admin decision, there's unlikely to be a good way to tell which case it is.

Thinking a bit more about this, what about versioned %triggerpostun, that would only re-enable once, when first upgrading from affected version.  Assuming this is first fixed in nss-3.12.7-10.fcX, this may work:

%triggerpostun -n nss-sysinit -- nss-sysinit < 3.12.7-10
/usr/bin/setup-nsssysinit.sh on

--- Additional comment from updates on 2010-09-29 20:25:49 EDT ---

nss-3.12.7-8.fc14,nss-softokn-3.12.7-7.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/nss-3.12.7-8.fc14,nss-softokn-3.12.7-7.fc14

--- Additional comment from updates on 2010-09-29 20:29:49 EDT ---

nss-3.12.7-8.fc13,nss-softokn-3.12.7-7.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/nss-3.12.7-8.fc13,nss-softokn-3.12.7-7.fc13

--- Additional comment from updates on 2010-09-30 01:31:34 EDT ---

nss-3.12.7-8.fc14, nss-softokn-3.12.7-7.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss nss-softokn'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/nss-3.12.7-8.fc14,nss-softokn-3.12.7-7.fc14

--- Additional comment from thoger on 2010-09-30 02:43:47 EDT ---

Elio, I believe you want to use nss-sysinit < 3.12.7-8 trigger on F13/F14 and not the same < 3.12.8-3 as in Rawhide, where nss is already updated to 3.12.8.

--- Additional comment from emaldona on 2010-09-30 12:45:35 EDT ---

oops, poor cherry-picking when merging.

--- Additional comment from emaldona on 2010-09-30 13:01:31 EDT ---

%triggerpostun -n nss-sysinit -- nss-sysinit < 3.12.7-9
as I have to bump the release number

--- Additional comment from updates on 2010-10-01 21:12:36 EDT ---

nss-3.12.7-9.fc14, nss-softokn-3.12.7-7.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss nss-softokn'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/nss-3.12.7-9.fc14,nss-softokn-3.12.7-7.fc14

--- Additional comment from updates on 2010-10-07 14:19:15 EDT ---

nss-3.12.8-2.fc14,nss-softokn-3.12.8-1.fc14,nss-util-3.12.8-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/nss-3.12.8-2.fc14,nss-softokn-3.12.8-1.fc14,nss-util-3.12.8-1.fc14

--- Additional comment from updates on 2010-10-07 20:07:36 EDT ---

nss-util-3.12.8-1.fc12,nss-softokn-3.12.8-1.fc12,nss-3.12.8-2.fc12 has been submitted as an update for Fedora 12.
https://admin.fedoraproject.org/updates/nss-util-3.12.8-1.fc12,nss-softokn-3.12.8-1.fc12,nss-3.12.8-2.fc12

Comment 5 errata-xmlrpc 2011-05-19 14:03:45 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0692.html