[dev.icinga.com #1611] Support two external command files. #639

Closed
icinga-migration opened this Issue Jun 3, 2011 · 10 comments

Comments

Projects
None yet
1 participant
Member

icinga-migration commented Jun 3, 2011

This issue has been migrated from Redmine: https://dev.icinga.com/issues/1611

Created by rbowlby83 on 2011-06-03 18:58:19 +00:00

Assignee: (none)
Status: Closed (closed on 2012-04-13 14:29:14 +00:00)
Target Version: (none)
Last Update: 2014-12-08 09:32:32 +00:00 (in Redmine)


In distributed setups where the central host only receives passive checks it would be nice if the classic UI could send commands to the "collector" server. As it is there's no way to re-schedule a svccheck through the Classic UI when using a distributed setup.

If it could at least write the commands to two command files then I could script something to pass those checks along. Even better would be support for ssh-based checks.

Member

icinga-migration commented Jun 3, 2011

Updated by ricardo on 2011-06-03 20:56:49 +00:00

Hi,

There are no such plans at the moment to do that but there are tools which can help.

Have you tried socat? http://www.dest-unreach.org/socat/

I think with socat you can create a unix-pipe which gets transported over tcp to another server and pipe it via socat into the command pipe.

Never tried, but its worth a shot. And let us now if it worked.

Member

icinga-migration commented Jun 4, 2011

Updated by mfriedrich on 2011-06-04 10:03:16 +00:00

  • Status changed from New to Feedback

someone might add an opt-in to allow $app $args $icingacmd to be called (like several nagios plugins do e.g. check_dns calling nslookup) whereas $app consists of the ssh call, $args adds more params like user@foo.com -c ... and $icingacmd just contains the path to the commandfile (remotely).

this is just an idea, the real implementation and design is up to someone actually using ssh for distributing that stuff.

Member

icinga-migration commented Jun 4, 2011

Updated by rbowlby83 on 2011-06-04 18:49:10 +00:00

Thanks guys, I'm sure there are others who still prefer the classic UI but need to send commands to collector instances. Hopefully the opt-in will exist some day. I would help but it's outside my capabilities.

For now I just added a second command file to the cmd.c and used socat to send the results to the collector. It's a hack for sure but it works perfectly.

Added the socat to inittab. Here's the central servers:

sc:345:respawn:/usr/bin/sudo -u icinga /usr/bin/socat PIPE:/var/icinga/rw/icinga_collector.cmd TCP:HOSTNAME:PORT

Here's the collectors inittab:

sc:345:respawn:/usr/bin/sudo -u icinga /usr/bin/socat TCP-LISTEN:5667 PIPE:/var/icinga/rw/icinga.cmd

Works perfectly. Thanks for the socat suggestion!

[[http://www.ryanbowlby.com/infotech/send-external-commands/\]\]

Member

icinga-migration commented Jun 5, 2011

Updated by mfriedrich on 2011-06-05 02:14:27 +00:00

could you add a guide to the icinga wiki then? https://wiki.icinga.org/display/howtos/Home

Member

icinga-migration commented Jan 15, 2012

Updated by ricardo on 2012-01-15 01:43:01 +00:00

should we add another command file or not?

Member

icinga-migration commented Jan 15, 2012

Updated by rbowlby83 on 2012-01-15 03:12:33 +00:00

While I continue to use the setup documented previously it is not working as well as initially thought.

The problem is with socat and may even be considered a bug. The socat process listening on the remote "collector" icinga server, responsible for appending to the remote cmd file, ends up in a non-functional state. If the icinga service is restarted for any reason the init script removes and re-adds the cmd file. This causes the socat to lose functionality, but unfortunately does not terminate the process.

The hung socat on remote server kills the central servers socat process. init attempts to spawn without success and eventually stops trying. With nothing listening to the central servers second external cmd file, the cgi hangs when submitting a command (fifo being a blocking operation).

Alternative proposed solution:

Rather then have a second fifo perhaps extending the cgis to support remote RESTful submissions of commands. As well as a cgi configuration option to have the command submitted to remote collectors via this RESTful submission.

Central Server

  • User submits cmd
  • cgi writes to local cmd file (normal)
  • cgi checks cgi.cfg to see if cmd should additionally be sent to remote

(remote / collector)

  • remote receives submission request via HTTP and writes to local cmd file
Member

icinga-migration commented Jan 15, 2012

Updated by mfriedrich on 2012-01-15 10:48:16 +00:00

i would make it something more generic, allowing sort of an array of commandfiles.

actually, i have no idea how to let the user configure that in cgi.cfg

i'd rather integrate something based on icinga-mq distributed, also allowing the cgis to query that api for configs and status data.

Member

icinga-migration commented Jan 15, 2012

Updated by mfriedrich on 2012-01-15 10:48:49 +00:00

dnsmichi wrote:

i would make it something more generic, allowing sort of an array of commandfiles.

actually, i have no idea how to let the user configure that in cgi.cfg

i'd rather integrate something based on icinga-mq distributed, also allowing the cgis to query that api for configs and status data - broadcasting a command.

Member

icinga-migration commented Apr 13, 2012

Updated by ricardo on 2012-04-13 14:29:14 +00:00

  • Status changed from Feedback to Closed

closing for now. Reopen if needed.

Member

icinga-migration commented Dec 8, 2014

Updated by mfriedrich on 2014-12-08 09:32:32 +00:00

  • Project changed from 19 to Core, Classic UI, IDOUtils
  • Category changed from 53 to Classic UI
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment