Re: [Pki-devel] [Freeipa-users] Unable to communicate with CMS (Service Unavailable) (Solved)
by Fraser Tweedale
On Fri, Nov 13, 2015 at 12:00:16PM +0100, Martin Kosek wrote:
> On 11/13/2015 11:14 AM, Terry John wrote:
> >>On 11/12/2015 04:51 PM, Terry John wrote:
> >>>I got a core dump of certmonger failing user abrt but it's huge. Is there any particular part that would be useful.
> >
> >>CCing Nalin and David for the core dump. More below.
> >
> >>On 11/12/2015 02:17 PM, Terry John wrote:
> >>>>I had a working freeipa setup on a CentOS release 6.7 machine. All was well until I did a yum update. Now I have multiple issue apparently based around the CMS (Service Unavailable) issue.
> >>>>My current version of ipa-server is 3.0.0-47 Certmonger crashes with
> >>>>a segmentation fault at boot time and crashes every time I try to restart it when ipa is running.
> >>
> ><snip>
> >
> >>>>># ipa cert-status
> >>>>>Request id: 20140417164153
> >>>>>ipa: ERROR: Certificate operation cannot be completed: Unable to
> >>>>>communicate with CMS (Service Unavailable) # service certmonger
> >>>>>status certmonger (pid 3030) is running...
> >>>
> >>>>It looks like PKI cannot be contacted. I would recommend checking /var/log/httpd/error_log, it may have more details. I would also recommend checking "ipa cert-show 1", it will probably fail with the same bug.
> >>>Yes ipa cert-show 1 does show the same thing # ipa cert-show 1
> >>>ipa: ERROR: Certificate operation cannot be completed: Unable to
> >>>communicate with CMS (Service Unavailable)
> >>>
> >>>>Next steps may include checking that dogtag service really runs, there is no SELinux AVC. If neither of this helps, you can check PKI logs /var/log/pki... to see what went wrong.
> >>>I'm pretty certain the dogtag service is not running
> >
> >Then you have your lucky winner! :-)
> >
> >>>>Some pointers to logs are for example here:
> >>>>http://www.freeipa.org/page/Troubleshooting#Server_Installation
> >>
> >>>/var/log/pki-ca/catalina.out contains the lines at boot time:
> >
> >
> >>>SEVERE: Error deploying web application directory ca
> >>>java.lang.UnsupportedClassVersionError: com/netscape/cms/servlet/filter/AgentRequestFilter : Unsupported major.minor version 51.0 (unable to load class com.netscape.cms.servlet.filter.AgentRequestFilter) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappC> lassLoader.java:2334).... lots of traceback
> >>>
> >>>/var/log/pki-ca/system is empty
> >>>/var/log/pki-ca/debug has nothing new for 2 days
> >
> >>CCing Fraser. This is a wild guess, but maybe you updated your java to java-1.8.0-openjdk? PKI does not work on it on RHEL/CentOS:
> >
> >>https://bugzilla.redhat.com/show_bug.cgi?id=1262516
> >
> >>java would need to be switched with "alternate" to pre-1.8.0 version if this is the case.
> >
> >The java version was the problem.
>
> Good! Fraser, can we improve anything in pki-core, so that wrong java
> version issue like this one does not occur? IIRC, pki-core in RHEL-6.x was
> updated to somehow deal with java 1.8.0 (conflict), not sure if lower
> versions are also covered.
>
AFAICT there is no such protection. It seems to be more of an
unspoken "don't do that".
I guess the right approach when an unsupported alternative is
selected is to explicitly use a supported one. I'm not sure what's
involved in making that change or whether it is worth the effort.
Adding pki-devel for comment from those with packaging experience.
Cheers,
Fraser
> >Luckily I have a java expert to hand and explained that major.minor version 51.0 corresponds to java 7
> >http://stackoverflow.com/questions/9170832/list-of-java-class-file-format...
> >When I did
> ># ps ax | grep java I got"
> >1460 ? Sl 1:21 /usr/java/default/bin/java -Djavax.sql.Da.......
> ># /usr/java/default/bin/java -version
> >java version "1.6.0_31"
> >Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
> >Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
> >
> >I have both java-1.6.0-openjdk and java-1.7.0-openjdk installed but the /usr/java/default/bin is all from java-1.6.0-openjdk
> >
> >I have renamed /usr/java/default/bin/java to javaold and done
> ># ln -s /usr/bin/java /usr/java/default/bin/java
> ># /usr/java/default/bin/java -version
> >java version "1.7.0_91"
> >OpenJDK Runtime Environment (rhel-2.6.2.2.el6_7-x86_64 u91-b00)
> >OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode)
>
> This may work, but looks a bit hacky. I think the right way is to use
> "alternate" program I mentioned earlier to let you choose the right version
> of the java executable and/or libraries.
>
> >After a reboot FreeIPA works properly which is great but I'm wondering if there is a better fix though since all the other executables in are from the 1.6 version. I can't find a corresponding location for 1.7 executables.
>
> The "alternate" approach should "just work". I am glad you made the instance
> working again!
>
> >
> >Thanks very much
> >
> >
> >The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions.
> >
> >V:0CF72C13B2AC
> >
> >
>
8 years, 5 months
SPNEGO for Dogtag
by Fraser Tweedale
Hi all,
Just an update on my investigations of doing SPNEGO authn to
Dogtag/Tomcat and a summary of what I think I'll need to do to get
it going.
Even for a trivial app configuring Tomcat to do SPNEGO is pretty
awful. I made some notes[1] on this and I'll turn that into a blog
post later, once I have a Realm story to go with it (I'm thinking
mod_lookup_identity for Tomcat; more on that below).
[1] https://github.com/frasertweedale/notes-redhat/blob/master/tomcat.rst
The unfortunate case is that the `Authenticator' interface does not
chain, hence we already have our own `SSLAuthenticatorWithFallback'
authenticator valve implementation which we use to fall back to
Basic authentication when there is no client certificate.
I see two general approaches to the "multiple authentication
options" problem.
a) a "parallel deployment" in a separate <Context> where we host the
app in parallel at '/<subsystem>/spnego/...' or
'/spnego/<subsystem>/...' and use the `SpnegoAuthenticator' valve.
This is a pretty "heavyweight" approach and I believe sessions from
one do not flow to the other, and a whole separate CMS application
is running. So it does not seem viable.
b) `SSLAuthenticatorWithFallback' becomes "SSL or SPNEGO or Basic"
valve. The problem here is that protocol-wise there is no
indication on initial request whether client can do SPNEGO or not,
so it is not clear how server should respond. An example of how
this could be resolved is the client providing a '?spnego=1' query
param; ugly but it should work, and w.r.t. REST API the client need
only do it on /rest/account/login and use their session cookie
thereafter, so I don't think it is too onerous.
So it looks like (b) but if someone can suggest another approach I'm
listening!
As for the Realm, the current implementation is a bit unorthodox -
we use our own ProxyRealm class and "inject" a PKIRealm into it.
I'm not sure why this approach is needed becaues PKIRealm does not
need any configuration either on instantiation or afterwards.
I think the best approach here would be to use CombinedRealm[2] and
add PKIRealm as well as whatever other Realms are needed. For IPA
usage I am leaning toward the mod_lookup_identity approach; given
principal name look up roles (groups) via D-Bus.
[2] https://tomcat.apache.org/tomcat-7.0-doc/config/realm.html#Combined_Realm...
Jan: does this approach make sense to you and do you know of any
projects to do this with Tomcat already?
Ade: what sort of behaviour do you need in the Realm for the Barbian
use case?
Any and all feedback welcome.
Thanks,
Fraser
8 years, 5 months
