|
Gern kommt es vor, dass man sich bei seinem Dienstanbieter nicht einloggen kann, weil der "TOTP-Token" laut Fehlermeldung nicht passt. Auch die Neueingabe bzw. das Generieren eines neuen Tokens klappt dann nicht. Das Problem ist sehr simpel: Die Zeit zwischen dem lokalen Gerät - welches den Token berechnet - und dem entfernten Server sind nicht synchron. Bei einem PC mit Windows 10 kann es jedoch schon recht schnell umständlich werden, "mal eben" die lokale Uhrzeit auf den richtigen Stand zu bringen... Und wie geht das nun?
Wir werden immer mal wieder um Hilfe gebeten, das eine oder andere Problem im Blog aufzunehmen - dafür wollen wir keinen schnöden Mammon! Wir freuen uns über eine simple Postkarte von Ihnen - und/oder wenn Sie vielleicht einen kleinen Betrag an die Einrichtung "Raum 58" spenden, bei der Sie uns vielleicht im Verwendungszweck mit "Spende durch die BITFOX an RAUM 58" erwähnen Die Kontaktdaten sind wie folgt:
Raum 58 - Obdachlosen-Schlaftstelle für Jugendliche Bank im Bistum Essen
IBAN DE62 3606 0295 0096 8000 70
BIC GENODED1BBE https://www.raum-58.de/spenden/ Warum tun wir das? Wir sind der Meinung, das insbesondere "durch das Raster gefallene"
Jugendliche und junge Erwachsene im Alter zwischen 18-21 Jahren
tatkräftige Hilfe benötigen, die nicht gedeckt ist.
Ein klassische Beispiel ist, wenn die grade "volljährigen" Kids von den
Eltern aus Differenzen heraus "vor die Tür gesetzt" werden.
Wo kann man nun schlafen? Wie behält man nun den Ausbildungsjob, die erste Arbeitsstelle - oder den Studienplatz? Gibt es Anspruch auf Überbrückungsleistungen, Unterhalt/BAFöG, etc.
pp.?
Ausgerechnet an dieser Stelle greift auf Grund der Volljährigkeit die staatliche Jugendhilfe in Deutschland eben nicht mehr!
Wir Danken für Ihre Spende.
Irgendwie nervte mich das Telefonieren im Homeoffice in letzter Zeit: Es klingelt und bimmelt an gefühlt 20 Geräten mit 30 Kopfhörern und 40 Mikrofonen für 50 Telefonnummern, an die man überall sein Ohr steckt und für die Arbeit, privat und von Callcentern angerufen werden kann... Sicherlich - Ein arabisches Sprichwort sagt, Allah habe uns zwei Ohren und einen Mund gegeben, damit wir besser zuhören als zu reden - aber auch zwei Ohren sind manchmal einfach echt nicht genug. Geht das alles nicht etwas einfacher und zentralisierter? Kann man seine Festnetz-Telefonate auf seinen PC schicken? Und kann ich mich gleichzeitig noch um Skype-Telefonate (...) kümmern? 'türlich!
Für eine ausgefuchste Lösung braucht es eine Fritz!Box, ein wenig OpenSource-Software und ggf. ein Sennheiser EPOS SDW66 DECT Headset-Package...
Aber fangen wir von vorne an.. :-)
Man hat mich zum letzten Post zum Thema GPS gefragt. welcher USB-Stick das genau gewesen wäre.
dmesg sagt hier folgendes:
[ 2.371051] usb 5-1: Product: u-blox 7 - GPS/GNSS Receiver [ 2.371058] usb 5-1: Manufacturer: u-blox AG - www.u-blox.com
Bei eBay findet man ein Gerät was genau so aussieht: "VK172 G-MOUSE USB GPS/GLONASS USB GPS Receiver for Windows 10/8/7/VISTA/XP (L49)" Kostenpunkt: 30 Euro.
Beschreibung: Modell VK-172 automatically adapt the baud rate, the baud rate has any data output Tracking Channels: 56 Google Earth is supported C / A code, 1.023MHz stream Receive Band: L1 [1575.42MHz] Support DGPS [WAAS, EGNOS and MSAS] Supported operating systems: Windows 10 8/7/Vista/XP
Leistungsdaten: Reference coordinate system: WGS-84 Acceleration: <4g 2D plane: 3.5m [average], has DGPS auxiliary. 2D plane: 5m [average] Maximum altitude: 18,000 Maximum speed: 500m/s Drift: <0.02m/s Timing Accuracy: 1µs
Aber ich denke auch die VK-162, welche grade für ca. 20 Euro bei eBay zu erhalten ist, dürfte genau so gut funktionieren.
Irgendwie flog nach dem Umzug hier ein kleiner USB-Stick mit der Aufschrift "U-blox7 G-7020" von "U-blox" auf dem Schreibtisch herum. Na was könnte das sein..? Zeit das große Oracle mal zu befragen.
AH - jah... das ist doch mein GPS-Stick, den ich gesucht habe... :-)
Na komm - dann mache ich "mal eben" wieder Zeit im lokalen Heimnetz. Mal eben die Phux-Ärmel hochkrempeln und den alten Artikel von mir rausgesucht...
https://blog.bitfox.com/2015/06/hands-on-wir-bauen-uns-unter-centos.html
Los gehts.. bestimmt dauert das nur zwei Minuten...?!
.....natürlich dauerte es keine 2 Minuten...
Auf den letzten Beitrag mit dem "Find" und den "Ein-/Ausgabekanälen" auf der Bash kamen einige Rückmeldungen; das würde Spaß machen und da solle ich mir doch noch mal was einfallen lassen. Einen "bösen lehrreichen Klassiker" hätte ich aber vielleicht noch.
Was ist richtig und warum? :-)
Nicht googlen - und bitte NICHT EINFACH AUSPROBIEREN - das könnte ggf. schief gehen und die Daten sind weg.... :-)
find /somewhere/ -type f -name foo -exec rm -f {} \; 2>&1 >/dev/null
find /somewhere/ -type f -name foo -exec rm -f {} + &>/dev/null
find /somewhere/ -delete -name foo -type f &>/dev/null
Wer seinem Windows10-Client genauer auf die Finger schaut wird merken, dass jede Eingabe in das Search-Feld am unteren Bildrand zur Folge hat, das Windows nicht nur lokal auf dem PC, sondern auch im Internet nach der getätigten Eingabe herum sucht: So werden einem die besten Treffer von der Microsoft-Suchmaschine Bing wie selbstverständlich neben den lokalen Treffern in Dateien und Progrogrammen auf der lokalen Festplatte präsentiert.
Persönlich mag ich es nicht, wenn meine Suchbegriffe mit der Welt geteilt werden, denn es geht das Internet nichts an, ob ich den lokal auf meinen PC einen herunter geladen Jahresbericht eines Ministeriums, ein Gedicht, eine Quittung oder sonst etwas suche. Und auch eher selten möchte ich einen alternativen Vorschlag für etwas vergleichbares aus dem Internet: Dann würde ich den Webbrowser für eine Suchmaschine öffnen.
Wie bremse ich also das automatische Gesuche im Internet?
Auf der Arbeit nervte ein Cronjob und löste immer wieder Fehler-Mails aus. "Kein Ding."
crontab -e ... "Alles klar, da fehlt was."
Am nächsten Tag: Wieder eMails. crontab -e ... Hmh... "Wieso...?!" ...und eine Nacht überlegen...
Autsch! Gemein! KLAR! DER ist guuuuuut! :-) crontab -e ...."Jetzt aber!" Ruhe.
Wer also einem Linux-Admin einmal eine wirklich gemeine Alltagsfrage stellen möchte, für den habe ich da was: find /does/not/exist -name foo -exec bar {}\; -print 2>&1 >/dev/null
find /does/not/exist -name foo -exec bar {}\; >/dev/null 2>&1
find /does/not/exist -name foo -exec bar {}\; -print &>/dev/null
Was davon ist richtig - und vor allem: Warum?
Nicht googeln - nicht ausprobieren - versucht's mal aus dem Stehgreif zu beantworten. :-)
Eher zufällig hatte ich heute mal wieder einen Windows10-Rechner in der Hand, der sich sehr sehr eigenartig in der Benutzerführung verhielt: Die Maus hob jedes Fenster beim herüberstreichen in den aktiven Focus und alles an Fenstern "klebte" förmlich an der Maus.
Der Besitzer hatte wohl unter "Systemsteuerung\Erleichterte Bedienung\Center für erleichterte Bedienung\Verwenden der Maus erleichtern" den Haken "Ein Fenster durch Zeigen mit der Maus aktivieren" gefunden - und zusätzlich noch auf Grund einer "Profi-Empfehlung" ein "exklusives" Konfigurationstool benutzt, das man lieber gleich hätte in das NULL-Device Schieb-en können...
Dieser MouseOver-Effekt ("Focus Follows Mouse") bzw. Fenster allein durch das Überfahren mit dem Mauszeiger zu aktivieren kann sicherlich für Menschen mit Behinderungen in der Hand-Motorik bzw. der Hand-Augen-Koordination eine erleichterte Bedienung sein --- Wenn ich jedoch als "Tekkie" nicht einmal mehr von links nach rechts eine Datei ziehen kann, ohne dass mir alle dazwischen liegenden Fenster hin und her switchen und ich nach loslassen meiner Maustaste mein altes "Quell"-Fenster verzweifelt suchen muss, wird es einfach nervig und das Gerät ist nicht mehr sinnvoll bedienbar: So kann man einfach nicht helfen.
Also mache ich das ganze "mal eben" wieder rückgängig... "Haken raus und gut, ne?" ....aber klaaaaar doch....! :-) Natürlich war es nicht so einfach... denn das "ProfiTool" hatte volle Arbeit geleistet und irgendwo in der Registry Einstellungen gesetzt, die nicht mehr zu retten waren.
Mit ziemlichem "Gefummel" konnte ich das Problem mit "Regedit" in der Registry ungefähr in "Computer\HKEY_CURRENT_USER\Control Panel\Desktop" einkreisen.
Also eine Text-Datei als "NoMouseOver.reg" mit folgendem Textinhalt erstellen und doppelt anklicken:Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\Desktop]
"CaretWidth"=dword:00000001
"ClickLockTime"=dword:000004b0
"MouseWheelRouting"=dword:00000002
"UserPreferencesMask"=hex:9e,1e,07,80,12,00,00,00
"Pattern"=-
"AutoColorization"=-
"ImageColor"=-
"WaitToKillAppTimeout"=-
"LockScreenAutoLockActive"=-
"EnablePerProcessSystemDPI"=-
"LogPixels"=-
"ScreenSaverIsSecure"=-
"ScreenSaveTimeOut"=-
Wenn das nicht klappen sollte, erinnere man sich daran, dass die Schlüssel im Bereich "HKEY_CURRENT_USER" stehen: Es handelt sich dabei um Einstellungen des Users. Man erstellt im Schlimstfalle also einfach an dem PC ein neues Dummy-Benutzerkonto, logged sich dort ein und exportiert dort einen "frischen" Schlüsselbaum aus der Registry des dann angemeldeten Benutzer.
Anschließend einfach wieder in den "Kaputten" User einloggen, den Ordner "Computer\HKEY_CURRENT_USER\Control Panel\Desktop" mit Regedit löschen und die korrekten Einstellungen mit Doppelklick wieder importierten - und das Dummy-Benutzerkonto wieder löschen. Das mag eine Holzhammermethode sein, aber wird aber im Zweifelsfalle ganz sicherlich funktionieren.
P.S.: Für die Benutzer mit englischem Windows: Die Einstellungen für das MouseOver befinden sich unter "ControlPanel\Ease of Access\Ease of Access Center\Make the Mouse easier to Use" und der Haken heisst hier "Activate a window by hovering over it with the mouse"
Edit: Nach einem kurzen Testlauf konnte ich feststellen, dass es reicht den Wert [HKEY_CURRENT_USER\Control Panel\Desktop]
"UserPreferencesMask"=hex:9e,1e,07,80,12,00,00,00
mit Regedit wie angegeben zu ändern.
Wer einen DHCPd errichtet und gegen den DNS betreibt stellt nach einer Zeit fest, dass die dynamischen Einträge im DNS durch Journal-Files (.jnl) in /var/named zu den Zonefiles vorgehalten werden. Nach einiger Zeit sieht das nicht nur ziemlich unschön aus, man kann auch aus den Zonefiles nicht mehr die "aktuelle Realität" ablesen - und die Journal-Files sind für das menschliche Auge nicht ohne weiteres sprechend.
Bereits im März 2019 hatte ich mich mal wieder damit befasst und hatte ein paar Zeilen geschrieben. Der wohl allgemeine Tipp um diese Deltas zwangsweise zusammen zu führen ist, die Zonen mit rndc freeze
rndc thaw
einzufrieren bzw. freizugeben. Das klappt jedoch auch nicht immer so ganz und persönlich fand ich das immer unschön, weil es nicht das "Problem" an der Wurzel packt - dem Synchronisieren der Files. Eher zufällig bin ich heute durch das Manual gestolpert und habe da eine definitiv schönere Lösung gefunden: rndc sync -clean
Das ganze als Cronjob auf 30 Minuten - und schon ist das Arbeiten wieder etwas einfacher. */30 * * * * rndc sync -clean
Man lernt nicht aus...! Schön! :-)
Sonntags um 03:00 Uhr - das eigene Monitoring klingelt: Internet gibt es nur noch so halb und alles alles an Maschinerie benimmt sich sehr sehr eigenartig. 5 Minuten später ist das Problem erkannt: Der hauseigene mini-DNSrelay hat versagt und ich schwenke erst einmal voll um auf die Fritzbox bzw. Telekom. Doch was war passiert? Aus unerklärlichen Gründen hatte sich beim Update der DNS-Rootserer-Einträge die /var/named/named.ca "aufgelöst" und somit konnten keine DNS-Rootserver mehr gefunden werden; was natürlich die entsprechenden Folgen hatte. Hrm.... Also - ein neues Update-Script für die Ermittlung der DNS-Rootserver....! :-) #!/bin/bash
#
# update-dns-roots
# Script zum Aktualisieren der DNS-Root-Adressen
#
# 2021-02-21 Oliver Lenz
#
# contab ->
# 0 10 1 * * /root/bin/update-dns-roots.bash >/dev/null 2>&1 || echo "Probleme in update-dns-roots.bash"
#
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
destination="69.58.179.79" # ftp.rs.internic.net
dt=$(date "+%Y%m%d%H%M%S")
filter="FILTER:$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)"
errorlevel=255
echo "Setup Firewall for ftp-Communication with ${destination}"
modprobe ip_conntrack
modprobe ip_conntrack_ftp
iptables -A OUTPUT -p tcp --sport 1024:65535 -d ${destination} --dport 20 -m state --state ESTABLISHED -j ACCEPT -m comment --comment "${filter}"
iptables -A OUTPUT -p tcp -m tcp --sport 1024:65535 -d ${destination} --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT -m comment --comment "${filter}"
iptables -A OUTPUT -p tcp --sport 1024:65535 -d ${destination} --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT -m comment --comment "${filter}"
iptables -A INPUT -p tcp -s ${destination} --sport 20 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT -m comment --comment "${filter}"
iptables -A INPUT -p tcp -m tcp -m multiport -s ${destination} --sports 21,1024:65535 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT -m comment --comment "${filter}"
echo "Getting ca-File from ${destination}"
wget -q --timeout=4 --tries=3 --waitretry=2 --user=ftp --password=ftp ftp://69.58.179.79/domain/db.cache -O /var/named/named.ca.tmp &>/dev/null
if [ "$?" == "0" ]; then
if cmp -s /var/named/named.ca /var/named/named.ca.tmp; then
echo "No changes."
rm -f /var/named/named.ca.tmp
else
cp -f /var/named/named.ca /var/named/named.ca.${dt}
mv -f /var/named/named.ca.tmp /var/named/named.ca
/usr/bin/systemctl restart named-chroot.service
echo "Update ca-file successfully."
fi
errorlevel=0
else
echo "Problems getting new ca-file via /root/bin/update-dns-roots.bash"
errorlevel=1
fi
echo "Remove Firewall-Rules for ftp-Communication with ${destination}."
while read rule; do
echo "${rule}" | xargs iptables
done< <( iptables-save | grep " --comment \"${filter}\"" | sed "s/-A /-D /g" )
exit ${errorlevel}
Update: 2022-01-16 Typo in der Dateiausleitung nach /dev/null in der wget-zeile.
Irgendwie wurden zu Hause in den letzten Tagen einige Windows-10-Clients immer langsamer. Hmh. Was ist denn da los? Der Taskmanager zeigte an, dass "Windows Update" 90% der CPU-Ressourcen verbrauchen würde - und ein Blick auf den Netzwerkadapter zeigte ebenfalls, dass da was "im Busch" war: Der Client versuchte ohne Rücksicht auf Verluste Netzwerkverbindungen zur Außenwelt aufzubauen. Virenbefall? Hier hätte der Client zumindest ein wenig Probleme durch den authentifizierenden Proxy.
Also schaute ich in das Log des Proxies, wohin die Verbindungen gehen sollten und das Problem wurde sichtbar: Windows Update kann nicht mit authentifizierenden Proxies arbeiten! Der Client versuchte gar tausende Anfragen nach Microsoft aufzubauen, die vom Proxy gedropped wurden; entsprechend wurden die Ressourcen des Gerätes verschwendet und der Client lief so im wahrsten Sinne des Wortes "heiß". Und nun?
Pest oder Cholera? Schalte ich den Update-Service des Clients ab, oder schalte ich die Authentifizierung des Proxies ab? Oder installiere ich nun extra einen WSUS-Server für das Update von einigen Windows-Clients....? Das kann alles nicht die Lösung sein. Mit einem gehörigen Knirschen habe ich folgende Zeilen in die Squid-Konfiguration eingetragen:
acl windowsupdates dstdom_regex -i (.*\.|)microsoft.com http_access allow windowsupdates ...Magenschmerzen...! Jetzt kann ein jeder hinaus auf ein Ziel bei Microsoft, ohne eine Authentifizierung. ......aber der Client läuft nun wieder schnell.... *hust*
Das BSI warnt grade vor alten sudo-Versionen auf unixoiden Betriebssystemen: Einfache Benutzer können Root-Zugriff erlangen, sogar wenn diese Benutzer nicht einmal in der /etc/sudoers erwähnt sind. Auch Accounts ohne Shell bzw. lediglich hinterlegtem Kontext sind somit gefährlich. "Also - mal eben schauen", wie "neu" das sudo auf der Maschine ist. rpm -qi $( rpm -qf "/bin/sudo" )
Aber geht's noch schöner? Klar - etwas CommandLine-Zauber... :-)
f="/bin/sudo" ; rpm -qf "${f}" --qf '%{name} %{version}-%{release}%{arch} from '; env TZ=Europe/Berlin date -d "@$( rpm -qf "${f}" --qf '%{buildtime}' )" "+%Y-%m-%d %H:%M:%S %Z"
Nachtrag: %{buldtime:date} Zeigt bereits einen Datumsstring, welcher jedoch nicht wirklich ansehnlich ist.
....so oder ähnlich könnte es nun heissen. Das Problem war eigentlich, nur "mal eben" einen JSON-String ohne zusätzliche Tools "menschlich lesbar" anzuzeigen. "Da muss doch schon mal wer was ordentliches gemacht haben?" Nach ca. 2 Stunden suchen hatte ich jedoch immer noch nichts wirklich funktionierendes gefunden, was einen JSON-String "ordentlich" menschlich visualisiert - oder auch ggf. aus einem JSON-String einen Variablen-Bereich einfach wieder heraus gibt. Na dann... bau ich da mal halt selbst - Auf geht's :-) #!/bin/bash
#
# Funktionen zum Umgang mit JSON-Strings.
#
# 2020-11-13 Oliver Lenz Initial
#
function parse_jsonvar_raw() {
# Parse einen JSON-String in menschlich lesbare form.
#
# $1 JSON-String
# $2 Tabulatorenweite (default:4) (optional)
# $3 Filtere die Ausgabe anhand eines Variablennamens (optional), z.B. "value.name"
#
local buchstabe="" letzter_buchstabe="" zeile=""
local in_gaensefuesschen=0 umbruch=""
local variablenname="" variablenstack=()
local ebene=0 anschlag=0
local tabbreite=4 filter="" zurueck=0
if [ $# -gt 1 ]; then
[[ "${2}" =~ (^[0-9]*$) ]] && tabbreite=$2 || filter=".${2}"
fi
[ $# -gt 2 ] && filter=".${3}"
function vartest() {
local voller_variablenname="" i=0 s
[ -n "${variablenname}" ] && variablennamenstack[${ebene}]="${variablenname}"
voller_variablenname=""
for((i=0;i<=${ebene};i++)){
s="${variablennamenstack[$i]#\"}"
s="${s%\"}"
voller_variablenname="${voller_variablenname}.${s}"
} # printf "%-60s" "${voller_variablenname}"
if [[ -z "${filter}" || "${filter}" == "${voller_variablenname}" || "${voller_variablenname:0:$((${#filter}+1))}" == "${filter}." ]]; then
[ "${filter}" == "${voller_variablenname}" ] && zurueck=$ebene # korrektur bei Filter
(( i=$anschlag-$zurueck*tabbreite ))
[ ${i} -gt 0 ] && printf "%${i}s" " "
[ -n "${zeile}" ] && echo "${zeile}"
fi
variablenname=""
zeile=""
}
while read -n1 buchstabe; do
if [ "${in_gaensefuesschen}" == "1" ]; then
[ "${letzter_buchstabe}" != "\\" ] && [ "${buchstabe}" == "\"" ] && in_gaensefuesschen="0"
elif [ "${letzter_buchstabe}" != "\\" ] && [ "${buchstabe}" == "\"" ]; then
in_gaensefuesschen="1"
else
case "${buchstabe}" in
'{' | '[' | '(' | ',' ) umbruch="nach_buchstaben";;
'}' | ']' | ')' ) umbruch="vor_buchstaben";;
':') variablenname="${zeile}";;
' ') buchstabe="";;
esac
fi
[ "${umbruch}" == "vor_buchstaben" ] && vartest && (( ebene-- ))
zeile="${zeile}${buchstabe}"
[ "${umbruch}" == "vor_buchstaben" ] && (( anschlag=ebene*tabbreite ))
if [ "${umbruch}" == "nach_buchstaben" ]; then
vartest
[ "${buchstabe}" != "," ] && (( ebene++ ))
(( anschlag=ebene*tabbreite ))
fi
letzer_buchstabe="${buchstabe}"
umbruch=""
done<<<"${1}"
[ -n "${zeile}" ] && vartest
}
function parse_jsonvar(){
ausgabe="$( parse_jsonvar_raw "${1}" "${2}" "${3}" )"
[ -n "${ausgabe}" ] && echo "${ausgabe%,}"
}
# json_str='value:{"name":"Hello World","myNumArray":{"index0":"Hello","varname":"value","some":"thing"}}'
# parse_jsonvar "${json_str}"
# parse_jsonvar "${json_str}" 8
# parse_jsonvar "${json_str}" 4 "value"
# parse_jsonvar "${json_str}" 4 "value.name"
# parse_jsonvar "${json_str}" 4 "value.myNumArray"
Geht doch... :-)
Wer Scripte in der BASH-Shell schreibt, der hat hin und wieder sehr unangenehme Erfahrungen mit Arrays: Ist man hier nicht sehr genau in der Syntax, gehen Einträge verloren, oder man erhält Null-Einträge.
Anbei eine Idee, wie man das Problem mit üblichen Funktionen wie "push" (etwas auf den Stack legen), "pop" (das letzte Element vom Stack zeigen und löschen), "delete_from_stack" (ein gezieltes Element vom Stack löschen) und "print_stack" (gebe einen Stack aus) lösen kann. Viel Spaß damit. :-)
Sehr (un)gern stellt man oft fest, dass die Shell auf der man grade arbeitet in einer ganz anderen Zeitzone lebt, als von der man aus arbeitet. Das Remote-System auf dem ich grade eingelogged bin, arbeitet z.B. in UTC.
$ date "+%c"
Wed Oct 7 23:26:47 UTC 2020
Da kann man als Europäer mal gar nichts mit anfangen. Wie kommt man nun also an die Uhrzeit zu Hause?
...oder auch: Die Magie von "date".
Wer mit einem Bash-Script einen Checkpunkt für ein Monitoring-System wie z.B. Check_MK schreibt, der kennt wahrscheinlich das Problem: Manchmal übertreibt ein Monitoring-System und ruft seinen Check von Remote so oft auf, dass die Ressourcen des zu überwachenden Clients schlichtweg zu ausgelastet sind. Das Monitoring hilft also nicht mehr, sondern bringt den zu überwachenden Client zu Fall. Man kann jedoch die Ausgaben eines Scriptes sehr einfach (selbst) Cachen und sollte das auch selbst übernehmen, denn die Caching-Mechanismen solcher Monitoring-Systeme sind auch gern mal etwas unberechenbar...
Wer z.B. wie gewohnt und brav nach Dokumentation in Check_MK mehrzeilige Ausgaben in /usr/lib/check_mk_agent/local/${CACHE_ZEITINDEX}/mein_check.bash hinterlegt, der wird feststellen, dass diese nicht (mehr) funktionieren: Das Ergebnis wird einfach verschluckt und nicht angezeigt. Mehrzeilige Ausgaben funktionieren anscheinend also nur noch in /usr/lib/check_mk_agent/local/ , wo jedoch dann kein Caching stattfindet und man den Client ggf. überlastet.
Ein Teufelskreis. :-) Was nun tun? Ein kleines "if" mit "date" und die Ausgabe mit "tee" bringt hier einen Ausweg. Hands on...!
"Mal eben" einen Proxy bauen, um die Geräte im Büronetzwerk ein wenig zu schützen und was passiert anschließend? Keiner der Windows10-Clients mag mehr so recht mit dem Update-Server von Microsoft sprechen. Das Problem scheint bekannt - doch eine wirkliche "Lösung" findet man im Internet nicht so recht.... Also - was tun?
....ja was ist denn schon dabei? Da war er wieder, der klassische Moment auf der Console: Man möchte "mal eben" ein CentOS-System neu aufsetzen und vorsichtshalber die Konfigurationsdateien etc. sichern - man weiß ja nie so recht, ob man doch noch was braucht.... Doch die Backupsoftware sagt "nein" und "Fehler", für ein dd-image fehlt ein zweiter Speicherort mit Platz und man weiß grade lokal ohnehin kaum aus dem Stehgreif, was man einpacken sollte. Na dann.... bist du nicht willig.... dann nehme halt ein wenig Commandline-KungFu...
Es fing damit an, dass ich lediglich "Mal eben[tm]" einen Windows-Client neu installierte: Browser, eMail, etc. - und ich empfing die Test-eMail auf meinem Laptop. Nanu? In den ankommenden Maildaten versteckt, meldet sich auf einmal ein eMail-Useragent:
"User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0"
Zu deutsch: Jeder Empfänger kann sehen: Ich schreibe eMails an einem Windows-Client des Kunden mit dem eMail-Programm Thunderbird in der Version 38.2 in 64 Bit.
Für einen Angreifer sind solche Informationen natürlich Gold wert, denn so kann man gleich den passenden Exploit heraussuchen, um den Empfänger einer eMail "zu beglücken".
Wer solche Informationen langfristiger sammelt weiß obendrein, wo der Absender seine eMails schreibt: Erscheint der gleiche eMail-Client oft in einer Mail von MO-FR zwischen 10 und 14 Uhr auf , wird das wohl der Mailclient sein, der im Büro genutzt wird. (Hint: Klar - ggf. passt obendrein sehr häufig auch noch der Netzbereich der einliefernden IP des Mailclients, aber auf Grund von VPN kommt man mit dieser Data nicht so schön weit wie mit dem Header "User-Agent") Wahrscheinlich nutzt auch jemand einen anderen eMail-Client an seinem Handy, als an seinem PC; wahrscheinlich werden von dort gehäuft Mails zwischen 06:00 bis 08:00 Uhr bzw. zwischen 16:00 und 18 Uhr kommen. Und so weiter, und so fort....
Mit etwas Dokumentations-Mühe erhält man so also mit einer sehr guten Wahrscheinlichkeit demnächst eine Vorhersage, wo der Absender seine eMail grade verfasst: "Schatzi, ich weiss, dass du grade nicht auf der Arbeit bist." "Und ich auch - ihr Chef."
Doch was tun? [Hier weiter lesen.]
|
|
|
|