[Bug 522210] New Package for Dogtag PKI: pki-ca

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=522210


John Dennis <jdennis at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jdennis at redhat.com




--- Comment #10 from John Dennis <jdennis at redhat.com>  2009-10-20 13:29:48 EDT ---
Adding comments here from an email exchange after attempting a pki-ca 1.2
install so these issues are not lost.

First John Dennis <jdennis at redhat.com> wrote:

You cannot remove the pki RPM's with rpm -e, it leaves junk behind (aside from
what the uninstall warns about) which prohibits a successful reinstall.
Specifically the files /etc/inid.d/pki-ca is generated, it's not listed in the
%files section of the rpm (even with %ghost) and is not removed when rpm -e is
run. The existence of the /etc/init.d/pki-ca file is used during the %post
stage as a condition to determine if the rest of the operations in
/usr/bin/pkicreate should execute. If the init script is present (it will be if
pki had ever been installed previously because it's never removed when the
package is removed) then the pkicreate script prematurely exits leaving the
system in an undefined and unworkable state.

My workaround fix was to manually remove /etc/init.d/pki-ca init script, e.g.:

rpm -e `rpm -qa pki-\*`
# If the following is not done then the subsequent yum install fails
rm /etc/init.d/pki-ca

and then do a

yum install pki-ca pki-silent

Obvious packaging problems:
---------------------------

An RPM must own (e.g. list in it's %files) every file it installs, otherwise
you end up with orphaned files and the inability of rpm to validate the set of
installed files. Orphaned files can create numerous other problems, one example
is seen above.

Generating files during install is generally frowned upon, however it's
sometimes necessary, in most circumstances those files must still be listed in
the %files using a %ghost directive. If you don't do this the files are neither
removed during an uninstall nor can they be validated after installation. There
are rare cases where a %post generated file will need to be removed in the
%preun stage.

Init scripts must be reviewable and verifiable, as such an init script must be
contained in the package. rpm -V must be able to validate all init scripts. It
is extremely doubtful a post install machine generated init script would ever
get approved for Fedora or RHEL.

It is never permissible to modify the file permissions of an installed file
from what it is in the %files section, especially to add execute permissions.

It is never permissible for a rpm install to prompt the user for input.

It is generally undesirable when installing an rpm to start any service as a
consequence of installation, especially one like pki which has numerous cross
dependencies and complex configuration.

Most of what occurs in /usr/share/pki/ca/setup/postinstall and
/usr/bin/pkicreate should never occur during an rpm install.

Then Mark Harmsen <mharmsen at redhat.com> wrote:

Certificate System separates the various servers (subsystems) from data
(instances). By default, the top-level services (CA, DRM, OCSP, RA, TKS,
or TPS) of RHCS 7.2, RHCS 7.3, RHCS 8.0 and the current packages all
generate an initial instance if one does not already exist; this allows
customers to update individual packages without removing any data. I
believe that this default would appear to conflict with packaging
guidelines.

The data portion of CS is controlled exclusively by the pki-setup
package (specifically the pkicreate and pkiremove scripts).

As a simple work-around, set the environment variable
"DONT_RUN_PKICREATE" prior to installing one of the top-level services
(CA, DRM, OCSP, RA, TKS, or TPS). To install an initial instance
manually, follow the instructions located at
http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/index.html. 

Then John Dennis <jdennis at redhat.com> wrote:

Setting special environment variables prior to an rpm install is not permitted.
It must be possible to install, uninstall, and install again using exclusively
the defined rpm commands "rpm -i" and "rpm -e" respectively.

An rpm install is only about laying files down in the file system and possibly
registering those files if necessary. An rpm install generally does not involve
the execution of any of the packages components. Running pkicreate
unconditionally in the %post section is not correct, it doesn't even check for
the install vs. upgrade case (testing $1) which is the defined way to handle
the situation you're trying to compensate for with DONT_RUN_PKICREATE. Please
see https://fedoraproject.org/wiki/Packaging:ScriptletSnippets.

Irrespective of when pkicreate is executed an rpm uninstall operation cannot
leave the system in a state where a subsequent install will fail.

The spec file is not following the init script guidelines found here:
https://fedoraproject.org/wiki/Packaging/SysVInitScript

Some of what pkicreate is doing is supposed to be done in the spec file, not an
external script (this is compounded by calling pkicreate at the wrong time,
e.g. during upgrade). Some of the execution logic in pkicreate is supposed to
be in the spec file and explicitly controlled by the scriplet $1 argument (e.g.
calling chkconfig, etc.). Some of what pkicreate is doing is supposed to be
postponed to a manual step performed by the user *after* installing the
package. Finally the problems are exacerbated by not properly tracking the
files belonging to the package.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.