Hello,
I have troubles with starting AppServer broker with different user ID than AdminServer is running. When I enter userName, groupName and password in ubroker.properties as documentation says, broker does not start.
Error message is:
AS_pb01_ws is not responding (12076)
In admserv.log I have this:
[11/4/15 2:29:15 PM] [3] [OpenEdge] /progress/oe113/bin/jvmStart -d -w /progress/PB/work101/db01/AppSrv -u pylek:*** -o stdout -e 1 /usr/java7_64/jre/bin/java -classpath /usr/java7_64/jre/i18n.jar:/usr/java7_64/lib/tools.jar:/progress/oe113/java/progress.jar -DInstall.Dir=/progress/oe113 -Djava.security.policy=/progress/oe113/java/java.policy -DCanonicalName=fathom1.ibm5:ID=AppServer com.progress.ubroker.broker.ubroker -t AS -i AS_pb01_ws -r rmi://ibm5:20932/AS_pb01_ws -f /progress/oe113/properties/ubroker.properties
[11/4/15 2:29:15 PM] [3] [OpenEdge] * Exception executing jvmStart:
[11/4/15 2:29:15 PM] [3] [OpenEdge] * java.lang.NullPointerException
[11/4/15 2:29:15 PM] [3] [STDERR] java.lang.IllegalThreadStateException: process hasn't exited
[11/4/15 2:29:15 PM] [3] [STDERR] at java.lang.UNIXProcess.exitValue(UNIXProcess.java:278)
[11/4/15 2:29:15 PM] [3] [STDERR] at com.progress.ubroker.tools.SvcControlCmd.startService(SvcControlCmd.java:326)
[11/4/15 2:29:15 PM] [3] [STDERR] at com.progress.ubroker.tools.UBRemoteCommand.runIt(UBRemoteCommand.java:353)
[11/4/15 2:29:15 PM] [3] [STDERR] at sun.reflect.GeneratedMethodAccessor1044.invoke(Unknown Source)
[11/4/15 2:29:15 PM] [3] [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
[11/4/15 2:29:15 PM] [3] [STDERR] at java.lang.reflect.Method.invoke(Method.java:619)
[11/4/15 2:29:15 PM] [3] [STDERR] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:339)
[11/4/15 2:29:15 PM] [3] [STDERR] at sun.rmi.transport.Transport$1.run(Transport.java:189)
[11/4/15 2:29:15 PM] [3] [STDERR] at sun.rmi.transport.Transport$1.run(Transport.java:186)
[11/4/15 2:29:15 PM] [3] [STDERR] at java.security.AccessController.doPrivileged(AccessController.java:366)
[11/4/15 2:29:15 PM] [3] [STDERR] at sun.rmi.transport.Transport.serviceCall(Transport.java:185)
[11/4/15 2:29:15 PM] [3] [STDERR] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
[11/4/15 2:29:15 PM] [3] [STDERR] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:823)
[11/4/15 2:29:15 PM] [3] [STDERR] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
[11/4/15 2:29:15 PM] [3] [STDERR] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1176)
[11/4/15 2:29:15 PM] [3] [STDERR] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
[11/4/15 2:29:15 PM] [3] [STDERR] at java.lang.Thread.run(Thread.java:795)
The log entry is exactly the same regardless I have correct password or not.
The same works correctly when AdminServer is started as root - but our system admin does not like this option so I am trying to find another way.
OpenEdge is 11.3.3, OS is AIX 6.1.
Any ideas ?
Regards,
Piotr
Could be that surrounding artifacts are not useable by that user. For example, a directory or subdirectories. A file that is owned and readable only by root. Things like that.
Hi Piotr,
A few things come to mind:
1) the password is only used on Windows, does not need to be set, is not used on, Unix
2) the user that started the AdminServer must be able to change to the user that is starting the AppServer. So they must be in the same group at least. Verify the user that starts the AdminServer is in a group that the user starting the AppServer is in
3) also depending on what system your AIX box is using for authorization the AdminServer user may need permissions to access the passwd file
Let me know,
Roy
Hi,
Thank you both for reaction.
> 1) the password is only used on Windows, does not need to be set, is not used on, Unix
Are you sure ? When I started AdminServer as root I still had to enter password property in ubroker.properties, otherwise broker didn't start (which is also weird)
> 2) the user that started the AdminServer must be able to change to the user that is starting the AppServer. So they must be in the same group at least. Verify the user that starts the AdminServer is in a group that the user starting the AppServer is in
Both users are in the same group
> 3) also depending on what system your AIX box is using for authorization the AdminServer user may need permissions to access the passwd file
How to check what authorisation system is used ? passwd file is readable by everyone, but it does not contain passwords. I suppose shadow file is in /etc/security, but ordinary users can't see it.
> Could be that surrounding artifacts are not useable by that user. For example, a directory or subdirectories. A file that is owned and readable only by root. Things like that.
I have checked write access right to broker and server logs, cmdplugin.log, admserv.log, name server log and directories where all these reside. Everything is right. Anything else I should check ?
P.
Hi Piotr,
I stand corrected the older versions of AdminServer did not use the password, sometime it changed and the password is now used if added. In fact it is recommended that the password is used for better security. Sorry to mislead you.
Also the AdminServer needs to have access to the nsswitch.conf file which has to be able to access the passwd file to verify users or the AppServer will not start.
I would say from what you are seeing that the new user starting the AdminServer (not the root user) does not have access to verify the user. How the system call getuid() is resolved might help you and your system administrator figure out where the problem might be.
Roy
Hi Roy,
I have talked to our system administrators. We have local user authentication on unix server, passwords are stored in /etc/security/passwd, which is not readable for ordinary users. I assume that this is the reason of the problem.
So there is no other way than starting AdminServer as root or implementing NIS for user authentication, right ?
Regards,
Piotr
Hi Piotr,
can your system administrator set up a user account for the AdminServer that has access to user authentication? This would prove the point.
If not I would think NIS would be the best bet, but even then the user starting the AdminServer would need to have access.
Regards, Roy
Hi Roy,
When sysadmin got choice to implement NIS or allow AdminServer to start as root, he eventually chosen second option :) So for now problem solved. Thanks for help !
Regards,
Piotr