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.
> >>>>># 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
> >>>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:
> >>>/var/log/pki-ca/catalina.out contains the lines at boot time:
> >>>SEVERE: Error deploying web application directory ca
> >>>com/netscape/cms/servlet/filter/AgentRequestFilter : Unsupported
> >>>major.minor version 51.0 (unable to load class
> >>>com.netscape.cms.servlet.filter.AgentRequestFilter) at
> >>>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:
> >>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.
> >Luckily I have a java expert to hand and explained that major.minor version
> >51.0 corresponds to java 7
> >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-184.108.40.206.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.
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project