August 2011 - Pki-devel - Dogtag PKI List Archives

restrictive proxy.conf for ipa
by Ade Lee 25 Aug '11

25 Aug '11

ProxyRequests Off # matches for ee port <LocationMatch "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange"> NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://[PKI_MACHINE_NAME]:[PKI_AJP_PORT]/ ProxyPassReverse ajp://[PKI_MACHINE_NAME]:[PKI_AJP_PORT]/ </LocationMatch> # matches for admin port <LocationMatch "^/ca/admin/ca/getCertChain|^/ca/admin/ca/getConfigEntries|^/ca/admin/ca/getCookie|^/ca/admin/ca/getStatus|^/ca/admin/ca/securityDomainLogin"> NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://[PKI_MACHINE_NAME]:[PKI_AJP_PORT]/ ProxyPassReverse ajp://[PKI_MACHINE_NAME]:[PKI_AJP_PORT]/ </LocationMatch> # matches for agent port and eeca port <LocationMatch "^/ca/agent/ca/displayBySerial|^/ca/agent/ca/doRevoke|^/ca/agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/eeca/ca/profileSubmitSSLClient"> NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient require ProxyPassMatch ajp://[PKI_MACHINE_NAME]:[PKI_AJP_PORT]/ ProxyPassReverse ajp://[PKI_MACHINE_NAME]:[PKI_AJP_PORT]/ </LocationMatch>

2 3

Patch for review - RA user enrollment issue
by Ade Lee 25 Aug '11

25 Aug '11

https://bugzilla.redhat.com/show_bug.cgi?id=733065 In the case of HSM, we were not reading password from password.conf correctly. This simple patch fixes that. Ade

2 1

Proxy/Port work status
by Adam Young 25 Aug '11

25 Aug '11

Had some success earlier today, but I seem to be unable to replicate it. I've been working with the "full" proxy.conf file lately,. and even that seems to be preventing a replica. It is quite possible that the problem is something on one of the two systems, as I've found that install/uninstall often leaves some of the files being owned by non-existent users. At this point, I'm not sure if the patch I've submitted will work on a vanilla system. Testing it has proven to be a pretty time consuming endeavour. Here's what I've gotten it down to: ON One machine, run ipa-server-install -U -r ` hostname | tr '[:lower:]' '[:upper:]'` -p freeipa4all -a freeipa4all --setup-dns --no-forwarders once that succeeds, I have to reset /etc/resolv.conf as the lab DNS server gets removed: cp ~/resolve.conf /etc then ipa-replica-prepare $REPLICA scp /var/lib/ipa/replica-info-$REPLICA.gpg root@$REPLICA: On the replica: ipa-replica-install --setup-ca replica-info-$HOSTNAME.gpg I have firewall off on master and replica At one point I had a replica install that worked with the Proxy, so I know it is possible, but for the last couple of hours this last command has been failing with: creation of replica failed: Configuration of CA failed pkisilent reports the failure in the debug log, but not the URL it is trying to reach. I'm going to modify it to give some more information in the morning. I'm not seeing anything in /var/log/httpd/error|access.log on the master, which is weird. I see this in /var/log/ipareplica-conncheck.log. We should not be trying to do anything in /home/admin 2011-08-24 21:52:18,544 DEBUG stderr= 2011-08-24 21:52:19,521 DEBUG args=/usr/bin/ssh -q -o StrictHostKeychecking=no -o UserKnownHostsFile=/dev/null admin(a)vm-088.idm.lab.bos.redhat.com /usr/sbin/ipa-replica-conncheck --replica vm-116.idm.lab.bos.redhat.com --check-ca 2011-08-24 21:52:19,521 DEBUG stdout=Check connection from master to remote replica 'vm-116.idm.lab.bos.redhat.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos (88): OK PKI-CA: Directory Service port (7389): OK PKI-CA: Agent secure port (9443): OK PKI-CA: EE secure port (9444): OK PKI-CA: Admin secure port (9445): OK PKI-CA: EE secure client auth port (9446): OK PKI-CA: Unsecure port (9180): OK Connection from master to replica is OK. 2011-08-24 21:52:19,522 DEBUG stderr=Could not chdir to home directory /home/admin: No such file or directory Ade Lee noticed that the replica install is failing before it ever attempts to talk to the Master, which corresponds with what I am seeing. I see in the PKI install log that [2011-08-24 22:23:50] [error] FAILED run_command("/sbin/service pki-cad restart pki-ca"), exit status=1 output="Stopping pki-ca: [FAILED] Starting pki-ca: [ OK ]^M" Running this command by hand gets the same output. In less /var/log/pki-ca/catalina.out /var/lib/pki-ca/logs/catalina.out: Permission denied /var/log/pki-ca/catalina.out (END) SO it looks like another cleanup issue.

4 3

Re: [Pki-devel] [Freeipa-devel] [PATCH] 0283-enable-proxy-for-dogtag
by Adam Young 24 Aug '11

24 Aug '11

This version tells pkisilent to use the remote ports for cloning.

1 0

patch for review - Bugzilla Bug #690950 - Update Dogtag Packages for Fedora 15
by Matthew Harmsen 23 Aug '11

23 Aug '11

*Bugzilla Bug #690950* <https://bugzilla.redhat.com/show_bug.cgi?id=690950> - Update Dogtag Packages for Fedora 15 Please review the attached patch: https://bugzilla.redhat.com/attachment.cgi?id=519522&action=diff&context=pa… Thanks, -- Matt

2 1

patch for review : https://bugzilla.redhat.com/show_bug.cgi?id=712931
by Ade Lee 23 Aug '11

23 Aug '11

https://bugzilla.redhat.com/show_bug.cgi?id=712931 - CS requires too many ports to be opened in firewall. This patch provides configuration to run the ca behind an apache proxy. For IPA, once you apply the patch, you will need to update pki-ca, pki-common, pki-setup, pki-selinux, pki-common-javadoc. The UI changes are just to remove some annoying 404's in the httpd logs. Then, you need to call pkicreate with the additional option -enable_proxy. This will configure the system to run behind a proxy with ajp port 9447, proxy secure port 443 and proxy unsecure port 80. Pkisilent can run as before. After pkisilent is complete, the file /etc/<instance_name/conf/proxy.conf will exist. Make a symbolic link of this file to /etc/httpd/conf.d/dogtag.conf Restart httpd and you should be able to browse from httpd. Adam, please test IPA install and also install of a replica. Remember that the replica security domain should be at port 443. Ade

3 4

Re: [Pki-devel] [Freeipa-devel] [PATCH] 0283-enable-proxy-for-dogtag
by Adam Young 23 Aug '11

23 Aug '11

With this version, and Ade's patch posted to the PKI list, we have a functioning proxy. I still need to do some cleanup in the /etc/httpd/conf.d directory: the modifications to nss.conf are not removed in uninstall, nor is the symlink to /etc/pki-ca/proxy.conf. We also need to limit the number of suburls of the PKI CA that the proxy exposes. This version exposes all of the. I think we need a very limited subset. I've created a replica --no-pki and successfully requested a certificate on it. On 08/19/2011 01:57 PM, Dmitri Pal wrote: > On 08/19/2011 01:19 PM, Adam Young wrote: >> The complete solution for this patch requires changes in Dogtag that >> Ade Lee is working on right now. In order to test, I have provided a >> couple of files that I have been using: >> >> >> 1. Apply patch, build and install IPA rpms, run ipaserver-install as >> per usual. >> 2. Move the dogtag.conf file into /etc/httpd/conf.d directorys >> 3. Run the proxy_dogtag.py script to modify the Dogtag instance to >> accept AJP connections from httpd so httpd can act as a proxy >> 4. Restart IPA >> >> >> To test: >> >> 1. add a host. >> 2. Generate a csr: >> http://freeipa.org/page/Certificate_Authority#Request_a_certificate >> 3. request a certificate for the newly added host. >> 4. Optionally, Revoke the certificate for the host >> > > > Please do not forget to test the proxy test when replica does not have > the CA installed and has to forward the request to the one that has. > >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel(a)redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel

1 0

[PATCH] 0283-enable-proxy-for-dogtag
by Adam Young 19 Aug '11

19 Aug '11

The complete solution for this patch requires changes in Dogtag that Ade Lee is working on right now. In order to test, I have provided a couple of files that I have been using: 1. Apply patch, build and install IPA rpms, run ipaserver-install as per usual. 2. Move the dogtag.conf file into /etc/httpd/conf.d directorys 3. Run the proxy_dogtag.py script to modify the Dogtag instance to accept AJP connections from httpd so httpd can act as a proxy 4. Restart IPA To test: 1. add a host. 2. Generate a csr: http://freeipa.org/page/Certificate_Authority#Request_a_certificate 3. request a certificate for the newly added host. 4. Optionally, Revoke the certificate for the host

1 1

Auth failure setting up the mod Proxy ajp
by Adam Young 18 Aug '11

18 Aug '11

I've made the same changes as I did last night, modulo that I've attempted to modify the IPA files in the repo and deploy them to the IPA server. However, when I attempt to talk to the server I get the following error. I suspect that I have mod_auth_proxy using the wrong port, based on the message at the top. THese are the ports I'm using + ('ca_port', 80), + ('ca_agent_port', 443), + ('ca_ee_port', 443), I'm using the dogtag.conf file you posted last night, which has everything going to ProxyPassMatch ajp://127.0.0.1:8009/ ProxyPassReverse ajp://127.0.0.1:8009/ server.xml has <Connector port="8009" protocol="AJP/1.3" redirectPort="9444" /> All filters are disabled in web.xml Restarted server ( a couple times). I've tried enabling basic auth instead of using Kerberos, but that seems to make no difference, although it does make me wonder about how we are going to pass authentication through in the future. here's the error from the debug log [17/Aug/2011:22:56:33][TP-Processor8]: com.netscape.cms.servlet.filter.EERequestFilter: Use HTTPS port '9444' instead of '443' when performing EE tasks! [17/Aug/2011:22:56:33][TP-Processor8]: Filter is disabled .. continuing [17/Aug/2011:22:56:33][TP-Processor8]: CMSServlet:service() uri = //ca/ee/ca/profileSubmitSSLClient [17/Aug/2011:22:56:33][TP-Processor8]: CMSServlet::service() param name='cert_request_type' value='pkcs10' [17/Aug/2011:22:56:33][TP-Processor8]: CMSServlet::service() param name='cert_request' value='-----BEGIN CERTIFICATE REQUEST----- MIIBbzCB2QIBADAwMS4wLAYDVQQDEyVncmFtcGEuYXlvdW5nLmJvc3Rvbi5kZXZl bC5yZWRoYXQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1+Igq1HNT V2Q35EBq8RoDTQxu+Hfquv8jDyLqlvw6O5sDnIldR0JnvJjZBYZS2TFyi2U1hXxJ zSg3xhM/7UF9TVerC7HIqRtXo1EPrzxfQZwOWOsZewtQc/cPCkLP4gz9rFXVtBwq z363YoKJIuXpNTeQyqAvYHTyeRvAth+xswIDAQABoAAwDQYJKoZIhvcNAQEFBQAD gYEARnikLtPQIAkfjDR5P/nNsTNjwMeGTxizPrt0e5uKaOTL+gsV747bYdRKL96G 11RPEtD1VwvuHbS4ao43oJ4gqOMsxWSXM4h1QcMF0Qz30G6ddobFTWh0XfRL32Dh 4cOxVGMp2IocJvi9VutQVZkwv7NO2GQ52yvZWgzNDdRKujY= -----END CERTIFICATE REQUEST-----' [17/Aug/2011:22:56:33][TP-Processor8]: CMSServlet::service() param name='xml' value='true' [17/Aug/2011:22:56:33][TP-Processor8]: CMSServlet::service() param name='profileId' value='caIPAserviceCert' [17/Aug/2011:22:56:33][TP-Processor8]: CMSServlet: caProfileSubmitSSLClient start to service. [17/Aug/2011:22:56:33][TP-Processor8]: xmlOutput true [17/Aug/2011:22:56:33][TP-Processor8]: Start of ProfileSubmitServlet Input Parameters [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet Input Parameter cert_request_type='pkcs10' [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet Input Parameter cert_request='-----BEGIN CERTIFICATE REQUEST----- MIIBbzCB2QIBADAwMS4wLAYDVQQDEyVncmFtcGEuYXlvdW5nLmJvc3Rvbi5kZXZl bC5yZWRoYXQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1+Igq1HNT V2Q35EBq8RoDTQxu+Hfquv8jDyLqlvw6O5sDnIldR0JnvJjZBYZS2TFyi2U1hXxJ zSg3xhM/7UF9TVerC7HIqRtXo1EPrzxfQZwOWOsZewtQc/cPCkLP4gz9rFXVtBwq z363YoKJIuXpNTeQyqAvYHTyeRvAth+xswIDAQABoAAwDQYJKoZIhvcNAQEFBQAD gYEARnikLtPQIAkfjDR5P/nNsTNjwMeGTxizPrt0e5uKaOTL+gsV747bYdRKL96G 11RPEtD1VwvuHbS4ao43oJ4gqOMsxWSXM4h1QcMF0Qz30G6ddobFTWh0XfRL32Dh 4cOxVGMp2IocJvi9VutQVZkwv7NO2GQ52yvZWgzNDdRKujY= -----END CERTIFICATE REQUEST-----' [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet Input Parameter xml='true' [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet Input Parameter profileId='caIPAserviceCert' [17/Aug/2011:22:56:33][TP-Processor8]: End of ProfileSubmitServlet Input Parameters [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet: start serving [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet: SubId=profile [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet: isRenewal false [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet: profileId caIPAserviceCert [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet: authenticator raCertAuth found [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet:setCredentialsIntoContext() authIds` null [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmistServlet: set Inputs into profile Context [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet: set sslClientCertProvider [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet: authentication required. [17/Aug/2011:22:56:33][TP-Processor8]: CMSServlet: in auditSubjectID [17/Aug/2011:22:56:33][TP-Processor8]: CMSServlet: auditSubjectID auditContext {sslClientCertProvider=com.netscape.cms.servlet.profile.SSLClientCertProvider@6a6078e7, profileContext=com.netscape.cms.profile.common.EnrollProfileContext@63a1bc40} [17/Aug/2011:22:56:33][TP-Processor8]: CMSServlet auditSubjectID: subjectID: null [17/Aug/2011:22:56:33][TP-Processor8]: AgentCertAuthentication: start [17/Aug/2011:22:56:33][TP-Processor8]: authenticator instance name is raCertAuth [17/Aug/2011:22:56:33][TP-Processor8]: AgentCertAuthenticator: got provider [17/Aug/2011:22:56:33][TP-Processor8]: AgentCertAuthenticator: retrieving client certificate [17/Aug/2011:22:56:33][TP-Processor8]: AgentCertAuthentication: No SSL Client Certs Found [17/Aug/2011:22:56:33][TP-Processor8]: ProfileSubmitServlet: authentication error Invalid Credential. [17/Aug/2011:22:56:33][TP-Processor8]: SignedAuditEventFactory: create() message=[AuditEvent=AUTH_FAIL][SubjectID=$NonRoleUser$ : Unidentified][Outcome=Failure][AuthMgr=raCertAuth][AttemptedCred=Unidentified] authentication failure [17/Aug/2011:22:56:33][TP-Processor8]: CMSServlet: curDate=Wed Aug 17 22:56:33 EDT 2011 id=caProfileSubmitSSLClient time=32 All the httpd log shows is: [Wed Aug 17 23:04:49 2011] [error] ipa: INFO: sslget 'https://ipa-server-3.ayoung.boston.devel.redhat.com:443/ca/ee/ca/profileSub…' If I enable debugging in NSS I get: [Wed Aug 17 23:11:23 2011] [info] Connection to child 4 established (server ipa-server-3.ayoung.boston.devel.redhat.com:443, client 192.168.122.203) [Wed Aug 17 23:11:23 2011] [info] Initial (No.1) HTTPS request received for child 4 (server ipa-server-3.ayoung.boston.devel.redhat.com:443) [Wed Aug 17 23:11:23 2011] [debug] src/mod_auth_kerb.c(1578): [client 192.168.122.203] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos, referer: https://ipa-server-3.ayoung.boston.devel.redhat.com/ipa/ui/ [Wed Aug 17 23:11:23 2011] [debug] src/mod_auth_kerb.c(967): [client 192.168.122.203] Using HTTP/ipa-server-3.ayoung.boston.devel.redhat.com(a)IPA-SERVER-3.AYOUNG.BOSTON.DEVEL.REDHAT.COM as server principal for password verification, referer: https://ipa-server-3.ayoung.boston.devel.redhat.com/ipa/ui/ [Wed Aug 17 23:11:23 2011] [debug] src/mod_auth_kerb.c(671): [client 192.168.122.203] Trying to get TGT for user admin(a)IPA-SERVER-3.AYOUNG.BOSTON.DEVEL.REDHAT.COM, referer: https://ipa-server-3.ayoung.boston.devel.redhat.com/ipa/ui/ [Wed Aug 17 23:11:24 2011] [debug] src/mod_auth_kerb.c(581): [client 192.168.122.203] Trying to verify authenticity of KDC using principal HTTP/ipa-server-3.ayoung.boston.devel.redhat.com(a)IPA-SERVER-3.AYOUNG.BOSTON.DEVEL.REDHAT.COM, referer: https://ipa-server-3.ayoung.boston.devel.redhat.com/ipa/ui/ [Wed Aug 17 23:11:24 2011] [debug] src/mod_auth_kerb.c(1046): [client 192.168.122.203] kerb_authenticate_user_krb5pwd ret=0 user=admin(a)IPA-SERVER-3.AYOUNG.BOSTON.DEVEL.REDHAT.COM authtype=Basic, referer: https://ipa-server-3.ayoung.boston.devel.redhat.com/ipa/ui/ [Wed Aug 17 23:11:25 2011] [error] ipa: INFO: sslget 'https://ipa-server-3.ayoung.boston.devel.redhat.com:443/ca/ee/ca/profileSub…' [Wed Aug 17 23:11:25 2011] [info] Connection to child 6 established (server ipa-server-3.ayoung.boston.devel.redhat.com:443, client 192.168.122.203) [Wed Aug 17 23:11:25 2011] [info] Initial (No.1) HTTPS request received for child 6 (server ipa-server-3.ayoung.boston.devel.redhat.com:443) [Wed Aug 17 23:11:25 2011] [debug] mod_proxy_ajp.c(45): proxy: AJP: canonicalising URL //127.0.0.1:8009//ca/ee/ca/profileSubmitSSLClient [Wed Aug 17 23:11:25 2011] [debug] proxy_util.c(1506): [client 192.168.122.203] proxy: ajp: found worker ajp://127.0.0.1:8009/ for ajp://127.0.0.1:8009//ca/ee/ca/profileSubmitSSLClient [Wed Aug 17 23:11:25 2011] [debug] mod_proxy.c(1015): Running scheme ajp handler (attempt 0) [Wed Aug 17 23:11:25 2011] [debug] mod_proxy_http.c(1963): proxy: HTTP: declining URL ajp://127.0.0.1:8009//ca/ee/ca/profileSubmitSSLClient [Wed Aug 17 23:11:25 2011] [debug] mod_proxy_ajp.c(659): proxy: AJP: serving URL ajp://127.0.0.1:8009//ca/ee/ca/profileSubmitSSLClient [Wed Aug 17 23:11:25 2011] [debug] proxy_util.c(2011): proxy: AJP: has acquired connection for (127.0.0.1) [Wed Aug 17 23:11:25 2011] [debug] proxy_util.c(2067): proxy: connecting ajp://127.0.0.1:8009//ca/ee/ca/profileSubmitSSLClient to 127.0.0.1:8009 [Wed Aug 17 23:11:25 2011] [debug] proxy_util.c(2193): proxy: connected //ca/ee/ca/profileSubmitSSLClient to 127.0.0.1:8009 [Wed Aug 17 23:11:25 2011] [debug] proxy_util.c(2444): proxy: AJP: fam 2 socket created to connect to 127.0.0.1 [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(224): Into ajp_marshal_into_msgb [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[0] [Host] = [ipa-server-3.ayoung.boston.devel.redhat.com] [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[1] [Accept-Encoding] = [identity] [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[2] [Content-Length] = [681] [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[3] [Content-type] = [application/x-www-form-urlencoded] [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[4] [Accept] = [text/plain] [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(450): ajp_marshal_into_msgb: Done [Wed Aug 17 23:11:25 2011] [debug] mod_proxy_ajp.c(265): proxy: APR_BUCKET_IS_EOS [Wed Aug 17 23:11:25 2011] [debug] mod_proxy_ajp.c(270): proxy: data to read (max 8186 at 4) [Wed Aug 17 23:11:25 2011] [debug] mod_proxy_ajp.c(285): proxy: got 681 bytes of data [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(687): ajp_read_header: ajp_ilink_received 04 [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(697): ajp_parse_type: got 04 [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(516): ajp_unmarshal_response: status = 200 [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(537): ajp_unmarshal_response: Number of headers is = 2 [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(599): ajp_unmarshal_response: Header[0] [Content-Type] = [application/xml] [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(609): ajp_unmarshal_response: ap_set_content_type done [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(599): ajp_unmarshal_response: Header[1] [Content-Length] = [134] [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(687): ajp_read_header: ajp_ilink_received 03 [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(697): ajp_parse_type: got 03 [Wed Aug 17 23:11:25 2011] [info] Connection to child 4 closed (server ipa-server-3.ayoung.boston.devel.redhat.com:443, client 192.168.122.203) [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(687): ajp_read_header: ajp_ilink_received 05 [Wed Aug 17 23:11:25 2011] [debug] ajp_header.c(697): ajp_parse_type: got 05 [Wed Aug 17 23:11:25 2011] [debug] mod_proxy_ajp.c(568): proxy: got response from (null) (127.0.0.1) [Wed Aug 17 23:11:25 2011] [debug] proxy_util.c(2029): proxy: AJP: has released connection for (127.0.0.1) [Wed Aug 17 23:11:25 2011] [info] Connection to child 6 closed (server ipa-server-3.ayoung.boston.devel.redhat.com:443, client 192.168.122.203)

2 2

CMake and eclipse
by Adam Young 17 Aug '11

17 Aug '11

I've spent a good amopunt of time over the last couple of days trying to come up with a strategy for integrating PKI development with Eclipse. I've learned a great bit in the interim and I'd like to share. I'm also soliciting some guidance on how to proceed. First, what I've learned: There are aspects to our cmake system that we are not documenting in the Development section of the website. Probably the most basic is how to do incremental builds, which will really speed up certain aspects of development. If you have the code checked out to ~/workspace/pki, the rpms will be built in ~/workspace/packages and related directories (packages.core, packages.kra and so on). It is not necessary to install the RPMs in order to compile the code. One approach would be to create a directory structure parallel to what the RPM compose scripts do: mkdir workspace/build-pki mkdir workspace/build-pki/core mkdir workspace/build-pki/kra then to compile the core code: cd ~/workspace/build-pki/core cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON ../../pki make A comparable set of lines for KRA is cd ~/workspace/build-pki/kra cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_KRA:BOOL=ON ../../pki make These lines can be found in the spec files, under the build sections. For example, in pki/specs/pki-core.spec cd build %cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON .. %{__make} VERBOSE=1 %{?_smp_mflags} CMake generats the Makefile etc in what it refers to as "OutOfSource" mode. This means that, while Make is executed in workspace/build-pki/core, the source remains in workspace/pki/base/core. This is a "best practice" to keep the Generated files separate from the revision controlled files. The PKI CMake setup insists on building the code outside of the source tree. This is enforced by the line pki/CMakeLists.txt line 69 include(MacroEnsureOutOfSourceBuild). Changes made in the original source tree are picked up via Makefile rules. This includes changes to the CMake infrastructure, meaning that configuration changes trigger a complete build. This is one of the positive aspects of CMake. CMake knows about eclipse, and has support for generating a project file for C and C++ Development. To configure this: cd ~/workspace/build-pki/core cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON -G"Eclipse CDT4 - Unix Makefiles" ../../pki/ This can then be imported into Eclipse. However, the project is a CDT project, not a Java project, and is not really a good match for Java development. Some of the shortcomings are that it does not provide automated refactorings or Type navigation. Ideally, we would have separate projects for the C code and the Java code, and let each live under the rules most appropriate to it. This is where the request for guidance comes from. I think the right approach is to modify the CMake approach to split out the C code from the rest of the Java code. The native tools can still remain in the same source RPM, but would have their own build step, something like: cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_NATIVE:BOOL=ON make For Java development, I'd ideally like to run an embedded tomcat. I'm not there yet: I think I need the target code in the form of a web archive, in the format that it lives in under /usr/share/pki/ca/webapps. This structure is set up by cmake baswed on the code in base/ca/CMakeLists.txt, but does not, as far as I can tell, show up in the target tree. I suspect that the approach would be to redefine the install directory for a cmake invocation to be the same as the build directory, or some other non-system owned directory. Making a Java project throws another curveball here. Since a Java project can't yet be autogenerated from CMake, it probably makes sense to check in the .project and .classpath files used. I've submitted one patch in the past that puts the whole tree into as single project. I could see continuing on this approach, and removing the C files from the build tree so that the CDT project. Even better would be to create one project per end RPM, or jar file, and collect them up into a single Eclipse workspace, and/or working set. I think that this is the right approach. I have set separate Java projects for base/ca base/common base/console base/java-tools base/ocsp base/silent base/symkey base/tks base/util base/tps Should be a CDT project as well. This is pretty well supported: cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_TPS:BOOL=ON -G"Eclipse CDT4 - Unix Makefiles" ../../pki/

2 3