[Eisfair_dev] Update nagios-objects 0.1.5

[kay]

Am 25.12.2016 um 18:28 schrob Ansgar Püster:
> 
> Am 25.12.2016 um 17:01 schrieb kay:
> nagios-objects hat den Status "testing".
> Du müsstest dich schon in den Menüpunkt
>   3 Manual system update (unstable packages)

Ja, das hatte ich danach auch noch probiert und hat geklappt.


>> Einen Verbesserungs-Wunsch hätte ich:
>>
>> Ich hatte vorhin einen server in der hosts konfig umbenannt. Im
>> ergebniss schlug der neustart von nagios mehrfach fehl weil ich vorher
>>
>> Kann man diese umbenennung nicht automatisiert in den relevanten konfigs
>> machen lassen?
> 
> Man müsste einen speziellen Menüpunkt "Rename Host" bauen,
> da bei Änderungen über "Configure Hosts" ggf. mehrerer
> Hosts umbenannt werden können, und so keine automatische
> eindeutige Änderung in den abhängigen Konfigurationen möglich
> ist.

Okay. Ich hatte gedacht man könne beim speichern durch vergleich mit der
vorigen konfig alten und neuen hostnamen eruiren und damit automagisch
die entsprechenden ersetzungen machen. Was natürlich nur klappt wenn
schon einmal gespeichert wurde.

> Es gäbe allerdings eine aufwendige Alternative (Speichern
> des Index aus der Host Konfiguration statt des Hostnamens
> in den abhängigen Konfigurationen) ... müsste man mal
> drüber nachdenken.

Ehrlich gesagt überlege ich momentan eher ob ich nicht evtl. doch mal
die "manual" Methode probiere. Dieses stängige [FAIL], Menü rauf,
Large-Check, sehen was angemeckert wird und dies dann suchen ist mir
inzwischen zu nervig weils immer wieder vorkommt. Liegt wohl auch an
meiner Trial-and-error Herangehensweise.

Und daran das die öfters nötigen optionen für services nicht im kontext
im hilfe-file zu finden sind. Dies wäre mein 2. Verbesserungs-wunsch.

>> Ich habe darüber hinaus festgestellt das offenbar die zählervariablen
>> (z.b. für hostgroup oder services) anscheinend manchmal nicht korrekt
>> ausgewertet werden. So hatte ich einen windows-PC eingetragen gehabt,
>> den aber per Menü gelöscht. In config.d/(nagios-hostgroup war er noch
>> als member drin, der zähler wohl um eins runter so das er "eigentlich"
>> nicht mehr berücksichtigt werden sollte.
>>
>> Aber bei den obigen konfig-änderungen wurde er dann doch wieder
>> angezeigt weil ihm keine services zugeordnet waren. Schluß: Irgend ein
>> script rechnet da falsch. 


> Das kann ich so aus deiner "Beschreibung" nicht nachvollziehen.
> Was bedeutet:
> - per Menü gelöscht
> - ... wurde er dann doch wieder angezeigt ...

Nein, aber er ist ja noch in der datei drin. Derzeit vermute ich das die
ihm zugeordneten services bereits vorher aus der datei gelöscht oder mit
anderen überschrieben wurden so das ein inaktiver host und NULL
servicves über blieben. Und das hatte der preflight-check dann moniert.

> - kannst du ein konkretes Beispiel hier posten
>   (oder ggf. als PM die Dateien aus /etc/config.d zur Verfügung stellen)

Wenn ich es genauer erklären kann werde ich das versuchen. Ja.

> 
> In den Dateien in /etc/config.d stehen ggf. mehr Einträge, die
> aber nicht aktiv sind. Entscheidend ist hier immer die Zählervariable,
> also z.B. NAGIOS_HOST_N, NAGIOS_HOSTGROUP_N etc.

Ja, und mein Eindruck ist das eben diese Zählervariable gelegentlich um
1 zu hoch ermittelt wird und dann eben ein host angemeckert wird der
zwar noch in der datei enthalten ist - aber eben EIGENTLICH dort nicht
mehr aktiv sein dürfte.

> Aber:
> Genauso wie das "automatische Umbenennen" ist derzeit auch das
> "automatische Löschen" in abhängigen Konfigurationen nicht
> realisiert ... müsste man mal drüber nachdenken.

Ich denke es wäre hilfreich wenn "Löschen" auch wirklich "Löschen" wäre.
Aktuell ist es eher nur Counter=Counter-1 und das scheint mir beim
späteren neu starten nicht immer sauber wieder ausgelesen zu werden.

> "automatisches Löschen" bei nconf standardmäßig enthalten, da
> dort eine relationale Datenbank im Hintergrund genutzt wird,

Nimm's mir nicht übel aber eine Datenbank für konfigurationen ist nicht
das was ich haben wollte, nicht für die paar hosts hier. Bei Enterprise-
oder verteilten installationen ist das sicher sinnvoller.


-- 
Posted via SN