OSS

Seit pfSense 2.0 ist ein Zertifikatmanager in die Weboberfläche integriert, mit dem sich Zertifikate, z.B. für IPSEC, erzeugen und signieren lassen.

Bei der Verwendung der mit pfSense erstellten Zertifikate in Strongswan in Versionen kleiner als 4.6.2 kann der private Key nicht geladen werden. Folgende Fehlermeldung erscheint:

charon: 00[LIB] L1 - modulus: ASN1 tag 0x02 expected, but is 0x30
charon: 00[LIB] building CRED_PRIVATE_KEY - RSA failed, tried 8 builders

Ursache ist, dass Strongswan bis Version 4.6.2 nur private Keys im PKCS#1-Format lesen kann. Die aus pfSense exportierten privaten Keys liegen aber im PKCS#8-Format vor.

IPv4 Adressen werden immer knapper und mittlerweile bekommt man bei vielen Hostern schon standardmäßig einen IPv6-Adressblock zum gemieteten Server dazu. Wer wie ich einen Debian-Server verwendet, bei dem die Root-Partition mit LUKS verschlüsselt ist und diese beim Bootvorgang über einen Dropbear-SSH-Zugang freigeschaltet werden muss, wird feststellen, dass nach dem Booten die Interfaces nicht die korrekte IPv6-Konfiguration haben.

Unter Debian kann die Netzwerkschnittstelle für Dropbear über die Datei /etc/initramfs-tools/initramfs.conf nur als IPv4 konfiguriert werden. Nach dem Booten stellen die Debian-Skripte fest, dass eth0 schon konfiguriert ist und verwenden die Einstellungen aus /etc/network/interfaces nicht mehr. Etwaige weitere Einstellungen in dieser Datei haben keine Wirkung, da sie nicht ausgewertet werden.

Mit den Tastenkombinationen Strg-Alt-F1 bis Strg-Alt-F6 kann man unter Xserver auf klassische Linux-Konsolen umschalten. Was aber nun, wenn man diese Konsolen gar nicht benötigt, ja sogar diese Tastenkombinationen in anderen Programmen braucht?

In der Man-Page von xorg.conf ist die Option DontVTSwitch aufgeführt, die genau das bewirken soll.

This disallows the use of the Ctrl+Alt+Fn sequence (where Fn refers to one of the numbered function keys). That sequence is normally used to switch to another “virtual terminal” on operating systems that have this feature. When this option is enabled, that key sequence has no special meaning and is passed to clients. Default: off.

[Mehr]

Eine neues “Feature” habe ich nun für die Benutzer von Dualboot-Systemen gefunden, welche ab und zu auch mal Windows starten. Wenn man ein Mal Windows gebootet hat und anschließend wieder zu Linux wechselt, ist die Maus rasend schnell. Viel zu schnell! Leider scheint das ein Bug im Treiber zu sein, der die Maus nicht richtig initialisiert.

Seit kurzem habe ich mein ausgedientes Keyboard, ein Logitech G110, gegen ein aktuelles Modell, ein Logitech G19s, ausgetauscht. Früher habe ich mich nicht um die Ansteuerung der Sondertasten unter Linux gekümmert. Das neue Keyboard mit seinem Display brachte aber den Wunsch wieder hervor, doch einmal zu probieren, was alles mit diesem Keyboard unter Linux möglich ist. Die Software des Herstellers unter Windows hatte ich bereits gesehen und war gespannt, was die Entwickler unter Linux gezaubert haben.

Ab und zu findet man im weiten Netz auch Konfigurationen, in denen für den MX-Record einer Domain ein CNAME geliefert wird. RFC2181 verbietet ausdrücklich, für den MX-Record einen CNAME zu verwenden:

10.3. MX and NS records

   The domain name used as the value of a NS resource record, or part of
   the value of a MX resource record must not be an alias.  Not only is
   the specification clear on this point, but using an alias in either
   of these positions neither works as well as might be hoped, nor well
   fulfills the ambition that may have led to this approach.  This
   domain name must have as its value one or more address records.
   Currently those will be A records, however in the future other record
   types giving addressing information may be acceptable.  It can also
   have other RRs, but never a CNAME RR.

Es ist also ausdrücklich verboten, auf eine MX-Anfrage einen CNAME-Record zu liefern. Ganz praktisch: der PHP-Mailer von 1&1 verschickt an CNAME-Records bei einer MX-Anfrage keine E-Mails, sondern deren Mailsystem lehnt dann den Versand der E-Mail ab.

Das Smartphone Moto G von Motorola kann über die USB-Schnittstelle auf zwei unterschiedliche Arten mit dem PC kommunizieren. Standardmäßig ist Mediengerät (MTP) eingestellt. Der zweite Modus ist Kamera (PTP), mit dem das Gerät sofort unter Linux Mint 16 erkannt wird, aber leider nur Zugriff auf bestimmte Ordner erlaubt.

Um auch den MTP-Modus nutzen zu können, muß das Moto G durch Vendor-ID und Product-ID erst einmal dem udev-Prozess bekannt gemacht werden. Dazu editiert man (als root) die Datei /lib/udev/rules.d/69-libmtp.rules und fügt dort zwei Zeilen an passender Stelle, evtl. nach den bereits dort eingetragenen Motorola-Geräten ein:

Zum schnellen Bearbeiten von Videos (Bildschirmmitschnitten oder anderen Sourcen) unter Linux wird oftmals Avidemux eingesetzt. Das Programm kann die am häufigsten verwendeten Video-Codecs lesen und auch Videos in den entsprechenden Formaten schreiben.

Bearbeiten von großformatigen Videos

Beim Bearbeiten von Bildschirmaufnahmen trifft man unmittelbar auf das Problem, dass Avidemux das Video in voller Auflösung anzeigt und dieses natürlich dann größer als der Bildschirmbereich ist. Da der Fensterrahmen von Avidemux sich nicht kleiner als das angezeigte Video ziehen läßt, erreicht man einige Steuerelemente nicht. Einzige Abhilfe: im Menü Ansicht die Größe auf 1:2 oder noch kleiner setzen.

Mit älteren Mint-Versionen wurde das Programm alacarte zum Bearbeiten des Menüs vorinstalliert. Mit Linux Mint 16 Cinnamon ist das nicht mehr notwendig. Cinnamon bringt seinen eigenen Menüeditor mit.

Aufgerufen wird der Menüeditor durch einen Rechtsklick auf das Menü…

… dem Anklicken von Einrichten… …

… und dem Klick auf Den Menübearbeiter öffnen.

Beim Mieten eines Root- oder vServers von einem Hoster oder, wenn der eigene Server bei einem Hoster untergestellt werden soll (Co-Location) hat man ein Problem: der Server ist nicht unter eigener Kontrolle, Mitarbeiter des Hosters können darauf zugreifen, im schlimmsten Fall Daten ändern oder kopieren. Bei vServern ist dieser Angriff releativ einfach, da die gängigen Systeme problemlos einen Snapshot der vServer-Festplatten erstellen können, die dann von bösen Buben in Ruhe ausgewertet werden können. Bei Root-Servern wird meistens ein vom Hoster geliefertes Kernelimage installiert, dessen Quellcode nicht offenliegt, die gesamte Funktionalität also nicht bekannt ist und somit auch z.B. Keylogger enthalten könnte.