Bug 636787 - nss-sysinit: sysinit disabled on package upgrade
Summary: nss-sysinit: sysinit disabled on package upgrade
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nss
Version: 13
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Elio Maldonado Batiz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 643554
TreeView+ depends on / blocked
 
Reported: 2010-09-23 10:08 UTC by Tomas Hoger
Modified: 2010-11-05 04:45 UTC (History)
4 users (show)

Fixed In Version: nss-util-3.12.8-1.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 643554 (view as bug list)
Environment:
Last Closed: 2010-10-27 22:30:27 UTC


Attachments (Terms of Use)
Fix the disabling of nss-sysinit on update (1.48 KB, patch)
2010-09-27 19:34 UTC, Elio Maldonado Batiz
rrelyea: review+
Details | Diff

Description Tomas Hoger 2010-09-23 10:08:09 UTC
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

Comment 1 Elio Maldonado Batiz 2010-09-27 19:30:56 UTC
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.

Comment 2 Elio Maldonado Batiz 2010-09-27 19:34:49 UTC
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.

Comment 3 Bob Relyea 2010-09-28 19:16:17 UTC
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...

Comment 4 Tomas Hoger 2010-09-29 09:45:43 UTC
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.

Comment 5 Elio Maldonado Batiz 2010-09-29 15:31:10 UTC
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?

Comment 6 Tomas Hoger 2010-09-29 16:04:44 UTC
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

Comment 7 Fedora Update System 2010-09-30 00:25:49 UTC
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

Comment 8 Fedora Update System 2010-09-30 00:29:49 UTC
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

Comment 9 Fedora Update System 2010-09-30 05:31:34 UTC
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

Comment 10 Tomas Hoger 2010-09-30 06:43:47 UTC
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.

Comment 11 Elio Maldonado Batiz 2010-09-30 16:45:35 UTC
oops, poor cherry-picking when merging.

Comment 12 Elio Maldonado Batiz 2010-09-30 17:01:31 UTC
%triggerpostun -n nss-sysinit -- nss-sysinit < 3.12.7-9
as I have to bump the release number

Comment 13 Fedora Update System 2010-10-02 01:12:36 UTC
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

Comment 14 Fedora Update System 2010-10-07 18:19:15 UTC
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

Comment 15 Fedora Update System 2010-10-08 00:07:36 UTC
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 16 Fedora Update System 2010-10-27 22:29:59 UTC
nss-3.12.8-2.fc13, nss-softokn-3.12.8-1.fc13, nss-util-3.12.8-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 Fedora Update System 2010-10-28 05:47:43 UTC
nss-3.12.8-2.fc14, nss-softokn-3.12.8-1.fc14, nss-util-3.12.8-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Fedora Update System 2010-11-05 04:45:09 UTC
nss-util-3.12.8-1.fc12, nss-softokn-3.12.8-1.fc12, nss-3.12.8-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


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