Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #1329] add complete command line to config.cgi #591

Closed
icinga-migration opened this issue Mar 22, 2011 · 20 comments
Closed

Comments

@icinga-migration
Copy link

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

Created by mfriedrich on 2011-03-22 12:17:33 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2011-11-01 11:59:15 +00:00)
Target Version: 1.6
Last Update: 2014-12-08 09:40:03 +00:00 (in Redmine)


currently, it does not replace $USER1$ and $HOSTADDRESS$ etc macros, only the $ARGn$ macro - it would be nice to grab those macros from the existing config like when a normal check happens and give the user a full command line for testing/debugging purposes.

Attachments

Changesets

2011-10-07 00:12:30 +00:00 by mfriedrich 067de8b

* classic ui: add complete command line to config.cgi #1329

** if resource.cfg readable by webserver for $USERn$ macros
** adds host/service params to config.cgi to process their macros

the processed command line is presented as 'raw commandline'.
if the resource.cfg can't be read a warning is being shown.

association is done via host and/or service making the command
expander more useful for viable copy paste of commands into
icinga users shell for manual testing.

refs #1329

2011-10-11 21:52:30 +00:00 by ricardo 527d782

classic-ui: enhanced add complete command line to config.cgi #1329

refs: #1329

* Now $ARGXX$ MACROS get resolved as well in raw command line.
* Only users who are authorized_for_full_command_resolution can see raw command line.
* commands can be "reexpanded" without loosing hostname or service description.

two new cgi config options added:
	authorized_for_full_command_resolution
	authorized_contactgroup_for_full_command_resolution

new auth function added:
	authorized_for_full_command_resolution()

2011-10-20 09:53:05 +00:00 by mfriedrich 10934c9

config.cgi: command expansion: allow raw commandline to be shown if no hosts/services params given (if authorized) #1329

refs #1329

Relations:

@icinga-migration
Copy link
Author

Updated by ricardo on 2011-05-20 11:24:10 +00:00

the $USERXX$ MACROS will be difficult. These are in resource.cfg and this one is usually only readable by the core, because it can contain passwords.

@icinga-migration
Copy link
Author

Updated by ricardo on 2011-06-20 20:53:37 +00:00

  • Status changed from New to Feedback

any ideas on that?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-07-16 12:33:39 +00:00

the main problem is that you can't use the already processed and loaded commands like the core would do with process_macros_r within get_raw_command_line_r

most likely, you need to

  • reparse configs to gather everything
  • add host and svc as GET target for config.cgi - if not you can't expand the macros dependent on host and/or service (e.g. $HOSTADDRESS$
  • rewrite the targets to config.cgi expander
    • extinfo.cgi - ACTIVE checks
    • config.cgi - hosts, services, contacts, etc urls
  • let the config expander process the commandline based on the host and service information

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-07-16 14:55:08 +00:00

  • File added 0001-basic-attempt-to-grab-all-macros-for-config.cfg-expa.patch

i've hacked around in icinga cgis, but this proof of concept is not yet completed.

see the attached diff against current test/cgis, which tries the basic host and service macros (if provided via GET param). the main problem remain the other macros, which need to be first grabbed into the mac struct (there are no global macros in cgis!) and then processed on the command line.

feel free to enhance that.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-09-12 13:39:18 +00:00

  • Status changed from Feedback to Assigned
  • Assigned to set to mfriedrich

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-09-23 09:23:08 +00:00

the $USERn$ macros can't be read directly, that requires base/config.c:read_resource_file in order to fill macro_user char array.

this methods needs to be implemented into the cgis too. the problem which remains - if apache is not allowed to read resource.cfg (that should be default for security reasons). so i would add another cgi.cfg like show_all_user_macros=1 (0 by default) and if enabled, warn if resource.cfg cannot be read.

furthermore, common/macros:grab_macro_value_r implemented the method where this array is being read. on the cgis the overall process_macros_r calls that (e.g.

cgi/status.c:                                   process_macros_r(mac, temp_host->notes_url, &processed_string, 0);
cgi/status.c:                                   process_macros_r(mac, temp_host->action_url, &processed_string, 0);
cgi/status.c:                                   process_macros_r(mac, temp_host->icon_image, &processed_string, 0);
  • but the *output on $USERn$ always remains NULL and it's not yet used either.

the other parts with passing hostname and servicedesc will resolve the association on the other parts.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-10-03 17:45:29 +00:00

any other thoughts on the $USERn$ macro solution? the host and service macros should be resolved by passing get params - if they are null, the default should be shown.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-10-07 00:18:30 +00:00

  • Category set to 43
  • Done % changed from 0 to 80

i have now pushed a version onto dev/cgis which does the following

* classic ui: add complete command line to config.cgi #1329

** if resource.cfg readable by webserver for $USERn$ macros
** adds host/service params to config.cgi to process their macros

the processed command line is presented as 'raw commandline'.
if the resource.cfg can't be read a warning is being shown.

association is done via host and/or service making the command
expander more useful for viable copy paste of commands into
icinga users shell for manual testing.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-10-07 00:20:50 +00:00

  • File added classicui_config_cgi_complete_commandline_resource_file_not_readable.png

it does not even need a config option, it just checks if the resource cfg is readable and if not, showing a warning in info table.

classicui_config_cgi_complete_commandline_resource_file_not_readable.png

@icinga-migration
Copy link
Author

Updated by tgelf on 2011-10-07 16:59:06 +00:00

Hey, that's a great feature! Even if there is the possibility to disable it by just keeping default permissions on your ressource.cfg I'd suggest to add some kind of additional filter/permission option to your cgi.cfg. The reason I'm asking this for is simple: I want to see the full command when there is something going wrong, but most of my Icinga-Users shouldn't, as it contains sensitive information.

People are currently using resource.cfg and customvars to store passwords, community strings and other sensitive stuff. What do you think about adding something like this to the cgi.cfg:

authorized_for_full_command_resolution=icingaadmin
sensitive_customvars=_COMMUNITY,_PASSWORD

Users "authorized_for_full_command_resolution" shall see everything, all the others able to see their host/service configs will not see $USERxy$-vars and customvars matching sensitive_customvars.

Cheers,
Thomas

@icinga-migration
Copy link
Author

Updated by ricardo on 2011-10-07 20:50:09 +00:00

this sounds good

@dnsmichi: when I try to expand a command, the raw command doesn't contain the $ARG*$ values. Can you have a look?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-10-09 12:19:31 +00:00

i don't know what you mean. can you rephrase/clarify that, maybe with a screenshot?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-10-09 12:23:22 +00:00

tgelf wrote:

Hey, that's a great feature! Even if there is the possibility to disable it by just keeping default permissions on your ressource.cfg I'd suggest to add some kind of additional filter/permission option to your cgi.cfg. The reason I'm asking this for is simple: I want to see the full command when there is something going wrong, but most of my Icinga-Users shouldn't, as it contains sensitive information.

People are currently using resource.cfg and customvars to store passwords, community strings and other sensitive stuff. What do you think about adding something like this to the cgi.cfg:

authorized_for_full_command_resolution=icingaadmin
sensitive_customvars=_COMMUNITY,_PASSWORD

Users "authorized_for_full_command_resolution" shall see everything, all the others able to see their host/service configs will not see $USERxy$-vars and customvars matching sensitive_customvars.

the first target would be easy to implement, but matching on sensitive custom vars would be rather tricky. i'd rather take the other suggestion in adding some new macros in a credentials file and make resource.cfg just the resource file for paths, but not user credentials.
custom variable resultion requires some tests though - i hadn't got those in mind, thanks for the pointer.

@icinga-migration
Copy link
Author

Updated by ricardo on 2011-10-11 21:55:37 +00:00

  • Done % changed from 80 to 90

Now users can only see raw command line if they are authorized for.

Custom vars only get resolved in raw command line.

commit message:

* Now $ARGXX$ MACROS get resolved as well in raw command line.
* Only users who are authorized_for_full_command_resolution can see raw command line.
* commands can be "reexpanded" without loosing hostname or service description.

two new cgi config options added:
    authorized_for_full_command_resolution
    authorized_contactgroup_for_full_command_resolution

new auth function added:
    authorized_for_full_command_resolution()

please TEST!!!

@icinga-migration
Copy link
Author

Updated by ricardo on 2011-10-12 20:17:39 +00:00

  • File added expand_command_final.png
  • Status changed from Assigned to Feedback

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-10-12 21:47:44 +00:00

enclose a picture filename with 2 '!' signs, to make it visible :)

expand_command_final.png

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-10-20 09:51:56 +00:00

  • Done % changed from 90 to 100

yeah, thats how it should be done. nice working together, ricardo! :)

  • urls with host/service from extinfo.cgi work
  • to expand pushes the host/service over, expands it correctly
  • simple to expand usage shows me a bug which i missed on the macro grabbings

config.cgi?type=command&expand=check_local_ido2db1:0.5

does not show raw commandline. this is the case because it's only printf'd when host/service objects are matched.

a proper fix for that will be in git soon.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-10-20 09:58:24 +00:00

https://git.icinga.org/?p=icinga-core.git;a=commit;h=10934c9

works as expected, pushed to dev/cgis - please test it and then merge to test/cgis

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-11-01 11:59:15 +00:00

  • Status changed from Feedback to Resolved

@icinga-migration
Copy link
Author

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

  • Project changed from 19 to Core, Classic UI, IDOUtils
  • Category changed from 43 to Classic UI

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant