Archiv ‘Linux’

Donnerstag, 22. März 2018

cacti benötigt die MySQL Zeitzonen-Datenbank

Vor kurzem habe ich meine cacti-Installation „gelüpft“. Leider kam es vorübergehend zu einem Showstopper, weil die Software nach einer MySQL Timezone database verlangt, welche ich nicht installiert hatte:

ERROR: Your MySQL TimeZone database is not populated. Please populate this database before proceeding.

Wieso das sonst sehr benutzerfreundliche cacti-Installationsscript diese Datenbank in so einem Fall nicht einfach nachinstalliert, wissen nur die Geier.

Es war also Handarbeit angesagt — nach etwas googlen kein Problem:

$ mysql -u root -p mysql < /usr/share/mysql/mysql_test_data_timezone.sql

Quelle: Upgrade problem MySQL Timezone

Die Empfehlung, dem cacti-Benutzer zudem noch die Leseberechtigung auf die Tabelle mysql.time_zone_name zu geben, war bei mir nicht nötig.

Offenbar gibt es bei MySQL auch einen eigenständigen Befehl, der die Sache installiert – getestet habe ich das aber nicht:

$ mysql_tzinfo_to_sql tz_dir

Quelle: 4.4.6 mysql_tzinfo_to_sql — Load the Time Zone Tables

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

mysqldump: MySQL-Benutzer hat keine Rechte, eine Tabelle zu sperren

Als ich kürzlich ein selten gebrauchtes Backup-Script ausführen wollte, kam ich folgende Fehlermeldung zu Gesicht:

mysqldump: Got error: 1044: "Access denied for user 'username'@'10.1.2.3' to database 'app_app'" when using LOCK TABLES

Die Lösung für das Problem ist eigentlich ganz simpel. Entweder über die mysql-Kommandozeile:

GRANT LOCK TABLES ON app_app.* TO 'username'@'10.1.2.3';
FLUSH PRIVILEGES;

… oder über phpMyAdmin, wo man dem zutreffenden Benutzer unter mysql > Tables > db ein Häkchen bei Lock_tables_priv setzt …

image-7782

… den Datensatz speichert und danach die Benutzerprivilegien neu lädt, indem man im Menupunkt „SQL“ den Befehl „FLUSH PRIVILEGES“ eingibt und das Kommando ausführt.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

Wenn der UniFi Controller die MongoDB Log-Datei gigabyteweise füllt

Ich betreibe an drei physischen Standorten auf zu Linux-Servern umfunktionierten Lenovo-Laptops je einen UniFi-Controller, um die UniFi-Access Points an diesen drei Standorten zu provisionieren und zu überwachen.

Wer diese Software ebenfalls im Einsatz hat, sollte insbesondere nach Updates gelegentlich mal in das Verzeichnis /var/log/unifi reinschauen und überprüfen, dass sich die Log-Datei mongod.log nicht im Sekundentakt mit nachfolgend aufgeführten Fehlermeldungen füllt und so locker mehrer Gigabyte gross werden kann:

2018-03-12T20:49:21.010+0100 I CONTROL  [main] ***** SERVER RESTARTED *****
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] MongoDB starting : pid=26817 port=27117 dbpath=/usr/lib/unifi/data/db 64-bit host=HOSTNAME
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] db version v3.2.11
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] git version: 009580ad490190ba33d1c6253ebd8d91808923e4
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2l  25 May 2017
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] allocator: tcmalloc
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] modules: none
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] build environment:
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten]     distarch: x86_64
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten]     target_arch: x86_64
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] options: { net: { bindIp: "127.0.0.1", http: { enabled: false }, port: 27117, unixDomainSocket: { pathPrefix: "/usr/lib/unifi/run" } }, storage: { dbPath: "/usr/lib/unifi/data/db" }, systemLog: { destination: "file", logAppend: true, path: "/usr/lib/unifi/logs/mongod.log" } }
2018-03-12T20:49:21.068+0100 E NETWORK  [initandlisten] listen(): bind() failed errno:98 Address already in use for socket: 127.0.0.1:27117
2018-03-12T20:49:21.069+0100 E NETWORK  [initandlisten]   addr already in use
2018-03-12T20:49:21.069+0100 E STORAGE  [initandlisten] Failed to set up sockets during startup.
2018-03-12T20:49:21.069+0100 I CONTROL  [initandlisten] dbexit:  rc: 48

Relevant ist die eine Zeile, die da lautet:

2018-03-12T20:49:21.068+0100 E NETWORK  [initandlisten] listen(): bind() failed errno:98 Address already in use for socket: 127.0.0.1:27117

Sie besagt, dass bereits ein Prozess auf Port 27117 lauscht. Und was macht das blöde Stück Software in einem solchen Fall? Es startet neu, immer wieder, ohne Ende. Und bei jedem Neustart (gefühlt alle Sekunde, wenn man sich mit tail -f dranhänkt) füllt sich das Log mit weiteren 1600+ Bytes und somit mit 5.6 Megabytes pro Stunde, 134.4 MB pro Tag und 940.8 MB pro Woche.

Als Anschauungsbeispiel das Log-Verzeichnis auf einem meiner Server:

/var/log/unifi]# ls -lh
total 1.2G
-rw------- 1 unifi root     0 Mar 18 00:08 mongod.log
-rw------- 1 unifi root   153 Jan 12 14:32 mongod.log.10.gz
-rw------- 1 unifi root   900 Jan  5 23:38 mongod.log.11.gz
-rw------- 1 unifi root   882 Dec 30 22:15 mongod.log.12.gz
-rw------- 1 unifi root   687 Dec 23 02:27 mongod.log.13.gz
-rw------- 1 unifi root   691 Dec 16 10:58 mongod.log.14.gz
-rw------- 1 unifi root  1.1G Dec  2 12:07 mongod.log.15.gz
-rw------- 1 unifi root  3.4M Mar 13 21:30 mongod.log.1.gz
-rw------- 1 unifi root   30M Mar 12 00:09 mongod.log.2.gz
-rw------- 1 unifi root   23M Mar  4 00:09 mongod.log.3.gz
-rw------- 1 unifi root   30M Feb 26 00:07 mongod.log.4.gz
-rw------- 1 unifi root   23M Feb 18 00:09 mongod.log.5.gz
-rw------- 1 unifi root   30M Feb 12 00:08 mongod.log.6.gz
-rw------- 1 unifi root  1.7M Feb  4 00:10 mongod.log.7.gz
-rw------- 1 unifi root   675 Jan 26 09:19 mongod.log.8.gz
-rw------- 1 unifi root   236 Jan 21 14:25 mongod.log.9.gz

Wie man auf einen Blick sieht, hat sich das Log in der Woche vom 25. November bis zum 2. Dezember auf diese Weise gefüllt und war selbst mit gzip gezippt noch satte 1.1GB gross. Im Vergleich zu anderen Wochen, wo ein paar wenige Bytes zusammenkommen.

Wer den UniFi-Controller auf einer SSD-Platte laufen hat, dem werden ob diesen Schreiboperationen die Tränen kommen.

Was ist die Lösung?

# killall mongod

Startet der UniFi-Controller die MongoDB das nächste Mal neu, kann sie sich an den Port binden.

In den Foren des Herstellers finden sich auf Anhieb eine einzige Meldungen zum Symptom, aber mit einem anderen Lösungsvorschlag, der mit meiner Situation nichts zu tun hatte:

Auf Ask Ubuntu findet sich eine generelle Problemmeldung zum Thema MongoDB: Mongod server not woking due to the following error. Von hier stammt schlussendlich der essentielle Hinweis, einfach den bereits laufenden mongodb-Prozess zu „killen“.

Tags: , , ,
Labels: Linux

2 Kommentare | neuen Kommentar verfassen

Sonntag, 25. Februar 2018

Eine RRD-Datei mit einer weiteren Data Source DS ergänzen

Heute musste ich in Cacti eine zusätzliche Data Source zu einer bestehenden Round Robin Database hinzufügen, welche bereits Daten enthielt, welche ich nicht verlieren wollte.

Cacti scheint ein solches Update des RRDs nicht selbständig machen zu können, weshalb etwas Handarbeit angesagt ist.

Glücklicherweise unterstützt rrdtool (mittlerweile) eine solche Aktualisierung von RRDs:

in the 1.5 series there is a much better solution for the whole ‚modify rrd‘ problem … create has the ability to pre-populate a new rrd file based on an existing one …

Quelle: since when rrdtool tune can add another DS?

Tatsächlich, schaut man sich die man-Page von rrdcreate an, findet man den Parameter --source, mit welchem man auf eine bestehende Datei zeigen kann, deren Messdaten dann nach allen Regeln der Kunst in die neue Datei importiert werden.

Da Cacti im Data Source Debug Mode einem auch den rrdcreate-Befehl anzeigt, konnte ich diesen kopieren und mit diesem Parameter ergänzen. Um keine Daten zu verlieren, kopierte ich vorher die ursprüngliche RRD-Datei nach /tmp/legacy.rrd und arbeitete nur mit dieser Datai als Quelle. Schlussendlich sah der Befehl dann so aus:

/usr/bin/rrdtool create \
/var/www/cacti/rra/fr24.rrd \
--step 60  \
--source /tmp/legacy.rrd \
DS:AIRCRAFTS:GAUGE:120:0:U \
DS:MESSAGES:COUNTER:120:0:U \
RRA:AVERAGE:0.5:1:500 \
RRA:AVERAGE:0.5:1:600 \
RRA:AVERAGE:0.5:6:700 \
RRA:AVERAGE:0.5:24:775 \
RRA:AVERAGE:0.5:288:797 \
RRA:MIN:0.5:1:500 \
RRA:MIN:0.5:1:600 \
RRA:MIN:0.5:6:700 \
RRA:MIN:0.5:24:775 \
RRA:MIN:0.5:288:797 \
RRA:MAX:0.5:1:500 \
RRA:MAX:0.5:1:600 \
RRA:MAX:0.5:6:700 \
RRA:MAX:0.5:24:775 \
RRA:MAX:0.5:288:797 \
RRA:LAST:0.5:1:500 \
RRA:LAST:0.5:1:600 \
RRA:LAST:0.5:6:700 \
RRA:LAST:0.5:24:775 \
RRA:LAST:0.5:288:797 \

In der Legacy-Datei existierte bereits eine Zeitreihe für AIRCRAFTS, MESSAGES kamen heute dazu.

Fertig!

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 21. Februar 2018

SSH mit Benutzernamen und Passwort forcieren

Es gibt Momente, da möchte man nicht, dass der lokale ssh-agent alle vorhandenen Private Keys durchprobiert, um auf einen SSH-Server einzuloggen, sondern einem das Eingabefenster für das Passwort präsentiert.

Dies gelingt folgendermassen:

$ ssh -o PreferredAuthentications=keyboard-interactive,password -o PubkeyAuthentication=no 10.11.12.13

Via: SSH use only my password, Ignore my ssh key, don’t prompt me for a passphrase

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 25. November 2017

Session Replay-Sites auf DNS-Ebene blocken

Vor ein paar Tagen publizierten Sicherheits-Forscher eine Untersuchung (deutsch) über eine Vielzahl von Web-Analyse-Services, welche jede Benutzereingabe auf einer Web-Site abfangen und an den Analyse-Server senden. Sozusagen ein web-site-spezifisches Keylogging.

Gefällt mir ganz und gar nicht.

Die Forscher stellten auch eine Datenbank ins Netz, welche auflistet, welche grössere Web-Site konkret welche Lösung im Einsatz haben.

Da ich seit einer Weile im internen Netzwerk bereits Ad-Sites auf DNS-Ebene blocke (mit der Folge, dass ich im Browser keine SPIEGEL-Artikel mehr lesen kann — Instapaper als funktionierender Workaround), habe ich die von den Forschern entdeckten Services zur offiziellen Block-Liste hinzugefügt.

Hier meine Konfiguration:

// Session Replay Prevention
// https://webtransparency.cs.princeton.edu/no_boundaries/session_replay_sites.html

// Already blocked by http://pgl.yoyo.org/adservers/:
// mouseflow.com
// hotjar.com
// userreplay.net

// Specific subdomains used by some sites investigated
//zone "cdnssl.clicktale.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "cdn.clicktale.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "cdn.decibelinsight.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "cdn.inspectlet.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "wu-app.quantummetric.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "ws.sessioncam.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "cdn.userreplay.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "mc.yandex.ru" { type master; notify no; file "/etc/bind/zones/null.dns"; };

zone "clicktale.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "fullstory.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "decibelinsight.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "inspectlet.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "quantummetric.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "sessioncam.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "yandex.ru" { type master; notify no; file "/etc/bind/zones/null.dns"; };

Die gröbsten Missetäter sollten somit nicht mehr ins Haus kommen …

Tags: , , , , , , , , ,
Labels: IT, Linux, Web

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 22. November 2017

rsync über SSH verwendet auf dem Zielsystem die falsche rsync-Version

Die Migration von meinem Mac mini auf einen iMac 27″ Retina schreitet stetig voran. Die Daten habe ich dazu mit rsync über Gigabit-Ethernet vom Mac mini auf den iMac rüberkopiert.

Der Befehl sah ungefähr so aus:

$ rsync --protect-args -avz -e ssh . mario@domain.tld:/tmp

Bei einem besonderen Verzeichnis trat (ungefähr) folgende Fehlermeldung auf (ich habe sie leider nicht festgehalten):

rsync: on remote machine: --extended-attributes: unknown option
rsync error: syntax or usage error (code 1) at /SourceCache/rsync/rsync-45/rsync/main.c(1333) [server=2.6.9]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.1]

Nach etwas Googlen realisiert ich, dass auf dem Zielsystem (dem iMac) zwar MacPorts mitsamt dem neuesten rsync längst installiert waren (/opt/local/bin/rsync mit rsync version 3.1.2 protocol version 31), über den ssh-Tunnel stattdessen aber das alte, von Apple mitgelieferte Binary verwendet wurde (/usr/bin/rsync mit rsync version 2.6.9 protocol version 29).

Der Grund: Wenn rsync einen SSH-Tunnel aufbaut, werden die üblichen Initialisierungsfiles von bash nicht geladen und somit auch die MacPorts-Pfade (/opt/local/...) nach Binaries abgesucht.

Abhilfe schafft man, indem man dem lokalen rsync mit dem Argument --rsync-path sagt, wo sich die gewünschte Binary befindet:

$ rsync --rsync-path=/opt/local/bin/rsync -av -e ssh . mario@domain.tld:/tmp

Quelle: How can I set environment variables for a remote rsync process?

Tags: , , , , ,
Labels: Apple, Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 21. November 2017

Turris Omnia: LuCI-Seite mit den Port-Weiterleitungen lädt im Schneckentempo

Vor einigen Wochen ist mir ein Bug in der LuCI Web-Oberfläche meines Turris Omnia aufgefallen: Die Seite zum Verwalten der Port-Weiterleitungen (ja, ich bin noch ein eingeschworener IPv4-Haushalt) lädt extrem langsam (Wartezeiten von über 2 Minuten). Will man dann auch noch einen bestehenden Eintrag bearbeiten, wartet man bis zu 16 Minuten (!), bis das Bearbeitungsformular geladen ist.

Mittlerweile habe ich einen Bug-Report im offiziellen Forum veröffentlicht, eine Lösung konnte mir aber noch nicht präsentiert werden. Immerhin haben sich bereits zwei Leidensgenossen gemeldet.

Aber aus einem Grund sind wir ja keine Klickibunti-Windows-Admins geworden und haben selbstverständlich auch den SSH-Zugang auf den Router freigeschaltet.

Die Anpassungen an den Firewall-Einstellungen finden sich in der Datei unter /etc/config/firewall. Am Besten kopiert man einfach einen bestehenden Eintrag und passt diesen nach den eigenen Wünschen an, zum Beispiel so:

...
config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp udp'
	option src_dport '1234'
	option dest_ip '10.10.10.10'
	option dest_port '1234'
	option name 'sikrit hole'
...

Anschliessend speichert man die Datei und lädt die Firewall neu:

# /etc/init.d/firewall restart

Via: Add a firewall rule

Tags: , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 5. November 2017

upsc meldet „libupsclient.so.4: cannot open shared object file“

Als ich letzten Mittwoch meine Debian-Server mit den neuesten stable-Paketen aktualisierte hatte, kam es zu einem Kollateralschaden: Plötzlich wollte cacti die Gesundheitswerte meiner neuen, über USB an die Server angeschlossenen Eaton 3S550IEC resp. Eaton 3S700IEC USVs nicht mehr aufzeichnen.

Nach etwas Debugging dann rasch die Erkenntnis, dass dem Kommandozeilen-Tool zum Auslesen der Parameter der USVs eine bestimmte Datei fehlt:

$ upsc
upsc: error while loading shared libraries: libupsclient.so.4: cannot open shared object file: No such file or directory

Dank der Suche nach dieser Shared Library in Paketen über packages.debian.org war dann schnell klar, dass ich folgendes Paket nachinstallieren musste:

apt-get install libupsclient4

Seither funzt die Aufzeichnung wieder:

image-7540

Schade nur, dass die Eaton USVs nur den Ladestand der Batterie sowie die Auslastung in Prozent ausgeben …

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 5. November 2017

SSH meldet „Bad SSH2 Mac spec“

Meine ~/.ssh/config habe ich gemäss den Empfehlungen von Mozilla konfiguriert.

Offenbar gab es Anpassungen am SSH-Client unter macOS, als ich zu Monatsbeginn (1. November) MacPorts aktualisiert habe.

Es waren keine Logins auf irgendwelche in config konfigurierten Server mehr möglich. Die Fehlermeldung lautete:

$ ssh sauron
/Users/mario/.ssh/config line 8: Bad SSH2 Mac spec 'hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96'.

Hmmm! Mit folgendem Befehl findet man raus, welche SSH2 Macs der SSH-Client mittlerweile nur noch unterstützt:

$ ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

Ich speicherte beide Werte in unterschiedlichen Textdateien, wobei ich die Werte aus der config von Hand auf einen Wert pro Zeile aufspaltete. Danach sortierte ich diese mit sort, um sie besser vergleichbar zu machen.

Ein Diff der beiden Listen zeigte mir schlussendlich klar auf, wo ich Hand anlegen musste:

$ diff ssh-enabled-sorted.txt ssh-available-sorted.txt 
3,4c3,4
< hmac-ripemd160
< hmac-ripemd160@openssh.com
---
> hmac-md5-96-etm@openssh.com
> hmac-md5-etm@openssh.com
6a7,8
> hmac-sha1-96-etm@openssh.com
> hmac-sha1-etm@openssh.com
12a15,16
> umac-64-etm@openssh.com
> umac-64@openssh.com

Damit konnte ich config anpassen. Vorher:

...
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
...

Nachher (hmac-ripemd160,hmac-ripemd160@openssh.com entfernt):

...
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
...

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen