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
