Letzte Woche ist die neue Ausgabe des englischsprachigen Magazins Full Circle Magazine erschienen. Themen der 70. Ausgabe sind unter anderem
In den letzten Tagen hatte ich etwas Gelegenheit, mich mit UEFI Secure Boot näher zu beschäftigen: Ich erstelle bekanntlich die Notfall-CDs für einige Computerzeitschriften oder arbeite intensiv daran mit (von Computer Bild bis desinfec’t gibt es einige). Ziel war, alle aktuellen, von Microsoft signierten EFI-Loader unter die Lupe zu nehmen und auf ihre Praktikabilität abzuklopfen. Die gute Nachricht vorweg: Wer Ubuntu oder Fedora verwendet und keine Kernel selbst kompiliert, muss sich nicht mit dem Schlüsselmanagement herumärgern. Beide Distributionen verwenden einen von Microsoft signierten Loader (auf Basis von Shim), der wenigstens sicherstellt, dass GRUB2 und der anschließend geladene Kernel “vertrauenswürdig” ist. Zu Funktionsweise, Unterschieden und Restriktionen der verwendeten gepatchten GRUB2-Varianten hat sich Thorsten Leemhuis in der c’t 5/2013 zur Genüge ausgelassen. Wirklich spannend ist die Thematik aber für den Start selbst kompilierter Kernel, für kleine Distributionen, die verteilt und schnell entwickelt werden und für Administratoren, die Linux basierte Deployment- und Notfall-Systeme per Netz oder vom Wechseldatenträger starten wollen.
In diesem Beitrag möchte ich die eher theoretischen Hintergründe erläutern und Entscheidungshilfen geben, demnächst folgen dann Beiträge zur praktischen Umsetzung von Secure Boot eigener Kernel auf USB-Sticks, optischen Datenträgern und via Netzwerk.
Ein großer – nicht von der Hand zu weisender – Kritikpunkt war Microsofts Rolle als Gatekeeper für den gesamten Bootprozess. Zwar war von vorneherein klar, dass UEFI mit Secure Boot (zunächst) abschaltbar und prinzipiell (immer) offen für alle Betriebssystemhersteller sein sollte. Wie dies in der Praxis aussehen sollte, war aber bis Herbst 2012 unklar. Eine totale Kontrolle der Hardware durch Microsoft wäre schon an kartellrechtlichen Bedenken gescheitert, so dass früh klar war, dass die Kontrolle der Schlüssel letztlich beim Eigentümer der Hardware verbleiben sollte. Das hätte in der Praxis aber auch ein striktes “entweder oder” bedeuten können: Ohne Microsofts Kooperation hätten Linux-Distributoren selbst Plattform-Schlüssel bereitstellen müssen. Der Anwender hätte seinen Rechner zur Installation in den “Setup Mode” versetzt und dann recht umständlich die Plattformschlüssel ausgetauscht. Der PC wäre mit allen Vorteilen des UEFI Secure Boot unter Linux gelaufen. Nur ein Dual Boot wäre unmöglich geworden – ein Szenario, mit dem Firmen, die Linux auf Thinclients oder Servern betreiben, durchaus leben können, das jedoch für den ambitionierten Anwender zuhause enorme Restriktionen bedeutet hätte. Der Einsatz von Live-CDs hätte hier immer vorausgesetzt, Secure Boot temporär zu deaktivieren – was keinesfalls standardisiert ist und möglicherweise irgendwann wegfällt.
Kritik erntet auch Microsofts Ansatz, Schlüssel und Hashwerte von Bootdateien auf eine schwarze Liste setzen zu können. Doch um diese schwarze Liste aktualisieren zu können, muss Windows laufen und Verbindungen ins Internet aufbauen können. Mittelfristig ist auch denkbar, dass Linux-Distributoren nach Absprache mit Microsoft Listen mit zurückgezogenen Schlüsseln und Hashes verteilen. Ich sehe hier durchaus Vorteile, beispielsweise wenn eine bestimmte Kernel- oder Bootloaderversion anfällig fürs Einschleußen von Rootkits ist. Unterm Strich bleibt aber die Freiheit, sowohl um Microsoft als auch um die großen Distributoren einen Bogen machen zu können und dennoch mit Microsofts Schlüsseln im NVRAM ein komfortables und (relativ sicheres) System nutzen zu können.
Derzeit existieren zwei Ansätze, einen komfortablen Linux-Start mit Secure Boot gewährleisten zu können: Bei beiden handelt es sich um kleine, vorgeschaltete Bootloader, die erst in der zweiten Stufe den eigentlichen Bootloader starten, der dann wiederum Kernel und Initramfs lädt, sowie Parameter übergibt. Aus Gründen der Konsistenz verwende ich derzeit einen selbst gebauten GRUB2 als zweite Stufe, der selbst keinerlei Prüfung durchführt, demnach theoretisch auch einen modifizierten Windows-Kernel mit darunter geschobenem Hypervisor-Rootkit starten kann. Das macht die Anwesenheit eines solchen GRUB und die Hinterlegung seines Hashes zu einem gewissen Sicherheitsrisiko.
Die Linux-Foundation bietet mit PreLoader.efi und HashTool.efi einen Bootloader und ein kleines Werkzeug zum Verwalten von Hashes. Die Kombination ist recht nutzerfreundlich umgesetzt: Der Anwender bootet Stick oder CD und startet damit den von Microsoft signierten PreLoader.efi. Findet der keinen Eintrag in der Liste erlaubter Hashes, startet er das ebenfalls signierte HashTool.efi. Mit diesem wählt der Anwender ein Binary, dessen Hash zur Liste erlaubter hinzugefügt werden soll – die beispielsweise die nach loader.efi umbenannte GRUB-Version, die beliebige Kernel booten kann. Nach einem Neustart startet PreLoader.efi den nun auf der weissen Liste stehenden Bootloader ohne weitere Nachfrage. PreLoader.efi ist recht simpel umgesetzt und wie bereits erklärt ziemlich nutzerfreundlich: Programmierer müssen Bootloader der zweiten Stufe nicht mit Zertifikaten versehen, stattdessen erklärt der Anwender beim Start, dass er einem bestimmten Binary vertraut. Ein großer Nachteil dieser Lösung ist, dass bei Änderungen am Bootloader der zweiten Stufe eine lokale Bestätigung des Hashes notwendig ist. Für Administratoren in großen Unternehmen mit weit verzweigten Standorten kann dies äußerst unpraktisch sein…
Shim ist ein etwas aufwendigerer Loader, der derzeit sowohl von Fedora als auch von Ubuntu genutzt wird und in seiner freien Variante auf MOKs – Machine Owner Keys – aufsetzt. Shim 0.2 wird mit einem ebenfalls von Microsoft signierten Binary MokManager.efi ausgeliefert, der es es erlaubt, eigene Signaturschlüssel für vertrauenswürdige Binaries ins NVRAM zu laden. Mit diesen signierte Bootloader führt Shim aus. Im Falle eines Bootloader-Updates muss lediglich der neue Bootloader mit dem gleichen Schlüssel wie der alte signiert werden. Der Vorteil dieses Ansatzes liegt ganz klar in der leichteren Remote-Administration und vereinfachten Updates.
Ein denkbares Szenario für die Vorteile des Shim-Einsatzes ist ein per PXE gebootetes Linux, das als Deployment- und Notfall-System dient: Um aus dem PXE-Boot kein Einfallstor für Schad- und Spionagesoftware zu machen, ist es möglich, die gesamte Boot-Kette vom Bootloader der zweiten Stufe, der nur signierte Kernel und Initrds lädt, über eine prüfende Initrd, die wiederum die Signatur des Root-Images checkt, zu booten. Ein derartiges System könnte für jeden Kunden mit einem eigenen “Machine Owner Key” signiert werden. Der Administrator muss vor dem Deployment eines PCs lediglich den MOK ins NVRAM aufnehmen. So ist auch ein sicherer Start von Thin-Client-Systemen möglich – vor Secure Boot konnte beim PXE-Boot niemand sicherstellen, dass kein korrupter Bootserver Systeme mit integriertem Keylogger ausliefert.
Ein Kritikpunkt an Shim war die hier implementierte Duplikation von Funktionalität: Shim implementiert ein eigenes Schlüsselmanagement und eigene Prüfungen. Dennoch bietet das Prinzip der Machine Owner Keys wie oben dargelegt viele Vorteile, insbesondere erlaubt es die Nutzung einer kompletten Secure Boot Kette, ohne dass eigene Binaries von Microsoft signiert werden müssen, stattdessen reicht es, auf jeder Machine einmal einen öffentlichen Schlüssel als vertraulich zu importieren. Matthew Garret, der Shim entwickelt, möchte den Code der Linux Foundation deshalb in Shim übernehmen um so die Vorteile beider Loader kombinieren zu können.
Mich stört, dass UEFI keinen Mechanismus bereitstellt, einen gewhitelisteten Hashwert oder Schlüssel verfallen zu lassen. Beim Einsatz von Live-Systemen zur Rettung wäre es von großem Vorteil, maximal fünf Mal oder maximal 24 Stunden mit einem Hash booten zu können, bevor dieser automatisch verfällt. So muss der Anwender selbst darauf achten, nicht mehr benötigte Hashes selbst zu löschen, damit ein allzu liberal agierender Bootloader (der alles lädt) nicht als Einfallstor für Schadsoftware mißbraucht werden kann.
Als normaler Anwender sollte man keine Angst vor Secure Boot haben und UEFI Secure Boot nach Möglichkeit aktiviert lassen. Beim Testen eigener Kernel oder dem Remastern von Live-Medien wird vielen Anwendern aber nichts anderes übrig bleiben als zu experimentieren: Zu klein ist die Erfahrung in der Community mit UEFI Secure Boot noch und zu klein ist das Angebot an Hardware (und UEFI-Implementierungen), um alle potentiellen Bugs zu kennen. Zudem ist Abwärtskompatibilität nun ein Thema: Gerade Live-Medien wie USB-Sticks oder CDs sollen möglichst auf UEFI- und BIOS-Systemen gleichermaßen bootfähig sein. Das ist möglich, erfordert aber gelegentlich Verrenkungen und zumeist doppelte Konfigurationsdateien: Je eine für den UEFI-Bootloader und den BIOS-Bootloader.
Nicht nur Mozilla arbeitet mit Firefox OS an einem neuen Betriebssystem für Smartphones, sondern auch Canonical. Für Ende des Jahres werden die ersten Geräte mit Ubuntu Phone OS erwartet. Auf diesen wird Firefox als Browser bereits vorinstalliert sein.
Die Ankündigung zu Ubuntu Phone OS ist nicht mehr ganz aktuell, doch interessiert hier natürlich die Frage, mit welchem Browser Ubuntu Phone OS ausgeliefert werden wird. Auf diese Frage liefert das Ubuntu Press Pack eine Antwort. In aller Kürze: Dieses beantwortet die Frage damit, dass sowohl Chromium als auch Mozilla Firefox als Teil von Ubuntu Phone OS ausgeliefert werden.
“Ubuntu will include both the Chromium and Firefox browsers, ensuring a first-class and competitive web browser experience as well as first class web and HTML5 applications.”
XML ist ja wahnsinnig angesagt für alle möglichen Dinge. Ich selbst kann mich damit nicht so recht anfreunden – zumindest ist manuelles editieren immer ein Krampf. Ich habe meist mit Konfigurationsdateien in XML zu tun. So auch mit meinem Telefonprojekt. Die Snom Telefone nutzen für das Provisioning eine XML Datei, welche über einen Webserver abgerufen wird. Da ich die Konfiguration sehr dynamisch gemacht habe (Webfrontend etc.) wird auch die XML Konfig für die Telefone dynamisch erstellt. Diese Datei sollte sich unbedingt an den XML Standard halten, da ansonsten die Telefone mit dem ganzen nichts anfangen können (dabei habe ich schon die seltsamsten Fehler erlebt).
Um XML zu validieren gibt es ein recht einfaches Tool unter Linux – xmllint. Einfach als Parameter eine XML Datei angeben und gut. xmllint kommt auch mit http Links zurecht – was mir ebenfalls gerade recht kommt 
Absolut simpel kann man das ganze nun in ein Icinga/Nagios Plugin verwandeln:
#!/bin/bash # validation of a remote XML File # Ronny Becker, 02.2013 RET="`xmllint --noout $1 2>/dev/null; echo $?`" case $RET in "0" ) echo "XML Validation OK" exit 0 ;; "1" ) echo "XML Validation NOT OK" exit 2 ;; * ) echo "unknown return code" exit 3 ;; esac
Das ganze als command einbinden, als ersten Parameter bekommt das Plugin die remote Adresse (http://…) und fertig.
Dieses How to zeigt wie man Google Chrome/Chromium auf Fedora 18/17/16/15/14/13/12, CentOS 6.3/6.2/6.1/6 und Red Hat (RHEL) 6.3/6.2/6.1/6. Der beste weg um es zu installieren und Updates von Google Chrome browser zu erhalten, ist das benutzen von Google’s eigener YUM repository.
Füge folgendes zu der Datei /etc/yum.repos.d/google-chrome.repo file hinzu:
32-Bit:
[google-chrome] name=google-chrome - 32-bit baseurl=http://dl.google.com/linux/chrome/rpm/stable/i386 enabled=1 gpgcheck=1 gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub
64-Bit:
[google-chrome] name=google-chrome - 64-bit baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64 enabled=1 gpgcheck=1 gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub
Ein kleiner Tipp: Die selben 32-bit und 64-bit repos können in einer Datei eingetragen werden ;).
Als root:
yum install google-chrome-stable
Um die Beta und Unstable zu installieren, füge einen der Beiden Begriffe einfach NACH google-chrome- ein.
Viel erfolg! 
Wenn man sowohl einen Computer als auch ein Handy hat, dann will man ja auch Daten von einem Gerät auf das andere kopieren. Notizen, Emails, Kalendereinträge und Kontakte geht ja automatisch. Ich werde jetzt einmal drei Wege beschreiben, wie man auch andere Daten übertragen kann.
Der erste Weg, der einem einfällt, wäre es ja, das Handy einfach mit dem USB-Kabel an dem Computer anzuschließen. Bis Android 4.0 war das auch kein Problem, das Handy wurde einfach als USB-Stick erkannt und konnte so befüllt werden. Ab Android 4.0 ist das nicht mehr so einfach. Aber auf webupd8.org gibt es eine ausführliche Anleitung, wie man es dennoch machen kann.
Hier noch einmal eine Kurzanleitung auf Deutsch:
Einfach die webupd8-unstable Quelle hinzufügen und go-mtpfs installieren.
sudo add-apt-repository ppa:webupd8team/unstable sudo apt-get update sudo apt-get install go-mtpfs go-mtpfs-unity
Nach dem Installieren noch go-mtpfs der Sidebar hinzufügen. Wenn man nun sein Handy anschließen will, einfach Rechtsklick auf das Icon und dann auf dem entsprechenden Quicklist-Eintrag klicken. Nun kann man sein Handy ganz normal mit Dateimanager befüllen. Unmounten kann man es nur über den Icon, nicht in der Sidebar von Nautilus.
Um auf mein Smartphone mal schnell Musik zu kopieren nutze ich Airdroid, ein Programm für Android, welches wir schon einmal in der App der Woche vorgestellt haben.
Die Übertragung dauert zwar etwas länger als über Kabel, was aber bei den vergleichsweise geringen Datenmengen nicht ins Gewicht fällt.
Ein weiterer Weg Dateien auf das Handy zu kopieren ist der Umweg über die Cloud. Einfach sowohl auf dem Smartphone als auch auf dem Computer Clouddienste wie Ubuntu One oder Dropbox installieren und dann die Dateien dort hochladen.
Dieser Weg hat den Vorteil, dass man die Daten auch noch auf anderen Daten Geräten oder im Browser abrufen kann. Allerdings gibt es auch den entscheidenden Nachteil, dass ein Dateitransfer erheblich länger dauert, als mit den anderen zwei Methoden.
Mein Favorit steht mit Airdroid schon fest, obwohl auch die anderen Wege ihre Existensberechtigung haben.
Das ändern des Hostnamens ist bei RHEL System sehr einfach.
Dazu öffnet man einfach eine Konsole und schreibt folgendes Hinein:
sudo /etc/sysconfig/network
Also editieren wir in deinem Favorisierten Editor die Datei etc/sysconfig/network. Normalerweise steht etwas wie hier drin:
NETWORKING=yes NETWORKING_IPV6=no HOSTNAME=localhost.localdomain
Um den Hostnamen zu ändern, ändert man – logischerweise – die Wörter hinter HOSTNAME. Es muss aber im Format einer Domain sein, deswegen geht sowas…HOSTNAME=darksider3.darksider3.
Aber NICHT sowas…HOSTNAME=darksider3.
Die Änderungen werden jeweils nach einem Neustart des Systems wirksam.
Ein kleiner Tipp: Um den Hostnamen sofort zu ändern kann man folgendes benutzen
$ hostname DEINS.DEINEDOMAIN
Um zu überprüfen, ob es funktioniert hat, kann man den Befehl ohne Parameter benutzen…
$ hostname
Ausgabe: DEINS.DEINEDOMAIN
Viel Erfolg!
Compton ist ein auf xcompmgr basierender Compositor, der aktiv weiterentwickelt wird und einige nette Features wie automatische Transparenz für inaktive Fenster mitbringt. Damit ist er derzeit die einzige Wahl, will man einen relativ bugfreien Compositor benutzen (der nicht in einem Fenstermanager integriert ist).
Allerdings liegt es nicht in den Quellen, compton muss selbst kompiliert werden.
Was noch fehlt ist Feinschliff. So haben Ubuntus Notify-OSD-Benachrichtigungen einen hässlichen weißen Schatten/Rahmen, genauso Simdock. Doch kann das mit ein paar Konfigurationseinstellungen gefixt werden:
shadow-exclude = [ "n:e:Notification" , "class_g ?= 'Notify-osd'"];
behebt den Schatten der Benachrigungen (via)
shadow-ignore-shaped = true;
half bei Simdock
Edit: Leider funktioniert das nicht zuverlässig, besser bewährt sich ein
wintypes:
{
dock = { shadow = false; };
};
Hier meine gesamte Konfigurationsdatei ~/.compton.conf (fast identisch zur Beispielkonfiguration):
# Shadow
shadow = true;
no-dnd-shadow = true;
no-dock-shadow = true;
clear-shadow = true;
shadow-radius = 7;
shadow-offset-x = -7;
shadow-offset-y = -7;
# shadow-opacity = 0.7;
# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;
shadow-exclude = [ "n:e:Notification" , "class_g ?= 'Notify-osd'"];
# shadow-exclude = "n:e:Notification";
shadow-ignore-shaped = true;
# Opacity
menu-opacity = 0.9;
inactive-opacity = 0.8;
frame-opacity = 0.7;
inactive-opacity-override = false;
alpha-step = 0.06;
# Fading
fading = true;
# fade-delta = 30;
fade-in-step = 0.03;
fade-out-step = 0.03;
# no-fading-openclose = true;
# Other
mark-wmwin-focused = true;
mark-ovredir-focused = true;
use-ewmh-active-win = false;
detect-rounded-corners = true;
detect-client-opacity = true;
refresh-rate = 0;
vsync = "none";
dbe = false;
paint-on-overlay = false;
sw-opti = false;
# Window type settings
wintypes:
{
tooltip = { fade = true; shadow = false; opacity = 0.75; };
dock = { shadow = false; };
};
Compton ist ein auf xcompmgr basierender Compositor, der aktiv weiterentwickelt wird und einige nette Features wie automatische Transparenz für inaktive Fenster mitbringt. Damit ist er derzeit die einzige Wahl, will man einen relativ bugfreien Compositor benutzen (der nicht in einem Fenstermanager integriert ist).
Allerdings liegt es nicht in den Quellen, compton muss selbst kompiliert werden.
Was noch fehlt ist Feinschliff. So haben Ubuntus Notify-OSD-Benachrichtigungen einen hässlichen weißen Schatten/Rahmen, genauso Simdock. Doch kann das mit ein paar Konfigurationseinstellungen gefixt werden:
shadow-exclude = [ "n:e:Notification" , "class_g ?= 'Notify-osd'"];
behebt den Schatten der Benachrigungen (via)
shadow-ignore-shaped = true;
half bei Simdock
Edit: Leider funktioniert das nicht zuverlässig, besser bewährt sich ein
wintypes:
{
dock = { shadow = false; };
};
Hier meine gesamte Konfigurationsdatei ~/.compton.conf (fast identisch zur Beispielkonfiguration):
# Shadow
shadow = true;
no-dnd-shadow = true;
no-dock-shadow = true;
clear-shadow = true;
shadow-radius = 7;
shadow-offset-x = -7;
shadow-offset-y = -7;
# shadow-opacity = 0.7;
# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;
shadow-exclude = [ "n:e:Notification" , "class_g ?= 'Notify-osd'"];
# shadow-exclude = "n:e:Notification";
shadow-ignore-shaped = true;
# Opacity
menu-opacity = 0.9;
inactive-opacity = 0.8;
frame-opacity = 0.7;
inactive-opacity-override = false;
alpha-step = 0.06;
# Fading
fading = true;
# fade-delta = 30;
fade-in-step = 0.03;
fade-out-step = 0.03;
# no-fading-openclose = true;
# Other
mark-wmwin-focused = true;
mark-ovredir-focused = true;
use-ewmh-active-win = false;
detect-rounded-corners = true;
detect-client-opacity = true;
refresh-rate = 0;
vsync = "none";
dbe = false;
paint-on-overlay = false;
sw-opti = false;
# Window type settings
wintypes:
{
tooltip = { fade = true; shadow = false; opacity = 0.75; };
dock = { shadow = false; };
};
Wer wie ich seinen USB Scanner im Netzwerk verwendet hat hierfür bisher meistens den guten alten xinetd in Kombination mit saned verwendet.
Das ist grundsätzlich auch keine schlechte Lösung, allerdings wurde der xinetd durch systemd in vielen Fällen überflüssig. Je weniger Software desto besser lautet mein Grundsatz, und daher habe ich meinen Scanner auf systemd umgestellt. Das Ganze ist sehr einfach:
systemctl stop xinetd.service
systemctl start saned.socketMehr ist nicht zu machen, der Rest der Konfiguration ändert sich nämlich durch die Umstellung nicht. Wer möchte kann nun noch den xinetd von der Platte entfernen und sich immerhin 0.29 MiB Speicherplatz sparen:
pacman -R xinetdWer wie ich seinen USB Scanner im Netzwerk verwendet hat hierfür bisher meistens den guten alten xinetd in Kombination mit saned verwendet.
Das ist grundsätzlich auch keine schlechte Lösung, allerdings wurde der xinetd durch systemd in vielen Fällen überflüssig. Je weniger Software desto besser lautet mein Grundsatz, und daher habe ich meinen Scanner auf systemd umgestellt. Das Ganze ist sehr einfach:
systemctl stop xinetd.service systemctl start saned.socket
Mehr ist nicht zu machen, der Rest der Konfiguration ändert sich nämlich durch die Umstellung nicht. Wer möchte kann nun noch den xinetd von der Platte entfernen und sich immerhin 0.29 MiB Speicherplatz sparen:
pacman -R xinetd
Der Timeout von Grub 2, also dass nach x Sekunden automatisch der Standardeintrag gestartet wird, funktionierte bei mir nicht zuverlässig. Manchmal startete der Timeout einfach nicht. Und tatsächlich hat Grub 2 einen Mechanismus, diesen Autoboot zu deaktivieren, wenn der letzte Boot nicht erfolgreich war - was mittels eines Boot-Skriptes festgestellt wird, über das ich beim Aufräumen gestolpert bin.
Nun ärgerte mich das schon eine Weile, weil jetzt nicht mehr zuverlässig mein Linux gestartet wurde. Ich weiß nicht, ob das am häufigeren Starten von Windows lag oder ob das Skript nicht zuverlässig funktionierte, aber der fehlende Timeout fiel mir erst seit kurzem auf.
Natürlich kann man den Autostart immer ausführen lassen. In der /boot/grub/grub.cfg steht in Zeile 59 dieser Code:
if [ ${recordfail} = 1 ]; then
set timeout=-1
else
set timeout=10
fiDie Abfrage kann ersetzt werden durch:
set timeout=10
Der richtige Ort, um das persistent zu machen, ist wohl die make_timeout-Funktion in /etc/grub.d/00_header.
PS: Wenn ich mir diese "Konfigurationsdatei" so ansehe, die ein einziges Bashskript-Wirrwarr ist, freue ich mich fast auf UEFI und die dadurch ausgelöste Bewegung bei den Booloadern. Grub 2 ist ein Moloch. Warum sollte ein Bootloader keine normale ini/tom/sonstige-einfach-lesbare Konfiguration haben?
Jubiläum! Die 70. Ausgabe vom Full Circle Magazine, dem „unabhängigen Magazin der Ubuntu-Linux-Community“, ist erschienen.
Themen der aktuellen Ausgabe sind:
Das englischsprachige Full Circle Magazine ist in den folgenden Formaten verfügbar:
The League of Moveable Type ist ein Projekt, dass sich zur Aufgabe gemacht hat eine Sammlung an typographisch wertvollen und freien Schriftarten zu erstellen.
Früher gab keine Möglichkeit die Schriftarten auf seiner Webseite zu beeinflussen. Später wurde der <font>-Tag eingeführt, allerdings konnten damit nur Schriften genutzt werden die beim Betrachter installiert waren, Webdesigner hat dies in ihrer Kreativität massiv eingeschrenkt. Dandurch gab es eine Zeit in der Buchstaben in Bilder verwandelt wurden, damit auch Nutzer ohne entsprechende Schriftart das Selbe (wie der Web-Designer) sahen. Wurden Informationen in Bildern gespeichert waren diese für Suchmaschinen verloren, also wurde die Information in die Alt-Tags geschrieben. Und die Suchmaschinen passten sich daran an. Der normale Benutzer hatte dadurch jedoch Nachteile. Etwa konnten Überschriften nicht selektiert und kopiert werden. Doch mit Technologien wie @font-face und später Webfonts wurden Web-Designern Mittel in die Hand gegeben, um sich “typographisch” auszuleben. Jedoch sind viele Fonts nicht frei. Und können nur sehr eingeschränkt benutzt, geschweige denn verändert werden. Zudem war die Auswahl an schönen und freien Schriftarten nicht gerade groß. Das Projekt The League of Moveable Type nahm sich das zum Anlass Schriften zu erstellen, die den Ansprüchen des modernen und freien Webs und Web-Designern erfüllen.
Schriftart: League Gothic (Bild: CC-BY-SA 3.0 – The League of Moveable Type)
Das Projekt wächst ständig, wenn auch gemächlich. Alle Schriftarten werden unter der OFL veröffentlicht. Und im Blog wird immer über Updates und Geschichten rund um die Fonts des Pojekts berichtet. Es lohnt also immer auf dem aktuellesten Stand zu bleiben. Die Quelldateien des Projekts sind auf GitHub zu finden.
Für heute hatte ich einen schönen Vorsatz: Finde einen Ersatz für Simdock, damit du das Projekt aufgeben kannst. Ich bin gescheitert.
Meine Anforderungen an ein Dock sind ziemlich simpel:
Nun ist es natürlich nicht so, dass es kein anderes Programm gäbe, das dem im Grunde gerecht wird. Aber alle scheitern an der Transparenz - bzw am Zusammenspiel mit compton.
Als mögliche Alternative zu Simdock kenne ich diese Programme:
Insbesondere Plank ist ein guter Kandidat, Simdock zu ersetzen: Ähnlich schlicht, aktiver entwickelt und mit allen notwendigen und zusätzlich einer Autohide-Funktion. Der einzige Nachteil wäre, dass es keine Pseudotransparenz zu unterstützen scheint. Und ich mag Simdocks Feature, das Programmicon im Dock mit dem Fenstericon zu updaten, was Plank ebenfalls nicht zu können scheint, aber das wäre kein Ausschlusskriterium.
Doch trotzdem funktionieren weder Plank noch die anderen Docks für mich. Wbar ist generell kaputt, die Icons schlieren und es scheint keine Menüs zu haben. Die anderen drei kommen mit compton/xcompmgr nicht zurecht. Hier die Bilder:
Sie alle scheitern daran, bei aktiviertem Compositor Transparenz so zu aktivieren, dass der leere Bereich echt transparent ist, bzw bei AWN an der Transparenz des Iconhintergrunds. Dies ist das gleiche Problem, welches ich damals schon hatte und mich überhaupt zum Schrauben am verlassenen Simdock bewegt hat. Damals war es allerdings eine andere Ubuntuversion und andere Hardware, ich habe nicht damit gerechnet, dass das Problem noch existiert.
Ein Dock muss eigentlich keine echte Transparenz per Compositor unterstützen, da es sowieso nie Fenster hinter sich hat. Die Ausnahme dieser Regel ist die Autohide-Funktion: Wenn das Dock von Vollbild-Fenstern verdrängt wird und vom Bildschirmrand aus über das Vollbild-Fenster fährt, wenn es aktiviert wird. Plank verhält sich so und das ist eigentlich ein schönes Feature.
Ein Dock mit Autohide-Funktion kann also eine Compositor-Funktion gut gebrauchen, ein Dock ohne (wie Simdock) kann probemlos darauf verzichten.
Warum aber ist der schwarze Balken so viel größer als die Docks selbst, was ist der leere Bereich? Ich bin darauf gestoßen, als ich an Simdock gearbeitet habe. Grundsätzlich will ein Dock gerne in Bereiche zeichnen, die erstmal nicht direkt zum Dock gehörig sind. Beispielsweise den Programmnamen in einem Tooltip über den Icons anzeigen oder die Icons nach oben hüpfen lassen, aber ohne den Bereich für sich zu beanspruchen. Ohne in den Code geschaut zu haben gehe ich davon aus, dass Plank und Cairo-Dock sich einen entsprechend großen Bereich als Canvas sichern.
Das wollte ich für Simdock übrigens auch machen, zusätzlich zum bestehenden Fenster mit einer hübschen dafür gedachten Funktion, das hat aber ein wxWidget-Bug verhindert (es hatte schlicht keinen Effekt).
Es scheint nun so, als ob im Zusammenspiel mit AMD-Grafikkartentreibern und xcompmgr/compton die in diesen Docks verwendete Transparenz nicht funktioniert und der von ihnen registrierte Canvasbereich davon ebenfalls betroffen ist.
Das soll nicht heißen, dass Simdocks den anderen Docks grundsätzlich überlegen ist - ich bin im Gegenteil überzeugt davon, dass Plank in vielen Fällen eine bessere Wahl ist. Der Vorteil in diesem Fall rührt einfach aus der Beschränkung Simdocks auf Pseudotransparenz - der von Simdock verdeckte Bildschirmhintergrund wird per XServer-Funktion als Bild geholt und hinten eingefügt, was unabhängig vom Compositor zuverlässig zu funktionieren scheint.
Auf Simdocks Seite steht:
Das sind rein zufällig die grundlegenden Features, die ich gerne in einem Dock hätte.
Gegen Simdock spricht natürlich auch einiges. Zum einen wird es nicht aktiv weiterentwickelt. Ich habe anfangs eingebaut, was ich haben wollte, und danach noch einzelne Bugs gefixt, aber bisher war es das. Zum anderen wird es wenn, dann von mir entwickelt. Das ist von Nachteil, weil ich normalerweise nicht an C++-Programmen arbeite - so gibt es immer noch einen Bug, der manchmal zu Abstürzen führt, der kein mir ersichtliches Schema hat und daher nicht von mir nachstellbar und fixbar ist. Und ich bin durch die nötige Speicherverwaltung schlicht daran gescheitert, Einstellungen on-the-fly übernehmen zu lassen (jemand Lust, mir einen entsprechenden Pull-Request zukommen zu lassen?). Außerdem ist die ganze Library- und Build-Umgebung unter C++ ein für mich schwer durchschaubares Wirrwarr und müsste sicher aufgeräumt werden.
Trotzdem: Für die eigene Desktopumgebung scheint Simdock derzeit meine einzige Wahl zu sein, will ich einen Compositor mit meiner AMD-Grafikkarte nutzen. Oder kennt jemand noch eine von mir übersehene Alternative?
Es ist ganz interessant zu beobachten, wohin die Reise bei Ubuntu Touch für Smartphones und Tablets gehen wird. Daher habe ich nebenbei immer mal ein Auge darauf, wie sich die 13 Haupt-Apps, die zu Beginn mit Ubuntu Phone ausgeliefert werden, so entwickeln. Zu den sogenannten Core-Apps zählt z.B. auch die Taschenrechner-App, von der es inzwischen auch eine erste Demo gibt.
Zwar alles noch nicht wirklich spektakulär, dennoch erkennt man in dem folgenden Video bereits das typische Design für diese Apps. Mit verschiedenen Gesten kann man zwischen den normalen Funktionen und den wissenschaftlichen Funktionen einfach hin- und herwechseln, oder sich die letzten Ergebnisse anzeigen lassen. Gefällt mir bisher ganz gut, auch wenn solche technische Namen, wie NaN noch zu technischer Natur sind. Ist allerdings auch nicht mehr als eine erste Demo, aber trifft schon recht gut die vorgegebenen Design-Vorgaben. [via]
Zum Abschluss noch das Video:
http://www.youtube.com/watch?v=1Yb0blrXyN8&feature=player_embedded
In meinem Artikel von neulich habe ich beschrieben wie man dem NetworkManager dazu zwingt das dieser für IPv6 auch die Privacy Extensions verwendet. Dazu habe ich, als Workaround, ein Dispatcher Script vorgeschlagen.
Diese Lösung hat sich in den letzten 2-3 Tagen als nicht sonderlich zuverlässig erwiesen, ich vermute es gibt eine Race Condition zwischen meinem Script und dem was NetworkManager selbst nutzt um diese Extension zu verwalten. Aus diesem Grund habe ich mir den Quellcode von NetworkManager mal angesehen und geschaut wie diese Einstellung verwaltet wird. Das ganze ist je nach Distribution unterschiedlich, wird also beim bauen des Paketes festgelegt.
Für Arch Linux, und wohl auch viele andere Distributionen, funktioniert es zuverlässig wenn in der /etc/sysctl.conf oder /lib/sysctl.d/sysctl.conf folgender Eintrag zu finden ist:
# IPv6 Privacy Extension
net.ipv6.conf.default.use_tempaddr = 2Dieser Wert wird von NetworkManager ausgelesen, und dann automatisch auch gesetzt. Ist genau diese Variable nicht vorhanden stellt NetworkManager diese Extension automatisch ab. Nicht besonders schön gelöst finde ich, aber da muss ich wohl mit Leben können.
In meinem Artikel von neulich habe ich beschrieben wie man dem NetworkManager dazu zwingt das dieser für IPv6 auch die Privacy Extensions verwendet. Dazu habe ich, als Workaround, ein Dispatcher Script vorgeschlagen.
Diese Lösung hat sich in den letzten 2-3 Tagen als nicht sonderlich zuverlässig erwiesen, ich vermute es gibt eine Race Condition zwischen meinem Script und dem was NetworkManager selbst nutzt um diese Extension zu verwalten. Aus diesem Grund habe ich mir den Quellcode von NetworkManager mal angesehen und geschaut wie diese Einstellung verwaltet wird. Das ganze ist je nach Distribution unterschiedlich, wird also beim bauen des Paketes festgelegt.
Für Arch Linux, und wohl auch viele andere Distributionen, funktioniert es zuverlässig wenn in der /etc/sysctl.conf oder /lib/sysctl.d/sysctl.conf folgender Eintrag zu finden ist:
# IPv6 Privacy Extension net.ipv6.conf.default.use_tempaddr = 2
Dieser Wert wird von NetworkManager ausgelesen, und dann automatisch auch gesetzt. Ist genau diese Variable nicht vorhanden stellt NetworkManager diese Extension automatisch ab. Nicht besonders schön gelöst finde ich, aber da muss ich wohl mit Leben können.
Der zweite Mojam ist beendet. Ergebnis sind acht Spiele, knapp 72.000 Verkäufe und Einnahmen von etwas über $455,000. Damit hat man also ungefähr wieder das Ergebnis von letztem Jahr erreicht (was den Umsatz angeht – Spender waren es 2012 rund 9.000 mehr) und Notch darf seinen Bart noch etwas behalten…
Was die Verkäufe angeht, wird sich aber womöglich noch etwas tun. Denn diesmal wird man die Kaufoption noch bis 2. März (15:00 PST) bestehen lassen. Und scheinbar gab es auch nach Mitternacht noch ein paar Käufer – denn da waren es noch 68.000 Verkäufe und $439,000 Umsatz.
Unzählige Leute werden sich jetzt erst einmal wieder eine andere Beschäftigung suchen müssen. Kein Entwickler- und Designer-Livestream mehr, den man gebannt verfolgen kann. Das Wort “annual” auf dem Logo lässt ja aber darauf hoffen, dass die Aktion nächstes Jahr wieder stattfinden wird. Interessant wird dann auch sein, ob sich ggfs. Nachahmer finden, die zeitgleich einen Jam veranstalten. In den letzten Tagen gab es Tweets, die so etwas zumindest angekündigt haben.
Jens Bergsten alias Jeb hat mit seinem Cyborg Hippo Team ein Spiel gebaut, in dem man die Aufgabe hat, mit seinem Spieler eine riesige Pizza gegen Aliens zu verteidigen. Von Level zu Level werden die Angriffe natürlich gefährlicher.
Das Spiel ist m.E. das, das am detailreichsten umgesetzt wurde. Außerdem ist es wahrscheinlich für die meisten das interessanteste, weil es derzeit das einzige ist, für das der Quellcode heruntergeladen werden kann. Wie beim letztjährigen Catacomb Snatch wird es sicher nicht lange dauern bis sich die Community um die Weiterentwicklung kümmern wird.
Allerdings habe ich auch noch die Hoffnung, dass zumindest von den beiden anderen Mojang-Spielen ebenfalls der Quellcode herausgegeben wird. Alle drei Mojang-Teams haben diesmal auf Slick gesetzt.
Das Spiel kommt als Jar und muss mit java -jar Cyborg_linux.jar gestartet werden.
Bei Endless Nuclear Kittens geht es darum so schnell wie möglich alle Kätzchen, die da im Weltraum auftauchen zu eliminieren.
Sind sie auch noch so süß, irgendwann drehen sie durch und dann fallen sie dich an! Außerdem werden es immer mehr und bei einer bestimmten Anzahl in das Spiel verloren.
Ein schnelles Spiel, das ganz lustig ist. Von einigen Fans inoffiziell zum Favoriten gekürt.
Das Spiel kommt mit einem .sh-Launcher für Linux. Launcher für Windows und Mac sind außerdem auch enthalten.
Das dritte Spiel von Mojang (Team Striped Zebras) lässt den Spieler “ein französiches Mädchen auf einem französischen Kolonial-Raumschiff” steuern. Das Raumschiff ist von riesigen Fröschen befallen.
Optisch finde ich das Spiel recht ansprechend gemacht. Wobei die Animationen noch nicht ganz rund scheinen. Zudem ist das Spiel etwas Adventure-artig aufgebaut, was, angesichts der kurzen Entwicklungszeit sicher ein Problem ist/war. Man sollte also nicht allzu viel erwarten. Trotzdem würde mich auch hier der Quellcode sehr reizen.
Auch die Frösche kommen mit .sh-Launcher für Linux und .bat– bzw. .sh-Launcher für Windows und Mac.
Der Mojam spielte sich ja wieder hauptsächlich in Europa und somit in der MEZ ab, weshalb David und Aubrey von Wolfire (San Fransisco) immer mit etwas Versatz am arbeiten waren. Leider haben sie es zum offiziellen Ende der Aktion nicht bis zu einer endgültigen Version ihres Spiels geschafft. Die zweite Demo ist derzeit das aktuellste, was man sich ansehen kann. Nach wie vor ist es so, dass man den Unity Webplayer (für Linux nicht erhältlich) benötigt, um die Demo auszuprobieren. Das fertige Spiel sollte allerdings dann auch unter Linux laufen.
Es ist allerdings angekündigt, dass die beiden das Wochenende über noch an ihrem Spiel tüfteln werden.
Sobald das Spiel verfügbar ist, werde ich es hier noch nachtragen.
Die Niederländer von Vlambeer haben mit dem Game Maker 7 ein recht umfangreich gestaltetes Shoot’em Up auf die Beine gestellt. Es erinnert im ersten Moment vielleicht etwas an Catacomb Snatch ist aber dann doch anders.
Dass es mit dem Game Maker gebaut wurde, bedeutet leider, dass es wohl keine native Linux-Version geben wird. Die Windows-Version ist zwar mit Hilfe von WINE startbar, allerdings bricht die Geschwindigkeit komplett zusammen, sobald das Level gestartet wird. Sound kommt auch keiner.
Falls jemand herausfindet, wie man das Spiel unter Linux spielbar bekommt, wäre ich für einen Hinweis in den Kommentaren dankbar.
Tja, mal sehen, ob es von Tektonik, dem Spiel von Grapefrukt, einen Linux-Build geben wird. Bislang gibt es nur Downloads für Windows und Mac. Allerdings kann unter Linux das Spiel online im Browser, als reine Flash-Variante, gespielt werden.
Das Spiel-Prinzip ist etwas verwirrend, aber nach etwas Zeit hat man den Kniff raus. Es geht darum, von einem Planeten Rohstoffe abzubauen – und das schnellstmöglich, denn Gegner, die einem in die Suppe spucken, gibt es auch.
Die Idee gefällt mir grundsätzlich, böte aber sicher noch einiges Potenzial für Erweiterungen. Die Steuerung hakelt manchmal etwas.
Klopperei im Weltall. Bei Ludosity’s “Space Hunk” liefern sich zwei Spieler (an der selben Tastatur spielend) ein Space-Duell. Zuerst wählen beide ihren Helden aus – jeder hat seine spezielle Fähigkeit.
Dann kann es losgehen. Die Helden sind mit einem Gummi-artigen Band an ein Raumschiff gebunden. Nun steuert man sein Raumschiff, um den eigenen Helden gegen den Duell-Gegner zu schleudern. Das Spiel ist in liebevoller Retro-Optik gestaltet.
Leider gibt es auch hier nur einen Windows-Build. Allerdings kann das Spiel mit WINE gespielt werden. Eine Installation ist nicht notwendig – einfach die .exe-Datei starten. Sound bekomme ich allerdings keinen. Auch hier wäre ich für Tipps dankbar. Der Sound funktioniert, wenn man das Spiel über die spacehunk_gms.exe startet.
Recht wenig im Stream zu sehen, war die Arbeit von Oxeye. In 3918 (Projektname war wohl Daisy Moon?!) geht es um ein Kriegsduell. Man steuert ein Raumschiff, das zunächst wie eine Rakete ins All geschossen wird. Damit muss man sich dann auf zum Gegner machen und dessen Städte angreifen.
Der Ansatz ist nicht schlecht. Allerdings denke ich, dass noch einiges fehlen würde, um das Spiel komplett zu machen bzw. um genügend Spielspaß zu erzeugen.
Leider gibt es auch hier nur ein Windows-Build, das aber ebenfalls per WINE ohne Installation spielbar ist. Das Spiel lässt sich leider nicht beenden (zumindest habe ich keinen Weg gefunden) und muss per kill abgeschossen werden.
Angenommen ein Server hat die Zeichenkodierung de_DE.UTF-8, ein auszuführendes Shellscript muss jedoch mit der Zeichenkodierung de_DE.ISO-8859-1 laufen.
Die Lösung ist sehr einfach. In dem auszuführenden Script muss folgende Zeile am Anfang stehen:
export LANG=de_DE.ISO-8859-1
Cronjobs
Wenn ein oder mehrere Shellscripte als cronjob gestartet werden, kann die Zeichenkodierung auch in der /etc/environment hinterlegt werden. Damit entfällt die Angabe der Zeichenkodierung in dem Shellscript.
 |
|
| Malen mit Freunden | |
|---|---|
| Genre | Spiel |
| Preis | kostenlos |
| Homepage | Malen mit Freunden |
Die heutige App der Woche ist ein super Zeitvertreib für langweilige Vorlesungen. Es handelt sich um ein Spiel, das noch nicht zum Zynga-Imperium gehört.
Das Spiel kennt jeder, denn es existiert schon seit hunderten Jahren. Im echten Leben nennt es sich Montagsmaler: Jemand zeichnet einen vorgegebenen Begriff, der Mitspieler muss ihn erraten.
Nach jeder Runde werden 5 neue Begriffe angezeigt (in 2 unterschiedlichen Schwierigkeitsgraden), wovon einer gezeichnet werden muss.
Dem Mitspieler wird zeitversetzt die Zeichnung übermittelt. Dabei wird das Bild in erhöhter Geschwindigkeit „gemalt“, sodass man den Entstehungsprozess nachvollziehen kann. Die Punkte werden nach der Ratezeit vergeben.
Das gezeichnete Wort muss nun erraten werden
Das Spiel ist kostenlos für Android und iOS verfügbar. Zumindest die Android-Version ist stark mit Werbung versehen. Kostenlos sind einige Wortpakte verfügbar, die man über ein Bezahlsystem ergänzen kann. Hierzu gibt es ein Münz-Bezahlsystem. Münzen bekommt man entweder durch hohe Punktzahlen, oder durch Geld. In der aktuellen Version kann man gegen 2 Münzen auch einen eigenen Begriff zeichnen.
Man kann sich dort entweder mit seinem Facebook-Account oder über eine E-Mail Adresse registrieren. Dies ist notwendig, damit man sich mit seinen Freunden verbinden kann.
Die App läuft leider nicht 100% stabil, es gab schon einige Abstürze. Nach jeder Runde wird man auf Bezahldienste hingewiesen, die man erst nach einigen Sekunden verbergen kann.
Mozilla hat die erste Beta-Version von Firefox 20 veröffentlicht. Firefox 20 bringt sehr viele interessante Neuerungen. Eine dieser Neuerungen ist der neue Private Modus, welcher ab sofort auf Fenster-Basis aktiviert werden. Bei diesem häufig scherzhaft auch als Porno-Modus bezeichneten Modus werden keine Chronik oder sonstige private Daten beim Surfen auf der Festplatte gespeichert. Bislang konnte Firefox nur ganz oder gar nicht in diesem Modus sein, der parallele Betrieb verschiedener privater wie nicht privater Fenster ist ab Firefox 20 möglich.
Neu ist auch die standardmäßige Aktivierung eines neuen Panels für aktive Downloads, welches anstelle des bisherigen Download-Fensters erscheint und bereits seit einigen Versionen versteckt implementiert ist und seit dem viele Verbesserungen erhalten hat. In diesem Zusammenhang wurde auch die Download-Ansicht in der Bibliothek überarbeitet.
Ebenso verbessert wurde das Click-to-Play-Feature von Firefox, welches es erlaubt, Plugins erst bei Bedarf zu laden. Hierfür muss über about:config der Schalter plugins.click_to_play auf true gesetzt werden. Dabei kann ab Firefox 20 die Entscheidung für eine Webseite separat für verschiedene Plugins getroffen werden. Außerdem lassen sich die Berechtigungen nun auch über den Seiteninformations-Dialog festlegen.
Nutzer von Windows erhalten eine weitere Neuerung in Bezug auf Plugins. Bislang wartet Firefox 45 Sekunden, wenn ein Plugin wie Flash aufhört zu reagieren, ehe ein Beenden des Plugins erzwungen wird. In dieser Zeit hört allerdings auch Firefox auf zu reagieren. Firefox auf Windows erkennt sich aufhängende Plugins und zeigt nach elf Sekunden einen Dialog an, welcher den Benutzer über den Umstand informiert und bietet an, weiter auf eine Reaktion des Plugins zu warten oder das Plugin zu beenden.
Bildquelle: ghacks.net
Ebensfalls Nutzern von Windows (Vista und höher) vorbehalten, zumindest derzeit, ist die (standardmäßig noch deaktivierte) Unterstützung von H.264, MP3 sowie AAC in <video>- und <audio>-Tags, ohne dass ein Plugin hierfür installiert sein muss. Firefox wird weiterhin ohne die entsprechenden Codecs ausgeliefert, stattdessen wird sich an den auf dem System installierten Codecs via Windows Foundation Framework bedient. Zur Aktivierung muss der Schalter media.windows-media.foundation.enabled via about:config auf true gesetzt werden.
Ein weiteres Highlight dieser Version ist eine von Firefox angebotene Möglichkeit, den Schalter keyword.URL für Adressleisten-Suchen wieder auf die Standard-Suche zurückzusetzen, wenn eine Drittanwendung diesen Schalter ungefragt verändert hat. Sogenanntes Suchmaschinen-Hijacking wurde in den letzten Monaten zu einem sehr großen Problem, insbesondere da die meisten Anwender nicht wissen, wie sie dies wieder zurücksetzen können. Mit dieser Neuerung reagiert Mozilla auf das Problem.
Webentwickler freuen sich über ein neues, durchdachteres Layout für die Entwickler-Werkzeuge, welche nun außerdem vom unteren Fensterrand losgelöst und als eigenständiges Fenster geöffnet werden können. Mit einem JavaScript-Profiler gibt es außerdem ein weiteres neues Entwickler-Werkzeug.
Einen detaillierten Überblick über diese und weitere Neuerungen bietet der dazugehörige Aurora-Artikel.
Download & Zeitplan
Die aktuelle Beta-Version kann hier heruntergeladen werden: Download Mozilla Firefox 20 Beta.
Läuft alles nach Plan, erscheint die finale Version am 02.04.2013.
Während des dist-upgrade beim konfigurieren kam es zu haufenweise
Fehlern. Da Apt selber nicht mehr lief, dachte ich booten wäre eine
gute Idee.
Tja die Idee war blöd, ich bekomme einen Kernel Panic, die Libraries passen nicht mehr zueinander.
Ziemlich dumm geguckt habe ich da. Das ist mir glaube ich noch nie mit Debian Testing passiert.
Ziemlich Dumm war, das ich nun kein Rettungsystem da hatte, um mal zu gucken.
Da habe ich mir den Laptop meiner Frau ausgeliehen (auch Debian) und grml runterladen und auf einen rumliegenden USB-Stick geschrieben, so mit mit isohybrid und dd und so.
Grml hat LVM Management tools komfortablerweise bereits on Board, so dauerte es nicht lange, bis ich in einer chroot Sitzung die notwendigen Informationen wie atp.log und histroy.log zusammenklauben konnte und im debianforum auf nopaste ablegen konnte. Dort habe ich einen Hilferuf gestartet, beim zusammenstellen der Informationen ging ich nochmal systematisch vor, damit die Member im Forum nicht so viel nachfragen müssen, dabei fiel mir auf, das mit den Libraries eigentlich alles in Ordnung sein müsste, denn obwohl immer die Meldung libray xyz nicht gefunden, waren sie allesamt da.
ein ldconfig half dann auch immer für einen Befehl.
Bash und ls z.B. liefen auch nicht, erst nach einem ldconfig.
An ein apt-get -f install war nicht zu denken, es brach immer mittendrin mit
cannot open shared object file: No such file or directory
ab.
Ich habe es so gelöst, das ich einen Dreizeiler geschrieben habe und im Hintergrund laufen ließ
cat /llc.sh while [ 1 = 1 ] do ldconfig done
Nun lief apt-get -f install durch und ich konnte wieder booten. Full Story hier: debianforum.de/forum/viewtopic.php?f=13&t=141064
Ich setzte mich gerade wegen LPIC 301 etwas mit OpenLDAP auseinander. Um Dinge zu testen wie Replikation über syncrepl, Index Aufbau oder Accesslists für Gruppenadmins brauche ich Datensätze.
Um diese Daten nicht alle von Hand schreiben zu müssen, hatte ich mir überlegt
eine Art Automatismus zu basteln, mit der ich LDIF Files erzeugen kann.
Vor kurzem habe ich (als ich auf der Suche nach einem Hostnamen war) mal
larisweb.de gefunden. Dort gibt es tolle Generatoren
für Fantasy Namen die man mit ein bisschen curl schoen maschinell auslesen
kann.
1 2 3 4 | |
Leider sind auf der Site keinerlei Informationen zur Lizenz oder ähnlichem angegeben. .oO(Auch wenn ich somit keinerlei Recht hätte die Namen für irgendwas zu benutzen sollte es für private Zwecke wohl ok sein, für was gäbs die Seite sonst?).
Als erstes brauche ich aber eine Gruppe ou=zwerge,dc=noqqe,dc=de für die neuen User in meinem
Verzeichnis.
1 2 3 4 5 6 | |
Der Einfachheit halber habe ich mich bei den erzeugten Usern für die
STRUCTURAL Objektklasse inetOrgPerson gepaart mit der AUXILIARY Klasse
posixAccount entschieden.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | |
Den Output des Skripts am Besten in ein File umleiten und dann mit ldapmodify zum Directory hinzufügen.
1
| |
Wichtig ist dabei das -c da ich innerhalb des Scripts keine Prüfung auf
duplicates durchführe. Im Continuous Operation Mode macht OpenLDAP bei Fehlern einfach weiter mit dem LDIF File.
Mein konkreter Anwendungsfall ist der: Ich möchte in diverse Blogartikel Warnboxen einfügen, die den Leser in vier Kategorien auf besonders wichtige Punkte aufmerksam machen sollen. Dabei soll der Text im WordPress-Editor für Beiträge (basierend auf TinyMCE) geschrieben werden und über ein Dropdown-Menü direkt aus dem Editor formatiert werden.
Als erstes muss man die Formatierung in CSS definieren. Dazu muss man sich erstmal festlegen, wie das in HTML umgesetzt werden soll. Ich habe mir das so vorgestellt (die denkbar einfachste Lösung):
<div class="warning">Hier seht die Warnung</div>
Die vier angesprochenen Kategorien (rot, gelb, grün, blau) werden über die Klasse ausgewählt. Mein CSS-Code sieht dabei folgendermaßen aus (er ist stark an diesen hier angelehnt):
.info, .success, .warning, .error {
border: 1px solid;
margin: 10px 0px;
padding:15px 10px 15px 50px;
background-repeat: no-repeat;
background-position: 10px center;
}
.info {
color: #00529B;
background-color: #BDE5F8;
background-image: url('info.png');
}
.success {
color: #4F8A10;
background-color: #DFF2BF;
background-image:url('success.png');
}
.warning {
color: #9F6000;
background-color: #FEEFB3;
background-image: url('warning.png');
}
.error {
color: #D8000C;
background-color: #FFBABA;
background-image: url('error.png');
}
Dieser CSS-Code muss in 2 Dateien eingefügt werden. Zuerst in der style.css des Themes. Diese kann man über den Design-Editor im Backend bearbeiten.
Optional, aber sehr zu empfehlen, ist noch eine zweite CSS-Datei. Diese sorgt dafür, dass die Formatierung auch schon in TinyMCE korrekt angezeigt wird. Die Datei liegt auch im Theme-Ordner und nennt sich editor-style.css (kann notfalls dort angelegt werden).
Jetzt müssen die vier neuen Formatvorlagen auch in TinyMCE eingebunden werden, damit man sie ohne Bearbeitung des HTML-Codes anwenden kann. Dazu bearbeitet man die Datei /wp-includes/class-wp-editor.php und fügt folgenden Text hinzu Der folgende Text kann ebenfalls mit dem Theme-Editor in die Datei functions.php eingefügt werden. [Danke Chris für den Hinweis]
// Callback function to filter the MCE settings
function my_mce_before_init_insert_formats( $init_array ) {
// Define the style_formats array
$style_formats = array(
// Each array child is a format with it's own settings
array(
'title' => 'Error',
'block' => 'div',
'classes' => 'error',
'wrapper' => false,
),
array(
'title' => 'Warnung',
'block' => 'div',
'classes' => 'warning',
'wrapper' => false,
),
array(
'title' => 'Info',
'block' => 'div',
'classes' => 'info',
'wrapper' => false,
),
array(
'title' => 'Bestätigung',
'block' => 'div',
'classes' => 'success',
'wrapper' => false,
),
);
// Insert the array, JSON ENCODED, into 'style_formats'
$init_array['style_formats'] = json_encode( $style_formats );
return $init_array;
}
// Attach callback to 'tiny_mce_before_init'
add_filter( 'tiny_mce_before_init', 'my_mce_before_init_insert_formats' );
Jedes der oben angegebenen Arrays ist dann ein neuer Eintrag in der Styles-Liste. “block” sorgt für die div-Box um unseren Text herum, “classes” legt die CSS-Klasse fest und “wrapper” sorgt dafür, dass es nicht als „Absatz“ behandelt wird.
Es gibt noch etliche weitere Konfigurationsmöglichkeiten, die ihr bei Codex nachlesen könnt.
Der größte Teil ist schon geschafft. Ab jetzt kommt die Hilfe eines Plugins zum Tragen: TinyMCE Advanced. Damit kann man das Dropdown-Feld Styles in die Bearbeitungsseite holen. Wenn ihr das gemacht habt, sieht euer Editor so aus:
Die neu erstellten Formatvorlagen sind jetzt über eine Dropdown-Liste auswählbar
Die vier neu erstellten Boxen sehen so aus:
