Execute a script located on Zabbix server on trigger - zabbix

We are monitoring our production environments using Zabbix 2.4. New instances are provisioned with Ansible that sets up a Zabbix agent. What we need is for hosts to be removed from the server if they have been terminated so that we only receive messages about running instances becoming unavailable.
To do this I wrote a Python script that can take a zabbix host name as an argument, check if that host is on the list of running instances by calling awscli and delete the host if it's not on a "not terminated" list.
I put the script in /usr/bin/delete_host.py and configured an action to call for it when a "Agent not available" trigger is activated. This is how the Operation tab looks like link
And here is the Action Log link
I've tried a couple of ways to write the command, also placed the script in ExternalScripts directory. Turned on debug logs for the server but nothing in it mentioned an error or anything. In fact it only showed messages that command is being executed and everything is ok, but the host is still there. When I copy the command from Action Log and execute it manually everything works fine.
At this point I am really out of options on how to troubleshoot this further. I disabled selinux and added zabbix user to sudoers file with nopasswd. I can't find anything in any logs. Is it even possible to execute non-messaging scripts with zabbix?

Try to write the script in a way that will print "OK" or 0 if it ran properly and the error message or error code if it fails. Run the script using an active zabbix agent item on the Zabbix server host (use the function system.run). In this way you'll be able to create a trigger that will raise an error if the script fails to run.
You can also just schedule it using a different tool such as Rundeck.

The script does not have to be in the ExternalScripts directory, that is only required for items of type "external check". The operation screenshot you linked to uses relative path of delete_host.py, and that is almost guaranteed not to work. Your action log screenshot shows a few entries with /usr/bin/ prefixed, which is better.
At least for testing, make sure to specify full path to everything, including the python binary, for example /full/path/to/python /full/path/to/delete_host.py.
You also had a few entries that redirected all output to a file in /tmp/, but you didn't mention what got logged in there. Please use that approach and check the potential error messages as well.

Remote commands from "Actions" are run using the key system.run[command,nowait]. This "nowait" key returns 1 irrespective of the command result.
Try running system.run with "wait" parameter and see what the actual error is under "Latest data".
For me the error was "sudo: sorry, you must have a tty to run sudo" even i had "Defaults:zabbix !requiretty" in the sudoers file. I commented out the "#Defaults requiretty" line in /etc/sudoers file and it worked.

Related

libvirt qemu hook is not running

I am following what's suggested in this article to change the iptables rules in order to allow incoming connections. For some reason, the qemu hooks does not run. I simply tried to write into a file with echo 'some output' > someweirdfilename before making any vm name checks to run the actual script itself to later check the existence of the file. It looks like the hook is not executed at all. Made sure that libvirtd.service is restarted, so is guest and eventually tried the complete reboot. All resulted in the same. Running libvirt 7.6.0 on a fedora 35. Does anyone have any suggestions for troubleshooting?

InstallShield 2014, Custom Actions and executing sql files into MySQL

I am building an installer for our product which works well. I've managed to build custom actions to install our services including a MySQL server.
The problem I have is executing a sql file to build the schema structures.
I have a custom action which uses mysql.exe and the command line arguments:
--port=### --user=### --password=### < "[INSTALLDIR]db\EmptyStruct.sql"
It tries to execute this ok but the cmd window which pops up, during the install, just runs through the mysql.exe command line options, which says to me that the command line it gets passed is not correct. However if I run the command manually after the install, it works perfectly.
Does anyone has any ideas please.
I'm making a few assumptions here:
You have a Windows Installer exe custom action that specifies mysql.exe and a command line as you showed
You are expecting the contents of [INSTALLDIR]db\EmptyStruct.sql to be redirected to mysql.exe's standard input
This will not happen. Behind the scenes, Windows Installer's exe custom action support uses the CreateProcess API and this API will interpret command lines literally. However the redirect < needs special handling to actually perform redirection.
To get that behavior, you must use a layer of indirection. For example, you could run cmd.exe as the exe, and give it a command line that will make it interpret and run the command line mysql.exe --port= ... < "[INSTALLDIR]...". However, if you didn't already have a command prompt showing, this would cause one to show up. If you want to avoid that, you could write a custom wrapper that performs the redirection for you, either as a C++ DLL or, say, InstallScript action.
Alternately, if there is a parameter that tells mysql.exe to run a script from a file, you could pass that instead of using redirection. I wasn't able to find evidence of such a parameter in a quick web search.
Thanks for your comments Michael and I used cmd.exe /k AddStruct.bat to accomplish the task!

external auth module for ejabberd on windows

How can I get ejabberd to run an external auth script on windows?
So far- I've modified the file
C:\Program
Files\ejabberd-15.06\lib\ejabberd-15.06\priv\cfg\ejabberd.yml
to comment out the existing auth_method directive and instead added this:
auth_method: external
extauth_program: "D:\\DROPBOX\\Dropbox (Personal)\\EJABBERD\\auth\\ejabberd-auth.exe"
However, when I try to connect to the server- I see nothing in the logs indicating an attempt to run the script. I've even tried changing it to a non-existant file to see if that will log an error of some sort, but nothing.
All I get are "Accepted connection" type of logs.
In case it matters- upon start I do get several "unknown option" errors, including "ejabberd_config:validate_opts:752 unknown option 'auth_method' will be likely ignored" - however it seems this is a known, cosmetic-only error (see: https://github.com/processone/ejabberd/issues/630)
I do not use Windows, but, you should try playing with Erlang open_port command:
open_port({spawn, "YOURCOMMAND"}, [{packet, 2}]).
Note that open_port Erlang documentation says:
For external programs, the PATH is searched (or an equivalent method is used to find programs, depending on operating system). This is done by invoking the shell on certain platforms. The first space separated token of the command will be considered as the name of the executable (or driver). This (among other things) makes this option unsuitable for running programs having spaces in file or directory names.
I see your path has spaces. That alone should indeed make it impossible to call your command.
That said, external_auth command has never been tested on Windows. You may need to patch ejabberd command to make that authentication through external process work. I would be surprised if it works as is.

Zabbix external checks cannot be executed due to SELinux

I try to implement external checks in Zabbix 2.2. I've created simple bash script for SSL verification which should be executed by zabbix service. The script is located in /var/lib/zabbixsrv/externalchecks directory. Even if there are 777 permission for the .sh script I still receive message telling
unable to execute /var/lib/zabbixsrv/externalscripts/test.sh: Permission denied
I've got same message when I try to run the command even as root. The ls -Z /var/lib/zabbixsrv/externalscripts/test.sh command output says:
-rwxrwxrwx. zabbixsrv zabbixsrv unconfined_u:object_r:default_t:s0 /var/lib/zabbixsrv/externalscripts/test.sh
There is no message relating this in /var/log/massages. Does anybody know how to force selinux to allow execute zabbixsrv user the script without disabling selinux?
Which zabbix service (zabbix-server, zabbix-agent, ...) should execute the external checks script?
Did you tried to set AllowRoot=1 in /etc/zabbix/zabbix_agentd.conf?
The main issue was in /etc/fstab configuration file. The Zabbix has defined as default values for script /var/lib/zabbixsrv/excernalscripts directory. My server has /var mounted with rw and noexec permissions.
I've already moved the script to different location and change the configuration file accordingly. Checks are working fine now.
Thanks everybody for any contribution relating this topic.

SSIS package not running when called as step in SQL Job

I have a .dtsx file (an SSIS package) that downloads files from an FTP server and imports data. It runs fine whenever I run it manually. However, when I schedule calling the package as a step in a SQL server agent job, it fails. The step it fails at is the one where I call a .bat file. The error in the job history viewer says this:
Error: 2009-05-26 12:52:25.64
Code: 0xC0029151 Source: Execute
batch file Execute Process Task
Description: In Executing
"D:\xxx\import.bat" "" at "", The
process exit code was "1" while the
expected was "0". End Error DTExec:
The package execution returned
DTSER_FAILURE (1).
I think it's a permissions issue, but I'm not sure how to resolve this. The job owner is an admin user, so I've verified they have permissions to the directory where the .bat file is located. I've tried going into Services and changing the "Log On As" option for SQL Server Agent, and neither option works (Local System Account and This Account). Does anyone have ideas as to what other permissions need to be adjusted in order to get this to work?
I tried executing just the batch file as a SQL Job step, and it gave more specifics. It showed that it failed when I was trying to call an executable, which was in the same directory as my .bat file, but not in the windows/system32 directory, which is where it was executing from.
I moved the executable to the system32 directory, but then I had no clue where my files were being downloaded to. Then I found that there's a property for the Execute Process Task (the one that executes the .bat) called WorkingDirectory. I set this to be the directory where the bat is located, moved the executable back into the same one as the .bat file, and it's now working as expected.
For me it was a permissions issue. Go to Environment --> Directories, then change Local directory to something the SQLAgentUser can access. I used C:\temp. Click the dropdown for Save, and choose "Set defaults".
Are you executing the SSIS job in the batch file, or is the batch file a step in the SSIS control flow?
I'm assuming the latter for this answer. What task are you using to execute the batch file (e.g. simple execute program task or a script task). If the latter, it looks like your batch file is actually failing on some step, not the SSIS script. I'd check the permissions of what your batch file is trying to access
In fact, it might be a better idea to rewrite the batch file as a script task in SSIS, because you'll get much better error reporting (it'll tell you which step in the script fails).
You could try executing the batch file using the runas command in a command window. If you try and execute it under the local system or network system account, it should give you a better error. If it does error, you can check the error level by going "echo %ERRORLEVEL%".
If it wasn't the latter, and you're executing the SSIS package via a batch file, why?
Are you possibly accessing a mapped drive in your .bat file? If so, you can't rely on the mapped drive from within the service, so you'd have to use UNC path.
I had the same error and I resolved it by logging on to the user account that runs the job, opened Coreftp site in question there, test the site access, made the change there (in my case, I had to reenter the new password) and now it works.
So yes, it is an issue of file access. This one is file access to the coreftp site in question.