restrictive proxy.conf for ipa
by Ade Lee
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>
12 years, 11 months
Proxy/Port work status
by Adam Young
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.
12 years, 11 months
patch for review : https://bugzilla.redhat.com/show_bug.cgi?id=712931
by Ade Lee
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
12 years, 11 months
Re: [Pki-devel] [Freeipa-devel] [PATCH] 0283-enable-proxy-for-dogtag
by Adam Young
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
12 years, 11 months
[PATCH] 0283-enable-proxy-for-dogtag
by Adam Young
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
12 years, 11 months
Auth failure setting up the mod Proxy ajp
by Adam Young
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/profileS...'
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/profileS...'
[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)
12 years, 11 months
CMake and eclipse
by Adam Young
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/
12 years, 11 months
