Mit Cockpit lässt sich der aktuelle Status des Systems erfassen: Sich fortwährend aktualisierende Graphen zeigen Auslastung, Speicherbelegung oder die Load an. Wie bei ähnlich gelagerten Projekten wie etwa Webmin bieten sich aber über das reine Monitoring hinaus zahlreiche andere Funktionen. Ihr könnt die Systemlogs einsehen, über Systemd verwaltete Dienste kontrollieren und einrichten oder auch die Benutzeraccounts des Systems verwalten. Wer mehr als nur einen Fedora-Rechner im Einsatz hat, kann diese Installation in ein zentrales Cockpit integrieren und seine Rechner von diese Zentrale aus administrieren.

Cockpit unter Fedora 21 Workstation aktivieren

$ sudo yum install cockpit
$ sudo systemctl enable cockpit.socket
$ sudo systemctl start cockpit
$ sudo firewall-cmd --add-service=cockpit
$ sudo setenforce 0 # being fixed

Dabei kommt Cockpit nicht den über das Terminal gewohnten Funktionen in die Quere. Cockpit dreht nicht sein eigenes Ding, sondern setzt auf die üblichen Kommandos auf, die man auch im Terminal verwenden möchte. Da Cockpit perfekt auf Fedora abgestimmt ist, kommt es nicht zu Konflikten, wie man sie bei Webmin immer fürchten muss. Cockpit ist nur bei Fedora 21 Server von Haus aus aktiv, wer die Workstation-Version von nutzen möchte, der kann sich Cockpit allerdings auch nachträglich aus den Paketquellen installieren und selber mal einen Blick auf das Webfrontend werfen. Nach der Installation des Dienstes könnt ihr diesen dann über den Localhost unter localhost:9090 aufrufen.

Für mich ist Bluetooth recht wichtig, da ich ansonsten mit meiner Magic Mouse nicht arbeiten kann. Mein Belkin Bluetooth-Stick wird zwar von Fedora 15 als USB-Gerät gefunden, doch hcitool meldet, dass kein BT-Empfänger verfügbar sei…

Mit den Kommandos lsusb und hcitool kommt man den Problem ganz gut auf die Schliche. Wenn lsusb meldet, dass ein BT-Adapter gefunden wurde und hcitool kein Gerät ausgibt, dann wird man wohl auch von dieser Problematik betroffen sein…

$ lsusb | grep Blue
Bus 007 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)
Bus 007 Device 005: ID 050d:0017 Belkin Components B8T017 Bluetooth+EDR 2.1
$ hcitool dev
Devices:

Die Lösung besteht im Aktivieren des Bluetooth-Dienstes. Über die zwei folgendes Komandos aktiviert man den Dienst und startet ihn anschließend von Hand. Danach sollte der BT-Dienst in Zukunft beim Booten automatisch geladen werden.

$ sudo systemctl enable bluetooth.service
$ sudo systemctl start bluetooth.service

Danach könnt Ihr eure BT-Geräte wieder mit eurem Fedora-System verknüpfen. Laut den oben genannten Bugs betrifft dieses Problem nur Anwender, die von einer älteren Version aktualisiert haben, doch mein System hier ist frisch mit der finalen Version von Fedora 15 installiert worden.

Ansonsten macht Fedora 15 optisch einen klasse Eindruck. GNOME 3 und das Artwork von Fedora machen viel her, allerdings muss man sich als Anwender noch viel viel mehr an die neue GNOME-Shell gewöhnen, als an Ubuntus Unity. Technisch gibts für mein System leider neben dem Bluetooth-Bug auch noch einen anderen Showstopper.

So ließ sich die Live-CD problemlos auf meinem System starten und installieren, doch beim Booten des installierten Systems bekomme ich nur Meldungen ich nur eine schwarzes Bild mit Meldungen im Stile von „CPU#0 stuck, CPU#1 stuck, usw“ auf den Schirm. Mit ein bisschen Ausprobieren bekomme ich meinen Rechner mit der Kernel-Option „noapic“ zum Laufen. Doch es ist schon komisch, wenn die Live-CD ohne Probleme bootet, das installierte System aber beim Booten hängen bleibt.

Außerdem wollten sich bei mir die Kernelmodule nicht bauen lassen, so lange das System nicht auf einem aktuellen Stand ist, daher führt man am besten vorher noch ein Update aus…

$ sudo yum update -y
$ sudo yum install kernel-headers kernel-devel gcc gcc-c++ dkms

…danach kann man sich wie gewohnt an die Installation der Gasterweiterungen machen. Über das Menü lässt man das CD-Abbild mit den Erweiterungen als CD in der virtuellen Maschine laden, bindet dann die CD ein und lässt dann die Kernelmodule bauen. Für alte Hasen im Umgang mit VirtualBox ist das nichts neues…

…das Vorgehen unterscheidet sich dabei auch nicht von anderen Linux-Distributionen. Wechselt in das Verzeichnis mit der gemounteten CD und führt das Installationsprogramm mit Root-Rechten aus. Da Fedora wie Debian oder Ubuntu auch sudo benutzt, muss man nicht lange mit su hantieren.

$ cd /media/VBOXAD...   # Bitte einfach via Tab-Tab ergänzen lassen
$ sudo ./VBoxLinuxAdditions.run

Achtet bitte danach auf die Ausgaben, nur wenn überall ein grünes [OK] und kein rotes [Fail] zu finden ist, war die Installation der Gasterweiterungen auch wirklich erfolgreich. Bei einem Fail konnten die Kernelmodule nicht erzeugt werden und somit ist es auch unwahrscheinlich, dass später GNOME 3 laufen kann.

Hat das Erzeugen der Kernelmodule geklappt, steht eurem virtualisierten Fedora 15 mit GNOME 3 eigentlich nichts mehr im Wege. Achtet jedoch bitte drauf, dass GNOME nur mindestens VirtualBox 4.08 erfordert! Ältere Versionen können die GNOME-Shell noch nicht starten. Ihr müsst nun nicht einmal das System neu starten, loggt euch einfach aus und wieder ein, dabei wird automatisch der Xserver neu gestartet und der VirtualBox-Treiber geladen.

Ich bin mir nicht sicher, ob Probleme im Zusammenhang mit der neuen Desktop-Shell von GNOME 3 und VirtualBox auch auf das Host-System zurückzuführen sind. Im Beitrag zu GNOME3 unter Ubuntu mit VirtualBox 4.08 haben Leser berichtet, dass GNOME 3 unter Ubuntu trotz der aktuellen VirtualBox-Version und aktuellen Gasterweiterungen nicht laufen möchte, auf einem System mit Intel-Grafikkarte macht jedoch weder Unity noch GNOME 3 zicken…

Ansonsten setzt Fedora weiter auf die übliche Kost. Mit LibreOffice und Firefox 4 werden die wichtigsten Desktop-Anwendungen auf einen aktuellen Stand gebracht. Wichtiger sind jedoch ein paar Änderungen unter der Haube. Fedora setzt nun auf systemd (Wikipedia) zum Booten und Starten von Diensten und Betreiber von Servern können dank der Dynamic Firewall iptables setzen, ohne dass die Firewall komplett neu gestartet werden. So bleiben bestehende Verbindungen auch bei Änderungen an der FW aktiv.

Für den Betrieb von GNOME3 wird eine Grafikkarte/ein Treiber mit 3d-Beschleunigung benötigt. Besitzer von Rechnern mit Intel- eigentlich auch ATI-/AMD-Grafikkarten müssen dazu nichts nachinstallieren, da im Kernel schon geeignete Treiber enthalten sein sollten. Besitzer von Nvidia-Systemen müssen oft erst den proprietären Nvidia-Treiber nachinstallieren. Sollte die Grafikkarte nicht mitspielen, wird anstatt der neuen GNOME-Shell ein „Classic Desktop“ mit gewohnter Panel-Anordnung geladen.

CD-Images stehen für 32- und 64-Bit Systeme zum Download bereit. Neben den „Spins“ mit GNOME gibt es auch CDs, die KDE, LXDE oder Xfce als Desktopumgebung beinhalten. Wer eher alles auf einem Medium herunterladen möchte, der bekommt auch DVDs, die sämtliche Desktopumgebungen enhalten. Weitere Informationen findet Ihr bei Was ist neu bei Fedora 15 sowie in den ausführliche Release-Notes.

Das Paket yum-utils ist bei Fedora 13 von Haus aus installiert, von daher kann man auf jedem aktuellen Fedora-System einfach etwas in dieser Art…

$ package-cleanup --oldkernels --count=2

…aufrufen. Dabei werden alle Kernel bis auf die letzten zwei deinstalliert. Einfacher gehts eigentlich nicht mehr.

Noch besser wäre es in meinen Augen, wenn der Update-Manager auf die Vielzahl von installierten Kernels hinweisen und auf Wunsch die letzten Kernel – bis auf die X neusten – deinstallieren würde, doch das zum Implementieren bedeutet natürlich einen höheren Aufwand als das eigentlich doch recht simple Kommando. Ich hatte daher auf brainstorm.ubuntu.com eine Idee eingebracht…[Offline]…doch mir kam jemand zuvor, somit muss ich mich mit „Solution #4“ zufrieden geben [Offline] Wäre schön, wenn sich hier früher oder später eine simple Lösung ergeben würde, denn gerade unerfahrene Anwender misten selten die Kernel aus. Ich habe schon Rechner mit mehr als zehn Kernel gesehen (Ubuntu Brainstorm wurde eingestellt und die Webseiten abgeschaltet).

Signierte Pakete aus signierten Paketquellen lassen sich in den Standardeinstellungen von PolicyKit ohne Root-Rechte installieren. Dieses Verhalten stößt nun einigen Anwendern übel auf und sorgt für viel Wind im oben verlinkten Bug-Report. Wer die übliche Einstellung wieder haben will, der sollte von Hand die Datei /var/lib/polkit-1/localauthority/20-org.d anlegen und folgendes…

[NoUsersInstallAnythingWithoutPassword]
Identity=unix-user:someone;unix-user:someone_else
Action=org.freedesktop.packagekit.*
ResultAny=auth_admin
ResultInactive=auth_admin
ResultActive=auth_admin

…als Inhalt einfügen. Weiter Informationen zu dieser Änderung finden sich mittlerweile auch in den Release Notes. [UPDATE 20.11.2009: Laut Berichten in diversen Medien wurde dieses Verhalten nun mit einem Update wieder auf den alten Stand gebracht. Somit braucht man auf jeden Fall wieder Root-Rechte, um Software installieren zu können.]