BITFOX® | LÖSUNGEN | SERVICE | LOGIN | BLOG | KONTAKT

Samstag, 27. Februar 2021

Windows und die "erleichterte Bedienung" der Maus.

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.

Montag, 22. Februar 2021

DDNS: DHCPd und die Journal-Files (.jnl)

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! :-)

Sonntag, 21. Februar 2021

DNS und Root-Adressen updaten


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.

Dienstag, 2. Februar 2021

Windows 10 und seine Updates:
Wenn hinter einem Proxy der Windows-Client unerklärlich "stirbt"

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*

Aktuelles