Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dev.icinga.com #13389] bash command output available in configuration files #4819

Closed
icinga-migration opened this issue Dec 2, 2016 · 4 comments
Labels
area/configuration DSL, parser, compiler, error handling enhancement New feature or request

Comments

@icinga-migration
Copy link

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

Created by pooh on 2016-12-02 18:15:07 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-12-06 18:37:28 +00:00 (in Redmine)

Backport?: Not yet backported
Include in Changelog: 1

I'd like to have a function which I can call in a configuration file to get the output of a bash command.

Specific example: I define hosts by their FQDN; I'd like to be able to create a template which says "define 'address' if there is an IPv4 A record for that FQDN" and "define 'address6' if there is an IPv6 AAAA record for that FQDN", so that it's automatic for all hosts (and also updates on reloads if a record gets added or removed, for example).

I'm sure there are other use cases, but this is what I was trying to do when I found out there's no "system()" call, or backtick notation, in icinga2 configuration files.

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-12-05 13:44:40 +00:00

pros:

  • allows to easily create custom scripts shipping parts of the configuration logic
  • doesn't change much from a security point of view (we are forking plugins, so "exec" cannot be a problem for us)

cons:

  • would slow down the Icinga reload
  • Reload does a lot of things in parallel. As this would be called for every host, it would hammer your external data source
  • Could have bad consequences, think of an Icinga reload triggered by a cluster event during some network outage. And try to imagine what could happen when all DNS lookups would therefore time out.

In the meantime you could give Icinga Director a look. It provides import property modifiers to solve exactly this problem, and there are also multiple ones dealing with DNS lookups. They are configurable and let you for example specify that an unanswered lookup would either store the DNS name, leave the field empty or let the whole import run fail.

Cheers,
Thomas

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-12-06 17:28:14 +00:00

I am pro and contra in a similar way like Thomas is. I also do see problems with creating file dependencies referenced in those calls. What if they do not exist on a certain cluster node where the configuration is loaded? That involves in-depth knowledge about synchronising such as well. And it certainly involves additional documentation, support & troubleshooting. The Icinga 2 DSL already is somewhat dynamic and feels uncontrollable at some point. This would add a yet more complex difficulty level to it.

Still, I am open for discussion. What do others think of that?

@icinga-migration
Copy link
Author

Updated by pooh on 2016-12-06 18:37:28 +00:00

I'd like to think that the admins who make use of such a feature can be responsible about the scalability - it may not be appropriate for really big installations - but it could still be useful for smaller ones.

I think Thomas' comment that "as this would be called for every host, it would hammer your external data source" may be true for the DNS lookup example I gave, but for other uses it would only be called for a small number of hosts.

Also, regarding the "bad consequences", I'd hope that the admin using this would create logic around the system call in the configuration stanza so that timeouts or other inappropriate output don't make a complete mess of the object definition.

I'm not sure I see any greater problem with file dependences on various cluster nodes than already exists with custom plugins etc - you can reference them in your configuration and have it pushed to all the nodes, but you still have to separately ensure that the plugin scripts exist where they are needed.

@icinga-migration icinga-migration added enhancement New feature or request area/configuration DSL, parser, compiler, error handling labels Jan 17, 2017
@dnsmichi
Copy link
Contributor

There's no progress here, nor would we want to implement it. Closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/configuration DSL, parser, compiler, error handling enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants