Hi all, I have rebased all the previous patches against master, and have squashed them all into a single patch. Its a large patch, but as many folks have already reviewed the constituent precursor patches, most if it should be familiar and easier to review. The main difference with what was specified before is that the DRM database is installed as a subtree to o=ipaca. This means that no new replication agreements will be needed to replicate DRM data. Replication agreements set up for the Dogtag CA will automatically replicate DRM data. In order for this patch to work, a new 10.2 build of Dogtag 10.2 is needed - with specific changes to allow the ability to install a database as a subtree of an existing tree. At this time, these changes have not yet been checked into the dogtag source. You can obtain such a build from: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/ Please review, Thanks, Ade
On 7/14/2014 4:45 AM, Ade Lee wrote:
Hi all,
I have rebased all the previous patches against master, and have squashed them all into a single patch. Its a large patch, but as many folks have already reviewed the constituent precursor patches, most if it should be familiar and easier to review.
The main difference with what was specified before is that the DRM database is installed as a subtree to o=ipaca. This means that no new replication agreements will be needed to replicate DRM data. Replication agreements set up for the Dogtag CA will automatically replicate DRM data.
In order for this patch to work, a new 10.2 build of Dogtag 10.2 is needed - with specific changes to allow the ability to install a database as a subtree of an existing tree. At this time, these changes have not yet been checked into the dogtag source. You can obtain such a build from:
http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/
Please review,
Thanks, Ade
Some comments/questions: 1. The suffix for the DRM is o=ipadrm,o=ipaca. It's probably better to change it to ou=drm,o=ipaca since another "ipa" under o=ipaca would be redundant. In the future we might want to migrate the current CA entries into ou=ca,o=ipaca subtree so that ou=ca and ou=drm will be at the same level, and keep o=ipaca as the parent tree for Dogtag subsystems. Alternatively, we probably could merge o=ipaca and o=ipadrm since the structure of each tree seems to have been designed to share the user and groups, but still maintain separate structure for CA/KRA-specific storage. The current Dogtag probably doesn't support this, but it's a possibility with additional works. 2. If a clone doesn't have DRM installed but it's getting replicated DRM data, is there any concern? 3. The Dogtag dependency should be updated to 10.2. Also the dogtag_version and DOGTAG_VERSION variables are probably not granular enough to detect the minor version. This message should be updated too: Dogtag must be version 10.1 or above to install DRM 4. It's probably unnecessary to override the following methods in CAInstance since they only call the base methods. * enable() * start_instance() * stop_instance() * restart_instance() * http_proxy() 5. The following code in ipaserver/plugins/dogtag.py will no longer work due to a recent change in Dogtag: transport_cert = kraclient.system_certs.get_transport_cert() tcert = transport_cert[ len(pki.CERT_HEADER): len(transport_cert) - len(pki.CERT_FOOTER)] crypto.import_cert( self.transport_nick, base64.decodestring(tcert), "u,u,u") This is how it's used now in drmtest.py: transport_cert = kraclient.system_certs.get_transport_cert() print "Subject DN: " + transport_cert.subject_dn print transport_cert.encoded crypto.import_cert(transport_nick, transport_cert, "u,u,u") 6. The code in ipaserver/install/drminstance.py creates a file /tmp/drm.p12. How long will this file stay in the /tmp folder? Should it be moved into a more permanent location? If it's a temporary file, can we use the python tempfile module? -- Endi S. Dewata
Ade Lee wrote:
Hi all,
I have rebased all the previous patches against master, and have squashed them all into a single patch. Its a large patch, but as many folks have already reviewed the constituent precursor patches, most if it should be familiar and easier to review.
The main difference with what was specified before is that the DRM database is installed as a subtree to o=ipaca. This means that no new replication agreements will be needed to replicate DRM data. Replication agreements set up for the Dogtag CA will automatically replicate DRM data.
In order for this patch to work, a new 10.2 build of Dogtag 10.2 is needed - with specific changes to allow the ability to install a database as a subtree of an existing tree. At this time, these changes have not yet been checked into the dogtag source. You can obtain such a build from:
http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/
Please review,
The BuildRequires needs to be updated to avoid a bunch of lint errors: ./make-lint ************* Module ipaserver.plugins.dogtag ipaserver/plugins/dogtag.py:249: [E0611(no-name-in-module), ] No name 'crypto' in module 'pki') ipaserver/plugins/dogtag.py:250: [E0611(no-name-in-module), ] No name 'key' in module 'pki') ipaserver/plugins/dogtag.py:251: [E0611(no-name-in-module), ] No name 'kra' in module 'pki') ipaserver/plugins/dogtag.py:1952: [E1101(no-member), drm._setup] Instance of 'PKIConnection' has no 'set_authentication_cert' member) ipaserver/plugins/dogtag.py:1963: [E1101(no-member), drm._setup] Module 'pki' has no 'CERT_HEADER' member) ipaserver/plugins/dogtag.py:1964: [E1101(no-member), drm._setup] Module 'pki' has no 'CERT_FOOTER' member) ************* Module ipaserver.install.dogtaginstance ipaserver/install/dogtaginstance.py:71: [E1101(no-member), get_security_domain] Instance of 'SecurityDomainClient' has no 'get_security_domain_info' member) I forget what back and forth we had on DRM vs no DRM by default, but is it right to have no option at all to add one at install time, ala DNS? My first install failed: Jul 18 15:38:36 ipa.example.com pkidaemon[16516]: ln: failed to create symbolic link ‘/var/lib/pki/pki-tomcat/conf/ca/CS.cfg.bak’: Permission denied Jul 18 15:38:36 ipa.example.com pkidaemon[16516]: SUCCESS: Successfully archived '/var/lib/pki/pki-tomcat/conf/ca/archives/CS.cfg.bak.20140718153836' Jul 18 15:38:36 ipa.example.com pkidaemon[16516]: WARNING: Failed to backup '/var/lib/pki/pki-tomcat/conf/ca/CS.cfg' to '/var/lib/pki/pki-tomcat/conf/ca/CS.cfg.bak'! Jul 18 15:38:36 ipa.example.com pkidaemon[16516]: /usr/share/pki/scripts/operations: line 1579: 0: command not found Jul 18 15:38:36 ipa.example.com systemd[1]: pki-tomcatd@pki-tomcat.service: control process exited, code=exited status=1 Jul 18 15:38:36 ipa.example.com systemd[1]: Failed to start PKI Tomcat Server pki-tomcat. This is due to SELinux issues: type=AVC msg=audit(1405712316.049:1656): avc: denied { setfscreate } for pid=16702 comm="cp" scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=system_u:system_r:pki_tomcat_t:s0 tclass=process type=AVC msg=audit(1405712316.049:1657): avc: denied { relabelfrom } for pid=16702 comm="cp" name="CS.cfg.bak.20140718153836" dev="dm-0" ino=431097 scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file type=AVC msg=audit(1405712316.050:1658): avc: denied { create } for pid=16703 comm="ln" name="CS.cfg.bak" scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=lnk_file I put it into permissive and continued. The installer still references backing up /root/drmcert.p12 but it isn't created by default. The estimate for configuring the DRM seems off. On my VM it took 126 seconds, not 210. Mileage may vary but since my box was the source for all the other timings :-) On the plus side the DRM seems to work. I used the ca-agent cert and was able to follow the steps at https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1... to issue and recover a key. rob
participants (3)
-
Ade Lee -
Endi Sukma Dewata -
Rob Crittenden