Connecting remotely to AppServer on UNIX via Windows Progress Explorer Tool

#1
Hello Everyone,

As the title suggests, I'm trying to Connect to an AppServer that is on a UNIX machine via Windows through the Progress Explorer Tool GUI. I've tried putting in the UNIX's server name in the "Server" textbox when you click New -> Add Progress Server, I use my root account (root account on UNIX) to attempt to log in, but I keep getting the following error:

"Invalid username and/or password specification. (9173)"

What am I doing wrong? Am I missing an installation/configuration on the UNIX (or Windows) machines? At first, I thought it was a security problem, but, using the root username should have gotten passed the security, but it didn't, so I'm thinking it's a connection problem, but not sure where to go from here.

Any help is apprieciated.

Thanks,

Tim


Additional Info (if needed):
UNIX Machine:
Running Apache
Running OpenEdge 10.2A
Running AdminService

Windows Machine (it's just a developer's machine):
Windows 7
OpenEdge 10.2A
AdminService Running
Progress Explorer Tool

If more information is needed, just let me know.
 
#4
vinod_home,

Thanks for the prompt reply. I checked to see if adminserver is running on the unix machine as root, and it is. I also checked out the admserv.log and the last entry in it is from March. (below is the last few lines of my admserv.log file (not going to post the whole thing here since it's a rather large file)).

[3/13/10 11:40:27 AM] [2] [AdminServer] Shutting down plugin Plugin.Da
tabaseAgent. (7436)
[3/13/10 11:40:27 AM] [3] [AdminServer] Shut down plugin Plugin.Databa
seAgent. (7437)
[3/13/10 11:40:27 AM] [2] [AdminServer] Shutting down plugin Plugin.UB
PropMgr. (7436)
[3/13/10 11:40:27 AM] [3] [AdminServer] Shut down plugin Plugin.UBProp
Mgr. (7437)
[3/13/10 11:40:27 AM] [2] [AdminServer] Shutting down plugin Plugin.Sy
stem. (7436)
[3/13/10 11:40:27 AM] [3] [AdminServer] Shut down plugin Plugin.System
. (7437)
[3/13/10 11:40:27 AM] [2] [AdminServer] Shutting down plugin Plugin.Ma
nagement. (7436)
[3/13/10 11:40:27 AM] [3] [AdminServer] Shut down plugin Plugin.Manage
ment. (7437)
[3/13/10 11:40:27 AM] [2] [AdminServer] AdminServer unbinding from reg
istry. (7419)
[3/13/10 11:40:27 AM] [1] [RegistryManager] Unregistering primary object w
ith name Chimera, and removing the registry. (7884)
[3/13/10 11:40:27 AM] [1] [AdminServer] Shutdown complete. (7420)
As you can see, the last input was 3/13/10 (over a month ago).

I also look at the Solution ID you gave and I'm not sure if it applies to me (since that Solution ID is for connecting to Adminserver on the same host, my UNIX and Windows are on two different machines), unless I'm reading it completely wrong, otherwise just put me in my place...lol.
 

RealHeavyDude

Well-Known Member
#5
From what I read in your admin server log file

[3/13/10 11:40:27 AM] [1] [RegistryManager] Unregistering primary object w
ith name Chimera, and removing the registry. (7884)
[3/13/10 11:40:27 AM] [1] [AdminServer] Shutdown complete. (7420)
the last thing the admin server did was to shut down ...

Are your sure that the admin server is running? If not configured otherwise, the admin server runs on port 20931.

HTH, RealHeavyDude.
 
#6
Do you have two versions of progress running on that machine. Try to restart the admin server and see if you have any new messages in the log file.

HTH
 
#7
Hey Guys,

Thanks for the replies.

RealHeavyDude, Yes I made sure it was running. When I ran the command "proadsv -query" it returned the following:

Euclides: /home/mis/sbtim> proadsv -query
OpenEdge Release 10.2A03 as of Wed Feb 24 21:09:11 EST 2010
AdminServer is alive. (8545)
Euclides: /home/mis/sbtim>
So I can only assume it's running.

vinod_home: No, we only have OpenEdge 10.2A running on the UNIX machine.

Is there certain start up parameters that I need to set for this remote connection to happen properly?
 
#9
Hey TomBasom,

Thanks for the reply.

I tried to set the "Server Name" (on the Progress Explorer Tool Add popup) to the ip address and i kept with the default port (20931) and I get the same error.
 
#10
From reading your initial post, makes me wonder if you aren't using the correct login... are you entering a user and password that is set up in the Progress database or the unix login?

Connecting remotely you need to use a username/password setup within Progress, not the *nix system.
 
#11
Hello LarryD,

Thanks for the reply. The username/password I am using is a UNIX account (as well as a username/password set up in the Progress Database). I just tried to connect to a AdminServer that is running on a different Windows machine (running Windows Server 2003 R2) and I was able to connect to that without any problem (using a valid windows username).

This doesn't seem like it should be this difficult to set up, but seems like my systems are being difficult lately...haha.
 
#12
We have had the same problem; at one point (don't remember which Progress version, but it was HP-UX) we tracked it down to Windows and Unix handling CR and LF differently, and this somehow messing things up. We never could get it to work with Progress Explorer, now we use the Management Console and it is OK.

Anne
 
#13
Hey Anne,

Thanks for the reply. I'm REALLY hoping that's not the case for me...haha. I dug a little more deeper on it, and come to find out, apparently my log files have been pointing to my backup directory (dunno why/how, but it is), so here is the lastest from my log file:

[4/26/10 4:10:39 PM] [2] [Security] sbtim:Y:No Group Checking: User
is not authenticated. (9897)
[4/26/10 4:12:03 PM] [2] [Security] sbtim:Y:No Group Checking: User
is not authenticated. (9897)
Which, is a little more helpful than what I have been given in the past. Now are there any other suggestions? I checked to make sure my password I'm using is correct (which it is), so now I'm at a loss).

Thanks for all those that have replied thus far. Definitely helping me learn the innards of how things are set up.
 

RealHeavyDude

Well-Known Member
#14
It's been a long time that I had to fiddle with this. But there is an option during installation ( and, AFAIK, unfortunately it's checked by default ) which asks you whether the admin server should check groups or not. AFAIK, if that is checked then you need to set up security groups for the admin server which must contain the OS accounts in order to be able to successfully connect to it.

Didn't dig very deep into this, but, in the ubroker.properties file there is a section [AdminRole] where you should be able to change it. Mine looks like this:

[AdminRole]
apps_defaults=
apps_enable=
apps_props=
apps_stats=
servlet_props=
servlet_services=read
servlet_stats=

[AdminRole.PSCAdmin]
apps_defaults=read,write
apps_enable=read,write
apps_props=read,write
apps_stats=read,write
servlet_props=read,write
servlet_services=read,write,delete
servlet_stats=read,write

[AdminRole.PSCOper]
apps_defaults=read
apps_enable=read
apps_props=read
apps_stats=read
servlet_props=read
servlet_services=read
servlet_stats=read
You also might want to check the knowledge base entry "ID: P136009 Title: "Progress Explorer fails to start a database and generates a "User is not authenticated" error in the adminserv.log file." ...

HTH, RealHeavyDude.
 
#15
Hello RealHeavyDude,

Thanks for the reply. My ubrokers.properties file looks just like yours and still doesn't work. we ended up changing it to be:

[AdminRole]
apps_defaults=read,write
apps_enable=read,write
apps_props=read,write
apps_stats=read,write
servlet_props=read,write
servlet_services=read,write
servlet_stats=read,write
Restarted the AdminServer and that doesn't work either. Ugh, this is a rather annoying problem...haha.
 
#16
try to use admingroup parameter when you start the AdminServer on unix. That way you can log in using a unix user belonging to the group.

sudo proadsv -start -port 20931 -admingroup dbagroup

HTH
 
#17
Hey vinod_home,

Thanks for the reply. I just attempted to start the AdminServer (as root) with a -admingroup parameter. That didn't seem to work either. I've got an open ticket with progress right now on this problem (but, they are taking forever to get back to me and when they do respond, it was stuff I already tried, thanks to you guys :) ). Any other suggestions would be helpful.

Loks like Progress will be getting a call from me today...haha

Thanks,

Tim
 
#19
Hello,

Unfortunetly it did not get resolved since we are apparently using a trusted system on HP for our security and it isn't supported by Progress. I'm currently looking into an easy way to switch our security to something that Progress does support.

Thanks,

Tim
 
Top