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-major-version-numbers
> >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
> >
> >
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to