Bug 694569

Summary: parameter used by pkiremove not updated
Product: [Retired] Dogtag Certificate System Reporter: Ade Lee <alee>
Component: Installer (pkicreate/pkiremove)Assignee: Ade Lee <alee>
Status: CLOSED CURRENTRELEASE QA Contact: Chandrasekar Kannan <ckannan>
Severity: unspecified Docs Contact:
Priority: high    
Version: 9.0CC: aakkiang, alee, benl, ksiddiqu
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-04 20:13:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 445047    
Attachments:
Description Flags
patch to fix
mharmsen: review+
patch to fix tps security domain removal
cfu: review+
additional ra changes
none
patch for tip none

Description Ade Lee 2011-04-07 16:37:39 UTC
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:

Comment 1 Ade Lee 2011-04-12 01:55:05 UTC
Created attachment 491392 [details]
patch to fix

Comment 2 Matthew Harmsen 2011-04-12 02:16:51 UTC
Comment on attachment 491392 [details]
patch to fix

CAVEAT:  Make changes discussed on phone call.

Comment 3 Ade Lee 2011-04-12 05:35:05 UTC
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.

Comment 4 Ade Lee 2011-04-12 14:33:14 UTC
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.

Comment 5 Ade Lee 2011-04-12 15:58:54 UTC
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.

Comment 6 Ade Lee 2011-04-12 20:29:02 UTC
Created attachment 491582 [details]
additional ra changes

Comment 9 Ade Lee 2011-04-15 18:10:51 UTC
Created attachment 492466 [details]
patch for tip

Comment 10 Ade Lee 2011-04-15 18:24:08 UTC
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.

Comment 11 Kashyap Chamarthy 2011-05-05 09:55:14 UTC
Ade/Matt, can you provide a little bit more detail here for verifying this?

Comment 12 Ade Lee 2011-05-16 13:47:32 UTC
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.

Comment 13 Kaleem 2011-05-17 09:47:07 UTC
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?

Comment 14 Ade Lee 2011-05-17 14:24:15 UTC
No that is a bug.  Please file a bug against the RA Installation wizard,

Comment 15 Kaleem 2011-05-24 09:25:23 UTC
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.