Fedorausers.de

Wer LightDM unter Fedora 19 nutzt, wird sicher schon mit der Meldung

SELinux is preventing /usr/sbin/lightdm from ‘create’ accesses on the file .dmrc.T5D7TW

Bekanntschaft gemacht haben. Wobei der Teil T5D7TW ein zufälliger Wert ist, der sich bei jedem Systemstart ändert.

Um die Meldung los zu werden sollte man zuerst sicherstellen, das man die aktuellste SELinux Policy verwendet:

su -c'yum update selinux-policy\*'

Sofern man die aktuellste Version der SELinux Policy verwendet, muss nur noch folgender Befehl ausgeführt werden:

su -c'setsebool -P xdm_write_home 1'

Danach sollte die SELinux Fehlermeldung zukünftig nicht mehr auftauchen.

Bereits vor einiger Zeit haben wir gezeigt, das man mit VLC Videos von YouTube schauen kann. Aber auch das Extrahieren von Audiospuren aus YouTube Videos ist mit VLC ohne großen Aufwand möglich.

Dazu wählen wir einfach im Menü “Medien” den Punkt “Konvertieren/Speichern …” aus, wechseln anschließend in das Register “Netzwerk” und fügen dort die URL zu dem YouTube Video ein und klicken auf “Konvertieren/Speichern”.

Achtung: Gegebenenfalls muss das Protokoll noch von https auf http geändert werden.

Im sich nun öffnenden Dialog geben wir den gewünschten Dateinamen für die extrahierte Audiospur an und wählen das Profil für das gewünschte Dateiformat aus.

Um den Extraaktionsvorgang zu starten, klicken wir anschließend auf “Start”.

Wie Robyn Bergeron heute auf der Fedora Mailingliste für Ankündigungen bekanntgegeben hat, wurde im Fedora Account System (FAS) eine seit 2008 bestehende Sicherheitslücke entdeckt und umgehend geschlossen, über die es möglich war, private Daten anderer User auszuspähen.

Auch wenn man keine Anzeichen dafür gefunden hat, das diese Lücke ausgenutzt wurde, empfiehlt man allen Nutzern des FAS, ihr Passwort sowie die Sicherheitsfrage und -antwort zu ändern und die übrigen Account-Informationen auf mögliche Änderungen zu überprüfen.

Es gibt schon viele Artikel, wie man SSD-Festplatten richtig in Linux einbindet. Aber entweder sind sie unvollständig oder recht lange. Also, hier eine tl;dr-Fassung – SSD mit Fedora, kurz und schmerzlos.

Wenn die SSD trimming kann (was mittlerweile bei allen SSDs auf dem Markt der Fall sein sollte), sollte es natürlich auch verwendet werden. Dadurch ermöglicht man wear levelling, gibt also der SSD die Möglichkeit, den Verschleiß der Speicherzellen zu verteilen.

In der /etc/fstab wird bei jedem Mountpoint, der auf eine SSD-Partition verweist, die Parameter discard angehängt. Eine gute Idee ist es außerdem, noatime hinzuzufügen, um die Schreibzugriffe auf die Platte zu reduzieren. Das sieht dann zum Beispiel so aus:

UUID=939446e3-9bb9-40a6-bf03-2d87bb8f5837 /                       ext4    discard,noatime        1 1
UUID=4f75261d-2e40-4e39-bf63-2a9c517fc73d /home                   ext4    discard,noatime        1 2
UUID=05db751b-5c2b-47da-8577-89ee30d90e56 swap                    swap    defaults        0 0

Das funktioniert mit reinen ext4-Partitionen, aber auch mit LVM- und RAID-Partitionen, jedoch nicht mit Partitionen, die mit LUKS verschlüsselt sind. Swap-Partitionen trimmen immer, ein discard-Parameter ist nicht erforderlich.

Nach einem Neustart sollte man einmalig alle SSD-Partitionen von Hand trimmen:

sudo fstrim -v /
sudo fstrim -v /home

Was bei mechanischen Festplatten wirklich Zeit kostet, ist das Positionieren des Schreib-Lesekopfes, weshalb Linux versucht, die Daten möglichst zu sammeln und zu gruppieren. Bei SSDs spielt es dagegen keine Rolle, wie fragmentiert die Daten sind. Aus dem Grund kann man das Gruppieren wegfallen lassen und sich über die gewonnene Performance freuen.

Dazu wird eine Datei /etc/udev/rules.d/40-ssd.rules mit folgendem Inhalt angelegt:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

Beim nächsten Neustart verwenden SSD-Platten den noop-Scheduler, mechanische Festplatten weiterhin den für sie optimalen cfq.

SSDs können beliebig oft und schnell gelesen werden, verschleißen aber bei Schreibzugriffen. Swapping auf eine SSD-Partition ist zwar möglich, aber der Lebensdauer nicht sehr zuträglich. Folgende Zeilen in der /etc/sysctl.conf reduzieren das Auslagern auf die Swap-Partition auf ein Minimum.

vm.swappiness=1
vm.vfs_cache_pressure=50

Bei den heutigen Preisen selbst für üppige RAM-Ausstattung wäre es zumindest bei Desktop-Rechnern eine Überlegung wert, ob eine Swap-Partition überhaupt notwendig ist. Nachträglich kann eine Swap-Partition durch Auskommentieren der entsprechenden Zeile in der /etc/fstab deaktiviert werden.

Firefox lagert seinen Cache in das Home-Verzeichnis aus, was eine zusätzliche Belastung für die SSD darstellt. Wer einen Rechner sein Eigen nennt, der mit üppig viel RAM gesegnet ist, kann auf das /tmp-Verzeichnis ausweichen, welches bei Fedora 18 im Arbeitsspeicher statt auf der Festplatte liegt. Das geht leider nur über einen Eingriff in die Eingeweide des Browsers über die URL about:config.

Nach einer Bestätigung, dass man sich benehmen wird, wird mit der rechten Maustaste über Neu - String ein neuer String-Eintrag angelegt. Der Eigenschaftsname lautet browser.cache.disk.parent_directory, der String-Wert /tmp.

Danach muss der Firefox noch neu gestartet werden.

Da fehlt doch was!

Ist es ein Bug, oder ist es ein Feature des für Gnome-Entwickler typischen Aufräumwahns? Ich weiß es nicht. Aber ich war erstaunt, als ich in Gnome 3.6 die Mausbeschleunigung verstellen wollte und mich dort ein fast leerer Dialog angähnte.

Die Mausparameter können über das mittlerweile zum wohl wichtigsten (und wenig komfortablen) Gnome-Konfigurationstool dconf-editor eingestellt werden. Falls noch nicht geschehen, wird es über

sudo yum install dconf-editor

installiert. Nach dem Start klicken wir uns durch den Pfad org - gnome - settings-daemon - peripherals - mouse durch. Dort kann die Mausbeschleunigung über die Paramerer motion-acceleration (Standardwert “-1.0”) und motion-treshold (Standardwert -1) eingestellt werden.

Um die Mausbeschleunigung ganz auszuschalten, wird motion-acceleration auf 0 gestellt.

Die Arbeit an einem Blog kostet ziemlich viel Zeit. Zeit, die ich (wie man sieht) immer weniger erübrigen kann. Leider hat die Website in den letzten knapp vier Jahren nicht die kritische Masse erreicht, um zu einem echten Community-Projekt zu werden.

Jetzt ist abzusehen, dass Red Hat die Unterzeichnung eines Vertrages für die Nutzung der Domain und des Fedora-Markenzeichens anfordern wird. Ich verstehe Red Hats Gründe dafür und erkenne an, dass sie sich nach erheblicher Kritik bereits auf die Community zubewegt haben. Ich habe es mir dennoch überlegt, und ich bin zu dem Schluss gekommen, dass es unter den oben genannten Voraussetzungen für mich keinen Sinn macht, diesen Vertrag mit seinen rechtlichen Anforderungen als zusätzliche Hürde mitzunehmen. Ich habe mich also entschlossen, das fedorablog.de zu schließen.

Einige Fedora-bezogene Artikel, zum Beispiel die Installation von Google Earth, werde ich im Laufe des Oktobers in das Fedora Wiki umziehen. Allgemeinere Artikel, zum Beispiel über HDR-Fotografie, werde ich in mein privates Blog stellen und in Zukunft sicher noch um weitere ergänzen. Repowatch ist bereits auf meine private Domain umgezogen und steht unter http://repowatch.shredzone.net zur Verfügung. Bitte stellt gegebenenfalls euren RSS-Reader auf die neue Adressen um.

So bleibt mir jetzt, mich bei meinen Lesern für ihre Treue zu bedanken. Hoffentlich war der eine oder andere Artikel interessant oder hilfreich. Dank schulde ich auch meinen Mitautoren, die das Blog mit ihren Artikeln bereichert oder mir gute Hinweise gegeben hatten.

Macht’s gut, und danke für den Fisch!

NACHTRAG: Danke für die vielen netten Kommentare und E-Mails! Vor allem eine E-Mail war sehr interessant, und bei Red Hat tut sich etwas bezüglich des Vertrages. Ich weiß zwar noch nicht, wohin das führt, aber vielleicht solltet ihr eure Bookmarks noch nicht gleich entsorgen.