Description of problem: CA Setup Wizard cannot create new Security Domain. Clicking on "Next" brings back the same "Security Domain" page. Attached screen shot shows highlighted "$https_port" string, which should be replaced by port number. Version-Release number of selected component (if applicable): 1.0 How reproducible: There is only one F8 system on which this case is always reproducible. Steps to Reproduce: 1. Start CA Setup Wizard 2. On the second page select "Create a New Security Domain" 3. Click on the "Next" button. CA Setup Wizard returns to the same "Security Domain" page. Actual results: Clicking on the "Next" button on the "Security Domain" page, causes CA Setup Wizard to go to the same "Security Domain" page. Expected results: Clicking on the "Next" button on the "Security Domain" page, should move CA Setup Wizard to the next page. Additional info:
Created attachment 302083 [details] CA Setup Wizard - Screen shot of Security Domain page
(In reply to comment #1) i can confirm this, i have the same. using the pki-ca on a centos5 though. what's shown in the debug log is: [11/Apr/2008:11:46:43][http-9080-Processor22]: WizardServlet: process [11/Apr/2008:11:46:43][http-9080-Processor22]: WizardServlet:serice() uri = /ca/admin/console/config/wizard [11/Apr/2008:11:46:43][http-9080-Processor22]: CMSServlet::service() param name='sdomainURL' value='https://ourCAserver:9443' [11/Apr/2008:11:46:43][http-9080-Processor22]: CMSServlet::service() param name='sdomainName' value='WR' [11/Apr/2008:11:46:43][http-9080-Processor22]: CMSServlet::service() param name='choice' value='newdomain' [11/Apr/2008:11:46:43][http-9080-Processor22]: CMSServlet::service() param name='p' value='1' [11/Apr/2008:11:46:43][http-9080-Processor22]: CMSServlet::service() param name='op' value='next' [11/Apr/2008:11:46:43][http-9080-Processor22]: WizardServlet: op=next [11/Apr/2008:11:46:43][http-9080-Processor22]: WizardServlet: size=18 [11/Apr/2008:11:46:43][http-9080-Processor22]: WizardServlet: in next 1 [11/Apr/2008:11:46:43][http-9080-Processor22]: panel no=1 [11/Apr/2008:11:46:43][http-9080-Processor22]: panel name=securitydomain [11/Apr/2008:11:46:43][http-9080-Processor22]: total number of panels=18 p.s.: also note the typo "serice" in the second line :)
I can reproduce this problem on Andrew's machine. Addition useful error was found prior to the error reported. Found the following in the debug log: [10/Apr/2008:15:55:06][main]: CMSEngine: done init id=os [10/Apr/2008:15:55:06][main]: CMSEngine: initialized os [10/Apr/2008:15:55:06][main]: CMSEngine: initSubsystem id=jss [10/Apr/2008:15:55:06][main]: CMSEngine: ready to init id=jss [10/Apr/2008:15:55:06][main]: CMS:Caught EBaseException Failed to create jss service: org.mozilla.jss.CryptoManager$NotInitializedException at com.netscape.cmscore.security.JssSubsystem.init(JssSubsystem.java:252) at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:735) at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:664) at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:276) at com.netscape.certsrv.apps.CMS.init(CMS.java:152) at com.netscape.certsrv.apps.CMS.start(CMS.java:1490) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:78) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:966) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3956) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4230) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:926) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:889) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022) at org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:448) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:623) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
The interesting error seems to be: 16.04.2008 18:04:51 org.apache.catalina.core.ApplicationContext log SCHWERWIEGEND: StandardWrapper.Throwable java.util.MissingResourceException: Can't find bundle for base name LogMessages, locale de_DE at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1539) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1278) at java.util.ResourceBundle.getBundle(ResourceBundle.java:733) at com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:974) at com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1047) at com.netscape.certsrv.apps.CMS.getLogMessage(CMS.java:637) at com.netscape.cms.servlet.common.Utils.initializeAuthz(Utils.java:89) at com.netscape.cms.servlet.base.CMSServlet.init(CMSServlet.java:288) at com.netscape.cms.servlet.csadmin.MainPageServlet.init(MainPageServlet.java:44) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:791) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:127) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:675) after setting LANG=C and restarting pki-ca the wizard goes on.
For the record... On Andrew's machine, it appears that tomcatjss was never called. In comparing Andrew's machine (failed installation) and mine (successful installation), I found two tomcat related packages on his machine that are not on mine: tomcat-native-1.1.10-1.fc8.i386 tomcat-native-1.1.10-1.fc8.x86_64 I uninstalled the two rpms: # rpm -ev tomcat-native-1.1.10-1.fc8.i386 # rpm -ev tomcat-native-1.1.10-1.fc8.x86_64 And now I could install the instance successfully. What is needed now is for someone with the two tomcat packages to install and verify the theory: if you have those packages, the installation will fail.
We have duplicated Christina's scenario on another x86_64 machine. The install works when "tomcat-native" is absent and does not work when it is present. I was able to duplicate the entire scenario on a i386 machine. I also researched to find out what this package is. It is a package designed to take over many of tomcat's Java based services with native code. The idea is to get about a 10% speed boost. My theory is that this thing is forcibly taking over the SSL/crypto functionality that we so carefully configured to use our "tomcatjss" component. Performing an LDD on the "tomcat-native" library shows us that it depends upon openssl. The fix is to not have "tomcat-native" installed on the same system. More information about "tomcat-native" can be found here: http://wiki.liferay.com/index.php/Tomcat_Native_Library
The appropriate fix for this is to provide a "Conflicts" keyword in the "pki-common" spec file to insure that this package does not exist on the system on which Dogtag PKI is to be installed.
i know that i'm using an unsupported OS (Centos 5.1), but maybe it helps anyway: i do not have tomcat-native installed on my machine: # rpm -qa | grep tomcat tomcat5-jsp-2.0-api-5.5.23-0jpp.3.0.3.el5_1 tomcat5-servlet-2.4-api-5.5.23-0jpp.3.0.3.el5_1 tomcat5-jasper-5.5.23-0jpp.3.0.3.el5_1 tomcat5-server-lib-5.5.23-0jpp.3.0.3.el5_1 tomcat5-5.5.23-0jpp.3.0.3.el5_1 tomcat5-common-lib-5.5.23-0jpp.3.0.3.el5_1 tomcatjss-1.1.0-10.fc8 but i could indeed fix this issue by changing LANG to "C" in /etc/sysconfig/i18n maybe this is a different bug? regards, johannes
Created attachment 302829 [details] Added Conflicts conditional to specfile
rpm -Uvh pki-common-1.0.0-5.fc8.noarch.rpm error: Failed dependencies: tomcat-native conflicts with pki-common-1.0.0-5.fc8.noarch
attachment (id=302829) +jmagne
svn status | grep -v ^$ | grep -v ^? | grep -v ^P | grep -v ^X M linux/common/pki-common.spec Sending linux/common/pki-common.spec Transmitting file data . Committed revision 28.
Added Johannes comment to http://pki.fedoraproject.org/wiki/PKI_Known_Issues#PKI_Subsystem_Configuration.
Bug already MODIFIED. setting target CS8.0 and marking screened+
Moved "Conflicts: tomcat-native" from 'pki-common' package to the more appropriate 'tomcatjss' package: # svn diff Index: tomcatjss.spec =================================================================== --- tomcatjss.spec (revision 66) +++ tomcatjss.spec (working copy) @@ -1,6 +1,6 @@ Name: tomcatjss Version: 1.2.0 -Release: 2%{?dist} +Release: 3%{?dist} Summary: JSSE implementation using JSS for Tomcat URL: http://pki.fedoraproject.org/ License: LGPLv2+ @@ -16,15 +16,26 @@ BuildRequires: jpackage-utils BuildRequires: tomcat5 BuildRequires: jss >= 4.2.6 + Requires: java >= 1:1.6.0 Requires: jpackage-utils Requires: tomcat5 Requires: jss >= 4.2.6 +# The 'tomcatjss' package conflicts with the 'tomcat-native' package +# because it uses an underlying NSS security model rather than the +# OpenSSL security model, so these two packages may not co-exist. +# (see Bugzilla Bug #441974 for details) +Conflicts: tomcat-native + %description A Java Secure Socket Extension (JSSE) implementation using Java Security Services (JSS) for Tomcat 5.5. +NOTE: The 'tomcatjss' package conflicts with the 'tomcat-native' package + because it uses an underlying NSS security model rather than the + OpenSSL security model, so these two packages may not co-exist. + %prep %setup -q @@ -61,6 +72,11 @@ %{_sharedstatedir}/tomcat5/server/lib/%{name}.jar %changelog +* Thu Jan 14 2010 Matthew Harmsen <mharmsen> 1.2.0-3 +- Bugzilla Bug #441974 - CA Setup Wizard cannot create new Security Domain. +- Added 'Conflicts: tomcat-native' plus descriptive comment +- Updated 'description' section with this information + * Fri Sep 11 2009 Kevin Wright <kwright> 1.2.0-2 - Bugzilla Bug #521979 - Removed references to jre, fedora 8, etc # svn diff Index: pki-common.spec =================================================================== --- pki-common.spec (revision 911) +++ pki-common.spec (working copy) @@ -1,6 +1,6 @@ Name: pki-common Version: 1.3.0 -Release: 4%{?dist} +Release: 5%{?dist} Summary: Dogtag Certificate System - PKI Common Framework URL: http://pki.fedoraproject.org/ License: GPLv2 @@ -40,8 +40,6 @@ Requires: %{_javadir}/xerces-j2.jar Requires: velocity -Conflicts: tomcat-native - Source0: http://pki.fedoraproject.org/pki/sources/%{name}/%{name}-%{version}.tar.gz %description @@ -116,6 +114,10 @@ %{_javadocdir}/%{name}-%{version}/ %changelog +* Thu Jan 14 2010 Matthew Harmsen <mharmsen> 1.3.0-5 +- Bugzilla Bug #441974 - CA Setup Wizard cannot create new Security Domain. +- Moved 'Conflicts: tomcat-native' to lower-level 'tomcatjss' package + * Mon Dec 7 2009 Matthew Harmsen <mharmsen> 1.3.0-4 - Bugzilla Bug #522207 - packaging for Fedora Dogtag - Removed 'postinstall' tasks # cd tomcatjss # svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^? M tomcatjss.spec # svn commit Sending tomcatjss.spec Transmitting file data . Committed revision 67. # cd pki/dogtag # svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^? M pki-common.spec # svn commit Sending common/pki-common.spec Transmitting file data . Committed revision 913.
tomcatjss-1.2.0-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/tomcatjss-1.2.0-3.fc11
tomcatjss-1.2.0-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/tomcatjss-1.2.0-3.fc12
tomcatjss-1.2.0-3.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/tomcatjss-1.2.0-3.el5
tomcatjss-1.2.0-3.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
tomcatjss-1.2.0-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
pki-common-1.3.0-7.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/pki-common-1.3.0-7.fc11
pki-common-1.3.0-7.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/pki-common-1.3.0-7.fc12
pki-common-1.3.0-7.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/pki-common-1.3.0-7.el5
pki-common-1.3.0-8.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/pki-common-1.3.0-8.fc11
pki-common-1.3.0-8.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/pki-common-1.3.0-8.el5
pki-common-1.3.0-7.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
pki-common-1.3.0-7.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
pki-common-1.3.0-8.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
tomcatjss-1.2.0-3.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
I encountered the same problem on Fedora 12 and pki-common-1.3.2. Like described above it is a missing fallback-locale/resource problem, if the machine locale is different to en. (de_DE for me) Solution: In the sources: - Rename LogMessages_en.properties to LogMessages.properties - Rename UserMessages_en.properties to UserMessages.properties - Edit build.xml according to the changes - Rebuild and have fun. ;-) BTW: A similar problem exists in dogtag-pki-console-ui-1.3.1 with pki-console-theme_en.jar having the lanquage-code in its name. Maybe there are other places, where this happens. I think the english resources should alwas be the last fallback, without language-codes in its names. Best regards, Oli
Hello, I had time to investigate all the pki-* and dogtag-pki-* packages and made some changes to spec-files as a quick hack, so I can rebuild them for my local repository, 'till the bug is fixed. Changes attached. Maybe someone will incorporate the intention of my %prep-sections in the sources. I tested the changes with a fresh and clean F-12 installation with machine locale set to de_DE.UTF-8, free-ipa v2 setup (1.91-0.2010032620gitc7a35f9.fc12), dogtag browser console and pkiconsole. Everything works fine now, no exceptions because of missing resource-files with other machine-locale than en anymore. The CA was set up flawlessly and works. I than changed the machine-locale to en, and tested again. If someone needs other tests, please let me know. BTW: I'm currently cleaning the "dirty" html-templates for dogtag to be "xhtml-1.0 strict" compliant, because there were parser-errors in the logs. If someone of the developers is interested, please let me know. Beste regards, Oli --- pki-common.spec 2010-02-11 01:03:00.000000000 +0100 +++ pki-common_burtchen.spec 2010-03-30 13:15:22.122138895 +0200 @@ -1,11 +1,11 @@ Name: pki-common Version: 1.3.2 -Release: 1%{?dist} +Release: 1.1_burtchen%{?dist} Summary: Dogtag Certificate System - PKI Common Framework URL: http://pki.fedoraproject.org/ License: GPLv2 Group: System Environment/Base BuildArch: noarch BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) @@ -58,18 +58,26 @@ %description javadoc Dogtag Certificate System - PKI Common Framework Javadocs This documentation pertains exclusively to version %{version} of the Dogtag PKI Common Framework. %prep - %setup -q +cd %{_builddir}/%{name}-%{version}/src +mv LogMessages_en.properties LogMessages.properties +mv UserMessages_en.properties UserMessages.properties +cd .. +mv build.xml build.xml.orig +sed 's/LogMessages_en.properties/LogMessages.properties/g' < build.xml.orig > build.xml.orig2 +sed 's/UserMessages_en.properties/UserMessages.properties/g' < build.xml.orig2 > build.xml +rm -f build.xml.orig2 + %build ant \ -Dproduct.ui.flavor.prefix="" \ -Dproduct.prefix="pki" \ -Dproduct="common" \ -Dversion="%{version}" --- pki-console.spec 2010-02-10 00:08:54.000000000 +0100 +++ pki-console_burtchen.spec 2010-03-31 20:32:20.606591010 +0200 @@ -1,11 +1,11 @@ Name: pki-console Version: 1.3.1 -Release: 1%{?dist} +Release: 1.1_burtchen%{?dist} Summary: Dogtag Certificate System - PKI Console URL: http://pki.fedoraproject.org/ License: GPLv2 Group: System Environment/Base BuildArch: noarch BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) @@ -32,16 +32,23 @@ The PKI Console is a java application used to administer Dogtag Certificate System. %prep %setup -q +cd %{_builddir}/%{name}-%{version}/templates +mv pki_console_wrapper pki_console_wrapper.orig +sed 's/pki-console-theme_en.jar/pki-console-theme.jar/g' < pki_console_wrapper.orig > pki_console_wrapper.orig2 +sed 's/cms-theme_en.jar/cms-theme.jar/g' < pki_console_wrapper.orig2 > pki_console_wrapper +rm -f pki_console_wrapper.orig2 + + %build ant \ -Dproduct.ui.flavor.prefix="" \ -Dproduct.prefix="pki" \ -Dproduct="console" \ -Dversion="%{version}" %install --- dogtag-pki-console-ui.spec 2010-02-10 00:08:21.000000000 +0100 +++ dogtag-pki-console-ui_burtchen.spec 2010-03-30 14:09:20.915139260 +0200 @@ -1,11 +1,11 @@ Name: dogtag-pki-console-ui Version: 1.3.1 -Release: 1%{?dist} +Release: 1.1_burtchen%{?dist} Summary: Dogtag Certificate System - PKI Console User Interface URL: http://pki.fedoraproject.org/ License: GPLv2 Group: System Environment/Base BuildArch: noarch BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) @@ -29,37 +29,40 @@ %description Dogtag Certificate System is an enterprise software system designed to manage enterprise Public Key Infrastructure (PKI) deployments. The Dogtag PKI Console User Interface contains the graphical user interface for the Dogtag PKI Console. %prep - %setup -q +cd %{_builddir}/%{name}-%{version} +mv build.xml build.xml.orig +sed 's!<jar jarfile="${build.jars}/pki-console-theme-${version}_en.jar">!<jar jarfile="${build.jars}/pki-console-theme-${version}.jar">!g' < build.xml.orig > build.xml + %build ant \ -Dproduct.ui.flavor.prefix="dogtag" \ -Dproduct.prefix="pki" \ -Dproduct="console-ui" \ -Dversion="%{version}" %install rm -rf %{buildroot} cd dist/binary unzip %{name}-%{version}.zip -d %{buildroot} cd %{buildroot}%{_javadir} -ln -s pki-console-theme-%{version}_en.jar pki-console-theme_en.jar +ln -s pki-console-theme-%{version}.jar pki-console-theme.jar # supply convenience symlink(s) for backwards compatibility mkdir -p %{buildroot}%{_javadir}/pki cd %{buildroot}%{_javadir}/pki -ln -s ../pki-console-theme_en.jar cms-theme_en.jar +ln -s ../pki-console-theme.jar cms-theme.jar %clean rm -rf %{buildroot} %files %defattr(-,root,root,-) %doc LICENSE %{_javadir}/*