RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 643554 - nss-sysinit: sysinit disabled on package upgrade
Summary: nss-sysinit: sysinit disabled on package upgrade
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss
Version: 6.1
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Elio Maldonado Batiz
QA Contact: Aleš Mareček
URL:
Whiteboard:
Depends On: 636787
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-15 23:15 UTC by Elio Maldonado Batiz
Modified: 2011-05-19 14:03 UTC (History)
6 users (show)

Fixed In Version: nss-3.12.9-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 636787
Environment:
Last Closed: 2011-05-19 14:03:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0692 0 normal SHIPPED_LIVE nspr, nss, nss-softokn, and nss-util bug fix and enhancement update 2011-05-19 09:37:17 UTC

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


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