We are running a typical zabbix server setup. A zabbix server and a couple linux servers that has zabbix agent installed and monitored by the zabbix server. However, my problem is there a way to check ping (icmppingsec maybe? :confused:) in between linux_host A to linux_host B and output the result to the zabbix server coming from linux_host A??
I have tried simple check icmppingsec[<target>,<packets>,<interval>,<size>,<timeout>,<mode>] but I found out that the ping is executed by the zabbix server itself and not the host A.
Thanks for the help!
Found solution to add this user parameter:
UserParameter=chk.fping[*],sudo /usr/bin/fping -c 3 $1 2>&1 | tail -n 1 | awk '{print $NF}' | cut -d '/' -f2
Add permition in /etc/sudoers because of error in creating SOCKET.
zabbix ALL=(ALL) NOPASSWD:/usr/bin/fping
In template you can add items you'd like to ping
chk.fping[8.8.8.8]
Currently, the ability to ping a host by Zabbix agent is not supported out of the box, but there is a feature request for that: ZBXNEXT-739. Meanwhile, you should add a user parameter on the agent that would do the pinging.
I have found a way to get the ping latency from the zabbix agent in order to ping an external host. I declared this parameter to the zabbix_agentd.conf
UserParameter=key_name[*],fping -e x.x.x.x | awk '{ print $4 }' | tr -d '('
It outputs the response time, numeric value only. My next problem is how to make this command readable by zabbix server so that it will be viewable thru graph. On zabbix server the output is "no data" but under Hosts > Items, it is green and enabled.
Thanks for the help!
Related
When I use command zabbix_agentd -t "proc.num[sshd]"
in zabbix agent machine,it returns proc.num[sshd] [u|3]
However, when I user command zabbix_get -k zabbix_agent IP -k proc.num[sshd]
in zabbix server machine,it returns 0
the version of zabbix is 1.8.
One of the common issues in such cases might be permissions: you might be running the first command under root, whereas in the second case the agent is running as a non-root user and is thus in a different environment.
Get in to the server to be monitored check the agent is running or not
Check your agent config file
>vim /etc/zabbix/zabbix-agent.conf
>server ip : your ip of zabbix server
Then save the file and restart the zabbix agent
sudo service zabbix-agent restart
Go to Zabbix dashboard and Monitoring > Latest data > select host > Apply
I'm currently trying to manipulate the metadata of my instance from the startup-script. To do that I have to use the following command :
gcutil setinstancemetadata <instance-name> --metadata=<key-1:value-1> --fingerprint=<current-fingerprint-hash>
As you can see the command ask for the instance-name. For I tried to get it from the metadata, but it was not there (see : Default Metadata).
My question is how to get this instance name ?
Edit: For now my only solution is to add the instance-name as a metadata when I create the instance :
gcutil addintance my-cool-instance --metadata=instance-name:my-cool-instance
And then get it with a curl request :
curl 'http://metadata/computeMetadata/v1/instance/attributes/instance-name' -H "X-Google-Metadata-Request: True"
Google Cloud Platform MetaData URL supports getting the instance name via hostname resource, irrespective of any custom hostnames set for the instance. That's why $HOSTNAME is not recommended.
URL1:
INSTANCE_NAME=$(curl http://169.254.169.254/0.1/meta-data/hostname -s | cut -d "." -f1)
URL2:
INSTANCE_NAME=$(curl http://metadata.google.internal/computeMetadata/v1/instance/hostname -H Metadata-Flavor:Google | cut -d . -f1)
GCP follows a common regex pattern for the resource names (?:[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?) , so it's safe to cut the result based on . and use the first part as the instance name.
The instance name is the same as its hostname, you can just use the $HOSTNAME environmental variable, e.g.:
gcutil setinstancemetadata $HOSTNAME --metadata=<key-1:value-1> --fingerprint=<current-fingerprint-hash>
This works on my instance which was built from the debian-7-wheezy-v20140318 image.
UPDATE: The above works fine on Debian 7 (Wheezy), but on OS's where the HOSTNAME variable is the fully qualified domain name, rather than just the host name, you should use the syntax below:
gcutil setinstancemetadata $($HOSTNAME | cut -d . -f1) --metadata=<key-1:value-1> --fingerprint=<current-fingerprint-hash>
A better means to get the instance name is to use the hostname command included in the GCE images :
[benoit#my-instance ~]$ hostname
my-instance
I have access to a MySQL database through ssh,
Could someone direct me to a MySQL-python code that will let me do this?
I need to save my query results on my local WINDOWS computer,
Thanks,
You can use SSH port forwarding to do this.. in fact first google hit looks to walk you through this exact thing:
http://www.howtogeek.com/howto/ubuntu/access-your-mysql-server-remotely-over-ssh/
And since you're on windows, translate that to using PuTTY:
https://intranet.cs.hku.hk/csintranet/contents/technical/howto/putty-portforward.jsp
You'll then connect to localhost:3306 with your python script, SSH will forward that over to the other machine and you'll end up connecting to the remote mysql instance.
You need to open up an SSH Tunnel to your sql server and then you can run paramiko to connect locally to the port you are using locally. This is done quite easily in *nix systems and I am sure you can download ssh command line too for windows. Try putty or plink, see here. What I do is I run a shell script like so, then I execute my paramiko python script, then I kill the
ssh -N remote_server#54.221.226.240 -i ~/.ssh/my_ssh_key.pem -L 5433:localhost:5432
python paramiko_connect.py
kill pkill -f my_ssh_key.pem # kill using the pattern,
#see ''ps aux | grep my_ssh_key.pem'' to see what it will kill
-N means don't execute any commands, -L is the local port to tunnel from, followed by the remotes server port, assuming you are connected to that server already.
Works like a charm for me for my postgres server & I did try it on mysql too.
I need to execute a mysql command on a remote server but seem to be hitting problem when it comes to executing the actual mysql bit
#!/usr/bin/expect -f
spawn /usr/bin/ssh -t root#10.0.0.2
expect "password: "
sleep 1
send "password\r"
sleep 2
/usr/bin/mysql databasename -e "update device_log set status = 'Y' where device_id in ('1','2');"
basically I want to change the flag to Y on device id's 1&2
but the script outputs
invalid command name "/usr/bin/mysql"
Just append the mysql command to the ssh command to run it in one go, like this:
#!/usr/bin/expect -f
spawn /usr/bin/ssh -t root#10.0.0.2 /usr/bin/mysql databasename -e "the query"
expect "password: "
sleep 1
send "password\r"
I'm not very much into expect, but I'm expecting that your attempt in the mysql line isn't actually valid syntax for expect to run a command.
Additionally:
You should use SSH keys for passwordless login instead of having a root password hardcoded in a script.
Consider running MySQL remotely e.g. mysql -h 10.0.0.2 -e "the query", or
Use port forwarding in SSH to connect to MySQL securely, e.g. run ssh -L 3307:localhost:3306 root#10.0.0.2 in the background and then connect to TCP port 3307 on localhost mysql -h 127.0.0.1 -P 3307.
It sounds like /usr/bin/mysql is not the the path to the mysql binary on that remote server. You could use just mysql instead, assuming that the binary is somewhere in that remote server's PATH. Otherwise you will have to go and find out where the binary is actually located and alter the absolute path accordingly.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I opened a ssh tunnel as described in this post: Zend_Db: How to connect to a MySQL database over SSH tunnel?
But now I don't know what I actually did. Does this command affect anything on the server?
And how do I close this tunnel, because now I can't use my local mysql properly.
I use OSX Lion and the server runs on Ubuntu 11.10.
Assuming you ran this command: ssh -f user#mysql-server.com -L 3306:mysql-server.com:3306 -N as described in the post you linked.
A breakdown of the command:
ssh: that's pretty self-explanatory. Invokes ssh.
-f: (From the man ssh page)
Requests ssh to go to background just before command execution.
This is useful if ssh is going to ask for passwords or
passphrases, but the user wants it in the background.
Essentially, send ssh to background once you've entered any passwords to establish the connection; it gives the shell prompt back to you at localhost rather than logging you in to remote-host.
user#mysql-server.com: the remote server you'd like to log into.
-L 3306:mysql-server.com:3306: This is the interesting bit. -L (from the man ssh page):
[bind_address:]port:host:hostport
Specifies that the given port on the local (client) host is to be
forwarded to the given host and port on the remote side.
So -L 3306:mysql-server.com:3306 binds the local port 3306 to the remote port 3306 on host mysql-server.com.
When you connect to local port 3306, the connection is forwarded over the secure channel to mysql-server.com. The remote host, mysql-server.com then connects to mysql-server.com on port 3306.
-N: don't execute a command. This is useful for "just forwarding ports" (quoting the man page).
Does this command affect anything on the server?
Yes, it establishes a connection between localhost and mysql-server.com on port 3306.
And how do I close this tunnel...
If you've used -f, you'll notice that the ssh process you've opened heads into the background. The nicer method of closing it is to run ps aux | grep 3306, find the pid of the ssh -f ... -L 3306:mysql-server.com:3306 -N, and kill <pid>. (Or maybe kill -9 <pid>; I forget if just kill works). That has the beautiful benefit of not killing all your other ssh connections; if you've got more than one, re-establishing them can be a slight ... pain.
... because now I can't use my local mysql properly.
This is because you've effectively "captured" the local mysql process and forwarded any traffic that attempts to connect to it, off to the remote mysql process. A much nicer solution would be to not use local port 3306 in the port-forward. Use something that's not used, like 33060. (Higher numbers are generally less used; it's pretty common to port-forward a combination like this: "2525->25", "8080->80", "33060->3306" or similar. Makes remembering slightly easier).
So, if you used ssh -f user#mysql-server.com -L 33060:mysql-server.com:3306 -N, you'd then point your Zend connect-to-mysql function to localhost on port 33060, which would connect to mysql-server.com on port 3306. You can obviously still connect to localhost on port 3306, so you can still use the local mysql server.
This will kill all ssh sessions that you have open from the terminal.
sudo killall ssh
Note: adding as answer since comments don't support code blocks.
In my opinion it is better to NOT use -f and instead just background the process as normal with &. That will give you the exact pid you need to kill:
ssh -N -L1234:other:1234 server &
pid=$!
echo "waiting a few seconds to establish tunnel..."
sleep 5
... do yer stuff... launch mysql workbench whatever
echo "killing ssh tunnel $pid"
kill $pid
Or better yet, just create this as a wrapper script:
# backend-tunnel <your cmd line, possibly 'bash'>
ssh -N -L1234:other:1234 server &
pid=$!
echo "waiting a few seconds to establish tunnel..."
sleep 5
"$#"
echo "killing ssh tunnel $pid"
kill $pid
backend-tunnel mysql-workbench
backend-tunnel bash