Pagerduty.cgi Integration URL

nagios
questions

(Troy Bennett) #1

Hello, first I’d just like to thank you so much for helping me in the past with some other issues that your advice helped me correct post haste. I’m finalizing my integration with Nagios and I am currently receiving triggers from Nagios to my phone via PD and I’m able to resolve and acknowledge challenges. I just have one question as I’m not sure how relative it is as I’m unable to browse to my URL containing my pagerduty.cgi to receive that POSTS error. My pagerduty.cgi is located at /usr/lib64/nagios/cgi/pagerduty.cgi so I was unsure of how much of the path would be necessary in the URL. The access log for my web server isn’t really giving any definitive information. Any advice helps. Thank you.


(Jonathan Curry) #2

In almost all cases the webhook URL will be http(s)://<host>/nagios/cgi-bin/pagerduty.cgi

For example, on my CentOS 7 system, I have pagerduty.cgi in /usr/local/nagios/sbin, and on Ubuntu 16.04 it’s in /usr/lib/cgi-bin/nagios3, but Apache is configured to route the same URL above to right place on each system.


(Troy Bennett) #3

Thank you. I just wanted verification because I know under the guide it will say something about POST when browsing to the site, but I’m just getting the unable to connect to server. I verified my nagios .cmd path is correct as well in pagerduty.cgi and that the file lives in the correct directory so I just wanted to ensure it’s setup correctly. I am getting notifications from my service, but wanted to ensure my web hook extension was working correctly.


(Demitri Morgan) #5

@Troy_Bennett Just wanted to chime in and add: if you’re seeing “unable to connect to server” when in your web browser when you’re trying to access the CGI script (to test that it’s set up properly) this could indicate any of several things, but the bottom line is that the HTTP service is inaccessible. Here are a few things you can try:

  • Check that Apache is running, i.e. via service httpd status (CentOS/RHEL) or service apache2 status (Debian/Ubuntu).
  • If the host is behind a firewall (or has a local firewall), ensure that the firewall rules permit accessing the host on the HTTP(S) ports 80 and 443 (assuming you’ve made no special configuration changes, these are the defaults)
  • Make sure that the server has a globally routable IP address, i.e. not a local one like 192.168.X.X
  • If the host exists in a private subnet (i.e. without a public IP address), ensure that NAT is configured properly so that the gateway forwards connections to it.

Also, make sure you have the host (IP or name) correct in the URL, and that in general you can connect to it.