8:47 p.m.
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
11:22 a.m.
I'm strill tracking down why the install failed. So far, I can just
determine that the CS DirSrv is not running when the ldap modify command
comes through, but I am not sure why.
base/ca/shared/conf/proxy.conf
while it is a proxy to tomcat, from the apache perspective, tomcat is a
subordinate. It might not be the clearest name. Perhaps
proxy-tomcat.conf or proxy-dogtag.conf, although I thought
dogtag.conf was a fairly descriptive name.
All of the stanzas now appear identical with the exception of the
LocationMatch and one with NSSVerifyClient require. Can the 3
NSSVerifyClient stanzas be collapsed be collapsed into one?
ImportCAChainPanel.java:display
if this line fails:
context.put("machineName", cs.getString("machineName"));
The processing continue on, but the next two lines:
context.put("https_port",
cs.getString("pkicreate.ee_secure_port"));
context.put("http_port",
cs.getString("pkicreate.unsecure_port"));
Will never get executed. THat doesn't seem like the intention we want.
These two lines should probable be outside the catch block, and trigger
an exception that stops processing, as it seems like things are
significantly broken at this point.
AdminRequestFilter.java
Drop the bad_port boolean and move the conditional code up to where
bad_port is set.
if (bad_port) {
CMS.debug( filterName + ": " + msg );
CMS.debug( filterName + ": uri is " + uri);
if ((param_active != null)
&&(param_active.equals("false"))) {
CMS.debug("Filter is disabled .. continuing");
} else {
resp.sendError(
HttpServletResponse.SC_NOT_FOUND, msg );
return;
}
}
AgentRequestFilter.java
EEClientAuthRequestFilter.java
EERequestFilter.java
Code is duplicate of the code in the AdminRequest\Filter. refactor to a
common method. Comment from above applies here as well re: bad_port
fixProxyPorts: Why catch the exception and continue. Wouldn't it be
better to throw the exception? Do we really want to continue if this
code does not succeed?
Relative paths in html files: seesm like we should specify a place for
the helper files to live, instead of assuming they will be in
../cms-funcs.js as that is a little on the fragile side. I am guessing
that it can no longer be just /ee/ since we might be coming from
/eeca/ Probably OK as is for this commit, but lets figure out what
we'd ideally want to do. I'm guessing that the eeca approach is
really not what we want, and this is a work around for it, too.
I didn't give the perl code a thorough a look as the Java code, but it
looked OK.
10:39 a.m.
New subject: patch for review : https://bugzilla.redhat.com/show_bug.cgi?id=712931
On Mon, 2011-08-22 at 12:22 -0400, Adam Young wrote:
I'm strill tracking down why the install failed. So far, I can
just
determine that the CS DirSrv is not running when the ldap modify command
comes through, but I am not sure why.
base/ca/shared/conf/proxy.conf
while it is a proxy to tomcat, from the apache perspective, tomcat is a
subordinate. It might not be the clearest name. Perhaps
proxy-tomcat.conf or proxy-dogtag.conf, although I thought
dogtag.conf was a fairly descriptive name.
As discussed in review, we will leave this name as is.
All of the stanzas now appear identical with the exception of the
LocationMatch and one with NSSVerifyClient require. Can the 3
NSSVerifyClient stanzas be collapsed be collapsed into one?
They could - but I suggest we leave that for a later patch where we
clean up the URL structure. For now, it makes more sense to me to keep
them separate because the separate stanzas accurately describe what is
on each of the admin, agent and ee ports.
Another thing to consider. In the non-IPA product, it is possible to
configure the console (which uses admin URLs) to use client auth. If we
were to move some of the admin functions to http in future, I could see
a need to make them client-auth. (and therefore, there may be a need to
keep them separated).
ImportCAChainPanel.java:display
if this line fails:
context.put("machineName", cs.getString("machineName"));
The processing continue on, but the next two lines:
context.put("https_port",
cs.getString("pkicreate.ee_secure_port"));
context.put("http_port",
cs.getString("pkicreate.unsecure_port"));
Will never get executed. THat doesn't seem like the intention we want.
These two lines should probable be outside the catch block, and trigger
an exception that stops processing, as it seems like things are
significantly broken at this point.
The correct thing to do here if any of these lines are not executed is
to log an error and display an error message to the user. Which I have
now done.
Note that this does not affect IPA as this is in the display of an
installation panel. pkisilent does not use these values.
AdminRequestFilter.java
Drop the bad_port boolean and move the conditional code up to where
bad_port is set.
if (bad_port) {
CMS.debug( filterName + ": " + msg );
CMS.debug( filterName + ": uri is " + uri);
if ((param_active != null)
&&(param_active.equals("false"))) {
CMS.debug("Filter is disabled .. continuing");
} else {
resp.sendError(
HttpServletResponse.SC_NOT_FOUND, msg );
return;
}
}
Actually, I disagree with this one. There are two places where bad_port
is set - so not using the boolean causes unnecessary duplication of
code. We might be able to do without the boolean, but not without
compromising the readability of the code.
AgentRequestFilter.java
EEClientAuthRequestFilter.java
EERequestFilter.java
Code is duplicate of the code in the AdminRequest\Filter. refactor to a
common method. Comment from above applies here as well re: bad_port
Yes -- I agree with this. Actually, as all the code in each of the
filters is pretty much duplicated - I think we can refactor this to a
single filter class which can be instantiated with a couple of
parameters.
As we want to get this out for 6.1 and in as much testing as possible, I
suggest we open a bug to do this refactoring in the 8.2 timeframe.
fixProxyPorts: Why catch the exception and continue. Wouldn't it
be
better to throw the exception? Do we really want to continue if this
code does not succeed?
Done
Relative paths in html files: seesm like we should specify a place for
the helper files to live, instead of assuming they will be in
../cms-funcs.js as that is a little on the fragile side. I am guessing
that it can no longer be just /ee/ since we might be coming from
/eeca/ Probably OK as is for this commit, but lets figure out what
we'd ideally want to do. I'm guessing that the eeca approach is
really not what we want, and this is a work around for it, too.
OK
I didn't give the perl code a thorough a look as the Java code, but it
looked OK.
We walked through it in the code review.
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
12:54 p.m.
Looks Good. ACK
On 08/23/2011 11:39 AM, Ade Lee wrote:
On Mon, 2011-08-22 at 12:22 -0400, Adam Young wrote:
> I'm strill tracking down why the install failed. So far, I can just
> determine that the CS DirSrv is not running when the ldap modify command
> comes through, but I am not sure why.
>
>
> base/ca/shared/conf/proxy.conf
>
> while it is a proxy to tomcat, from the apache perspective, tomcat is a
> subordinate. It might not be the clearest name. Perhaps
> proxy-tomcat.conf or proxy-dogtag.conf, although I thought
> dogtag.conf was a fairly descriptive name.
>
As discussed in review, we will leave this name as is.
> All of the stanzas now appear identical with the exception of the
> LocationMatch and one with NSSVerifyClient require. Can the 3
> NSSVerifyClient stanzas be collapsed be collapsed into one?
>
>
They could - but I suggest we leave that for a later patch where we
clean up the URL structure. For now, it makes more sense to me to keep
them separate because the separate stanzas accurately describe what is
on each of the admin, agent and ee ports.
Another thing to consider. In the non-IPA product, it is possible to
configure the console (which uses admin URLs) to use client auth. If we
were to move some of the admin functions to http in future, I could see
a need to make them client-auth. (and therefore, there may be a need to
keep them separated).
> ImportCAChainPanel.java:display
>
> if this line fails:
> context.put("machineName", cs.getString("machineName"));
>
> The processing continue on, but the next two lines:
> context.put("https_port",
> cs.getString("pkicreate.ee_secure_port"));
> context.put("http_port",
> cs.getString("pkicreate.unsecure_port"));
>
> Will never get executed. THat doesn't seem like the intention we want.
> These two lines should probable be outside the catch block, and trigger
> an exception that stops processing, as it seems like things are
> significantly broken at this point.
>
The correct thing to do here if any of these lines are not executed is
to log an error and display an error message to the user. Which I have
now done.
Note that this does not affect IPA as this is in the display of an
installation panel. pkisilent does not use these values.
> AdminRequestFilter.java
>
> Drop the bad_port boolean and move the conditional code up to where
> bad_port is set.
>
> if (bad_port) {
> CMS.debug( filterName + ": " + msg );
> CMS.debug( filterName + ": uri is " + uri);
> if ((param_active != null)
> &&(param_active.equals("false"))) {
> CMS.debug("Filter is disabled .. continuing");
> } else {
> resp.sendError(
> HttpServletResponse.SC_NOT_FOUND, msg );
> return;
> }
> }
>
Actually, I disagree with this one. There are two places where bad_port
is set - so not using the boolean causes unnecessary duplication of
code. We might be able to do without the boolean, but not without
compromising the readability of the code.
> AgentRequestFilter.java
> EEClientAuthRequestFilter.java
> EERequestFilter.java
>
> Code is duplicate of the code in the AdminRequest\Filter. refactor to a
> common method. Comment from above applies here as well re: bad_port
>
Yes -- I agree with this. Actually, as all the code in each of the
filters is pretty much duplicated - I think we can refactor this to a
single filter class which can be instantiated with a couple of
parameters.
As we want to get this out for 6.1 and in as much testing as possible, I
suggest we open a bug to do this refactoring in the 8.2 timeframe.
> fixProxyPorts: Why catch the exception and continue. Wouldn't it be
> better to throw the exception? Do we really want to continue if this
> code does not succeed?
>
Done
> Relative paths in html files: seesm like we should specify a place for
> the helper files to live, instead of assuming they will be in
> ../cms-funcs.js as that is a little on the fragile side. I am guessing
> that it can no longer be just /ee/ since we might be coming from
> /eeca/ Probably OK as is for this commit, but lets figure out what
> we'd ideally want to do. I'm guessing that the eeca approach is
> really not what we want, and this is a work around for it, too.
>
OK
> I didn't give the perl code a thorough a look as the Java code, but it
> looked OK.
>
We walked through it in the code review.
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
2:17 p.m.
New subject: patch for review : https://bugzilla.redhat.com/show_bug.cgi?id=712931
On 08/21/11 18:47, Ade Lee wrote:
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
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
ACK - with Caveats:
(1) fix 'base/selinux/src/pki.if' line to use subsystem variable rather than
'pki_ca_t'
(2) clone bug to provide 'proxy.conf' file for KRA, OCSP, and TKS subsystems
4869
days inactive
4870
days old
4 comments
3 participants
participants (3)
-
Adam Young -
Ade Lee -
Matthew Harmsen