Custom Userparameter Permission Question

[ldunston]

I'm having some difficulty getting a UserParameter to work correctly. I think it's a permissions problem but can't seem to work around it.

My UserParameter is the following:
UserParameter=custom.chat.users,cd /usr/local/ejabberd-2.0.0.2/bin; ./ejabberdctl connected-users-number

When I run that command from the CLI as the zabbix user, it returns the value as expected. However, when zabbix runs that command it returns an error.

The ejabberdctl command requires a cookie file with 400 permissions and owned by the user calling the command. That file exists for both root and zabbix and works as expected via CLI. When zabbix server runs that command it looks as though ejabberdctl was called by the root user.


Output of ./zabbix_get -s chat-server -k custom.chat.users

{error_logger,{{2009,6,3},{13,22,10}},"Error when
reading /root/.erlang.cookie: eacces",[]}

That same error occurred from the CLI prior to creating the cookie file for the zabbix user. I've tried putting the userparameter arguments into a bash script and calling the script but I get the same error.

Any insight into zabbix_get calls vs. running something via CLI would be appreciated.

Thanks,
Les

[nelsonab]

First question is do you need to have the cd statement, or can you execute it with a fully qualified path name?

What if you wrapped this with a bash script or something similar.

Also when you are calling it from the command line how do you become the Zabbix user? Are you doing "su zabbix" or "su - zabbix"? The second method is preferred as it will setup the full environment from the zabbix user. The first method inherits the environment from the origional user.

[ldunston]

Thanks for the reply.

The command requires execution from the directory (relative path dependencies) so the cd is required.

I've tried wrapping it in a bash script and calling the script as the userparameter but get the same result (i.e. ejabberdctl looks for the root cookie file instead of the zabbix cookie file).

The script works as expected via CLI. I'm using su - zabbix from root and then running the command.

I've setup zabbix as a sudoer and added the NOPASSWD option for calling the script as 'sudo ejabberusers.sh' but that throws a "Must have tty" error in the zabbix agentd log.

My best guess thus far is that ejabberctl can't really figure out the UID when it's called from within zabbix so the next thing I'm trying is to port a ejabberctl-zabbix script that uses the default zabbix shell account.

--Les

[ldunston]

So after banging my head for awhile I worked around it by moving the userparameters to a cronjob that write to file and set the new userparameters to cat the file which works. Still seems like a hack

[nelsonab]

I think you're close on the UID postulation. Can you look at the source to see where the jabber program is getting it's uid? If so could you then set that as an environment variable within your wrapper script? Also out of curiosity, if you add the following "id > /tmp/script_userid" what do you get in the /tmp/script_userid file? Does it show Zabbix there?

[trikke]

Hi,

just a guess but try:
UserParameter=custom.chat.users,cd /usr/local/ejabberd-2.0.0.2/bin && ./ejabberdctl connected-users-number

Or even
./zabbix_get -s chat-server -k sytem.run["cd /usr/local/ejabberd-2.0.0.2/bin && ./ejabberdctl connected-users-number"]

To check the user : ./zabbix_get -s chat-server -k sytem.run["id"]

Greets
Patrick

[ldunston]

Hi Guys,
Thanks for the responses.

So when echoing id into a file it shows the id is indeed zabbix.

Patick,
Changing the UserParameters to those you suggested yield the same results. Ejabberctl is still searching for the root cookie file even though the id of the caller is clearly zabbix. I'm chocking this up to ejabberdctl doing something whacky. I've got a work around for now which is putting the ejabberdctl into a cronjob that echoes online users to a file. Zabbix just reads the contents of the file. I'll revisit this when I have more time and post anything I find but I'm good for now.

Thanks again for the help.

--Les