weird log_info messages from mpt2sas

Veröffentlicht am von
2

LSI SAS 9200 packageFor no obvious reason mpt2sas started to spam my system logs on a Wheezy box with an LSI SAS 9200 controller, no raid function, many disks attached) and I worried about something being broken or breaking right away. Just for the record: I would recommend this particular controller as being rock-solid and fast under heavy load.

mpt2sas0: log_info(0x30030101): originator(IOP), code(0x03), sub_code(0x0101)

Sadly, there was no useful documentation from LSI and no good hints anywhere else. Also the lsi_log_decode i stumbled upon had no clue at all. What led me to the cause of these messages was an old bug report from CentOS which finally mentioned the exact log message i got and pointed me to an issue with calls to non-existent pages from a controller related management software.

I remembered testing different cli tools. One of these was sas2ircu respectively sas2ircu-status which didn’t meet my requirements while testing, but still was installed on the system. Apparently sas2ircu-status was trying to request some information from the controller to which it responded by putting broccoli in his ears. As sas2ircu and sas2ircu-status anyway are of no use to me, the solution was to simply purge the sas2ircu* packages and hey presto, log messages stopped immediately.

Icinga-Configs aus ISPConfig-DB

Veröffentlicht am von
Antworten

Ich war schlicht zu faul Domains, die neu im ISPConfig eingetragen wurden, jedes Mal im Anschluss auch noch in die Icinga-Config zu übernehmen. Drin stehen sollten die aber schon. Meine Lösung dafür ist die entsprechenden Configs per Bash-Script aus den Infos der ISPConfig-DB zu erzeugen.

Die Domains aus der ISPConfig-DB holen wir uns so:

mysql -u user -passwd –database ispconfigdb -e “SELECT domain FROM web_domain WHERE type=’vhost’ AND active=’y’ into outfile ‘/pfad/file’;”

Damit haben wir ein File mit allen aktiven vhost-Domains aus ISPConfig, kommt eine dazu, haben wir die beim nächsten Lauf auch im File drin. Die eigentliche Erzeugung der Config-Files ist eine unspektakuläre for-Schleife mit ein paar echos, nicht besonders elegant, aber funktioniert. Eine Kleinigkeit machen wir dabei noch extra: PCOUNT zählt die Punkte (genau genommen den character count, das ist Anzahl Punkte +1, wegen new line) und beim erzeugen der Config unterscheiden wir zwischen explizit angelegten Subdomains (z.B. webmail.domain.tld) und “normalen” vhost-Domains (z.b. domain.tld) um jeweils passend ein “www.” davor zu setzen oder eben nicht.

for domain in $(cat /pfad/file); do
PCOUNT=$(echo -e “$domain” | sed -e ‘s/[^.]//g’ | wc -m)
conf=/zielpfad/der/configs/$domain.cfg
echo -e “define service{” >> $conf
echo -e “use generic-service” >> $conf
echo -e “host_name derhost” >> $conf
if [ $PCOUNT -le 2 ]; then
echo -e “service_description www.$domain” >> $conf
echo -e “check_command check_site!www.$domain” >> $conf
else
echo -e “service_description $domain” >> $conf
echo -e “check_command check_site!$domain” >> $conf
fi
echo -e “}” >> $conf
done

Im vollständigen Script gibt’s dann noch verschieden Details, z.B. ob die Kommandos auch vorhanden sind, Prüfung von exit-codes, logging, tmp-files anlegen und löschen, und im Fehlerfall Mails schicken. Am Schluss zählen wir dann noch mal nach ob es auch genau so viele Config-Files wie Domains gibt und geben Icinga nen reload mit Prüfung des exit-codes. Das Ganze läuft einmal pro Nacht per Crontab, alternativ könnte man es auch an geeigneter Stelle in den ISPConfig-Ablauf beim Speichern einer neuen Domain einlöten.