BIOS und EFI Version unter Windows anzeigen (ohne reboot)

Problem

Welche BIOS- oder EFI-Version hat der Server oder der PC oder der MAC?  Muss ich aktualisieren? Kann ich das nachschauen ohne gleich die ganze schöne Maschine zu rebooten und einen Monitor anzuschliessen und im richtigen Moment eine geheime magische Taste zu drücken?

Lösung

Kein Problem, mann auch unter Windows/Linux/MacOS die BIOS-Version anzeigen. Funktioniert praktisch überall, Ausnahmen bestätigen allerdings die Regel. Bleibt die Anzeige leer oder zeigt „????“ ist warscheinlich einfach nicht der richtige Chipsatz-Treiber geladen.

BIOS-Version unter Windows 8/8.1/10

An der Kommandozeile (CMD/PowerShell):

C:\> wmic bios get smbiosbiosversion

BIO-version-anzeigen-unter-windowsBIOS-Version unter Linux (Debian/RedHat/CentOS/SuSE/LFS)

An der Shell:

bldgrdian:~# dmidecode | grep Version

bios-version-anzeigen-unter-linux

BIOS-Version unter MacOS X (EFI und SMC PCs)

Die Auswahl via GUI starten: den System-Ordner „Programme“ öffnen > Dienstprogramme > Systeminformationen > Hardware (der Wurzelknoten ganz oben, unter den Auswahlpunkten wird die Version nicht mehr aufgeführt)

bios-version-anzeigen-unter-macosAchtung bei Apple-FW-Updates! Durch den bunten Chipsatz- und CPU-Zoo der schon ähnliche Außmaße annimmt wie bei DELL oder ASUS, gibt es einen unübersichtlich koplexen Abhängigkeitsbaum. „Einfach auf die letzte Version aktualisieren“ endet manchmal in einem nicht mehr startenden MacOS. Bewährt hat sich Step-by-Step updates mit jeweiligem OS-Boot und Update dazwischen.

Alternativ tut es oft auch

dmidecode

aber erst bei aktuellen Macs.

Debian: Es gibt keine öffentlichen Schlüssel für die folgenden Schlüssel-IDs …

Problem

apt-get update schlägt „seit neuestem“ mit seltsamen Schlüsselpaar-Fehlermeldungen fehl:

[email protected]:~# apt-get update
OK   http://security.debian.org wheezy/updates Release.gpg
OK   http://security.debian.org/ wheezy/updates/main Translation-en
OK   http://security.debian.org wheezy/updates Release
OK   http://security.debian.org wheezy/updates/main Sources
OK   http://ftp.at.debian.org wheezy Release.gpg
OK   http://ftp.at.debian.org/debian/ wheezy/main Translation-de
OK   http://ftp.at.debian.org/debian/ wheezy/main Translation-en
OK   http://ftp.at.debian.org wheezy-updates Release.gpg
OK   http://ftp.at.debian.org/debian/ wheezy-updates/main Translation-en
OK   http://security.debian.org wheezy/updates/main amd64 Packages
OK   http://ftp.at.debian.org wheezy Release
OK   http://ftp.at.debian.org wheezy-updates Release
OK   http://ftp.at.debian.org wheezy/main Sources
OK   http://ftp.at.debian.org wheezy/main amd64 Packages
OK   http://ftp.at.debian.org wheezy-updates/main Sources
Hole:1 http://ftp.at.debian.org wheezy-updates/main amd64 Packages/DiffIndex [1.012 B]
Es wurden 1.012 B in 0 s geholt (4.720 B/s)
Paketlisten werden gelesen... Fertig
W: Es gibt keine Öffentlichen Schlüssel für die folgenden Schlüssel-IDs:
9D6D8F6BC857C906
W: Es gibt keine Öffentlichen Schlüssel für die folgenden Schlüssel-IDs:
7638D0442B90D010
W: Es gibt keine Öffentlichen Schlüssel für die folgenden Schlüssel-IDs:
7638D0442B90D010

Alternativ jammert apt auch gerne auf English:

There is no public key available for the following key IDs: 8B48AD6246925553

Lösung

Die Schlüssel-IDs 9D6D8F6BC857C906 und 7638D0442B90D010 gehören zu den Debian Wheezy Update Package Repositorys und sind Teil des Keyring-Pakets (die Update-Pakete benötigen das Keyring-Archiv). Einfach den debian-keyring installieren:

[email protected]:~# apt-get install debian-keyring debian-archive-keyring

Dann läuft das nächste apt-get auch schon fehlerfrei durch:

[email protected]:~# apt-get update

(Referenz: http://gnuru.org/article/1486/debian-public-keys-error-2)

Tomcat liefert „ssl_error_weak_server_ephemeral_dh_key“ im Firefox

Problem

Firefox ab Version 39 zeigt bei von einem frischen Tomcat ausgelieferten Webseiten nur noch diese Alternativlose Fehlermeldung an:

Fehler: Gesicherte Verbindung fehlgeschlagen

Ein Fehler ist während einer Verbindung mit oputils.pflitsch.de aufgetreten.
SSL hat einen schwachen kurzlebigen Diffie-Hellman-Schlüssel in der Handshake-Nachricht
"Server-Schlüsselaustausch" empfangen.
(Fehlercode: ssl_error_weak_server_ephemeral_dh_key)

    Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
    Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren.

Lösung

Der unsichere DH/SSL Schlüsselaustausch ist anfällig für die „Logjam“ Attacke (https://weakdh.org), aber noch die Defaultkonfiguration für neue SSL-Connectoren im Tomcat.

In der server.xml kann man im Abschnitt <connector> die passenden Cipher-Suiten vorgaben. Bewährt hat sich diese Liste hier, weil sie auch noch die älteren aber sicheren SSL-Handshakes für den Internet-Explorer enthält.

<Connector
   port="443"
   protocol="HTTP/1.1"
   SSLEnabled="true"
   keystoreFile="uggliest.keystore"
[...]
   ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA"
/>

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 Standartmäß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.

  1. 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))

  2. Konfigurationsdatei /etc/cups/cupsd.conf anpassen:
    ServerAlias *
  3. Neustart der CUPS-Dienste
    /etc/init.d/cups restart

CentOS 6 statische IP-Adresse an der Shell konfigurieren

logo_smallStatische IP-Adresse in CentOS konfigurieren

Die Netzwerkkonfiguration in CentOS Linux ist in der Datei

/etc/sysconfig/network-scripts/ifcfg-eth0

abgelegt. Der Inahlt der Datei sieht bei einer statischen IP so aus:

DEVICE="eth0"
 NM_CONTROLLED="yes"
 ONBOOT=yes
 HWADDR=DE:AD:BE:EF:F1:04
 TYPE=Ethernet
 BOOTPROTO=static
 NAME="System eth0"
 UUID=5fbfffff-0fff-7ffb-4ff1-fffffff3e02
 IPADDR=192.168.66.6
 NETMASK=255.255.0.0

Default Gateway

Für das Routing ist diese Datei

/etc/sysconfig/network

verantwortlich, die dann so aussieht:

NETWORKING=yes
HOSTNAME=foobaerchen
GATEWAY=192.168.1.1

DNS-Einstellungen

DNS-Einstellungen sind wie bei (nahezu jedem) Linux in der

/etc/resolv.conf

abgelegt. Der Inahlt sieht dann auch entsprechend einfach aus:

nameserver 8.8.8.8      # Replace with your nameserver ip
 nameserver 192.168.1.1  # Replace with your nameserver ip

Wenn alle diese Einstellungen getätigt sind, einmal das Netzwerk neu starten:

/etc/init.d/network restart

 

Linux später neu starten ohne angemeldete Shell

Problem

Ein Linux/Unix Computer soll später neu starten. Der Reboot soll nicht permanent angelegt sein (z.B. als Cronjob) und es gibt kein screen auf dem System. Die Shell ist bis dahin auch nicht mehr verbunden, daher fällt ein simpler ’shutdown‘ Befehl aus.

Lösung

Das Shutdown mir nohub starten. nohup ist ein Befehl, ein Programm auszuführen, wobei dieses dann das HUP-Signal unterdrückt. Dadurch kann man das Programm starten und laufen lassen, auch wenn es kein offenes TTY mehr gibt.

Üblicherweise nutzt man nohup, um Dienste im Hintergrund zu starten und diese so von der Login-Shell zu trennen. Ausgaben des aufgerufenen Programmes werden automatisch in die Datei nohup.out geleitet, die im Verzeichnis angelegt wird, von dem aus der Befehl ausgeführt wurde. Um zu verhindern, daß das Programm nicht weiterläuft, weil es auf Eingaben wartet, ist es außerdem manchmal notwendig, auch die Standard-Eingabe etwa mit „</dev/null“ umzulenken.

In unserem „Sei still und boote einfach neu“ Beispiel könne wir auf die Ausgane verzichten, daher sieht die einfachste Lösung so aus:

nohub shutdown -r -t sec 120 >/dev/null 2>&1 &

ACHTUNG. nohub ist nicht die Lösung der Wahl, um Dienste permanent im System zu verankern. Wer sein node.js so startet, hat weder nodeJS noch das system.d Konzept verstanden 😉

Linux: mount error 13 = Permission denied

Problem

  • Es soll ein CIFS share von einem Netapp Filer, einem Windows 2000 oder anderem Linux-System gemountet werden; es tritt der Fehler „mount error 13 = Permission denied“ auf.
  • Einzelne (bis zu zwei) Shares können problemlos verbinden werden. Ob die Credentials an der Kommandozeile eingegeben oder aus einer Credentialsfile eingelesen werden ist egal, es tritt immer der selbe Fehler auf.
  • Das sieht zum Beispiel so aus:
# mount -t cifs //exampleserver/share1 /mnt/share1 -o credentials=/root/.credentials/s1
# mount -t cifs //exampleserver/share2 /mnt/share2 -o credentials=/root/.credentials/s2
mount error 13 = Permission denied
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

Lösung

Die Verbindungssicherheit erlaubt nur zwei Verbindungen pro Hostsitzung für einen Benutzer (=Mountpoint). In älteren Kernels wird dieses System umgagen, wenn das Ziel ein Windows 2000 ist. Netapp nutzt (im Moment) die CIFS-Version von Windows 2000, daher fehlen einige Protokollfeatures.

Möglichkeit 1: Einen älteren Kernel installieren (Redhat: vor 2.6.18-348.18.1)

Möglichkeit 2: Maximal zwei Verbindungen pro Benutzersitzung verwenden.

Referenz: https://access.redhat.com/site/solutions/509393