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

[dev.icinga.com #2474] add modified attributes reset command to extinfo.cgi allowing to reset to original config #922

Closed
icinga-migration opened this issue Mar 28, 2012 · 10 comments

Comments

@icinga-migration
Copy link

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

Created by mfriedrich on 2012-03-28 16:30:46 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2012-04-24 15:06:45 +00:00)
Target Version: 1.7
Last Update: 2014-12-08 09:27:11 +00:00 (in Redmine)


modified attributes are more prior (set via webgui) than the original config, so the core will use those and override settings from original config.

normally, you don't see that in the gui. you'll only see e.g. that notifications are disabled, then rush into the config, see that they are not, wonder why, look into retention.dat, see modified attributes. within #2473 they will be shown.

but we also need a way to actually reset those modified attributes accordingly via a command sent via cmd.cgi

CHANGE_HOST_MODATTR

CHANGE_HOST_MODATTR;;

This command changes the modified attributes value for the specified host. Modified attributes values are used by Icinga to determine which object properties should be retained across program restarts. Thus, modifying the value of the attributes can affect data retention. This is an advanced option and should only be used by people who are intimately familiar with the data retention logic in Icinga.

CHANGE_SVC_MODATTR

CHANGE_SVC_MODATTR;;;

This command changes the modified attributes value for the specified service. Modified attributes values are used by Icinga to determine which object properties should be retained across program restarts. Thus, modifying the value of the attributes can affect data retention. This is an advanced option and should only be used by people who are intimately familiar with the data retention logic in Icinga.

given that, the reset should set that to 0

include/common.h:#define MODATTR_NONE                            0
include/common.h:#define MODATTR_NOTIFICATIONS_ENABLED           1
include/common.h:#define MODATTR_ACTIVE_CHECKS_ENABLED           2
include/common.h:#define MODATTR_PASSIVE_CHECKS_ENABLED          4
include/common.h:#define MODATTR_EVENT_HANDLER_ENABLED           8
include/common.h:#define MODATTR_FLAP_DETECTION_ENABLED          16
include/common.h:#define MODATTR_FAILURE_PREDICTION_ENABLED      32
include/common.h:#define MODATTR_PERFORMANCE_DATA_ENABLED        64
include/common.h:#define MODATTR_OBSESSIVE_HANDLER_ENABLED       128
include/common.h:#define MODATTR_EVENT_HANDLER_COMMAND           256
include/common.h:#define MODATTR_CHECK_COMMAND                   512
include/common.h:#define MODATTR_NORMAL_CHECK_INTERVAL           1024
include/common.h:#define MODATTR_RETRY_CHECK_INTERVAL            2048
include/common.h:#define MODATTR_MAX_CHECK_ATTEMPTS              4096
include/common.h:#define MODATTR_FRESHNESS_CHECKS_ENABLED        8192
include/common.h:#define MODATTR_CHECK_TIMEPERIOD                16384
include/common.h:#define MODATTR_CUSTOM_VARIABLE                 32768
include/common.h:#define MODATTR_NOTIFICATION_TIMEPERIOD         65536

Attachments

Changesets

2012-04-23 17:43:23 +00:00 by mfriedrich 1538f2d

classic ui: add modified attributes row to extinfo.cgi showing diffs to original config #2473 add modified attributes reset command to extinfo.cgi allowing to reset to original config #2474

unluckily a combined commit for both.

thing is that current objects contain the
modified_attributes, which is stored in
retention.dat by the core, plus written/read
to/from status.dat
the cgis did not have that as statusdata
defined, so changed that, now keeping the
status objects with another attribute.

ever since modified_attributes is a bitmask
we need to re-calculate that into a string.
printing it plain (json) and colored (html)
makes this another row in extinfo.cgi

while seeing the modified_attributes, one
might want to reset those - just changing
the values won't reset the modification
itsself.

problem - normally cmd.cgi would not allow
to send CHANGE_* commands. this is now
opened, but only for the MODATTR change cmds
as well es only allowing new cgi GET param
'attr' to bet set to 0 (reset, MODATTR_NONE).
other values will provoke an error on the
cmd.cgi not allowing you to send that cmd
to the core, in order to prevent XSS and such.

combined, this generates another valuable
enhancement for the Icinga Classic UI :)

(the idoutils database already got those
information, so Icinga Web can fetch them
already)

plus: adding modified_attributes to json
output for extinfo.cgi too

plusplus: new cmd.cgi GET param 'attr'

refs #2473
refs #2474

2012-04-24 06:59:49 +00:00 by mfriedrich 47b36d1

Changelog: add thx to Sven Nierlein for the idea of modified_attributes in classic ui

refs #2473
refs #2474

2012-04-24 14:55:59 +00:00 by ricardo b37cbf2

classi-ui: fixed some stuff in lost commit for modified attributes #2473, #2474

refs: #2473
refs: #2474

* added Changelog entry I forgot to add earlier
* removed compiler errors for extinfo.c and idoutils/logging.c
* added "Reset Modified Attributes" command to
  host and service command list in status.cgi
* remove left over line for debugging.

2012-04-24 21:56:46 +00:00 by ricardo 68c59b7

classic-ui: changed downtime->is_in_effect in extinfo to true/false #2473/#2474

refs: #2473
refs: #2474

* changed dispalying of downtime->is_in_effect to true/false
* removed a compile error

Relations:

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-03-28 16:37:40 +00:00

reset means - MODATTR_NONE

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-03-28 16:52:50 +00:00

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

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-03 15:02:16 +00:00

  • Target Version changed from 1.7 to 1.8

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-23 15:43:28 +00:00

hmpf. the cgis do not allow to send commands like CHANGE*

        if (!command || (strlen(command) > 6 && !memcmp("CHANGE", command, 6)))
                return ERROR;

this must be lowered for

CHANGE_HOST_MODATTR
CHANGE_SVC_MODATTR

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-23 17:37:55 +00:00

  • File added icinga_classicui_1.7_extinfo_modified_attributes_other_than_none01.png
  • File added icinga_classicui_1.7_extinfo_modified_attributes_other_than_none02.png
  • Target Version changed from 1.8 to 1.7

well actually this can be done quite handy, allowing those 2 commands, and checking if the attr value is something different than MODATTR_NONE.

try it with a custom value

icinga_classicui_1.7_extinfo_modified_attributes_other_than_none01.png

submit the form, works via POST, so send hidden values

icinga_classicui_1.7_extinfo_modified_attributes_other_than_none02.png

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-23 17:50:07 +00:00

  • Status changed from Assigned to Feedback
  • Done % changed from 0 to 90

currently in dev/cgis, please test!

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-24 06:58:23 +00:00

  • File added icinga_classicui_1.7_extinfo_modified_attributes_reset.png

icinga_classicui_1.7_extinfo_modified_attributes_reset.png

@icinga-migration
Copy link
Author

Updated by ricardo on 2012-04-24 15:01:58 +00:00

looks good and works for me.

You can set this to "resolved"

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-24 15:06:45 +00:00

  • Status changed from Feedback to Resolved
  • Done % changed from 90 to 100

fine, thanks for testing plus fixing smaller issues. we might then re-assign the docs issue as well.

@icinga-migration
Copy link
Author

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

  • Project changed from 19 to Core, Classic UI, IDOUtils
  • Category set 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