first pass at getting ca-ui into Fedora.
changed title from ca-ui to ca per request from alee.
Spec URL: http://people.redhat.com/kwright/ca/pki-ca.spec SRPM URL: http://people.redhat.com/kwright/ca/pki-ca-1.3.0-1.fc11.src.rpm Description: Dogtag PKI is an enterprise software system designed to manage enterprise Public Key Infrastructure (PKI) deployments. The Dogtag Certificate Authority is a required PKI subsystem which issues, renews, revokes, and publishes certificates as well as compiling and publishing Certificate Revocation Lists (CRLs). The Dogtag Certificate Authority can be configured as a self-signing Certificate Authority (CA), where it is the root CA, or it can act as a subordinate CA, where it obtains its own signing certificate from a public CA.
Is the package pki-ca or ca?
The package name is actually pki-ca. I've changed the title of the bug.
# rpmlint pki-ca-1.3.0-1.fc11.noarch.rpm pki-ca.noarch: E: non-readable /usr/share/pki/ca/conf/CS.cfg 0660 pki-ca.noarch: E: non-standard-dir-perm /usr/share/pki/ca/logs/signedAudit 0770 1 packages and 0 specfiles checked; 2 errors, 0 warnings. EXPLANATION: (1) The 'CS.cfg' file requires a mode of '0660' due to security sensitive information potentially contained within this file; therefore, it must not be viewable by others, and since this package is part of a cross-platform product, it may not rely exclusively upon SELinux access control. (2) Similarly, the 'signedAudit' directory requires a mode of '0770' as this directory, when enabled, contains security sensitive logfiles that must not be viewable by others, and since this package is part of a cross-platform product, it may not rely exclusively upon SELinux access control.
Updated spec and src.rpm files can be found here: Spec URL: http://people.redhat.com/kwright/pki-ca/pki-ca.spec SRPM URL: http://people.redhat.com/kwright/pki-ca/pki-ca-1.3.0-1.fc11.src.rpm
EXPLANATION: It was determined that the special permissions for CS.cfg and the signedAudit directory are in fact enforced when instances of the server are created after the rpm is installed. We do not, therefore, need to deliver these files with non-standard permissions. The current updated packages deliver this file (and directory) with standard permissions, and thus eliminate the rpmlint warnings. Rpmlint output is now clean.
Ugh. The spec file is a mess, too much definitions, too much commented bits and so on. - Is the license statement really necessary? After all, http://fedoraproject.org/wiki/Licensing#License_of_Fedora_SPEC_Files - You have defined %defattr(-,root,root), so there's no need to define %attr(-,root,root) for every single object in %files. - The comment ## Without Requires something, rpmbuild will abort! is nonsense. Rpmbuild will abort if you have an empty Requires: line, but if you don't have any requirements, the package builds fine. - You should drop ## Without AutoReqProv: no, rpmbuild finds all sorts of crazy ## dependencies that we don't care about, and refuses to install AutoReqProv: no
These packages address the issues in #8 - removed license - removed most commented bits - removed some %defines - removed %attr when not needed - removed rpmbuild comment - removed AutoReqProv: Updated spec and src.rpm files can be found here: Spec URL: http://people.redhat.com/kwright/pki-ca/pki-ca.spec SRPM URL: http://people.redhat.com/kwright/pki-ca/pki-ca-1.3.0-2.fc11.src.rpm
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> 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> 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> 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.
Updated spec and src.rpm files can be found here: Spec URL: http://people.redhat.com/kwright/pki-ca/pki-ca.spec SRPM URL: http://people.redhat.com/kwright/pki-ca/pki-ca-1.3.0-3.fc11.src.rpm
using the 1.3 version from subversion one still cannot successfully remove installed rpm's If you try and remove pki components via: rpm -e `rpm -qa pki-\*` It fails with: Shutting down the default instance "/var/lib/pki-ca" PRIOR to uninstalling the "pki-ca" package: This machine is missing all PKI subsystems! error: %preun(pki-ca-1.3.0-3.fc11.noarch) scriptlet failed, exit status 255 The problem seems to be %preun is trying to stop the service but the previously rpm erased the files /usr/bin/{pkiarch,pkiflavor,pkiname} Thus this code in the pki-ca init script causes the init script to abort. if [ ! -x /usr/bin/pkiarch ] || [ ! -x /usr/bin/pkiflavor ] || [ ! -x /usr/bin/pkiname ]; then echo "This machine is missing all PKI subsystems!" exit 255 which then causes %preun to abort, which causes the rpm removal to fail. Also these files are left behind (these are init scripts and the fact they are not removed via rpm -e is a very serious packaging failure) /etc/init.d/pki-ca /etc/init.d/pki-ocsp /etc/init.d/pki-tks /etc/init.d/pki-kra /etc/init.d/pki-ra
The package pki-native-tools is doing a number of bogus things. It installs these executable scripts: /usr/bin/pkiarch /usr/bin/pkidist /usr/bin/pkiflavor /usr/bin/pkihost /usr/bin/pkiname whose job is to echo (hardcoded) configuration information. This is not how we store and query configuration information in Fedora (and RHEL). This information should be located in files under /etc. pkiarch returns 'i386', pkidist returns 'fc11' on my machine, Each of the above executable needs to be removed and replaced with mechanisms appropriate to our distributions (e.g. store the information in a configuration file, marked as %config, and read the information out of that file) and/or use the existing mechanisms to determine the arch, release, etc. If the packages need executables like pkiarch and pkidist then it's an indication of bad packaging practices elsewhere which also will need to be corrected. The package pki-native-tools also installs a symbolic link /usr/bin/pkiperl which points to /usr/bin/perl Then all the perl scripts in all the pki packages have this in their shebang line: #!/usr/bin/pkiperl This also is bad packaging practice. If you need a specific version of perl then that needs to be specified in the spec file so that rpm can resolve those dependencies. Scripts then invoke /usr/bin/perl. Setting up links in /usr/bin to specific versions of interpreters is likely to create all sorts of problems in RPM managed systems.
Notes on this update: * "BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)" is provided because this package must also be made into an EPEL package * "BuildRequires: java-devel >= 1:1.6.0" and "Requires: java >= 1:1.6.0" versions are needed to distinguish our need for OpenJDK rather than libgcj * The "%{_initrddir}/*" macro must be used because this package must also be made into an EPEL package * Several packages may own the "%{_datadir}/pki/" directory, since there are multiple subdirectories (some owned solely by one package) underneath this common directory -- see "https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership" * Mon Dec 7 2009 Matthew Harmsen <mharmsen> 1.3.0-6 - Bugzilla Bug #522210 - Packaging for Fedora Dogtag - Bugzilla Bug #529070 - rpm packaging problems (cannot reinstall correctly) - Removed 'with exceptions' from License * Tue Nov 24 2009 Matthew Harmsen <mharmsen> 1.3.0-5 - Bugzilla Bug #522210 - Packaging for Fedora Dogtag - Use "_javadir" macro when appropriate * Mon Nov 2 2009 Matthew Harmsen <mharmsen> 1.3.0-4 - Bugzilla Bug #522210 - Packaging for Fedora Dogtag - Take ownership of directories Updated spec and src.rpm files can be found here: Spec URL: http://people.redhat.com/kwright/pki-ca/pki-ca.spec SRPM URL: http://people.redhat.com/kwright/pki-ca/pki-ca-1.3.0-4.fc11.src.rpm
pki-common & pki-util now build in rawhide. All dependencies should be satisfied.
re: comment #15, what do you mean built in rawhide? Did you mean to say a scratch build for rawhide? There shouldn't be any dogtag packages in rawhide because this review has not been closed.
John, I just wanted people looking at this to be aware of the fact that the dependencies (Build Requires) pki-common and pki-util had been built in rawhide so they shouldn't be a blocker for this package.
can pki-common and pki-util ever be used without dogtag?
re: comment #18: Currently, Dogtag consists of six distinct servers: * pki-ca (Java/Tomcat) * pki-kra (Java/Tomcat) * pki-ocsp (Java/Tomcat) * pki-ra (Perl/Apache) * pki-tks (Java/Tomcat) * pki-tps (C/C++/Apache) and some associated tools and management: * pki-native-tools (C/C++) * pki-java-tools (Java) * pki-console (Java) The 'pki-util' package contains application specific jar files required by: * pki-ca * pki-kra * pki-ocsp * pki-tks * pki-java-tools * pki-console The 'pki-common' package contains application specific jar files required by: * pki-ca * pki-kra * pki-ocsp * pki-tks
Details about the 'pki-util' package are documented in: * https://bugzilla.redhat.com/show_bug.cgi?id=521989 Details about the 'pki-common' package are documented in: * https://bugzilla.redhat.com/show_bug.cgi?id=522207
I hope Dennis will not mind If I will review this officially. also, I am unable to download SRPM for review.
updated srpm & spec file: Spec URL: http://people.redhat.com/kwright/pki-ca/pki-ca.spec SRPM URL: http://people.redhat.com/kwright/pki-ca/pki-ca-1.3.0-6.fc11.src.rpm
Review: + package builds in mock (rawhide i686). koji Build =>http://koji.fedoraproject.org/koji/taskinfo?taskID=1904607 + rpmlint is silent for SRPM and for RPM. + source files match upstream url (sha1sum) 92ea94f48a39af2776bb274a66f1a5db055dd745 pki-ca-1.3.0.tar.gz + package meets naming and packaging guidelines. + specfile is properly named, is cleanly written + Spec file is written in American English. + Spec file is legible. + dist tag is present. + license is open source-compatible. + License text is included in package. + %doc is present. + BuildRequires are proper. + %clean is present. + package installed properly. + Macro use appears rather consistent. + Package contains code, not content. + no headers or static libraries. + no .pc file present. + no -devel subpackage + no .la files. + no translations are available + Does owns the directories it creates. + initscript scriptlets present. + no duplicates in %files. + file permissions are appropriate. + Not a GUI application APPROVED.
New Package CVS Request ======================= Package Name: pki-ca Short Description: The Dogtag Certificate Authority Owners: kwright Branches: F-11, F-12, EL-5 InitialCC: ausil
cvs done.
pki-ca-1.3.0-6.el5.1 has been pushed to the Fedora EPEL 5 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 pki-ca'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-5/FEDORA-EPEL-2010-0063
pki-ca-1.3.0-6.fc11 has been pushed to the Fedora 11 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 pki-ca'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0486
pki-ca-1.3.0-6.fc12 has been pushed to the Fedora 12 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 pki-ca'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0531