Aus einem Schreiben für die Umstellung auf ganz, ganz neue statische IP-Adressen 🙂 von Unitymedia:
Autorenarchiv: weed
Intel „Grafikeigenschaften“ und „Grafikoptionen“ aus Rechte-Maustaste Menü entfernen
Ich bin nicht sicher, wie man zu einer solchen Idee kommt. Denkt Intel tatsächlich, jeder Computerbenutzer ruft täglich die Superlangsamen Intel-Grafikeinstellungen auf? Ist der Klick auf die „Grafikoptionen“ wichtiger als der Browser? Haben Jahre des Datensammelns ergeben, das es wichtig ist „Grafikeigenschaften“ stets griffbereit auf dme Desktop im Kontextmenü zu haben?
So wird man die Intel-Einträge im Kontectmenü auf dem Desktop los:
HKEY_CLASSES_ROOT\Directory\Background\shellex\ContextMenuHandlers\igfxDTCM
Entfernen, fertig.
Update: nVidia-Eintrag ins Kontextmenü ebenfalls loswerden:
HKEY_CLASSES_ROOT\Directory\Background\shellex\ContextMenuHandlers\NvCplDesktopContext
Danke @“Donald THE Duck “ 🙂
Adobe Acrobat Pro XI Seriennummer herausfinden
Problem
Die Seriennummer für die installierte Version von Adobe Acrobat XI herauszufinden ist nicht einfach. Bis Adobe Acrobat X funktioniert der Registry- oder cache.db Hack noch gut, ab XI leider nicht mehr.
Lösung
Das ausgezeichnete Tool „Belarc Advisor – Free Personal PC Audit“ kann ab Version 8.5c die Seriennummer aller Adobe XI-Produkte auslesen.
vSphere: Black Screen bei Installation von SLES 12 oder RHEL 7.x Linux, Kernel-Dump unter RHEL 7.x
Problem
Bei der Installation von SLES 12 oder RHEL 7.4 tritt ein Blackscreen auf, die Installation geht nicht weiter.
Nach der Migration (oder Upload) von einem fertig installierten RHEL 7.4x gibt es nach dem einschalten einen Kernel-Dump und die Maschine bleibt stehen.
Lösung
Das passiert nur beim Einsatz der Intel E1000 Netzwerkkarte in der VM. Tauscht man die Karte gegen einen VMXNET-Adapter klappt alles. Wenn man den Kernel-Dump zerpflückt, sieht man im Call trace einen Reset der E1000 Karte.
Update: Nach unserem Case dazu hat vmware ein Update für den Host herausgebracht:
This issue is resolved in:
- ESXi 6.0 Update 1 and later, available at VMware Downloads.
- ESXi 5.5 Update 3b and later, available at VMware Downloads.
CUPS meldet „Bad Request“ bei SSL auf IP/FQDN
Problem
Bei der Installation von CUPS (hier: 1.5.3) auf Debian gibt es ein unangenehmes Phänomen bei der Verwendung von ganzen Host- oder Domainnamen. Das CUPS-Webfrontend setzt standartmäßig bei einigen Operationen (Drucker ändern, Drucker löschen und so weiter) voraus, das die Seite via SSL geöffnet wird. Dazu wird auch ein Redirect-Link angezeigt. Klick man diesen, erscheint:
Bad Request
Passiert der Aufruf nicht über den im Zertifikat angegebenen CN, werfen erstens die großen Browser alle eine ’sec_error_untrusted_issuer‘ Meldung und zweitens das CUPS einen „Bad Request„. Dieser HTTP-Fehler 400 verwirrt, denn in der CUPS config ist der port korrekt eingetragen. Die Standardmäßige Wahl der Konfigurationsparameter ist hier etwas ungeschickt.
Lösung
Über die IP-Adresse (192.168.x.y:631) geht das Webfrontend auf, es sei denn das Zertifikat ist falsch. Der schnelle Admin erlaubt einfach alle eingehenden Anfragen.
- Korrektes, passendes Zertifikat für CUPS hinterlegen
openssl req -new -x509 -keyout /etc/cups/ssl/server.key -out /etc/cups/ssl/server.crt -days 3650 -nodes
(Hier dann dem Assistenten folgen, wichtig ist wie immer der „Common Name“ (CN))
- Konfigurationsdatei /etc/cups/cupsd.conf anpassen:
ServerAlias *
- Neustart der CUPS-Dienste
/etc/init.d/cups restart