|
From: Christopher C. <chr...@gm...> - 2009-03-12 01:06:54
|
Thanks Leif, replies inline: On Mon, Mar 9, 2009 at 9:35 PM, Leif Mortenson <le...@ta...>wrote: > I was not clear from your reply. Is the keyTab file failing to be > found BOTH when running under the Wrapper in console mode and when > running under the Wrapper as a service? Yes, it fails both ways. To be clear though: by console mode, do you simply mean running my run.bat from the console, which in turn invokes wrapper.exe? Vs. installing the service and clicking Start from the Services menu? Both of those approaches fail. Is there another "console mode" that bypasses wrapper.exe somehow? > > 1) The Wrapper creates a backend socket between the Wrapper and Java > processes. This results in two ports being bound. By default these > will be 31000 and 32000: > http://wrapper.tanukisoftware.org/doc/english/prop-port.html > http://wrapper.tanukisoftware.org/doc/english/prop-jvm-port.html > Cool, I doubt that's it, I believe communications to the KDC are on lower ports (mainly 88). > > 2) Normally when a JVM is run, a java.library.path is not defined on > the Java command line. When this is the case, the JVM will search the > system PATH by default for any native libraries. When running under > the Wrapper, for stability reasons, we specify a java.library.path for > the wrapper.dll file. We recommend that you use this method for any > of your native libraries as well. If your application makes use of > any native libraries that would normally be found on the PATH they > would not be found unless their location was added specifically. > There is a property which will get the PATH support back by appending > the full PATH to the java library path. > http://wrapper.tanukisoftware.org/doc/english/prop-java-library-path-n.html > > http://wrapper.tanukisoftware.org/doc/english/prop-java-library-path-append-system-path.html I'm pretty sure that's not it either, but good info and I'll keep a lookout. I use wrapper.java.classpath in my wrapper.conf to include .jar dependencies that aren't in the JVM lib or the JBoss class path (where my .ear is deployed). All of the other application behavior besides this GSSAPI stuff seems to be OK so it's likely all working. As of Java 6 all of the needed GSSAPI and Kerberos implementation should be available in the JRE. > Could you add the wrapper.java.command.loglevel=INFO property and then > copy the resulting Java command when running in Console mode into a > reply email. Send that along with the full java command generated by > your JBoss startup script. You can get that by inserting an "echo" at > the beginning of the line where java is launched. I might be able > to point to the problem by comparing them. I've made the script and wrapper.conf as similar as possible in terms of JVM -D args etc. Here's the full java command from my JBoss .bat: "C:\Program Files\Extensis\Universal Type Server\applications\jboss\bin\..\..\jre\bin\java" -Dprogram.name=jboss.bat -server -Xms512m -Xmx1024m -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.krb5.realm=MTEST.EXTENSIS.COM-Djava.security.krb5.kdc=10.1.6.100 -Dextensis.krb5.service-principal=utswin/10.1.3.101-Djava.library.path="../services/lib;../../../../../Bonjour" -Djava.net.preferIPv4Stack=true -Djava.rmi.server.hostname= "-Djava.endorsed.dirs=C:\Program Files\Extensis\Universal Type Server\applications\jboss\bin\..\lib\endorsed" -classpath "C:\Program Files\Extensis\Universal Type Server\applications\jboss\bin\..\..\jre\lib\tools.jar";"C:\Program Files\Extensis\Universal Type Server\applications\jboss\bin\run.jar";"C:\Program Files\Extensis\Universal Type Server\applications\jboss\bin\..\services\lib\esp-preferences.jar" org.jboss.Main -b 0.0.0.0 Here's the java command logging from wrapper: wrapper | command: "C:\Program Files\Extensis\Universal Type Server\applications\jre\bin\java.exe" -server -Djava.endorsed.dirs=../lib/endorsed/ -Dprogram.name=jboss.bat -Djava.net.preferIPv4Stack=true -Djava.rmi.server.hostname= -Djava.security.krb5.realm=MTEST.EXTENSIS.COM-Djava.security.krb5.kdc=10.1.6.100 -Djava.security.auth.useSubjectCredsOnly=false -Dextensis.krb5.service-principal=utswin/10.1.3.101-Dsun.security.krb5.principal=utswin/ 10.1.3.101 -Xms512m -Xmx1024m -Djava.library.path="../services/lib;../../../../../Bonjour" -classpath "run.jar;../services/lib/wrapper.jar;../services/lib/esp-preferences.jar;../services/lib/services.jar" -Dwrapper.key="sUvQil1BnYGHRgIP" -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=3720 -Dwrapper.version="3.2.3" -Dwrapper.native_library="wrapper" -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 extensis.esp.win32.JBossService org.jboss.Main -b 0.0.0.0 > What is the exception stack you are getting when the keyTab file fails > to be located? Here's a bit of it; most of the stuff higher in the stack are just EJB/webservice layers: 2009-03-11 18:02:53,569 DEBUG [extensis.esp.core] 50 <unknown> <unknown> - creating service GSSCredential 2009-03-11 18:02:53,569 ERROR [extensis.esp.core] 50 <unknown> <unknown> Exception from GSSAPI: GSSException: No valid credentials provided at sun.security.jgss.GSSCredentialImpl.<init>(Unknown Source) at sun.security.jgss.GSSCredentialImpl.<init>(Unknown Source) at sun.security.jgss.GSSManagerImpl.createCredential(Unknown Source) at extensis.esp.core.identity.auth.GSSCredentialsValidator.establishContext(GSSCredentialsValidator.java:114) at extensis.esp.core.common.EspSessionBean.authenticateGSSAPICredentials(EspSessionBean.java:159) at extensis.esp.core.common.EspSessionBean.authenticateCredentials(EspSessionBean.java:146) at extensis.esp.core.common.EspSessionBean$AbstractFacadeMethod.invoke(EspSessionBean.java:248) at extensis.esp.core.ejb.SystemFacade.login(SystemFacade.java:112) at extensis.esp.core.ejb.SystemFacade.login(SystemFacade.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.invocation.Invocation.performCall(Invocation.java:359) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237) (etc...) I tried removing the -Dwrapper.key from the wrapper console output command and running it directly at the prompt - no change, server runs but same exception from GSS-API. Thanks for your help. - Chris |