Description of problem: pkiremove uses the parameter pkiremove.cert.subsystem.nickname to read in the nickname of the subsystem cert. This is used when pkiremove contacts the security domain to remove the instance entry, Many changes have happened to the subsystem nickname, though - including the ability to modify the nickname - and this parameter has not been updated during the server install. It makes much more sense to modify pkiremove to use existing (and updated) parameters for the subsystem cert - even if they are different for each subsystem. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 491392 [details] patch to fix
Comment on attachment 491392 [details] patch to fix CAVEAT: Make changes discussed on phone call.
8.1: -bash-3.2$ svn ci -m "Bugzilla BZ 694569: parameter used by pkiremove not updated" ra/lib/perl/PKI/RA/NamePanel.pm tps/lib/perl/PKI/TPS/ImportAdminCertPanel.pm setup/pkiremove Sending ra/lib/perl/PKI/RA/NamePanel.pm Sending setup/pkiremove Sending tps/lib/perl/PKI/TPS/ImportAdminCertPanel.pm Transmitting file data ... Committed revision 1953.
Created attachment 491495 [details] patch to fix tps security domain removal Now that we have more robust error reporting on the action of updateDomainXML in pkiremove, it became clear that we were not removing the admin user correctly for the tps. This small patch fixes this.
8.1: svn ci -m "Bugzilla BZ694569: pkiremove parameter not updated - additional fix" common/src/com/netscape/cms/servlet/csadmin/UpdateDomainXML.java Sending common/src/com/netscape/cms/servlet/csadmin/UpdateDomainXML.java Transmitting file data . Committed revision 1957. tip: [vakwetu@dhcp231-121 base]$ svn ci -m "Bugzilla BZ694569: pkiremove parameter not updated - additional fix" common/src/com/netscape/cms/servlet/csadmin/UpdateDomainXML.java Sending common/src/com/netscape/cms/servlet/csadmin/UpdateDomainXML.java Transmitting file data . Committed revision 1958.
Created attachment 491582 [details] additional ra changes
Created attachment 492466 [details] patch for tip
tip: [vakwetu@dhcp231-121 base]$ svn ci -m "Bugzilla BZ 694569 - parameter used by pkiremove not updated" Sending base/ra/lib/perl/PKI/RA/NamePanel.pm Sending base/setup/pkiremove Sending base/tps/lib/perl/PKI/TPS/ImportAdminCertPanel.pm Transmitting file data ... Committed revision 1964.
Ade/Matt, can you provide a little bit more detail here for verifying this?
The pkiremove script is supposed to contact the security domain and remove the system's entry. This was not happening for the tps - because the subsystem certificate was not being correctly identified. After this fix, if you remove aTPS and RA subsystem usign pkiremove, the script should correctly contact the security domain and remove the entry from the security domain. You can confirm this by doing an ldapsearch on the security domain before and after running pkiremove.
Hi Ade Pkiremove script now removes the TPS subsystem entry from security domain but while verifying i observed that for RA Subsystems there is no Subsystem entry in security domain. (1)TPS entry in security domain # 4808756475213225084, sessions, Security Domain, cs81box.pnq.redhat.com-pki- ca dn: cn=4808756475213225084,ou=sessions,ou=Security Domain,dc=cs81box.pnq.redha t.com-pki-ca objectClass: top objectClass: securityDomainSessionEntry cn: 4808756475213225084 host: 10.65.201.207 uid: admin cmsUserGroup: Enterprise TPS Administrators dateOfCreate: 1305623395798 # cs81box.pnq.redhat.com:7889, TPSList, Security Domain, cs81box.pnq.redhat.c om-pki-ca dn: cn=cs81box.pnq.redhat.com:7889,cn=TPSList,ou=Security Domain,dc=cs81box.pn q.redhat.com-pki-ca objectClass: top objectClass: pkiSubsystem cn: cs81box.pnq.redhat.com:7889 host: cs81box.pnq.redhat.com SecurePort: 7889 DomainManager: false Clone: false SubsystemName: Token Processing System (2)RA entry in Security Domain # 7113365545046929316, sessions, Security Domain, cs81box.pnq.redhat.com-pki- ca dn: cn=7113365545046929316,ou=sessions,ou=Security Domain,dc=cs81box.pnq.redha t.com-pki-ca objectClass: top objectClass: securityDomainSessionEntry cn: 7113365545046929316 host: 10.65.201.207 uid: admin cmsUserGroup: Enterprise RA Administrators dateOfCreate: 1305625854385 So in case of RA subsystem only Session entry (objectClass: securityDomainSessionEntry) is there and not the System entry (objectClass: pkiSubsystem). is this expected behaviour?
No that is a bug. Please file a bug against the RA Installation wizard,
Verified. RHEL Version: Red Hat Enterprise Linux Server release 5.6 (Tikanga) RHCS Version: [root@cs81box ~]# rpm -qa|grep pki-|sort pki-ca-8.1.0-5.el5pki pki-common-8.1.0-10.el5pki pki-common-javadoc-8.1.0-10.el5pki pki-console-8.1.0-3.el5pki pki-java-tools-8.1.0-3.el5pki pki-java-tools-javadoc-8.1.0-3.el5pki pki-kra-8.1.0-5.el5pki pki-migrate-8.1.0-2.el5pki pki-native-tools-8.1.0-2.el5pki pki-ocsp-8.1.0-5.el5pki pki-ra-8.1.0-5.el5pki pki-selinux-8.1.0-2.el5pki pki-setup-8.1.0-3.el5pki pki-silent-8.1.0-2.el5pki pki-tks-8.1.0-5.el5pki pki-tps-8.1.0-10.el5pki pki-util-8.1.0-3.el5pki pki-util-javadoc-8.1.0-3.el5pki redhat-pki-ca-ui-8.1.0-3.el5pki redhat-pki-common-ui-8.1.0-2.el5pki redhat-pki-console-ui-8.1.0-2.el5pki redhat-pki-kra-ui-8.1.0-3.el5pki redhat-pki-ocsp-ui-8.1.0-2.el5pki redhat-pki-ra-ui-8.1.0-2.el5pki redhat-pki-tks-ui-8.1.0-2.el5pki redhat-pki-tps-ui-8.1.0-4.el5pki [root@cs81box ~]# Steps used to verify: (1)Install TPS Subsystem and create an instance of it (2)Perform ldapsearch on security domain for SessionEntry and SystemEntry in Security domain. [root@cs81box ~]# /usr/lib64/mozldap/ldapsearch -p 389 -h cs81box.pnq.redhat.com -D "cn=Directory Manager" -w redhat12 -x -b "ou=Security Domain,dc=cs81box.pnq.redhat.com-pki-ca" objectclass=* dn: cn=-6135793973824525037,ou=sessions,ou=Security Domain,dc=cs81box.pnq.redh at.com-pki-ca objectClass: top objectClass: securityDomainSessionEntry cn: -6135793973824525037 host: 10.65.201.121 uid: admin cmsUserGroup: Enterprise TPS Administrators dateOfCreate: 1306229239642 dn: cn=cs81box.pnq.redhat.com:7889,cn=TPSList,ou=Security Domain,dc=cs81box.pn q.redhat.com-pki-ca objectClass: top objectClass: pkiSubsystem cn: cs81box.pnq.redhat.com:7889 host: cs81box.pnq.redhat.com SecurePort: 7889 DomainManager: false Clone: false SubsystemName: Token Processing System [root@cs81box ~]# (3)Run pkiremove for TPS Subsystem (4)Perform ldapsearch on security domain for TPS subsystem [root@cs81box ~]# /usr/lib64/mozldap/ldapsearch -p 389 -h cs81box.pnq.redhat.com -D "cn=Directory Manager" -w redhat12 -x -b "ou=Security Domain,dc=cs81box.pnq.redhat.com-pki-ca" objectclass=* dn: cn=-6135793973824525037,ou=sessions,ou=Security Domain,dc=cs81box.pnq.redh at.com-pki-ca objectClass: top objectClass: securityDomainSessionEntry cn: -6135793973824525037 host: 10.65.201.121 uid: admin cmsUserGroup: Enterprise TPS Administrators dateOfCreate: 1306229239642 Result: SystemEntry of TPS subsystem from security domain removed. Note:In Case of RA subsystem , SystemEntry was not created for which a bug has been reported https://bugzilla.redhat.com/show_bug.cgi?id=705383. So this is not verified for RA subsystem.