Did some research and the reverse tunnel would show up as a listening port (that may have been obvious to some of you but I didn't know).
I now have done some limited testing of a perl based script called check_opsview_slave_rtunnel . The script -runs from the slave server -looks at "opsview-slave.conf" to fetch master server and slave port -uses Net::SSH to connect to the master and looks for listening process for its slave port -if it can't find a match is restarts the opsview-slave service I played around shutting down the opsview-slave service watching the check go critical and restarting things so I was pretty excited about that. I now need to hope my periodic issue with the reverse tunnel dropping happens on its own so I can be sure I am detecting the original problem. I had to add NET::SSH (libnet-ssh-perl in debian/ubuntu) to all my slave servers so I didn't check to see if there was a preferred opsview way of calling ssh. Anyway if it looks like the script works I'll be glad to share it with anyone who is interested. I actually think for the reverse ssh setup it would be a good fallback check when things don't go as planned with the autossh. The alternative to the script was to turn on autossh monitoring which the author of the tool says is buggy. James Whittington VC3, Inc. -----Original Message----- From: James Whittington Sent: Friday, May 15, 2009 12:32 PM To: 'Opsview Users' Subject: RE: [opsview-users] periodic autossh issues with reverse tunneldropping >Use netstat to look for the slave port which should be listening on the master. >This is how the master communicates with the slave - down this tunnel. >If you can't see it on the master then restart autossh on the slave - >using the opsview-slave script for example. I am working on a perl based script to run from the slave server that fetches the master address and port number from "opsview-slave.conf" then checks the master for the correct tunnel. Looking at my list of Opsview related tunnels on the master server I am not sure which ones I should be keying off of. If the reverse tunnel was down what would my output look like. For instance slave server at 25807 has these listed on the master, if the reverse tunnel was down would the status on one of these change? tcp 0 0 127.0.0.1:25807 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:51646 127.0.0.1:25807 TIME_WAIT tcp6 0 0 ::1:25807 :::* LISTEN I've never tried to ssh through perl scripting that I can recall but I had to add NET::SSH in the script I'm working to keep the process from forking. Any guidance would be appreciated as the periodic dropped tunnels are a pain to deal with. Thanks, James Whittington VC3, Inc. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Andrew Hall Sent: Friday, May 15, 2009 6:19 AM To: opsview-users Subject: Re: [opsview-users] periodic autossh issues with reverse tunneldropping On 2009-05-15 02:44, James Whittington wrote: > My other approach is to set up a check on the slave server to somehow > check for the existence of the reverse tunnel and restart the slave > service if it is detected as being down. > > I can do a process listing (from the slave to the master) and see ssh > sessions but I'm not sure how I would detect the existence of the > correct reverse ssh process? Use netstat to look for the slave port which should be listening on the master. This is how the master communicates with the slave - down this tunnel. If you can't see it on the master then restart autossh on the slave - using the opsview-slave script for example. Let me know how you get on as I'm looking to implement something similar myself :-) _______________________________________________ Opsview-users mailing list [email protected] http://lists.opsview.org/listinfo/opsview-users _______________________________________________ Opsview-users mailing list [email protected] http://lists.opsview.org/listinfo/opsview-users
