Bug 498123 - Unable to Format a token after a tks clone is created.
Unable to Format a token after a tks clone is created.
Status: CLOSED ERRATA
Product: Dogtag Certificate System
Classification: Community
Component: ESC (Show other bugs)
unspecified
All Linux
urgent Severity medium
: ---
: ---
Assigned To: Jack Magne
Chandrasekar Kannan
:
Depends On:
Blocks: 443788
  Show dependency treegraph
 
Reported: 2009-04-28 20:26 EDT by Asha Akkiangady
Modified: 2015-01-04 18:38 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-22 19:34:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tps-debug log attached (308.38 KB, text/plain)
2009-04-28 20:26 EDT, Asha Akkiangady
no flags Details
Screenshot of ESC application throwing error 41 for a format after a tks clone creation. (821.07 KB, image/png)
2009-04-28 20:33 EDT, Asha Akkiangady
no flags Details
tps-debug.log for the token enrollment. (225.31 KB, text/plain)
2009-04-29 13:03 EDT, Asha Akkiangady
no flags Details
tks debug log for the enrollment. (12.15 KB, text/plain)
2009-04-29 13:04 EDT, Asha Akkiangady
no flags Details
ca debug log for the enrollment. (31.72 KB, text/plain)
2009-04-29 13:05 EDT, Asha Akkiangady
no flags Details
tks debug log for the format operation. (14.91 KB, text/plain)
2009-04-29 13:38 EDT, Asha Akkiangady
no flags Details
Patch to fis this issue. (4.34 KB, patch)
2009-06-04 20:49 EDT, Jack Magne
no flags Details | Diff
Spec files. (4.34 KB, patch)
2009-06-05 15:43 EDT, Jack Magne
no flags Details | Diff

  None (edit)
Description Asha Akkiangady 2009-04-28 20:26:34 EDT
Created attachment 341676 [details]
tps-debug log attached

Description of problem:
After creating a tks clone, formatting a token throws error 41., Failed to update smart card database.

Version-Release number of selected component (if applicable):
cs 8.0

How reproducible:


Steps to Reproduce:
1. On RHEL 5.3, 64 bit installed the latest  CS 8.0 build for all the
components (CA, OCSP, KRA, RA, TKS and TPS).

2. On the same host, Installed redhat-ds ( Source RPM:
redhat-ds-8.1.0-1.el5dsrv.src.rpm) and configured with default port 389.

3. Configure all the cs instances.

4. In ESC client enrolled a security officer token. Enrolled and formatted a user token, works fine.

5. On the same host executed setup-ds-admin.pl and created another slapd
instance and configured at port 12979.

6. pkicreate a tks instance to  create the tks clone.
 pkicreate -pki_instance_root=/var/lib  -subsystem_type=tks -pki_instance_name=pki-tks-2 -agent_secure_port=10846 -ee_secure_port=10847  -admin_secure_port=10848 -unsecure_port=10183 -tomcat_server_port=20013 -verbose

7. Configure the tks instance by joining the existing security domain and select
'Clone an existing tks Subsystem' and provide the details. Enter the database details of the second slapd instance running at port 12979. restart tks.

8. In ESC, Enroll a user token., works fine. Format the same token.

Actual results:

 ESC throws error 41., Failed to update smart card database.

Expected results:

Format operation complete.

Additional info:
Comment 1 Asha Akkiangady 2009-04-28 20:33:16 EDT
Created attachment 341677 [details]
Screenshot of ESC application throwing error 41 for a format after a tks clone creation.
Comment 2 Chandrasekar Kannan 2009-04-29 08:40:06 EDT
could you attach all the relevant tps/tks/ca debug logs ?
Comment 3 Asha Akkiangady 2009-04-29 13:01:46 EDT
In step #8 enroll a user token, esc indicates that enrollment is complete and smart card has the right certs., but tps agent does not show the details of the enrollment for the token.
Comment 4 Asha Akkiangady 2009-04-29 13:03:12 EDT
Created attachment 341789 [details]
tps-debug.log for the token enrollment.
Comment 5 Asha Akkiangady 2009-04-29 13:04:08 EDT
Created attachment 341793 [details]
tks debug log for the enrollment.
Comment 6 Asha Akkiangady 2009-04-29 13:05:03 EDT
Created attachment 341794 [details]
ca debug log for the enrollment.
Comment 7 Asha Akkiangady 2009-04-29 13:38:11 EDT
Created attachment 341798 [details]
tks debug log for the format operation.
Comment 8 Asha Akkiangady 2009-04-29 13:44:09 EDT
No messages in CA debug log for the format operation.
Comment 9 Jack Magne 2009-04-30 20:01:51 EDT
I'll take this first and have a look.
Comment 10 Jack Magne 2009-04-30 20:44:29 EDT
Could we have the tps-debug log for the misfired format operation? This appears to be the main thrust of this bug..
Comment 11 Asha Akkiangady 2009-05-01 12:28:45 EDT
tps-debug log for format operation is the first attachment in the description:

"Created an attachment (id=341676) [details]
tps-debug log attached"
Comment 12 Asha Akkiangady 2009-05-01 12:59:19 EDT
In Steps to Reproduce #3 when I configured tps instance used database for the user certs with baseDN=dc=escusers,dc=redhat,dc=com. For this purpose using redhat-idm-console created a New Sub Suffix dc=escusers in dc=redhat,dc=com. Created a user in the database with this baseDN.
Comment 13 Jack Magne 2009-06-03 21:51:43 EDT
Amazing.

After setting this all up. I was able to reproduce this:

Here is the error when ldap is trying to update the token:

op=58 RESULT err=65 

This appears to be some sort of schema violation.
Comment 14 Jack Magne 2009-06-03 22:06:28 EDT
Just for fun I tried using the console to manually alter one of the existing token records. It gave me this:

Object class violation; unknown object class "tokenRecord"
Comment 15 Jack Magne 2009-06-04 17:09:10 EDT
After further investigation and assistance from Nathan:

1. This is an issue if the TPS subtree is on the same instance of DS with the TKS subtree to be cloned.

2. When the cloning is done, the schema entries added to the master instance are being lost. The schema having to do with the tokendb at the least are lost. This appears to be a side effect of the clone setup with the replication agreement et all.

3. I would suspect that would be an issue with the cloning of ANY other subsystem that resides on the same DS instance with the TPS tokendb data.

4. It remains to be seen what else could be getting blown away.
Comment 16 Jack Magne 2009-06-04 20:48:08 EDT
OK:

After further research, I found that when a Multi Master Replication agreement is created, there is also a schema agreement between the two. In this scenario, the last master to update it's schema will cause a sync between the changed master and the original master. If the original master had schema that it wanted to keep, it would be out of luck.

The problem is in the DataBase panel of the wizard for the Java subsystems. It appears that the file "schema.ldif" is sent to the database regardless of whether or not the database in question belongs to a clone. Hence the problem. The subsequent patch will simply resolve this issue.

It involves only sending the schema ldif to the database in the case that a clone is not being done. In the case of the clone, the schema from the original master will be sent to the new master through normal schema replication.

Patch to follow:
Comment 17 Jack Magne 2009-06-04 20:49:02 EDT
Created attachment 346598 [details]
Patch to fis this issue.
Comment 18 Jack Magne 2009-06-05 15:43:52 EDT
Created attachment 346707 [details]
Spec files.
Comment 19 Ade Lee 2009-06-05 16:25:09 EDT
alee +
Comment 20 Jack Magne 2009-06-05 17:16:09 EDT
Sending        base/ca/shared/conf/CS.cfg
Sending        base/common/src/com/netscape/cms/servlet/csadmin/DatabasePanel.java
Sending        base/kra/shared/conf/CS.cfg
Sending        base/ocsp/shared/conf/CS.cfg
Sending        base/tks/shared/conf/CS.cfg
Sending        dogtag/ca/pki-ca.spec
Sending        dogtag/common/pki-common.spec
Sending        dogtag/kra/pki-kra.spec
Sending        dogtag/ocsp/pki-ocsp.spec
Sending        dogtag/tks/pki-tks.spec
Transmitting file data ..........
Committed revision 554.

Note You need to log in before you can comment on or make changes to this bug.