Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Unix client agent security issue

Status
Not open for further replies.

mleggatt

Technical User
Jan 31, 2003
39
GB
I posted this issue here previously and though I had resolved the issue but it has turned out not to be the case. The backup is still failing on the unix client agents (solaris 2.7, 2.8) due to the security login failing on the Arcserve agents. I have looked on CA's site, Google, Newsgroups and found nothing relating to this. To summarise the enviroment:

Windows NT server (SP6)
ARCSERVE 2000 7.0 Build 1086

SunW,Ultra 250;Sparc;Sun4u
Sun OS release 5.7 Generic-106541-08
256Mb Ram
Client agent: Client Agent for ARCserveIT 6.61 Advanced Edition (Build 884)
Installation: \opt\uagent
\usr\CYEAGENT
Initially the issue occured on just one Solaris 2.7 server and I believed this may have been caused by a power failure and hostname change on the server. Subsequently the backup from another Solaris 2.8 box failed with similar symptoms even though I had altered nothing on this server or on the ARCSERVE backup job.

What happens is when the backup is run from an scheduled job overnight I get the following error:

20030611 091951 1146 E8531 Request denied by the client agent. (ADDRESS=@192.168.xxx.xxx (XXXXX ( 192.168.yyy.yyy )))

where xxx is the IP address of the server and XXXXX is the hostname.

When I look in the \usr\CYEagent\asagentd.log it looks as though the ARCSERVE server logs into the agent correctly:

06/17 18:45:06(9569) - (getRequest) enter ...
06/17 18:45:06(9569) - (getRequest) blkOffset=680
06/17 18:45:06(9569) - (getRequest) objType=0, opMode=14
06/17 18:45:06(9569) - (agentLogin) loginID=[root], paswd=[*]
06/17 18:45:06(9569) - (hostequiv) peerAddr=[192.168.xx.xxx]
06/17 18:45:06(9569) - (hostequiv) h_name=[YYYYY]UserID=[root]
06/17 18:45:06(9569) - (agentLogin) logged in OK.

but the backup fails with the error above.

To summarise I have done the following:

1. Confirmed that I can ping from both the Solaris servers to the Windows ARCSERVE server by name and by IP address.
2. Confirmed that I can telnet from the windows ARCSERVE server to the Solaris boxes using the same username and password as the ARCSERVE job uses.
3. Added the ARCSERVE server IP and hostname to the hosts files on the Unix servers and the Unix server names to the hosts files on the ARCSERVE server.
4. Tried re-installing ARCSERVE agents and then re-registering them using asagentdsetup script.
5. I have removed the Unix agents from the backup job (under backup manager - arcseve unix agents), saved the job, closed ARCSERVE manager, reopened ARCSERVE manager and then re-added the Unix machines by selecting add object and then putting in the correct username and password when prompted.

However when I try to browse down the tree to these I get "Failed to login to client agent" error box. The asagentd.log on when this happens shows:

6/04 17:38:04(1515) - (getRequest) enter ...
06/04 17:38:04(1515) - (getRequest) blkOffset=680
06/04 17:38:04(1515) - (getRequest) objType=0, opMode=14
06/04 17:38:04(1515) - (agentLogin) loginID=[], paswd=[*]
06/04 17:38:04(1515) - (hostequiv) peerAddr=[192.168.xxx.xxx]
06/04 17:38:04(1515) - (ckpasswd) Failed in getpwnam(), Socket operation on non-socket
06/04 17:38:04(1515) - -- Object [0] [/opt/uagent] ------------------
06/04 17:38:04(1515) - agent info: [Uagent] 5.0.0.2 0x0

Which looks as though the ARCSERVE server is not passing the username to the client agent and hence the login fails.
If I go directly into ARCSERVE activity screen and select a job and modify it, then click on the Unix agents tree and one of the failing unix boxes it prompts me for a username and password. If I click cancel and enter nothing the filesystem tree on the Unix server expands and I can browse the unix boxes file system. If however I put the correct username and password into these boxes the login fails and I cannot browse the file system.

I then tried modifying the job ensuring I could browse the Unix agents tree from the job screen and saved the job. I even checked under the security options for the job on these machines that the username and password were correct by re-entering them.

However the scheduled backup and "run now" backups of these two boxes still fails. Has anyone has similar issues and resolved them? Does anyone know where the usernames and passwords are kept for the backup job (I think it's in the backup job file).

Any hints or anwsers would be appreciated as I seem to have hit a dead end and this is driving me nuts!!!!.

Thanks in advance.
Martin
 
At last I finally found what was causing this and thought I would post explanation here to complete thread. Some time ago I added the following entries to some system files on the Solaris boxes to get the Uagentd daemon to startup automatically. If the server was rebooted the ARCSERVE agent would start automatically rather than having to manually start it each time:

\etc\services
uagentd 6050/tcp # ARCSERVE AGENT
uagentd 6050/udp


\etc\inet\inetd.conf
uagentd dgram udp wait root /opt/uagent/uagentd /opt/uagent/uagentd -i udp
uagentd stream tcp nowait root /opt/uagent/uagentd /opt/uagent/uagentd -i tcp

I then noticed in the syslog log files that it mentioned uagentd was looping many times and then failing. I think what was happening was either the Arcserve agent was already started and Inetd was attempting to start the uagentd daemon on recieving a request on port 6050 (ARCSERVES port) or everytime ARCSERVE server was sending a packet to port 6050 the inetd was trying to start a new uagentd process. It look as though the uagentd daemon needs to be started in an rc startup script when the server boots and not in inetd when ARCSERVE requests it as suggested on the Computer Associates support site!!!!!

Hopefully this may help someone else at some point.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top