Description: The Dogtag PKI System Token Processing System


Spec URL: http://people.redhat.com/kwright/pki-tps/pki-tps.spec
SRPM URL: http://people.redhat.com/kwright/pki-tps/pki-tps-1.3.0-4.fc11.src.rpm

updated spec file and src.rpm:

Spec URL: http://people.redhat.com/kwright/pki-tps/pki-tps.spec
SRPM URL: http://people.redhat.com/kwright/pki-tps/pki-tps-1.3.0-5.fc11.src.rpm

I still see some issues when I removed line
AutoReqProv:    no

As

--> Running transaction check
---> Package perl-XML-Parser.i686 0:2.36-6.fc12 set to be updated
---> Package pki-tps.i686 0:1.3.0-4.fc12 set to be updated
--> Processing Dependency: perl(..::sow/cfg.pl) for package: pki-tps-1.3.0-4.fc12.i686
--> Processing Dependency: perl(.::cfg.pl) for package: pki-tps-1.3.0-4.fc12.i686
--> Finished Dependency Resolution
pki-tps-1.3.0-4.fc12.i686 from /pki-tps-1.3.0-4.fc12.i686 has depsolving problems
  --> Missing Dependency: perl(..::sow/cfg.pl) is needed by package pki-tps-1.3.0-4.fc12.i686 (/pki-tps-1.3.0-4.fc12.i686)
pki-tps-1.3.0-4.fc12.i686 from /pki-tps-1.3.0-4.fc12.i686 has depsolving problems
  --> Missing Dependency: perl(.::cfg.pl) is needed by package pki-tps-1.3.0-4.fc12.i686 (/pki-tps-1.3.0-4.fc12.i686)


When I checked this issue on google, I see http://www.redhat.com/docs/manuals/cert-system/8.0/admin/html/System_Passwords.html#running-without-the-password.conf-file and there "12.3.3.3. Configuring Existing TPS Instances to Prompt for Passwords" and step 6 suggests
--------------------------------------------------------
the primary change is to replace any relative file paths with full paths. For example, replace this line:

require "./cfg.pl"

With:

require "/var/lib/pki-tps/cgi-bin/sow/cfg.pl"
-----------------------------------------------------------

So, I wonder if we need same and patch the source?

But then I see cfg.pl is not getting installed.

What you are alluding to cannot be done, as "/var/lib/pki-tps/cgi-bin/sow/cfg.pl" refers to an "instance-specific" path that is not generated until an instance is created.

However, I am currently working on a fix to be able to remove "AutoReqProv:    no" from the pki-tps.spec file.

What will be needed is that the following two lines:

    require "../sow/cfg.pl";
    require "./cfg.pl";

will need to be replaced by "slot" variables whose values are filled in during instance creation in the "pkicreate" script (which is part of the "pki-setup" package).  In this case, the entire line will be substituted in, so the automated requirement and provision processing performed by '/usr/lib/rpm/perl.req' and '/usr/lib/rpm/perl.prov' can be turned back on, and the explicit 'perl' Requires may be removed from the 'pki-tps.spec' file.

A couple thoughts here, bearing in mind that it's been a while since I've reviewed a hardcore non-perl package, so I'm liable to miss something :)  In arch-specific dir/paths referenced below I'll be using the 64-bit variants, as that's the machine I'm working on right now.

* In %build, make is called w/o options, not as "make %{?_smp_mflags}".  Any reason we can't include this?  (e.g. "build breaks when run in parallel")

* It looks like you're installing some sort of web-app as well as apache modules, but there don't appear to be any config files installed where apache can find them.

* Given that this is a binary (that is, arch-specific) package, disabling auto req/provides is not a good idea, as shlib / perl requires (at the least) need to be picked up and honored.  You're installing shlibs in a system path (/usr/lib64) and a private path (/usr/lib64/httpd/modules).  AutoReq/prov off in this situation is not permitted.

* You're also packaging a bunch of perl pakcages _outside_ perl's standard library path (aka @INC).  Perl provides coming from directories outside @INC need to be filtered out, one cannot simply "use" them w/o specifying the path.  Requires coming from directories outside of @INC _are_ valid unless they're private reqs that are part of that same package (e.g. perl(Parse::RecDescent) is a valid req of this package, but perl(PKI::TPS::CAInfoPanel) is not.)

Essentially: perl(PKI*) needs to be filtered from both requires and provides, perl(*::cfg.pl) as well.

* And speaking of perl(*::cfg.pl) -- this must be flitered, in any form.  This is not a valid system-wide dependency that can be managed by rpm: no package will ever provide it.

* You're stripping symbols out of shlibs and binaries manually, rather than letting the debuginfo package generation process handle it.  Is the automatic process inadequate in some way?  If not, why not let the automatic process do it?

Updates spec file and src.rpm:

Spec URL:  http://people.redhat.com/kwright/pki-tps/pki-tps.spec
SRPM URL:  http://people.redhat.com/kwright/pki-tps/pki-tps-1.3.0-7.fc11.src.rpm

The spec file and SRPM posted in Comment 9 attempts to address the issues raised by Comment #3 and Comment #6.

Chris Thanks for your help here.

Review:
+ package builds in mock (rawhide i686).
koji Build =>http://koji.fedoraproject.org/koji/taskinfo?taskID=1960544
+ rpmlint is silent for SRPM and for RPM.
+ source files match upstream url (sha1sum)
dc16095b91c96d7257328ce4b29423f173c25c9e  pki-tps-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.
+ no headers or static libraries.
+ no .pc file present.
+ -devel subpackage
+ no .la files.
+ no translations are available
+ Does owns the directories it creates.
+ initscripts scriptlets present.
+ no duplicates in %files.
+ file permissions are appropriate.

Like Chris asked can we know how apache uses these conf files?
/usr/share/pki/tps/conf/CS.cfg
/usr/share/pki/tps/conf/httpd.conf
/usr/share/pki/tps/conf/nss.conf
/usr/share/pki/tps/conf/perl.conf

The following files:

    /usr/share/pki/tps/conf/CS.cfg
    /usr/share/pki/tps/conf/httpd.conf
    /usr/share/pki/tps/conf/nss.conf
    /usr/share/pki/tps/conf/perl.conf

are NOT used directly by Apache at all.

Basically, they are used as "templates" that contain both fixed and substituted values whenever an "instance" of 'pki-tps' is created by the "pkicreate" program (which is part of the "pki-setup" runtime dependency used to create all six different types of Dogtag PKI subsystems - CA, KRA, OCSP, TKS, RA, and TPS).  

CA, KRA, OCSP, and TKS are created as instances of "Tomcat", while RA and TPS are created as instances of Apache.

Note that many instances of a given Dogtag PKI subsystem may be generated, and each need to contain their own unique name (and configuration files) - for example, 'pki-tps', 'pki-tps1', 'pki-tps2', etc.

For example, when creating an initial default instance of PKI TPS called 'pki-tps', the following command may be run:

pkicreate -pki_instance_root=/var/lib        \
          -pki_instance_name=pki-tps         \
          -subsystem_type=tps                \
          -secure_port=7889                  \
          -non_clientauth_secure_port=7890   \
          -unsecure_port=7888                \
          -user=pkiuser                      \
          -group=pkiuser                     \
          -redirect conf=/etc/pki-tps        \
          -redirect logs=/var/log/pki-tps    \
          -verbose

This will cause these template files to be filled with initial appropriate values for the 'pki-tps' instance being created.  In this example, these "instance" configuration files used by Apache will be stored under the following names:

    /etc/pki-tps/CS.cfg
    /etc/pki-tps/httpd.conf
    /etc/pki-tps/nss.conf
    /etc/pki-tps/perl.conf

More values will be changed in the "CS.cfg" file once this 'pki-tps' instance has been configured.

For all PKI TPS instances, start/stop/status control of this Apache module will be managed by the master '/etc/init.d/pki-tpsd' file utilizing these instance-specific configuration files (e. g. - service pki-tpsd status pki-tps).

Thanks for brief reply.

Package APPROVED.

New Package CVS Request
=======================
Package Name: pki-tps
Short Description: The Dogtag PKI Token Processing System
Owners: kwright
Branches: F-11, F-12, EL-5
InitialCC: ausil

CVS done (by process-cvs-requests.py).

pki-tps-1.3.0-7.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/pki-tps-1.3.0-7.fc11

pki-tps-1.3.0-7.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/pki-tps-1.3.0-7.fc12

pki-tps-1.3.0-7.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/pki-tps-1.3.0-7.el5

pki-tps-1.3.0-7.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

pki-tps-1.3.0-7.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.