Module: check_mk
Branch: master
Commit: f90d813c6c965c5d597657f5f632c09315924727
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=f90d813c6c965c…
Author: Lars Michelsen <lm(a)mathias-kettner.de>
Date: Tue Oct 2 15:16:29 2012 +0200
Fixed view editor change with current code
---
.bugs/584 | 7 +++++--
.bugs/716 | 7 +++++--
web/htdocs/views.py | 1 +
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/.bugs/584 b/.bugs/584
index abe9047..5c7530e 100644
--- a/.bugs/584
+++ b/.bugs/584
@@ -1,9 +1,12 @@
Title: How to control windows agent installer via cli
Component: docu
-State: open
+Class: todo
+State: done
Date: 2012-01-10 16:19:00
Targetversion: 1.2.0
-Class: todo
There are some command line options in the windows agent installer. Create a documentation
for these options.
+
+2012-10-02 15:00:58: changed state open -> done
+Is already documented.
diff --git a/.bugs/716 b/.bugs/716
index 2df2949..3e4a5f9 100644
--- a/.bugs/716
+++ b/.bugs/716
@@ -1,12 +1,15 @@
Title: Timeperiods as exceptions can only be selected after saving the rule
Component: wato
-State: open
+Class: nastiness
+State: done
Date: 2012-08-01 11:17:46
Targetversion: 1.2.0
-Class: nastiness
This is a nasty interface problem (for the user)
If you add a timeperiod, the exception (text) field is visible,
but the dropdown for selecting a timeperiod exception is not.
If you save the rule and go back to edit mode, then the dropdown
is there.
+
+2012-10-02 15:04:01: changed state open -> done
+This works with current WATO.
diff --git a/web/htdocs/views.py b/web/htdocs/views.py
index 3647eba..92a73ca 100644
--- a/web/htdocs/views.py
+++ b/web/htdocs/views.py
@@ -733,6 +733,7 @@ def page_edit_view():
if html.has_var("try") or html.has_var("search"):
html.set_var("search", "on")
if view:
+ bi.reset_cache_status()
show_view(view, False, False)
return # avoid second html footer
Module: check_mk
Branch: master
Commit: a526214d3b9be496af0dcff17f637bba61e3e4dd
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=a526214d3b9be4…
Author: Lars Michelsen <lm(a)mathias-kettner.de>
Date: Tue Oct 2 15:14:06 2012 +0200
FIX: Try out mode in view editor does not show context buttons anymore
Conflicts:
.bugs/772
---
.bugs/772 | 4 ++--
ChangeLog | 1 +
web/htdocs/views.py | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/.bugs/772 b/.bugs/772
index 45aad40..5029aac 100644
--- a/.bugs/772
+++ b/.bugs/772
@@ -8,5 +8,5 @@ Targetversion: 1.2.0
When hitting "Try out" in the edit mode of a view then
the buttons for commands etc are shown but shouldn't.
-2012-10-02 15:15:02: changed state open -> done
-Has been solved.
+2012-10-02 15:12:44: changed state open -> done
+Has just been fixed.
diff --git a/ChangeLog b/ChangeLog
index a781264..1e92aa1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -26,6 +26,7 @@
* Added "view" parameter to dashlet_pnpgraph webservice
* FIX: BI: Assuming "OK" for hosts is now possible
* FIX: Fixed error in makeuri() calls when no parameters in URL
+ * FIX: Try out mode in view editor does not show context buttons anymore
WATO
* Added "profile" option to be configurable via browser
diff --git a/web/htdocs/views.py b/web/htdocs/views.py
index 37711e9..3647eba 100644
--- a/web/htdocs/views.py
+++ b/web/htdocs/views.py
@@ -1351,7 +1351,8 @@ def render_view(view, rows, datasource, group_painters, painters,
len(rows) > 0 and \
should_show_command_form(display_options, datasource)
- show_context_links(view, hide_filters, show_filters, display_options,
+ if show_buttons:
+ show_context_links(view, hide_filters, show_filters, display_options,
painter_options, command_form, layout.get('checkboxes', False))
# User errors in filters
Module: check_mk
Branch: master
Commit: ed6e0f5686e84bccd7c1b6ebe383bed5af8ad11f
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=ed6e0f5686e84b…
Author: Lars Michelsen <lm(a)mathias-kettner.de>
Date: Tue Oct 2 11:02:29 2012 +0200
Updated bug entries #0652, #0108, #0582, #0487
---
.bugs/108 | 8 ++++++--
.bugs/487 | 7 +++++--
.bugs/582 | 7 +++++--
.bugs/652 | 7 +++++--
4 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/.bugs/108 b/.bugs/108
index a68a51e..66a4016 100644
--- a/.bugs/108
+++ b/.bugs/108
@@ -1,8 +1,12 @@
Title: WATO: link hosts to view in Multisite
Component: wato
-State: open
-Date: 2011-01-25 16:53:59
Class: feature
+State: done
+Date: 2011-01-25 16:53:59
+Targetversion: future
A host should show a link directly to the correct view in Multisite
(if this is possible).
+
+2012-10-02 08:58:07: changed state open -> done
+This is implemented since a long time.
diff --git a/.bugs/487 b/.bugs/487
index 1fc66c5..d0e7993 100644
--- a/.bugs/487
+++ b/.bugs/487
@@ -1,10 +1,13 @@
Title: Add optional comment when restarting Nagios via WATO
Component: wato
-State: open
+Class: feature
+State: wontfix
Date: 2011-12-08 17:03:28
Targetversion: 1.2.0
-Class: feature
We add a text input in the "Activate Changes" pages. The user
can enter a comment here. The comment will be added to the
audit-Log and will be used to name or tag the snapshot.
+
+2012-10-02 08:54:38: changed state open -> wontfix
+Duplicate of 735. Closing this one.
diff --git a/.bugs/582 b/.bugs/582
index 72dab63..fcdae83 100644
--- a/.bugs/582
+++ b/.bugs/582
@@ -1,11 +1,14 @@
Title: configure first_notification_delay from WATO
Component: wato
-State: open
+Class: feature
+State: done
Date: 2012-04-10 10:27:46
Targetversion: 1.2.0
-Class: feature
Currently we don't have support for setting the first notification delay from within WATO.
This is a helpful feature we recommended to many people, so it would be important to have it available;
I think it's the only notification-related setting not available in WATO, so by adding it we'd have
it all covered.
+
+2012-10-02 08:57:19: changed state open -> done
+It has already been added.
diff --git a/.bugs/652 b/.bugs/652
index fc74f09..691e23c 100644
--- a/.bugs/652
+++ b/.bugs/652
@@ -1,9 +1,12 @@
Title: Rulesets: not configurable with "secondary tags"
Component: wato
-State: open
+Class: feature
+State: done
Date: 2012-02-14 15:54:52
Targetversion: future
-Class: feature
When e.g. the "snmp" tag is added to the hosts as implicit tag it can not
be used in rulesets.
+
+2012-10-02 08:56:11: changed state open -> done
+This can already be done.
Module: check_mk
Branch: master
Commit: 7b68d42a688b0bb0546f9f9c0bec2de7d367775e
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=7b68d42a688b0b…
Author: Lars Michelsen <lm(a)mathias-kettner.de>
Date: Tue Oct 2 11:02:54 2012 +0200
Added internal notes
---
LIESMICH.ldap | 148 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 148 insertions(+), 0 deletions(-)
diff --git a/LIESMICH.ldap b/LIESMICH.ldap
new file mode 100644
index 0000000..14ca339
--- /dev/null
+++ b/LIESMICH.ldap
@@ -0,0 +1,148 @@
+Die LDAP-Anbindung kann sehr vielschichtig sein. Unterteilen wir mal in:
+
+1. Login: Die Validierung von Benutzername und Passwort
+2. User-Objekte/Attribute synchronisieren
+3. Rechnte: Gruppenmitgliedschaften
+
+1. Benötigte Konfigurationsoptionen
+--------
+
+multisite_login_modules = [ 'ldap', 'htpasswd' ]
+
+ldap_uri = 'ldap://<address>:<port>'
+ldap_version = 3
+ldap_bind_dn = '<DN>'
+ldap_bind_pw = '<pw>'
+
+
+ldap_user_base_dn = ''
+ldap_user_scope = 'sub'
+ldap_user_filter = ''
+ldap_user_attrs = {
+ # MK LDAP
+ 'username': 'uid',
+}
+
+ldap_sync_plugins = [
+ ldap_sync_name,
+ ldap_sync_mail,
+ ldap_sync_pager,
+ ldap_sync_groups,
+]
+
+# Aktiviert ddas Synchronisieren von Benutzerattributen mit dem LDAP
+ldap_auth_sync_users = True
+# Aktiviert das Erstellen von nicht vorhandenen Accounts im WATO
+ldap_auth_create_user = True
+
+Innerhalb einiger Konfigurationsoptionen, z.B. der DNs und der Filter müssen einige Macros verfügbar sein,
+z.B. der Name der lokalen OMD-Site. FIXME: Zumindest für Eckard brauchen wir das.
+
+2. Konfiguration über WATO
+--------
+
+Eine Möglichkeit wäre eine eigene Maske zu bauen, für den Anfang sollte es aber ausreichen
+die Einstellungen in der "Global Settings" Seite konfigurierbar zu machen. Unterhalb von
+"Multisite & WATO" könnte man die Option multisite_login_modules hinzufügen und für alle
+LDAP-Spezifischen Attribute eine eigene Gruppe "LDAP" erstellen.
+
+2. LDAP-Verbindung
+--------
+
+Für die Verbindung zum LDAP-Server wird das Modul "ldap" benutzt. Für unsere Implementierung könnte das
+Objekt ldap.ReconnectLDAPObject interessant sein. Es baut die Verbindung zum LDAP-Server automatisch wieder
+auf, wenn die Verbindung nicht aufgebaut ist oder abgebrochen hat. Für unsere Implementierung sind die
+synchronen Funktionen *_s() interessant.
+
+Die LDAP-Verbindung könnte pro Apache-Thread gehalten werden, so dass der Overhead für den Verbindungsaufbau
+bei wiederholten Anfragen entfällt.
+
+Die komplette LDAP-Anbindung muss read-only sein. Es dürfen keine schreibenden Aktionen in das LDAP
+ausgeführt werden.
+
+4. Login
+--------
+
+Die LDAP-Kopplung auf Login-Ebene wird in login.py implementiert. Dazu wird die
+Funktion do_login() so umgebaut, dass sie modularisierbar ist. Die Überprüfung
+der htaccess-Passwörter wird extrahiert und ersetzt. Es wird dann möglich sein
+mehrere Authentifizierungsmechanismen anzugeben, die dann der Reihe nach
+abgearbeitet werden, solange bis der Nutzer erfolgreich eingeloggt ist, oder
+alle Möglichkeiten ausprobiert wurden. Wobei eine Funktion drei Verschiedene Ergebnisse
+haben kann: 1) Erfolg 2) Falsches Passwort 3) Account nicht vorhanden. Nur im dritten
+Fall werden die folgenden Auth-Mechanismen benutzt.
+
+Beim LDAP-Login wird als erstes ein LDAP-Bind mit einem Service-Benutzer (ldap_bind_dn, ldap_bind_pw) ausgeführt.
+Dieser Benutzer muss innerhalb des LDAP ausreichende Rechte zum Auflisten aller Benutzer
+haben. Mit diesem Benutzer wird dann ein LDAP-Search (ldap_user_base_dn, ldap_user_scope, ldap_user_filter)
+durchgeführt, mit dem dann der Benutzername, der sich gerade authentifizieren will, gesucht wird (ldap_attr_map).
+Wenn der Benutzer nicht gefunden wurde, wird der LDAP-Login abgebrochen und mit dem nächsten Login-Modul
+weiter gemacht. Wenn der Benutzer gefunden wurde, wird versucht einen LDAP-Bind mit dem DN und Passwort des
+Benutzers zu machen. Wenn das funktioniert, ist der Benutzer erfolgreich eingeloggt.
+
+Auch die Funktion check_auth_cookie() muss modularisiert werden. Hier wird geprüft, ob der Benutzer noch
+existiert und der Passwort-Hash noch stimmt. FIXME: Hier den gleichen Mechanismus wie beim Login verwenden?
+
+Die Authentifizierung am LDAP-Server erfordert immer einen Online-Zugriff. Die LDAP-Authentifizierung ist
+also nicht möglich, wenn der LDAP-Server nicht erreichbar ist.
+
+Die restliche Verarbeitung (Cookie setzten etc.) geschieht über die vorhandenen Mechanismen im Multisite.
+
+5. User-Objekte/Attribute synchronisieren
+
+Es muss möglich sein Nutzer lokal im WATO zu verwalten. Trotzdem sollen sich Nutzer am Multisite anmelden
+können, die noch nicht im WATO vorhanden sind.
+
+5.1 Bei Login Accounts erstellen
+
+Beim Login eines Benutzers, der noch nicht im Multisite existiert, wird, sofern aktiviert (ldap_auth_create_user),
+ein neuer Benutzeraccount im WATO angelegt. Dieser Benutzer hat erst einmal keinen Eintrag in der htpasswd-Datei,
+kann sich also nicht lokal anmelden. FIXME: Welche Attribute setzen/sperren? Eventuell von einem Template klonen?
+
+5.2 Attribute abgleichen
+
+Attribute, wie z.B. Full name, Email address und Pager address sollen vom zentralen LDAP abgeglichen werden können,
+wenn konfiguriert (ldap_auth_sync_users). Dies geschieht für Benutzeraccounts, die im LDAP gefunden werden können.
+Sobald ein Attribut mit dem LDAP abgeglichen wird, ist das LDAP der zentrale Speicherpunkt für diese Information.
+Im WATO ist dieser Wert dann nicht mehr editierbar. Pro Attribut kann ein weiteres Attribut gesetzt werden, das den
+Schreibzugriff auf das dazugehörige echte Attribut verhindert, z.B. "email" und "email_locked = True". FIXME: Alternativ
+ein internes Attribut ".locked" einführen, das die Liste der gesperrten Felder hält.
+
+Die Attribute, die synchronisiert werden, werden vom LDAP abgefragt und im lokalen Datensatz des Benutzers gespeichert
+um von dort aus z.B. in die Nagios-Konfiguration geschrieben zu werden.
+
+Die Synchronisation von Attributen geschieht über eine Plugin-Schnittstelle. Sync-Funktionen können registriert und
+aktiviert (ldap_sync_plugins) werden, diese bekommen den LDAP-Datensatz des Nutzers und das WATO User-Objekt
+übergeben, können das WATO User-Objekt beliebig modifizieren und wieder zurück geben. Die Plugins sollten pro
+Installation konfigurierbar sein.
+
+Der Abgleich mit dem LDAP geschieht nach dem Login eines Benutzers. Bei der Cookie-Validierung sollte das nicht
+gemacht werden. Damit würde bei jedem HTTP-Request an die index.py ein Abgleich stattfinden.
+
+Die Synchronisation eines Benutzers kann von einem Admin manuell im WATO angestoßen werden. Diese Option wird auch
+für Accounts angeboten, die noch keinen Match im LDAP haben um eventuell nachträglich angelegte Accounts sycnrhonisieren zu können.
+
+Es wäre auch zu überlegen, ob es alternativ oder ergänzend einen Bulk-Abgleich, z.B. beim aktivieren der Konfiguration
+geben soll.
+
+Durch den Abgleich werden nur die Daten im WATO editiert. Die Änderungen werden nicht sofort aktiviert.
+FIXME: Wie dann?
+
+5.3 Distributed-WATO
+
+Bisher werden die Benutzer-Accounts beim Distributed-WATO alle synchronisiert. Das darf so nicht bleiben. Bei der
+LDAP-Integration muss es möglich sein Accounts nur in einer Site zu haben. Dabei muss es außerdem möglich sein pro
+Site eigene LDAP-Server zu konfigurieren.
+
+FIXME: Welche Benutzer sychronisieren? Wie wird das geregelt? Hatten wir da nicht schon eine Idee?
+FIXME: Immer LDAP-Server pro Site konfigurierbar machen, oder nur optional?
+
+6. Rechte: Gruppenmitgliedschaften
+
+Im WATO werden die Gruppenmitgliedschaften und Rollenzugehörigkeiten eines Benutzers im Datensatz des Nutzers
+gespeichert. Dadurch ist es möglich diese Listen mit einem sync-plugin zu modifizieren
+(ldap_sync_groups, ldap_sync_roles). Diese Plugins können diese Attribute anhand bestimmter Kriterien, die pro
+Plugin konfigurierbar gemacht werden können, die Listen der Gruppen oder Rollen pflegen und für die manuelle
+Bearbeitung im WATO sperren.
+
+FIXME: Kann ein Plugin Konfigurationsoptionen im WATO registrieren?
Module: check_mk
Branch: master
Commit: db3817c95737056261121a65e52113e63ed52803
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=db3817c9573705…
Author: Bastian Kuhn <bk(a)mathias-kettner.de>
Date: Mon Oct 1 15:57:45 2012 +0200
Updated bug entries #0744
---
.bugs/744 | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/.bugs/744 b/.bugs/744
new file mode 100644
index 0000000..d210025
--- /dev/null
+++ b/.bugs/744
@@ -0,0 +1,10 @@
+Title: Host- and Service Groups empty if contact not have the right for all members
+Component: livestatus
+State: open
+Date: 2012-10-01 15:54:12
+Targetversion: 1.2.0
+Class: bug
+
+On the Hostgroups (Summary) and the Servicegroups (Summary) all elements are missing,
+where a contact is not member for all childrens of element.
+For example, a hostgroup with ten hosts, is contact not member of all ten, the hostgroup doesent appear