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:
Created attachment 341677 [details] Screenshot of ESC application throwing error 41 for a format after a tks clone creation.
could you attach all the relevant tps/tks/ca debug logs ?
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.
Created attachment 341789 [details] tps-debug.log for the token enrollment.
Created attachment 341793 [details] tks debug log for the enrollment.
Created attachment 341794 [details] ca debug log for the enrollment.
Created attachment 341798 [details] tks debug log for the format operation.
No messages in CA debug log for the format operation.
I'll take this first and have a look.
Could we have the tps-debug log for the misfired format operation? This appears to be the main thrust of this bug..
tps-debug log for format operation is the first attachment in the description: "Created an attachment (id=341676) [details] tps-debug log attached"
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.
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.
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"
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.
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:
Created attachment 346598 [details] Patch to fis this issue.
Created attachment 346707 [details] Spec files.
alee +
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.