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@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jdennis@xxxxxxxxxx --- Comment #10 from John Dennis <jdennis@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review