Module: check_mk
Branch: master
Commit: 56f05ee2757289fd649757d399c396873dc7c847
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=56f05ee2757289…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Fri May 2 18:06:08 2014 +0200
Cumulative permissions and contact groups for WATO folders
WATO folders have now two new checkboxes in the <i>Permissions</i> attributes:
<ul>
<li><i>Give these groups also permission on all subfolders</i></li>
<li><i>Add these groups as contacts in all subfolders</i></li>
</ul>
The first one will add the configured groups of a folder also as permitted
groups to all subfolders (recursively). The second one will add the configured
groups as <b>contact groups</b> to the hosts in all subfolders.
The idea behind that is a simplification of the configuration. It is now
sufficient to specify the groups of you more general administrators at
the top of the folder tree and add more and more specific groups at
the lower levels of your folder tree.
In the table of hosts you now will see the permitted groups and the
contact groups of a host as two separate columns.
---
.werks/965 | 25 ++++
ChangeLog | 1 +
web/htdocs/wato.py | 203 +++++++++++++++++++++++---------
web/plugins/wato/builtin_attributes.py | 2 +-
4 files changed, 176 insertions(+), 55 deletions(-)
Diff: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=56f05ee275…
Module: check_mk
Branch: master
Commit: ed201374b763b56197c36fef707adbc021da5e9c
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=ed201374b763b5…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Fri May 2 13:48:25 2014 +0200
FIX Fix hanging shutdown of CMC on RedHat 5.X
When using the CMC on RedHat/CentOS 5.X then the CMC would not correctly
shutdown. The reason is, that the Python implementation of that OSes
raises an Exception on sys.exit, while newer versions don't. This has
been fixed by handling <tt>SystemExit</tt> explicitely.
---
.werks/964 | 12 ++++++++++++
ChangeLog | 1 +
modules/notify.py | 4 ++++
3 files changed, 17 insertions(+)
diff --git a/.werks/964 b/.werks/964
new file mode 100644
index 0000000..9f81088
--- /dev/null
+++ b/.werks/964
@@ -0,0 +1,12 @@
+Title: Fix hanging shutdown of CMC on RedHat 5.X
+Level: 2
+Component: notifications
+Class: fix
+State: unknown
+Version: 1.2.5i3
+Date: 1399031217
+
+When using the CMC on RedHat/CentOS 5.X then the CMC would not correctly
+shutdown. The reason is, that the Python implementation of that OSes
+raises an Exception on sys.exit, while newer versions don't. This has
+been fixed by handling <tt>SystemExit</tt> explicitely.
diff --git a/ChangeLog b/ChangeLog
index 6f65994..54fd5a1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -91,6 +91,7 @@
* 0752 FIX: FIX: compute correct state transitions for notifications...
* 0753 FIX: FIX: correctly show original state in HTML notification mails...
* 0609 FIX: mail notification script now uses 6 digit hex codes for colors to be better compatible with web based mail browsers
+ * 0964 FIX: Fix hanging shutdown of CMC on RedHat 5.X...
Reporting & Availability:
* 0756 Allow availability of multisite BI aggregates at once...
diff --git a/modules/notify.py b/modules/notify.py
index 2aa518d..4351b46 100644
--- a/modules/notify.py
+++ b/modules/notify.py
@@ -370,6 +370,10 @@ def notify_keepalive():
sys.stdout.write("*")
sys.stdout.flush()
+
+ # Fix vor Python 2.4:
+ except SystemExit, e:
+ sys.exit(e)
except Exception, e:
if opt_debug:
raise
Module: check_mk
Branch: master
Commit: a55b7ca559e5230743d1a432280c122f4b17e0ee
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=a55b7ca559e523…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Fri May 2 13:40:31 2014 +0200
Added draft for notification configuration (now really!)
---
doc/drafts/README.notification_configuration | 89 ++++++++++++++++++++++++++
1 file changed, 89 insertions(+)
diff --git a/doc/drafts/README.notification_configuration b/doc/drafts/README.notification_configuration
new file mode 100644
index 0000000..b9983a6
--- /dev/null
+++ b/doc/drafts/README.notification_configuration
@@ -0,0 +1,89 @@
+Configuration of notification plugins
+-------------------------------------
+
+Currently the only API for making notification plugins configurable is via
+a list of unnamed number parameters. The values of this list can be configured
+at the place where the notification is being setup (i.e. in a channel of
+flexible notifications and in a rule in the RBN).
+
+For the legacy ASCII-email in addition there are global options.
+
+This is not flexible enough, for several reasons. Here are some
+examples of missing configuration options:
+
+* Configure a From address for HTML emails
+ - This should be done as a global option
+
+* Configure a Reply-To address for HTML emails
+ - This should be on options to be set in the actual notification
+ rule, so that different rules can set differen reply-tos.
+
+* Configure the general structure of HTML emails
+ Which fields should be displayed? How should the subject
+ look like, etc.
+ - This should be global. Otherwise the user would have to repeate
+ the complete configuration for each rule.
+
+* Configure credentials for an SMS gateway
+ - should be a global option
+
+
+So what we need is two things:
+
+1. WATO configuration for the global settings of a notification. We
+could do this either as true global options. Or we could do that
+rule based. The idea: every notification is about a specific host
+and maybe also a service. So we could use the WATO rule system
+for having different groups of hosts have different global
+notification settings.
+
+2. WATO configuration for the per-rule settings of a notification.
+In order to be as flexible as possible we could allow the *same*
+configuration values as for the global settings. If we implement
+this as a dictionary with optional values then the settings
+in a specific rule can simply override global settings. So for
+example you could specify a From: address via a global setting
+but override this in a single rule.
+
+
+IMPLEMENTATION
+--------------
+Each notification plugin can optionally register a WATO
+configuration for its options. This must be of type dictionary
+and is configured in share/check_mk/web/plugins/wato/notifcations.py
+For each configuration there will be created two WATO rules:
+one for host notifications, one for service notifications.
+
+The same configuration will also be added to the notification
+rules. Here we need to change the way the script selection and
+cancelling is being configured, since the configuration of
+the plugin must be displayed as soon as the plugin is being
+selected.
+
+For each plugin that has a configuration a second plugin
+needs to be registered: One that converts the dictionary
+into a list of command line arguments. When a notification
+is being created then the upper configuration rules are
+being executed, then rule-specific configuration can
+override the parameters and as a last step this is
+being converted into command line arguments.
+
+Plugins that do not have a WATO configuration (legacy
+style, self written plugins) directly use a list
+of strings - like now.
+
+
+ACTUAL CONFIGURATION PARAMTERS
+------------------------------
+We will start by implementing the following parameters for
+the HTML emails:
+
+1. From: address
+2. Reply-To: address
+3. Subject:
+--> It is allowed to use macros like $HOSTNAME$ here.
+
+4. Selection of data fields to show. This will be selection from
+a list of fields, e.g. "Host name", "Service Description", "Current state",
+"Type of notification", etc..
+
Module: check_mk
Branch: master
Commit: 773c636bf11af94548fa64065e26b52ae2e5a5ee
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=773c636bf11af9…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Fri May 2 13:40:17 2014 +0200
Added draft for notification configuration
---
doc/drafts/LIESMICH.baum_anhand_von_tags | 52 ------------------------------
1 file changed, 52 deletions(-)
diff --git a/doc/drafts/LIESMICH.baum_anhand_von_tags b/doc/drafts/LIESMICH.baum_anhand_von_tags
deleted file mode 100644
index c14a81d..0000000
--- a/doc/drafts/LIESMICH.baum_anhand_von_tags
+++ /dev/null
@@ -1,52 +0,0 @@
-Konzept für ein automatisches Erzeugen eines Baumes
----------------------------------------------------
-
-Ausgangspunkt: WATO sieht über die Ordnerstruktur für Hosts vor, dass man
-diese hierarchisch organisieren kann. Nun gibt es hier leider nur einen
-Baum. Manchmal möchte man die Hosts nur unter dem Gesichtspunkt von
-anderen Hierarchien sehen.
-
-Die Idee ist jetzt, dass man dazu die vorhandenen Hosttag-Gruppen
-verwendet. Denn jeder Host hat in jeder Taggruppe genau einen
-Wert. Der Benutzer könnte jetzt eine Anzahl von Taggruppen
-herauspicken, z.B.:
-
-1. Standort
-2. Anwendung
-3. Kritikalität
-
-Diese können dann in hierarchieebenen eines logischen Baumes
-umgewandelt werden. Auf der obersten Ebene wäre der Standort,
-darunter die Anwendung, darunter die Kritikalität.
-
-Das ganze könnte man wie folgt umsetzen:
-
-1. In den globalen Einstellungen für Multisite fügen wir eine neue Option ein,
-mit der man beliebige virtuelle Baumansichten anlegen kann. Das wird als
-Liste realisiert. Dort kann man pro Eintrag eingeben:
- - Einen Titel für die Ansicht
- - Eine sortierte Liste von Hosttaggruppen, die den Baum bilden sollen.
-
-2. Ein neues Sidebar-Snanip "Virtuelle Baumansicht" wird geschrieben. Dieses
- erlaubt die Auswahl einer der oben realisierten virtuellen Bäume (falls
- es mehr als einen gibt). Es stellt dann diesen Baum zum Aufklappen dar.
-
- Wenn man auf einen Ast klickt, ergibt sich dadurch eine Liste von
- Hosttags bzw. von nicht vorhandenen Hosttags (wenn man bei Checkbox-
- Hosttags den negativen Wert wählt, oder ein Tag leer ist).
-
- Man landet dann auf der Ansicht "All Hosts", bei welcher der Filter
- für die Host-Tags vorausgefüllt ist.
-
-3. Die Ansicht "All Hosts" bekommt standardmäßig immer den Filter für
- die Host Tags.
-
-
-Eine mögliche Ausbaustufe wäre, dass man das Verhalten des neuen
-Snapins analog zu dem "Folders"-Snapin macht. Das würde bedeuten,
-dass man nicht immer auf die Ansicht "All Hosts" gelangt, sondern
-auf die jeweils gewählte Ansicht. Dazu müsste in jeder Ansicht
-der Hosttag-Filter implizit vorhanden sein. Außerdem müsste
-der kombinierte Filter aus Ordner und Tags dann sauber funktionieren.
-Frage ist, ob das nicht zu komplex wird.
-