|
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.]
|
Welches Stickchen hätten Sie denn gern? |
Wer Windows 10 links und rechts auf PCs installiert, hat irgendwann einen schönen Strauß an erstellen USB-Installations-Sticks mit jeweils verschiedenen Versionen.
Aus der Erfahrung empfiehlt sicht durchaus, eine jeweils schon veraltete Installations-Version an die Seite zu legen und nicht immer nur das "Installationsimage des Tages" auf einen Stick zu brennen, denn so habe ich selbst immer wieder erlebt, dass sich ein Windows 10 auf einem Notebook nicht vom stick neu installieren ließ, weil die Installationsversion "zu neu" war.
Erst ein Stick aus den Anfängen von Windows 10 half hier oft weiter....
Doch wie ermittele ich nun von den ganzen herumliegenden USB-Stick die Windows-Version, um diese z.b. auf der Rückseite des Sticks zu vermerken?
Wer mit verschiedenen Plattformen arbeitet, z.B. Amazon, eBay, Blogger, etc., der kennt die üblichen
"2Auth-OTP-Token" -
die Zweifach-Authentifizierung.
Beliebt dafür ist z.B.
der Yubikey 5 - mit der ensprechenden App "Yubikey Authenticator" auf dem Handy, die einen OTP-Hash speichern bzw. einen dazugehörigen OTP-Key
generieren kann, um sich "sicher" einzuloggen:
Den Stick an sein Handy halten um
den Token zu generieren bzw. zu lesen - fertig.
Wenn man dann jedoch ohne Handy an seinem PC "mal eben" den Key
eingeben will, muss man den USB-Stick dann umständlich in den USB-Port fummeln und das Programm am PC öffnen
...
Geht das denn nicht anders?
Heute mal ein interessanter Support-Fall von zu Hause. :-)
In den letzten Tagen war ich dann doch mal früher zu Hause und hatte periodisch immer wieder Kopfschmerzen. Mit
einem Schmunzeln hat mich jemand darauf hingewiesen, ich hätte dieses Mal viel am Fernseher gesessen bzw. viel Computer gespielt; was sonst nicht
wirklich der Fall ist.
Grübel Grübel - tatsächlich. Stimmt.
Das aber ein Amazon TV 4K-Stick zusammen mit einem Samsung-Fernseher ganz real die Ursache sein könnten, damit konnte keiner rechnen...
|
|
|
|