Automic Workload Automation

Hi
Hope somebody will be able to point me in the right direction.

We are setting up a new system and currently have several Unix agents on different servers. On one of the servers we are unable to run any Unix jobs - they are all failing with "U02001007 User 'uc4system' is unknown or an invalid password has been provided." error message. 
The password is correct etc (I am able to putty onto the server as uc4system and run commands on the server).
However, I've noticed the following in the logs when this particular Agent is starting up:

20170809/171514.354 - start real user name :  'uc4system'

20170809/171514.354 -                 . userID :  '9441'

20170809/171514.354 -                 . groupID :  '10000'

20170809/171514.354 -                 . home directory :  '/home/UC4SYSTEM'

20170809/171514.354 -       effective user name :  'uc4system'

.....while for the Agent on a different server where we have no problems runing UNIX commands, the log looks like this:

20170805/020008.054 - 20170721/181834.954 - start real user name :  'uc4system'

20170805/020008.054 - 20170721/181834.954 -                 . userID :  '9441'

20170805/020008.054 - 20170721/181834.954 -                 . groupID :  '10000'

20170805/020008.054 - 20170721/181834.954 -                 . home directory :  '/home/UC4SYSTEM'

 

20170805/020008.054 - 20170721/181834.954 -       effective user name :  'root'

If somebody could advise how to fix it, it would be much appreciated.

Thanks

Irene

20170809/171514.354 -       effective user name :  'uc4system'

20170805/020008.054 - 20170721/181834.954 -       effective user name :  'root'

I'd suspect the issue comes from there. The owner of the agent has to be user 'root' and permissions should be 4755.

There is a known error related to this issue, here is the link :
https://automic.force.com/support/apex/CommunityArticleDetail?id=ka4b00000004MLy                                           

Best regards,
Antoine

Thanks for this.

I was able to actually resolve this by following instructions in the "Mandatory file permissions for Linux Agents" white paper.

I've updated UC_HOSTCHAR_DEFAULT variable of client 0, setting 
ANONYMOUS_FT = Y
ANONYMOUS_JOB = Y

Re-started the Agent and it started working. Unix commands are getting executed without any issues. Cannot call shell scripts though (jobs end OK however shell scripts on the server dont do what they are supposed to do, but this could be a separate issue all together)

While Antoine_Sauteron is likely correct in his analysis, I find the linked content rather confusing (and in part also factually wrong: There is no sticky bit for binaries, only for directories).

On most Unix (and Linux), you can run the "stat" command on your agent binary and check the permissions it currently has, like so:

stat /path/to/agent/ucxjlx6 | grep -i "uid"

The result should look like this:

Access: (4755/-rwsr-xr-x)  Uid: (    0/    root)   Gid: (  169/   aeadm)

The important bits are: It must be owned by Root (Uid is 0, which is root), and the permissions need to be 4755 (or at least start with the "4"). If you compare the output of this command between the working and non-working server, you'll probably see a difference.

Then, as root on the non-working machine, run this:

chown root: /path/to/agent/ucxjlx6 && chmod 4755 /path/to/agent/ucxjlx6

Replace /path/to/agent with the actual path, obviously.

This is also in the installation document and has possibly been overlooked while installing. It's the second part of paragraph 2, at this impressive link:

https://docs.automic.com/documentation/webhelp/english/AWA/12.0/DOCU/12.0/AWA%20Guides/help.htm#AE_AWA_Source/Installation/ucaaks.htm%3FTocPath%3DInstallation%2520Guide%7CInstalling%2520the%2520Automation%2520Engine%7CNew%2520Installation%7CInstallation%2520Procedure%7CInstalling%2520the%2520Agents%7C_____11

Best,
Carsten

Hi Carsten

Thank you for your feedback. I've run the suggest command on the sever where the Agent isn't working (unless I change the settings on client 0 as per my previous comment) and it seem to return the result that suggests that the Agent is set up correctly?

Hi Irene,

Yes, it looks indeed as if both of your agents are configured correctly with regards to the suid bit.

Some more pointers:

Some distributions come with security frameworks such as selinux enabled, in the default install. Such a thing might also prohibit the agent to run as root, or possibly make use of the suid bit. So maybe have a look if your non-working server has selinux enabled. If so, check the logfiles (kernel log or separate selinux logs) for signs of the agent getting rejected. If you find evidence of that, you might want to write an selinux rule to either allow the agent to fully work, or disable selinux altogether.

It is also possible to mount file systems in a way that prevents running suid executables off of them. Have a look at the output of "mount" (as root) or /etc/fstab (on Linux), for the file system your agent is on. It should NOT have the mount flag "nosuid". "defaults" would be fine though, because that automatically includes the flag "suid", which is what you want.

I notice that your uc4 agent is installed under "/home". This is somewhat unusual (such binaries, especially daemons, usually get installed to /opt, /usr or /usr/local on UNIX-like systems). This means that the culprit may well be selinux policies or mount options, because /home is oftentimes secured by these mechanisms on a default install of some Linux distributions.

Last, you could analyze the agent's attempts to switch user by using strace (on Linux - there are equivalent tools on most other UNIXes, e.g. "truss" on SunOS/Solaris). "strace" prints the results of the agent's syscalls to the kernel. This is a somewhat advanced topic however.

Alternatively, you might want to open a trouble ticket with the Automic support, assuming that your file permissions are, as demonstrated, in order.

Hope this helps. Best,
Carsten