Bug 982723

My rhel-7.0 VM. from where I am typing,  is currently one release behind. I currently have problems upgrading so let's try to reproduce with what I have.

[emaldona@localhost ~]$ rpm -q nss-sysinit
nss-sysinit-3.15-5.el7.x86_64
[emaldona@localhost ~]$ rpm -ql nss-sysinit
/etc/pki/nssdb/cert9.db
/etc/pki/nssdb/key4.db
/etc/pki/nssdb/pkcs11.txt
/usr/bin/setup-nsssysinit.sh
/usr/lib64/libnsssysinit.so
/usr/share/man/man1/setup-nsssysinit.1.gz

I see both the script and the man page tarred.

Can I use it?
[emaldona@localhost ~]$ man setup-nsssysinit > man-setup-nsssysinit.txt 2>&1
SETUP-NSSSYSINIT(1)                                 Network Security Services                                SETUP-NSSSYSINIT(1)



NAME
       setup-nsssysinit - Query or enable the nss-sysinit module

SYNOPSIS
       setup-nsssysinit [--prefix] [--exec-prefix] [--includedir] [--libs] [--cflags] [--libdir] [--version]

Yes, I have it. 

In another system, I downloaded the nss-sysinit rpms for the 5 and an 6 relases. That's nss-sysinit-3.15-5.el7.x86_64.rpm and and nss-sysinit-3.15-6.el7.x86_64.rpm. I extracted them with rpmedev-extract and compared and it showed me I have the same files on each. The script hasn't gone missing.

The only change I made going from -5 to -6 is that I no longer strip off the ECC code from the upstream source tar ball as I did before. I can't explain the cause of the reported problem at this moment.

I downloaded the nss-3.15-6 rpms and manually updated via 'yum localupdate'.

This is what I now have:
[emaldona@localhost ~]$ rpm -q nss-sysinit
nss-sysinit-3.15-6.el7.x86_64

[emaldona@localhost ~]$ rpm -ql nss-sysinit
/etc/pki/nssdb/cert9.db
/etc/pki/nssdb/key4.db
/etc/pki/nssdb/pkcs11.txt
/usr/bin/setup-nsssysinit.sh
/usr/lib64/libnsssysinit.so
/usr/share/man/man1/setup-nsssysinit.1.gz

All files are present and invoking
[emaldona@localhost ~]$ man setup-nsssysinit
shows me:
SETUP-NSSSYSINIT(1)                                 Network Security Services                                SETUP-NSSSYSINIT(1)

NAME
       setup-nsssysinit - Query or enable the nss-sysinit module

.... etcetera ....

It's working on my test system.

I think I know what the problems is

[emaldona@localhost ~]$ ls -l /usr/bin/setup-nsssysinit*
-rwxr-xr-x. 1 root root 1539 Jul  1 20:45 /usr/bin/setup-nsssysinit.sh

[emaldona@localhost ~]$ ls -l /usr/sbin/setup-nsssysinit*
ls: cannot access /usr/sbin/setup-nsssysinit*: No such file or directory

I never created that symbolic link. If it's required, that's easy enough to do.

There no need for a symbolic link. After reading the problem description in Comment 0 more carefully I see the mistake. In the Files section, the path to /usr/sbin/setup-nsssysinit that should be changed to /usr/sbin/setup-nsssysinit. There is also a mistake in the --off option description, Turn off nss-sysinit, not on. I'll fix them in fedora first.

Hi Elio,
the problem is that man page contains links for nonexistent binary (script) - "setup-nsssysinit". Also, you have to call "man setup-nsssysinit" to enter man pages (not the "man setup-nsssysinit.sh"). Next problem is that manual page speaks about "/usr/sbin/setup-nsssysinit" and it doesn't exist.
All we have in package is "/usr/bin/setup-nsssysinit.sh". The problem is obvious - confusing man pages and the script file.

If we have "/usr/bin/setup-nsssysinit.sh", the man page should speak about "/usr/bin/setup-nsssysinit.sh".
If we create symlinks to "/usr/bin/setup-nsssysinit" and "/usr/sbin/setup-nsssysinit", the man page will be OK in that case.

Additional info: RHEL-5 and RHEL-6 don't have manual page for this this package thus this bug is irrelevant for -5 and -6.

using:
nspr-4.10-3.el7.x86_64
nss-softokn-freebl-3.15.1-2.el7.x86_64
nss-softokn-3.15.1-2.el7.x86_64
nss-sysinit-3.15.1-2.el7.x86_64
nss-tools-3.15.1-2.el7.x86_64
nss-3.15.1-2.el7.x86_64
nss-util-3.15.1-2.el7.x86_64

The error is still present in the man page:

# man setup-nsssysinit | col -b | grep setup-nsssysinit
       setup-nsssysinit - Query or enable the nss-sysinit module
       setup-nsssysinit [--prefix] [--exec-prefix] [--includedir] [--libs] [--cflags] [--libdir] [--version]
       setup-nsssysinit is a shell script to query the status of the nss-sysinit module and when run with root priviledge it can
                   /usr/bin/setup-nsssysinit --status
                   /usr/bin/setup-nsssysinit --on
       /usr/sbin/setup-nsssysinit



# /usr/bin/setup-nsssysinit --on
-bash: /usr/bin/setup-nsssysinit: No such file or directory

This is why
[emaldona@dhcp-32-223 nss]$ rpm -ql nss-sysinit | grep bin
/usr/bin/setup-nsssysinit.sh
                         ^^^

So we either have to:
 * add ".sh" to names in man page,
 * rename the scripts to not have the ".sh" extension, or
 * create links without extension to the scripts with the extension

either solution is fine by me, but the second one has a high chance to be rather disruptive...

(In reply to Hubert Kario from comment #9)
> So we either have to:
>  * add ".sh" to names in man page,
>  * rename the scripts to not have the ".sh" extension, or
>  * create links without extension to the scripts with the extension
> 
> either solution is fine by me, but the second one has a high chance to be
> rather disruptive...

I agree, the second one isn't wise. Though I prefer the third solution, symbolic links have caused me problems more than once before so I'll will likely go with the first solution. Fix coming soon.

Created attachment 811407 [details]
create symbolic link without extension to the script with the extension

The third alternative proposed which turned out not as hard as I had thought

The man page is still inconsistent with the tool:

# man setup-nsssysinit | col -b | grep setup-nsssysinit
       setup-nsssysinit - Query or enable the nss-sysinit module
       setup-nsssysinit [--prefix] [--exec-prefix] [--includedir] [--libs] [--cflags] [--libdir] [--version]
       setup-nsssysinit is a shell script to query the status of the nss-sysinit module and when run with root priviledge it can
                   /usr/bin/setup-nsssysinit --status
                   /usr/bin/setup-nsssysinit --on
       /usr/sbin/setup-nsssysinit

# /usr/bin/setup-nsssysinit --status
Usage: setup-nsssysinit [on|off]
  on     - turns on nsssysinit
  off    - turns off nsssysinit
  status - reports whether nsssysinit is turned on or off


But [on|off|status] without '--' works:
# /usr/bin/setup-nsssysinit status
NSS sysinit is disabled

So what's left to be done?
Can you please write a short comment, as a list, that summarizes all of the remaining work?

In an email, Elio said he already has a fix.
Once we have the list of remaining work, we can compare.

The man page lists following options that are completely unimplemented in the tool:
 * --prefix
 * --exec-prefix
 * --includedir
 * --libs
 * --cflags
 * --libdir
 * --version

I don't know if they were implemented before, or if they were planned to be implemented. As they are not explained in the man page, I'm assuming it's just some kind of left over from copy-paste. They should probably be deleted and replaced by [on] [off] [status].

The options supported by the tool:
 * on
 * off
 * status
must be provided without '--' in front of them, so the minus signs should be deleted in the man page.

Created attachment 818350 [details]
Fix options descrcrptions

Removes the incorrect -- in front of the on, off, and status options descriptions. It also removes from the options enumeration non-existent options.

(In reply to Hubert Kario from comment #15)
> The man page lists following options that are completely unimplemented in
> the tool:
>  * --prefix
>  * --exec-prefix
>  * --includedir
>  * --libs
>  * --cflags
>  * --libdir
>  * --version

Yes, I noticed while fixing the other ones. I
> 
> I don't know if they were implemented before, or if they were planned to be
> implemented. As they are not explained in the man page, I'm assuming it's
> just some kind of left over from copy-paste. They should probably be deleted
> and replaced by [on] [off] [status].

Your assumption is right, its indeed a cop-and-paste and forget to remove stuff as I was using other xml files as a starting point.

> 
> The options supported by the tool:
>  * on
>  * off
>  * status
> must be provided without '--' in front of them, so the minus signs should be
> deleted in the man page.

Yes, the attachment does just that.

nss-3.15.2-7.el7.x86_64

examples still use '--' syntax:

EXAMPLES
       The following example will query for the status of nss-sysinit:

                   /usr/bin/setup-nsssysinit --status

       The following example, when run as superuser, will turn on nss-sysinit:

                   /usr/bin/setup-nsssysinit --on

Created attachment 819279 [details]
Fix examples

Created attachment 819280 [details]
The xml file with all fixes applied

Also, I'm not quite sure what "count" does in explanation of "status" option:

OPTIONS
       on
           Turn on nss-sysinit.

       off
           Turn on nss-sysinit.

       status count
           returns whether nss-syinit is enabled or not.

(In reply to Hubert Kario from comment #22)
> Also, I'm not quite sure what "count" does in explanation of "status" option:
..
>        status count
>            returns whether nss-syinit is enabled or not.

Good catch, it should be removed.

Elio, I think you have dropped one patch when you merged them together, examples use the "--" syntax again:

EXAMPLES
       The following example will query for the status of nss-sysinit:

                   /usr/bin/setup-nsssysinit --status

       The following example, when run as superuser, will turn on nss-sysinit:

                   /usr/bin/setup-nsssysinit --on

Also, the path in FILES section is wrong, it specifies /usr/sbin instead of /usr/bin:

FILES
       /usr/sbin/setup-nsssysinit

Using nss-3.15.2-9.el7.x86_64 and nss-sysinit-3.15.2-9.el7.x86_64

Created attachment 823495 [details]
Needed fixes pointed out by Hubert in patch format

Created attachment 823501 [details]
The xml file with the fixes applied

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.