i live in my own little world, but it's ok… they know me here

merke… einfach mal user und gruppen in die /etc/passwd und /etc/group eintragen und die /etc/shadow vergessen ist doof. ssh logins klappen dann nicht. und wenn man das passwort setzen will, kommt sowas:

~$ passwd username
passwd: Authentication service cannot retrieve authentication info.

neulich im logfile eines bind dns servers gefunden:

25-Sep-2013 09:40:45.611 zone domain.tld/IN/trusted: zone transfer deferred due to quota

keine panik! die anzahl gleichzeitiger zonen transfers ist beschraenkt. (ich bin noch auf der suche nach der einstellung und dem default wert.) der bind holt das aber ziemlich bald nach.

immer schoen mit dem kopp auf der tastatur!

lotus notes nimmts da ganz genau:

auf debian systemen kommts beim upgrade auf neuere bind versionen (bzw. des ganzen systems) dazu, dass starten des bind diese warnung ausgespuck wird:

WARNING: key file (/etc/bind/rndc.key) exists, but using default configuration file (/etc/bind/rndc.conf)

abhilfe schafft es, die datei /etc/bind/rndc.conf zu loeschen. vorher pruefen, ob in der /etc/bind/rndc.key der passende key drin steht. dann noch in der datei /etc/bind/named.conf pruefen, ob diese zeile vorhanden ist und ggf. einfuegen:

include "/etc/bind/rndc.key";

ein gut gemachter scherz im look einer original apple werbung. und angeblich soll es echt leute geben, die daran geglaubt haben!

gerade noch irgendwo im tmp verzeichnis gefunden 😉

Ex-CIA-Direktor: Terroristen nutzen gerne Gmail
Deutschlands größter Mobilfunk-Hotspot
Trügerische Sicherheit: Der elektronische Personalausweis
Und dafür zahle ich GEZ!
Müll hat einen Namen: Nespresso

garantiert nicht echt, wenn ihr sowas bekommt:

heute wollte ich einen db server mit opsview (core) ueberwachen. das normale host template “Database – MySQL” funktionierte tadellos. als ich das etwas umfangreichere “Database – MySQL Server” angeschaltet habe, gabs nur fehler. der status war bei allen “(Return code of 255 is out of bounds)”

nachdem ich dann erst einmal rausgefunden habe, wie man den mysql check überhaupt konfiguriert:

…war das ergebnis noch nicht besser. also mal husch den check mit einem beliebigen parameter auf der commandline ausgefuehrt mit folgendem ergebnis:

root@nagios:~# /usr/local/nagios/libexec/check_mysql_performance -H db.int.domain.tld -u opsview -p mypassword --metricname=Connections -w 20 -c 30
Goto undefined subroutine &Carp::shortmess_real at /usr/share/perl/5.10/Carp.pm line 41.

die loesungen bei google waren recht uebersichtlich. eines hat jedoch die erhoffte abhilfe geschaffen. in der datei /usr/local/nagios/libexec/check_mysql_performance muss folgende ergaenzung gemacht werden (“use Carp::Heavy;” an der richtigen stelle eingefuegt):

[...]
use strict;
use warnings;
use FindBin qw($Bin);
use Carp::Heavy;
use lib "$Bin/../perl/lib", "/usr/local/nagios/libexec";
use Nagios::Plugin;
[...]

im hintergrund sind die knapp 40 weiteren checks natuerlich fleissig weiter gelaufen, so dass ich beim naechsten test folgende meldung bekam:

root@nagios:~# /usr/local/nagios/libexec/check_mysql_performance -H db.int.domain.tld -u opsview -p mypassword --metricname=Connections -w 20 -c 30
DBI connect('host=db.int.domain.tld','opsview',...) failed: Host 'nagios.int.domain.tld' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' at /usr/local/nagios/libexec/check_mysql_performance line 477

hmm… sind also so viele fehler aufgetreten, dass der mysql server die anfragen erstmal blockiert hat. im normalen nagios logfile steht nicht wirklich was aussagekraeftiges drin. also debugging einschalten, in dem man in der datei /usr/local/nagios/etc/nagios.cfg diese zeiel angepassen und opsview neu starten:

[...]
debug_level=16
[...]

dann wird in die datei /usr/local/nagios/var/log/nagios.debug protokolliert. und siehe da…

[1380044880.745551] [016.0] [pid=8622] ** Handling check result for service 'MySQL SSL Session cache overflows' on host 'db.int.domain.tld' from 'Core Worker 8626'...
[1380044880.745588] [016.1] [pid=8622] HOST: db.int.domain.tld, SERVICE: MySQL SSL Session cache overflows, CHECK TYPE: Active, OPTIONS: 0, SCHEDULED: Yes, RESCHEDULE: Yes, EXITED OK: Yes, RETURN CODE: 13, OUTPUT: (No output on stdout) stderr: can't write into /tmp/nagios_mysql_perf_db.int.domain.tld_a3sApVWRDav1..tmp: Permission denied at /usr/local/nagios/libexec/check_mysql_performance line 597.

aha… also permission denied auf die datei “/tmp/nagios_mysql_perf_db.int.domain.tld_a3sApVWRDav1..tmp”
das ist so, weil ich vorher den check als root ausgefuehrt habe. deswegen ist der besitzer nun root und der user nagios kann die datei nicht loeschen.

root@nagios:~# ls -lisa /tmp/
total 68
5406721  4 drwxrwxrwt  6 root   root    4096 Sep 24 19:50 .
      2  4 drwxr-xr-x 21 root   root    4096 Jan 28  2013 ..
[...]
5406744 12 -rw-r--r--  1 root   root    8194 Sep 24 19:38 nagios_mysql_perf_db.int.domain.tld_a3sApVWRDav1..tmp
5406731  8 -rw-rw-r--  1 nagios nagios  7657 Sep 24 19:51 nagios_mysql_perf_localhost_a3HhY0MKWDmPo.tmp
[...]

also hurtig loeschen und schon funktioniert die sache wieder.

bei einem dutzend checks musste ich die standardwerte fuer die alarme in den checks anpasssen, da diese total daneben waren. vielleicht muss ich auch ein paar der cheks raus schmeissen, weil total irrelevant fuer meine zwecke. schauen wir mal…