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.
Related
I want to use dovecot as a local IMAP server to serve my offlineimap synced mails to gnus. This is on a Nixos installation. I have installed the dovecot package via my configuration.nix. however I am having trouble configuring it, seeing where the log files are, etc. I copy the configuration files (dovecot.conf and config.d) from /nix/store/dovecot/share/doc/dovecot/example-config. I can then modify slightly the files to allow plain login (no ssl required) just to test.I can start dovecot (as root). I see the process running, the relevant ports are open and listening, e.g. 143. Everything looks OK. No crashes. However when I telnet localhost 143 (for imap) to test, I am connected and then immediately the connection is closed by foreign host. This is not what I expect from the Dovecot Wiki. I should get a statement that Dovecot is ready …
Additionally, the command doveadm log find responds with:
Looking for log files from /var/log Debug: Not found Info: Not found etc.
So there seem to be no log files. journalctl -u dovecot2.service shows logs begin …, end at …
No entries, so no issues ? I cannot find a log file which tells me why the connection on 143 is immediately closed.
I am at a loss what is going on. Is it to do with users needed, etc ? Appreciate any help. Can post doveconf -n if needed.
As written in the configuration file for dovecot2 here: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/mail/dovecot.nix#L344 as dovecot2 is the name of the service journalctl -u dovecot2 should be the right command to run to view its logs. That said, if for some reason there's a bug in the configuration module the command journalctl will show you the complete log, dovecot's included.
It would be nice if you had written here your configuration, because given that the configuation entries for dovecot are those listed here https://nixos.org/nixos/options.html#services.dovecot2 it's not clear to me what you mean when you write ... I copy the configuration files (dovecot.conf and config.d) from /nix/store/dovecot/share/doc/dovecot/example-config ... The configuration in nixos is comprised for the most part of Nix source files that specify entries in the NixOS configuration tree I've linked before.
I was doing things completely wrong. I now specify the dovecot service to start in my configuration.nic file and it sets up the correct environment with all config files in their correct place. To change options in the config file, e.g maildir, I now specify them also in the configuration.nix file. Thanks for your answer.
I am getting the below given error when I try to forward certain log files using syslog-ng in Suse Linux
Starting syslog servicesError opening file for reading; filename='/tmp/app.log', error='Permission denied (13)'
my conf file - Source definition seems to be ok
source app {
file("/tmp/app.log");
};
I went through similar posts and dont see any problems with my steps.The weird part is that the file is owned by root and when i run syslog-ng as root it gives read permission error
Am I missing anything?
This problem is caused because of AppArmor linux security module. Solution to this problem is mentioned in attached thread. syslog-ng read file permission denied
Here are steps I followed.
Open /etc/apparmor.d/sbin.syslong-ng
Add /opt/xxx/logs/* rw, line anywhere. rw below means allow read & write access. Change your directory appropriately.
Run apparmor_parser -r /etc/apparmor.d/sbin.syslong-ng to set new rules.
Restart syslog-ng using service command or any other way you have set up.
I am trying to use a shutdown-script to create a new instance from within the the instance that is shutting down now.
The script has three tasks,
1. creates an empty file
2. get the name of the new instance to be created
3. generates a name for the next new instance to be spawned
4. creates a new instance from within this instance with the name generated.
Here is the script:
#!/bin/bash
touch /home/ubuntu/newfile.txt
new_instance_name=$(curl http://metadata.google.internal/computeMetadata/v1/instance/attributes/next_instance_name -H "Metadata-Flavor: Google")
next_instance_name="instance-"$(printf "%04d" $((${new_instance_name: -4}+1)))
gcloud beta compute --project=xxxxxxxxx instances create $new_instance_name --zone=us-central1-c --machine-type=f1-micro --subnet=default --network-tier=PREMIUM --metadata=next_instance_name=$next_instance_name --maintenance-policy=MIGRATE --service-account=XXXXXXXX-compute#developer.gserviceaccount.com --scopes=https://www.googleapis.com/auth/cloud-platform --image=image-1 --image-project=xxxxxxxx --boot-disk-size=10GB --boot-disk-type=pd-standard --boot-disk-device-name=$new_instance_name
This script is made executable using chmod +xand the file-name of the script is /home/ubuntu/shtudown_script.sh.he metadata shutdown-script for this instance is also /home/ubuntu/shtudown_script.sh.
All parts of the script runs fine when I run it manually from within the instance, so a new file is created and also a new instance is created when the current instance shuts-down.
But when it is invoked from API when I stop the instance, it only creates the file I create using touch command, but no new instance is created as before.
Am I doing something wrong here?
So I was able to reproduce the behavior you described. I ran a bash script similar to the one you have provided as a shutdown script, and it would only create the empty file called "newfile.txt".
I then decided to append the output of the gcloud command to see what was happening. I had to tweak the bash script to fit my project. Here is the bash script I ran to copy the output to a file:
#!/bin/bash
touch /home/ubuntu/newfile.txt
gcloud beta compute --project=xxx instances create instance-6 --zone=us-central1-c --machine-type=f1-micro --subnet=default --maintenance-policy=MIGRATE --service-account=xxxx-compute#developer.gserviceaccount.com --scopes=https://www.googleapis.com/auth/cloud-platform --boot-disk-size=10GB --boot-disk-type=pd-standard --boot-disk-device-name=instance-6 > /var/output.txt 2>&1
The output I received was the following:
ERROR: (gcloud.beta.compute.instances.create) Could not fetch resource: - Insufficient Permission
This means that my default service account did not have the appropriate scopes to create the VM instance.
I then stopped my VM instance and edited the scopes to give the service account full access as described here. Once I changed the scopes, I started the VM instance back up and then stopped it again. At this point, it successfully created the VM instance called "instance-6". I would not suggest giving the default service full access. I would suggest specifying which scopes it should have, but make sure that it has full access to Compute Engine if you want the shutdown script to work.
If the shutdown script works when you stop the VM instance using the command:
$sudo shutdown -h now
And does not work when stopping the VM instance from the Cloud Console by pressing the “Stop” button, then I suspect this behavior is to be expected.
A shutdown script has a limited period of time to run when you stop a VM instance; however, this limit does not apply if you request the shutdown using the “sudo shutdown” command. You can read more about this behavior here.
If you would like to know more about the shutdown period, you can read about it here.
I already had given my instance proper scope by giving the service account full access (which is a bad practice).
But the actual problem was solved when I reinstalled google-cloud-sdk using
sudo apt-get install google-cloud-sdk
When I was running those scripts before reinstalling gcloud by sshing into the instance it was using the gcloud command from preinstalled directory /snap/bin/gcloud. But when it runs from the startup or shutdown script, for some reason it can not get an access to the preinstalled /snap/bin/ directory, and when I reinstall google cloud sdk using apt-get the gcloud command was being accessed from /usr/bin/gcloud which I think is accessible by the startup or shutdown script.
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.
So when I bring up a GCE instance using the standard debian 7 image, and issue a "gsutil config" command, it fails with the following message:
jcortez#master:~$ gsutil config
Failure: No handler was ready to authenticate. 4 handlers were checked. ['ComputeAuth', 'OAuth2Auth', 'OAuth2ServiceAccountAuth', 'HmacAuthV1Handler'] Check your credentials.
I've tried it on the debian 6 and centos instances and had the same results. Issuing "gcutil config" works fine however. I gather I need to set up my ~/.boto file but I'm not sure what to.
What am I doing wrong?
Using service account scopes as E. Anderson mentions is the recommended way to use gsutil on Compute Engine, so the images are configured to get OAuth access tokens from the metadata server in /etc/boto.cfg:
[GoogleCompute]
service_account = default
If you want to manage gsutil config yourself, rename /etc/boto.cfg, and gsutil config should work:
$ sudo mv /etc/boto.cfg /etc/boto.cfg.orig
$ gsutil config
This script will create a boto config file at
/home/<...snipped...>/.boto
containing your credentials, based on your responses to the following questions.
<...snip...>
Are you trying to use a service account to have access to Cloud Storage without needing to enter credentials?
It sounds like gsutil is searching for an OAuth access token with the appropriate scopes and is not finding one. You can ensure that your VM has access to Google Cloud Storage by requesting the storage-rw or storage-full permission when starting your VM via gcutil, or by selecting the appropriate privileges under "Project Access" on the UI console. For gcutil, something like the following should work:
> gcutil addinstance worker-1 \
> --service_account_scopes=https://www.googleapis.com/auth/devstorage.read_write,https://www.googleapis.com/auth/compute.readonly
When you configured your GCE instance, did you set it up with a service account configured? Older versions of gsutil got confused when you attempted to run gsutil config when you already had service account credentials configured.
If you already have a service account configured you shouldn't need to run gsutil config - you should be able to simply run gsutil ls, cp, etc. (it will use credentials located elsewhere than your ~/.boto file).
If you really do want to run gsutil config (e.g., to set up credentials associated with your login identity, rather than service account credentials), you could try downloading the current gsutil from http://storage.googleapis.com/pub/gsutil.tar.gz, unpacking it, and running that copy of gsutil. Note that if you do this, the personal credentials you create by running gsutil config will essentially "hide" your service account credentials (i.e., you would need to move your .boto file aside if you ever want to user your service account credentials again).
Mike Schwartz, Google Cloud Storage team
FYI I'm working on some changes to gsutil now that will handle the problem you encountered more smoothly. That version should be out within the next week or two.
Mike