ubuntuusers.de

11. April 2015

Google arbeitet bereits seit längerem an einer Vollverschlüsselung für Android. Die Funktionen sind bereits seit einigen Versionen enthalten, aber nicht standardmäßig aktiviert. Mit Lollipop sollte sich das eigentlich ändern, aber scheinbar haben Google und die Smartphonehersteller hier nochmal einen Rückzieher gemacht.

Das Problem ist möglicherweise, dass sie auf dm-crypt basierende Verschlüsselung für viele Anwender zu umständlich ist. Beim Anschalten des Gerätes wird erst das Passwort für die Betriebssystemverschlüsselung abgefragt, dann der SIM-Pin und  dann nochmal die Geräteentsperrung. Datenschutzbewusste Nutzer sehen hier den Sicherheitsaspekt, viele normale Anwender sind einfach nur genervt.

Nun scheint Google einen neuen Anlauf zu unternehmen.  Die bei Google angestellten Kernelentwickler Theodore Ts’o  (Maintainer ext4) und Michael Halcrow (eCryptFS Autor) haben einen Patch vorgestellt, der eine Verschlüsselung der Dateien und Dateinamen für das ext4 Dateisystem vorsieht. Die Verzeichnisstruktur bleibt sichtbar.

Letzteres ist zwar ein Nachteil gegenüber eCryptFS und LUKS/dm-crypt, scheint aber für den vorgesehenen Einsatzzweck ausreichend. Hier geht es schließlich nur darum Daten vor dem Zugriff durch Unbefugte zu bewahren (z.B. bei Diebstahl des Mobilgerätes). Spannend wird sein ob die bisherige dm-crypt basierte Verschlüsselung ersatzlos gestrichen wird oder optional erhalten bleibt. Letzteres wäre vor allem für Anwender interessant, die den Sicherheitsaspekt höher gewichten als den Bedienkomfort.

Mal sehen was das kommende Android “M” bringen wird.


Quellen:

  1. Pro-Linux
  2. Heise online

Im Rahmen der Blogparade Webspace-Inventar: Was ist auf deinem Webspace installiert? von demaya.de möchten wir kurz die Tools auflisten, die auf unseren Webservern installiert sind. Ich wähle hier bewusst den Plural, weil wir mittlerweile mehrere Server von unterschiedlichen Anbietern gemietet haben. Letztendlich sind unsere Softwaretools relativ unspektakulär, da das meiste weit verbreitet ist.

wordpress-logo-stacked-rgbWordPress: Das Haupttool auf unseren Servern ist fast jedes mal WordPress. Ganz einfach aus dem Grund, dass wir mehrere Webseiten betreiben die jeweils ein gutes CMS brauchen. Wir arbeiten schon seit vielen Jahren damit, ich erstelle und verwalte mittlerweile sogar kommerziell ein paar Webseiten mit dieser Software. WordPress ist sehr stabil und ausgereift und ist daher sehr zu empfehlen.

Piwik_2.0_logo.svgPiwik: Wo ein WordPress, da ein Piwik. Das ist stets die Devise bei unseren WordPress-Installationen. Wir benutzen Piwik zum Tracken von Besuchern aus dem einfachen Grund, dass wir schnelles Feedback zu unseren Artikeln möchten. Da der meiste Traffic über Google kommt, ist Piwik für uns ein wichtiges Instrument für die Erreichbarkeit unserer Seite. Früher konnten wir sogar die Suchbegriffe auswerten, über die wir gefunden werden. Dies wird leider immer ungenauer bzw. ist nicht mehr aussagekräftig.

OwnCloud2-Logo.svgOwnCloud: Früher hatten wir unsere Cloud-Daten bei Dropbox, doch mittlerweile ist uns der Speicherplatz zu klein und der Funktionsreichtum zu gering. OwnCloud ersetzt uns mittlerweile den Google Kalender, das Adressbuch und die geteilten Ordner aus der Dropbox. Außerdem ist es ein Backup der Handyfotos und diverser anderer Dateien. Dank Owncloud sind wichtige Daten für uns immer erreichbar und sensible Daten (z.B. Telefonnummern und Geburtstage von Kontakten) liegen auf unseren eigenen Servern und nicht bei Google.

question2answer-logo-350x40Question 2 Answer: Für meine Kunden habe ich mit Question 2 Answer ein Frage-und-Antwort-Forum installiert. Es ist von der Bedienung wie gutefrage.net oder stackexchange.com: Man stellt eine Frage und die Antworten können von anderen Benutzern bewertet werden. Die Antworten sind dann nach ihren Bewertungen sortiert. Das Forum wird allerdings eher sporadisch genutzt, daher sind meine Erfahrungen damit eher überschauber. Großes Plus: Die Benutzerverwaltung kann mit WordPress verknüpft werden, sodass man sich mit den WordPress-Anmeldedaten dort anmelden kann. Großes Minus: Es gibt nur sehr wenige Themes und das Personalisieren ist ziemlich aufwendig.

kivitendoKivitendo: Um die von mir geschriebenen Rechnungen zu verwalten, benutze ich die Software Kivitendo. Da sie in Perl geschrieben ist, ist die Installation eventuell etwas komplizierter als mit den genannten PHP-Anwendungen. Mit Kivitendo kann ich alle meine Dienstleistungen, Produkte und Kunden verwalten. Großer Vorteil: Die Rechnungen werden in LaTeX gesetzt, wodurch ich die Rechnungsvorlagen ziemlich einfach und gezielt bearbeiten kann (aber auch nur, da ich LaTeX-Erfahrungen habe). Auch Lieferscheine und Angebote lassen sich damit erstellen. Für kleine und mittlere Unternehmen habe ich kein besseres ERP-System gefunden, das auf Webspaces installiert werden kann. Ich bin mittlerweile sehr zufrieden. Die größte Hürde am Anfang ist allgemein die Bedienung von ERP-Systemen, doch Kivitendo macht den Einstieg recht einfach.

Das sind die Programme, die wir auf unseren Webservern laufen haben. Wir haben zwischendurch immer mal wieder andere Software installiert, um sie zu testen und einen Nutzen für uns zu finden. Doch meistens werden die Testprogramme wieder verworfen, da es gar nicht sooo viele wirklich nützliche und ausgereifte Programme für Webserver gibt.

Ich möchte gerne die Verbreitung der Parade unterstützen, daher lade ich Chrissss ein, an ihr teilzunehmen. Damit revangiere ich mich für eine andere Einladung zu einer Blogparade von vor fast 4 Jahren!

The post Blogparade: Tools auf dem Webserver first appeared on bejonet.

Posteo arbeitet bereits seit einiger Zeit an zusätzlichen Sicherheitsfunktionen für seine Kunden. Im Februar aktivierte man die Möglichkeit die eigenen Mails beim Eintreffen mittels des eigenen PGP Schlüssels zu verschlüsseln. Man verwies aber damals bereits auf neue Verschlüsselungsoptionen, die bald verfügbar sein sollten.

Man hat Wort gehalten. Am 09. April begann der Rollout des neuen Krypto-Mailspeichers. Leider hat dieser mein Konto noch nicht erreicht, weshalb ein  eigener Erfahrungsbericht aussteht.

Die Funktionsweise beschreibt Posteo wie folgt:

Sobald Sie Ihren Krypto-Mailspeicher in den Einstellungen aktivieren, erzeugt Posteo ein individuelles Schlüsselpaar für Sie. Mit diesem verschlüsseln wir alle E-Mail-Daten (Inhalte, Anhänge und Metadaten), die sich in Ihrem Postfach befinden. Dies geschieht mit dem Teil des Schlüsselpaares, der für das “Verschlüsseln” zuständig ist. Jede E-Mail wird einzeln verschlüsselt. Der Schlüssel, der eine E-Mail wieder “lesbar” machen kann, liegt durch Ihr persönliches Passwort geschützt in der Posteo-Datenbank. Somit können nur Sie auf Ihren verschlüsselten E-Mailspeicher zugreifen. An den Arbeitsabläufen im Postfach ändert sich nichts: Klicken Sie bei aktiviertem Krypto-Mailspeicher auf eine E-Mail, wird diese im Hintergrund für Sie lesbar gemacht – und zwar nur für den Moment des Zugriffs. Sie verwalten Ihre E-Mails so komfortabel und einfach wie bisher.

Quelle: Posteo Newsletter vom 09. April

Besonders begrüßenswert: Posteo hat hier nicht nur irgendeine Funktion implementiert, sondern diese auch extern einem Sicherheits-Audit unterzogen. Letztlich bleibt das natürlich eine Vertrauensfrage, aber es macht einen guten Eindruck.

Realisiert wird die Verschlüsselung durch ein Plugin für Dovecot, das nun auch unter einer freien Lizenz (AGPL) veröffentlicht wurde. Dieser Aspekt ist besonders schön zu sehen, da Posteo zwar konsequent auf Open Source setzt aber bisher immer wieder der Vorwurf laut wurde, dass kaum etwas an die Gemeinschaft zurück fließt. Wobei das ja zu den Standard-Anschuldigungen in der Open Source Community gehört.

Die neue Verschlüsselungstechnik ersetzt allerdings keineswegs eine vollwertige Ende-zu-Ende Verschlüsselung mittels PGP der S/MIME, da die Mails auf dem Transportweg weiterhin nicht verschlüsselt sind (außer zwischen einigen Anbietern).  Sie ist aber eine gute Ergänzung, weil bei einer verschlüsselten E-Mail bei der bisherigen Speicherung trotzdem unverschlüsselte Metadaten auf den Posteo-Servern lagen.

Die Verschlüsselung funktioniert auch wenn man als Kunde über IMAP  auf den Server zugreift. In diesem Fall ist es natürlich von zentraler Bedeutung, dass man seine Endgeräte wirkungsvoll absichert (Linux und eCryptfs, Linux und LUKS, Windows, Android). Wie so oft sitzt das letzte Risiko immer vor dem Monitor.

Systembedingt funktionieren nach der Aktivierung der Verschlüsselung einige Funktionen wie zum Beispiel die Zusendung eines neuen Passworts nicht mehr. Denn die E-Mails wurden mit dem alten Passwort verschlüsselt, was Posteo nicht einfach ändern kann (und das ist gut so!). Wer also Probleme hat sich Passwörter zu merken, sollte dringend über eine systematische Passwortverwaltung nachdenken.

Insgesamt wird Posteo mit jedem Jahr zu einem besseren Mailanbieter. Den Umzug dorthin habe ich in den vergangenen 2 Jahren kein einziges Mal bereut. Eine Aussage, die man sicherlich nicht bei vielen technischen Migrationen und Erwerbungen treffen kann. Posteo bietet einen hervorragenden Dienst, basierend auf freier Software.

Google arbeitet bereits seit längerem an einer Vollverschlüsselung für Android. Die Funktionen sind bereits seit einigen Versionen enthalten, aber nicht standardmäßig aktiviert. Mit Lollipop sollte sich das eigentlich ändern, aber scheinbar haben Google und die Smartphonehersteller hier nochmal einen Rückzieher gemacht

Das Problem ist möglicherweise, dass sie auf dm-crypt basierende Verschlüsselung für viele Anwender zu umständlich ist. Beim Anschalten des Gerätes wird erst das Passwort für die Betriebssystemverschlüsselung abgefragt, dann der SIM-Pin und dann nochmal die Geräteentsperrung. Datenschutzbewusste Nutzer sehen hier den Sicherheitsaspekt, viele normale Anwender sind einfach nur genervt.

 

Android Illustration von norebbo.com

Nun scheint Google einen neuen Anlauf zu unternehmen. Die bei Google angestellten Kernelentwickler Theodore Ts’o (Maintainer ext4) und Michael Halcrow (eCryptFS Autor) haben einen Patch vorgestellt, der eine Verschlüsselung der Dateien und Dateinamen für das ext4 Dateisystem vorsieht. Die Verzeichnisstruktur bleibt sichtbar.

Letzteres ist zwar ein Nachteil gegenüber eCryptFS und LUKS/dm-crypt, scheint aber für den vorgesehenen Einsatzzweck ausreichend. Hier geht es schließlich nur darum Daten vor dem Zugriff durch Unbefugte zu bewahren (z.B. bei Diebstahl des Mobilgerätes). Spannend wird sein ob die bisherige dm-crypt basierte Verschlüsselung ersatzlos gestrichen wird oder optional erhalten bleibt. Letzteres wäre vor allem für Anwender interessant, die den Sicherheitsaspekt höher gewichten als den Bedienkomfort.

Mal sehen was das kommende Android “M” bringen wird.


Quellen:

  1. Pro-Linux
  2. Heise online

Google arbeitet bereits seit längerem an einer Vollverschlüsselung für Android. Die Funktionen sind bereits seit einigen Versionen enthalten, aber nicht standardmäßig aktiviert. Mit Lollipop sollte sich das eigentlich ändern, aber scheinbar haben Google und die Smartphonehersteller hier nochmal einen Rückzieher gemacht

Das Problem ist möglicherweise, dass sie auf dm-crypt basierende Verschlüsselung für viele Anwender zu umständlich ist. Beim Anschalten des Gerätes wird erst das Passwort für die Betriebssystemverschlüsselung abgefragt, dann der SIM-Pin und dann nochmal die Geräteentsperrung. Datenschutzbewusste Nutzer sehen hier den Sicherheitsaspekt, viele normale Anwender sind einfach nur genervt.

Android Illustration von norebbo.com

Nun scheint Google einen neuen Anlauf zu unternehmen. Die bei Google angestellten Kernelentwickler Theodore Ts’o (Maintainer ext4) und Michael Halcrow (eCryptFS Autor) haben einen Patch vorgestellt, der eine Verschlüsselung der Dateien und Dateinamen für das ext4 Dateisystem vorsieht. Die Verzeichnisstruktur bleibt sichtbar.

Letzteres ist zwar ein Nachteil gegenüber eCryptFS und LUKS/dm-crypt, scheint aber für den vorgesehenen Einsatzzweck ausreichend. Hier geht es schließlich nur darum Daten vor dem Zugriff durch Unbefugte zu bewahren (z.B. bei Diebstahl des Mobilgerätes). Spannend wird sein ob die bisherige dm-crypt basierte Verschlüsselung ersatzlos gestrichen wird oder optional erhalten bleibt. Letzteres wäre vor allem für Anwender interessant, die den Sicherheitsaspekt höher gewichten als den Bedienkomfort.

Mal sehen was das kommende Android “M” bringen wird.


Quellen:

  1. Pro-Linux
  2. Heise online

10. April 2015

Das von mir kürzlich erworbene Subnotebook macht mir immer noch sehr viel Freude. Das kann man von Kubuntu leider nicht behaupten. Nach dem Kauf musste ja schnell ein Betriebssystem rauf und mangels Ethernet-Port wurde es die 14.04er LTS. Neben kleinen Problemchen, wie die nicht funktionierende Lautstärkesteuerung nervt mich der schlechte Pflegezustand der LTS jeden Tag mehr.

An allen Ecken und Enden finden sich Bugs, die teilweise schon seit Monaten/Jahren gemeldet sind und scheinbar keine Priorität genießen. Ganz besonders nervig ist der Akonadi-Bug, bei dem KOrganizer vollkommen unbegründet eingetragene Kalender vergisst, die sich erst durch einen Neustart wiederfinden lassen. Das brachte mich in den vergangenen Tagen an den Rand des Wahnsinn. Der Bug ist in neueren Akonadi/Kontact Versionen behoben, aber dem Kubuntu-Team scheint der Wille oder die Fähigkeit zu fehlen die Fehlerbehebung zurück zu portieren.

Neuere STS Releases kommen leider nicht in Frage. Das Subnotebook soll einfach nur funktionieren und mich nicht alle Nase lang alle paar Monate mit Distributionsupgrades nerven. Deshalb ja schließlich auch die Idee mit der LTS. OpenSUSE 13.2, das bei mir einen sehr guten Eindruck hinterlassen hat kommt aus selbigem Grund leider auch nicht in die nähere Auswahl. Also muss es wohl Debian werden. Das Release von Jessie steht kurz bevor und der Ersteindruck im vergangenen Jahr war nicht so übel. Das KDE Team ist dort zwar auch nicht mit Manpower oder durchweg weisen Entscheidungen gesegnet, aber immerhin liegt Kontact in Version 4.14 vor. Das man mal für einen blöden Bug einen Distributionswechsel vornimmt, kommt auch nicht so oft vor, aber bei einem zentralen Werkzeug für Kontact geht man über Leichen.

Die Softwarezusammenstellung: Ein verspäteter Aprilscherz?

Leider ist dem Notebook in der letzten Woche immer noch kein Ethnernet-Port gewachsen. Ein Netinstall fiel deshalb scheinbar leider flach. Debian bietet aber zum Glück mehr als genug Installationsmedien,  die DVD 1 sollte das notwendigste abdecken. Seit Jessie kann man in der Installationsroutine auch die Desktopumgebung ohne schmutzige Tricks auswählen. Mal schauen was Debians KDE Team dem Nutzer so andient. Die Installationsroutine verrät schon mal, dass es ca. 1 300 Pakete werden. Also ein ähnlicher Umfang wie eine  Kubuntu-Installation.

Nach dem obligatorischen Neustart und einem Blick in die Paketliste, sowie des Startmenüs fällt es einem schwer die Zusammenstellung zu beschreiben. Genau genommen wäre eine subjektive Beschreibung hier gerade gefährdend für alle Altersgruppen. Debians KDE Team ist wohl der Meinung, dass man drei Werkzeuge zur Drucker-Verwaltung braucht, Super-Karamba schön an KDE 3.5 erinnert, Kopete ein zeitgemäßerer IM-Client ist und kdesudo nicht schlecht wäre – obwohl Debian das von Haus aus nicht braucht.

Liebes Debian KDE Team. Apt-get ist ein super Werkzeug für die Paketverwaltung und Distributionsupgrades funktionieren bei Debian wirklich hervorragend. Scheinbar so gut, dass niemand in eurem Team in den letzten Jahren eine Neuinstallation vorgenommen hat. Jedenfalls nicht mit den normalen Installationsmedien und einer Standard-Installation. Anders kann man sich diesen Unfall nicht erklären.

Debian Netinstall ohne Ethernet Port

Mit dem System werde ich nicht glücklich. Alleine die Deinstallationsorgie braucht mehr Zeit, als eine frische Netinstallation in Anspruch nimmt. Wäre da nicht der fehlende Ethnernet-Port. Auf der Debian-Webseite versprechen die Debian-Maintainer allerdings, dass eine Netinstall (mit Einschränkungen) auch via WLAN möglich ist. Vielleicht hat sich seit den Zeiten von Lenny und KDE 3.5 doch was getan. Der Download geht bei knapp 200MB zum Glück auch schnell und selbst dd schafft es nicht sich an der Dateigröße zu verschlucken.

Die Überraschung folgt auf dem Fuße. Debians Installationsroutine (natürlich nach einbinden der unfreien firmware-Pakete) erkennt tatsächlich das WLAN und richtet es ein. Die Installation danach ist Routine, UEFI und LUKS/LVM werden zufriedenstellend eingerichtet. Bei der Task-Auswahl entscheidet man sich natürlich nur für eine Minimalinstallation. Das Softwaremuseum von oben will man schließlich kein zweites Mal auf der Festplatte sehen.

Das dem Neustart dann die Ernüchterung. Keine funktionierendes WLAN weit und breit. Allso muss doch wpa_supplicant und ifup ran. Wenigstens ist beides in der Minimalinstallation enthalten.

Zuerst ermittelt man den WPA-PSK Hash:

§ wpa_passphrase <meinessid> <meine_absolut_sichere_Passphrase> # natürlich ohne die <>

Das Ergebnis trägt an in /etc/interfaces/network ein.

auto wlan0
iface wlan0 inet dhcp
wpa-ssid <Meine SSID>
wpa-psk <Der ermittelte Hash-Wert>

Dann noch das WLAN aktivieren mit:

# ifup wlan0

Danach kann man wie gewohnt die notwendigen Pakete installieren. Sofern man auf den NetworkManager wechselt, muss man die Einträge in der network-Datei wieder entfernen.

Als ich den ersten Arduino Yún im Herbst 2013 in den Händen gehalten habe, war ich begeistert von der Eleganz der enthaltenen Bridge-Bibliothek. Die erlaubt es, den Yún per SSH zu programmieren und sie stellt viele Netzwerkfunktionen des Linux-Systems sehr simpel in Arduino bereit. Aaaaber: Das OpenWRT des Yún ist relativ unflexibel, RAM und Prozessor sind knapp und die Platine ist recht teuer.

Ich habe daher die Bridge-Bibliothek, die Scripte zum Flashen der Arduino-Seite und das Webinterface aus Yún herausgezogen, teilweise neu implementiert und auf Debian portiert. Unterstützt wird derzeit Wheezy mit SysV Init (Raspbian, Bananian), Ubuntu wird bald folgen.

www.arduino-hausautomation.de/nuage/

Post bei G+ (Arduino-Gruppe)

Das von mir kürzlich erworbene Subnotebook macht mir immer noch sehr viel Freude. Das kann man von Kubuntu leider nicht behaupten. Nach dem Kauf musste ja schnell ein Betriebssystem installiert werden und mangels Ethernet-Port wurde es die 14.04er LTS. Neben kleinen Problemen, wie die nicht funktionierende Lautstärkesteuerung nervte mich der schlechte Pflegezustand der LTS jeden Nutzungstag ein wenig mehr. An allen Ecken und Enden finden sich Bugs, die teilweise schon seit Monaten/Jahren gemeldet sind und scheinbar keine Priorität genießen. Ganz besonders nervig ist der Akonadi-Bug, bei dem KOrganizer vollkommen unbegründet eingetragene Kalender vergisst, die sich erst durch einen Neustart wiederfinden lassen. Das brachte mich in den vergangenen Tagen an den Rand des Wahnsinn. Der Bug ist in neueren Akonadi/Kontact Versionen behoben, aber dem Kubuntu-Team scheint der Wille oder die Fähigkeit zu fehlen die Fehlerbehebung zurück zu portieren.

Neuere STS Releases kommen leider nicht in Frage. Das Subnotebook soll einfach nur funktionieren und mich nicht alle Nase lang alle paar Monate mit Distributionsupgrades nerven. Deshalb ja schließlich auch die Idee mit der LTS. OpenSUSE 13.2, das bei mir einen sehr guten Eindruck hinterlassen hat kommt aus selbigem Grund leider auch nicht in die nähere Auswahl. Also muss es wohl Debian werden. Das Release von Jessie steht kurz bevor und der Ersteindruck im vergangenen Jahr war nicht so übel. Das KDE Team ist dort zwar auch nicht mit Manpower oder durchweg weisen Entscheidungen gesegnet, aber immerhin liegt Kontact in Version 4.14 vor. Das man mal für einen blöden Bug einen Distributionswechsel vornimmt, kommt auch nicht so oft vor, aber bei einem zentralen Werkzeug für Kontact geht man über Leichen.

Die Softwarezusammenstellung: Ein verspäteter Aprilscherz?

Leider ist dem Notebook in der letzten Woche immer noch kein Ethnernet-Port gewachsen. Ein Netinstall fiel deshalb scheinbar flach. Debian bietet aber zum Glück mehr als genug Installationsmedien, die DVD 1 sollte das notwendigste abdecken. Seit Jessie kann man in der Installationsroutine auch die Desktopumgebung ohne schmutzige Tricks auswählen. Mal schauen was Debians KDE Team dem Nutzer so andient. Die Installationsroutine verrät schon mal, dass es ca. 1 300 Pakete werden. Also ein ähnlicher Umfang wie eine Kubuntu-Installation. Nach dem obligatorischen Neustart und einem Blick in die Paketliste, sowie des Startmenüs fällt es einem schwer die Zusammenstellung zu beschreiben. Genau genommen wäre eine subjektive Beschreibung hier gerade gefährdend für alle Altersgruppen.

Debians KDE Team ist wohl der Meinung, dass man drei Werkzeuge zur Drucker-Verwaltung braucht, Super-Karamba schön an KDE 3.5 erinnert, Kopete ein zeitgemäßerer IM-Client ist und kdesudo nicht schlecht wäre – obwohl Debian das von Haus aus nicht braucht.

Liebes Debian KDE Team. Apt-get ist ein super Werkzeug für die Paketverwaltung und Distributionsupgrades funktionieren bei Debian wirklich hervorragend. Scheinbar so gut, dass niemand in eurem Team in den letzten Jahren eine Neuinstallation vorgenommen hat. Jedenfalls nicht mit den normalen Installationsmedien und einer Standard-Installation. Anders kann man sich diesen Unfall nicht erklären.

Debian Netinstall ohne Ethernet Port

Mit dem System werde ich nicht glücklich. Alleine die Deinstallationsorgie braucht mehr Zeit, als eine frische Netinstallation in Anspruch nimmt. Wäre da nicht der fehlende Ethnernet-Port. Auf der Debian-Webseite versprechen die Debian-Maintainer allerdings, dass eine Netinstall (mit Einschränkungen) auch via WLAN möglich ist. Vielleicht hat sich seit den Zeiten von Lenny und KDE 3.5 doch was getan. Der Download geht bei knapp 200MB zum Glück auch schnell und selbst dd schafft es nicht sich an der Dateigröße zu verschlucken.

Die Überraschung folgt auf dem Fuße. Debians Installationsroutine (natürlich nach einbinden der unfreien firmware-Pakete) erkennt tatsächlich das WLAN und richtet es ein. Die Installation danach ist Routine, UEFI und LUKS/LVM werden zufriedenstellend eingerichtet. Bei der Task-Auswahl entscheidet man sich natürlich nur für eine Minimalinstallation. Das Softwaremuseum von oben will man schließlich kein zweites Mal auf der Festplatte sehen. #

Nach dem Neustart dann die Ernüchterung. Keine funktionierendes WLAN weit und breit. Also muss doch wpa_supplicant und ifup ran. Wenigstens ist beides in der Minimalinstallation enthalten.

Zuerst ermittelt man den WPA-PSK Hash:

§ wpa_passphrase # natürlich ohne die <>

Das Ergebnis trägt an in /etc/interfaces/network ein.

auto wlan0

iface wlan0 inet dhcp

wpa-ssid <Meine SSIS>

wpa-psk <Mein ermittelter Schlüssel>

Dann noch das WLAN aktivieren mit:

# ifup wlan0

Danach kann man wie gewohnt die notwendigen Pakete installieren. Sofern man auf den NetworkManager wechselt, muss man die Einträge in der network-Datei wieder entfernen.

Das von mir kürzlich erworbene Subnotebook macht mir immer noch sehr viel Freude. Das kann man von Kubuntu leider nicht behaupten. Nach dem Kauf musste ja schnell ein Betriebssystem installiert werden und mangels Ethernet-Port wurde es die 14.04er LTS. Neben kleinen Problemen, wie die nicht funktionierende Lautstärkesteuerung nervte mich der schlechte Pflegezustand der LTS jeden Nutzungstag ein wenig mehr. An allen Ecken und Enden finden sich Bugs, die teilweise schon seit Monaten/Jahren gemeldet sind und scheinbar keine Priorität genießen. Ganz besonders nervig ist der Akonadi-Bug, bei dem KOrganizer vollkommen unbegründet eingetragene Kalender vergisst, die sich erst durch einen Neustart wiederfinden lassen. Das brachte mich in den vergangenen Tagen an den Rand des Wahnsinn. Der Bug ist in neueren Akonadi/Kontact Versionen behoben, aber dem Kubuntu-Team scheint der Wille oder die Fähigkeit zu fehlen die Fehlerbehebung zurück zu portieren.

Neuere STS Releases kommen leider nicht in Frage. Das Subnotebook soll einfach nur funktionieren und mich nicht alle Nase lang alle paar Monate mit Distributionsupgrades nerven. Deshalb ja schließlich auch die Idee mit der LTS. OpenSUSE 13.2, das bei mir einen sehr guten Eindruck hinterlassen hat kommt aus selbigem Grund leider auch nicht in die nähere Auswahl. Also muss es wohl Debian werden. Das Release von Jessie steht kurz bevor und der Ersteindruck im vergangenen Jahr war nicht so übel. Das KDE Team ist dort zwar auch nicht mit Manpower oder durchweg weisen Entscheidungen gesegnet, aber immerhin liegt Kontact in Version 4.14 vor. Das man mal für einen blöden Bug einen Distributionswechsel vornimmt, kommt auch nicht so oft vor, aber bei einem zentralen Werkzeug für Kontact geht man über Leichen.

Die Softwarezusammenstellung: Ein verspäteter Aprilscherz?

Leider ist dem Notebook in der letzten Woche immer noch kein Ethnernet-Port gewachsen. Ein Netinstall fiel deshalb scheinbar flach. Debian bietet aber zum Glück mehr als genug Installationsmedien, die DVD 1 sollte das notwendigste abdecken. Seit Jessie kann man in der Installationsroutine auch die Desktopumgebung ohne schmutzige Tricks auswählen. Mal schauen was Debians KDE Team dem Nutzer so andient. Die Installationsroutine verrät schon mal, dass es ca. 1 300 Pakete werden. Also ein ähnlicher Umfang wie eine Kubuntu-Installation. Nach dem obligatorischen Neustart und einem Blick in die Paketliste, sowie des Startmenüs fällt es einem schwer die Zusammenstellung zu beschreiben. Genau genommen wäre eine subjektive Beschreibung hier gerade gefährdend für alle Altersgruppen.

Debians KDE Team ist wohl der Meinung, dass man drei Werkzeuge zur Drucker-Verwaltung braucht, Super-Karamba schön an KDE 3.5 erinnert, Kopete ein zeitgemäßerer IM-Client ist und kdesudo nicht schlecht wäre – obwohl Debian das von Haus aus nicht braucht.

Liebes Debian KDE Team. Apt-get ist ein super Werkzeug für die Paketverwaltung und Distributionsupgrades funktionieren bei Debian wirklich hervorragend. Scheinbar so gut, dass niemand in eurem Team in den letzten Jahren eine Neuinstallation vorgenommen hat. Jedenfalls nicht mit den normalen Installationsmedien und einer Standard-Installation. Anders kann man sich diesen Unfall nicht erklären.

Debian Netinstall ohne Ethernet Port

Mit dem System werde ich nicht glücklich. Alleine die Deinstallationsorgie braucht mehr Zeit, als eine frische Netinstallation in Anspruch nimmt. Wäre da nicht der fehlende Ethnernet-Port. Auf der Debian-Webseite versprechen die Debian-Maintainer allerdings, dass eine Netinstall (mit Einschränkungen) auch via WLAN möglich ist. Vielleicht hat sich seit den Zeiten von Lenny und KDE 3.5 doch was getan. Der Download geht bei knapp 200MB zum Glück auch schnell und selbst dd schafft es nicht sich an der Dateigröße zu verschlucken.

Die Überraschung folgt auf dem Fuße. Debians Installationsroutine (natürlich nach einbinden der unfreien firmware-Pakete) erkennt tatsächlich das WLAN und richtet es ein. Die Installation danach ist Routine, UEFI und LUKS/LVM werden zufriedenstellend eingerichtet. Bei der Task-Auswahl entscheidet man sich natürlich nur für eine Minimalinstallation. Das Softwaremuseum von oben will man schließlich kein zweites Mal auf der Festplatte sehen. #

Nach dem Neustart dann die Ernüchterung. Keine funktionierendes WLAN weit und breit. Also muss doch wpa_supplicant und ifup ran. Wenigstens ist beides in der Minimalinstallation enthalten.

Zuerst ermittelt man den WPA-PSK Hash:

§ wpa_passphrase # natürlich ohne die <>

Das Ergebnis trägt an in /etc/interfaces/network ein.

auto wlan0

iface wlan0 inet dhcp

wpa-ssid <Meine SSIS>

wpa-psk <Mein ermittelter Schlüssel>

Dann noch das WLAN aktivieren mit:

# ifup wlan0

Danach kann man wie gewohnt die notwendigen Pakete installieren. Sofern man auf den NetworkManager wechselt, muss man die Einträge in der network-Datei wieder entfernen.

9. April 2015

Neues aus der Mozilla Design-Schmiede. Unter diesem Titel wird in regelmäßigen Abständen über aktuelle Mockups, Design-Experimente und Ähnliches berichtet. Manches davon wird in dieser oder ähnlicher Form sicher den Weg in ein Mozilla-Produkt finden, anderes wird vielleicht nie über den Status eines Entwurfes oder Experiments hinausgehen, viele Ideen entwickeln und verändern sich über die Zeit und diese Entwicklungen werden wir in dieser offenen Serie beobachten können. Heute geht es um die Zukunft der sogenannten Awesomebar und welches Potential in der Vereinigung von Adress- und Suchleiste steckt.

Die Idee, Adress- und Suchleiste zu vereinen, ist alles andere als neu. Auch die Adressleiste von Firefox kann für Websuchen genutzt werden, die Suchleiste muss also nicht zwingend genutzt werden. Chrome ist ganz konsequent und verzichtet komplett auf eine eigene Suchleiste. Aber so richtig viel gewonnen außer etwas Platz in der Oberfläche ist durch den Verzicht auf eine Suchleiste nicht. Wirklich spannend wird es erst, wenn man die Idee weiterdenkt: Suchbegriffe vorzuschlagen schön und gut, aber wie wäre es, direkt in der Adressleiste relevante Informationen anzuzeigen? Aktuelle Mockups von Mozilla zeigen, wie das aussehen könnte.

All diese Mockups sind als Ideal abgelegt, während das folgende Mockup noch nicht ganz so weit geht, aber einen ersten Schritt darstellt. Entsprechend ist dieses Mockup als initiale Version, die sich bereits in Entwicklung befindet, abgelegt. In einem entsprechenden GitHub-Repository kann auch schon die Entwicklung eines Prototyps beobachtet werden.

Ein weiteres Mockup zeigt, wie sich die sogenannte Awesomebar in Zukunft vor Eingabe eines Begriffes präsentieren könnte.

Die Neuentwicklung des Distrochoosers befindet sich nun auf der Zielgeraden. Ich möchte in diesem Beitrag zeigen, was nun die Kernunterschiede zwischen dem alten und dem neuen Distrochooser sind.

tux (1)

Statistiken

Statistiken werden grafisch aufbereitet, sodass man zum Beispiel klar erkennen kann, welche Distribution am häufigsten ermittelt wird.

Statistiken werden nun auch grafisch aufbereitet

Statistiken werden nun auch grafisch aufbereitet

Testverlauf

Es ist zu jedem Zeitpunkt möglich, die Ergebnisse des Tests auszuwerten, außerdem wird in Echtzeit die Anzahl der passenden Distributionen dargestellt.

Es ist nun möglich, jederzeit die Ergebnisse zu sehen

Es ist nun möglich, jederzeit die Ergebnisse einzusehen

Da beim alten Distrochooser häufig bemängelt wurde, dass die Entscheidungsbasis nicht erkennbar war, zeigt der neue Distrochooser eine einfache Matrix an. Dadurch ist es möglich, zu erkennen, warum das Ergebnis so ausgefallen ist.

Eine Matrix erläutert die Entscheidungsbasis

Eine Matrix erläutert die Entscheidungsbasis

Insgesamt wurde der Tests klarer und übersichtlicher entwickelt. So ist es auch möglich, Fragen zu überspringen, ohne den Überblick zu verlieren.

Es ist nun klar erkennbar, welche Frage beantwortet wurde und welche nicht

Es ist nun klar erkennbar, welche Frage beantwortet wurde und welche nicht

Um den Benutzer nicht mit einer Informationsflut zu belasten, gibt es für jede Distribution einzelne Detailseiten, die weiterführende Informationen bereitstellen.

Jede Distribution verfügt nun auch über einen Link, der auf eine Detailseite verweist

Jede Distribution verfügt nun auch über einen Link, der auf eine Detailseite verweist

Die Detailseite bietet weiterführende Infos zu der Distro

Die Detailseite bietet weiterführende Infos zu der Distro

Die Mobile Ansicht wurde deutlich optimiert.

Für die Mobilansicht wurde eine Navigationsleiste hinzugefügt

Für die Mobilansicht wurde eine Navigationsleiste hinzugefügt

Social Media

Es ist nun auch möglich, das eigene Ergebnis zu teilen.

Es ist erstmals möglich, auch das Eigene Ergebnis zu teilen

Es ist erstmals möglich, auch das Eigene Ergebnis zu teilen

Innere Werte

Der alte Distrochooser erkannte die Distributionen durch eine ungefähre Übereinstimmung. Das bedeutete auch, dass es Kombinationen gab, die schlicht unmöglich waren (z. B. Arch Linux und apt-get als Paketmanager). Der neue Distrochooser versucht zunächst, zu 100 % passende Distributionen zu ermitteln. Würde diese Suche jedoch kein Ergebnis zu Tage fördern, würden keine Distributionen geliefert. Daher liefert auch der neue Distrochooser eine ungefähre Übereinstimmung, wenn keine absoluten Treffer möglich waren. In diesem Falle wird neben einem Hinweis auch eine prozentuale Übereinstimmung dargestellt. Genaue Informationen, warum welche Distribution vorgeschlagen wird, liefert dann die Ergebnismatrix.

Es wird klar dargestellt, wenn relative Übereinstimmungen geliefert werden

Es wird klar dargestellt, wenn relative Übereinstimmungen geliefert werden

Außerdem ist der neue Distrochooser HTML5 valide.

Was fehlt jetzt noch?

Feinschliff & die ein oder andere Frage überarbeiten…

Auf meinem Ubuntu 14.04 Server hat sich folgende Fehlermeldung immer wieder in den Log Dateien gefunden:

no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory

Der Ursprung liegt im Zusammenspiel von Samba mit der lokalen Benutzerverwaltung. Interessanter weise kam die Fehlermeldung vom Dovecot auth-worker Dienst, was die Suche etwas erschwert hat.
Als Lösung habe ich folgenden Weg gefunden:

apt-get remove libpam-smbpass

Damit entferne ich das Modul welches die Samba Kennwörter abgleicht.
Das Problem ist damit behoben.


8. April 2015

Wie immer gab es zum Humble Indie Bundle 14 ein kleines Update, in dem drei weitere Spiele hinzugefügt wurden.

In 140 von Carlsen Games übernimmt man die Rolle eines Kreises (während der Bewegung), Dreiecks (beim Sprung) und Quadrats (beim Stillstand) und versucht verschiedene Level zu durchqueren, die sich im Takt der Musik verändern. Die Grafik ist sehr spartanisch, aber es ist ein nettes Denk-Jump'n'Run.

Mirror Moon von Santa Ragione habe ich leider nicht verstanden. Man erwacht in einem Raumschiff und drückt dort rote Knöpfe, wodurch man auf einem Mond landet. Dort wird man mit einer Kanone ausgerüstet, die einen anderen Planet am Himmel rotieren oder gar festhalten kann. So richtig habe ich aber nicht verstanden, was ich da tue.

Und Contraption Maker von Spotkin erwartet leider OpenGL 1.5 und ich habe nur OpenGL 1.4.2, sodass das Spiel bei mir leider nichts tut. Schade aber auch. Es handelt sich dabei um einen inoffiziellen Nachfolger von „The Incredible Machine“, was früher viel Spaß machte.

140
140
Mirror Moon
Mirror Moon

Zu „Shadow Warrior“ gab es zwar auch ein Update, aber leider poppt bei mir nach wie vor der Pause-Bildschirm auf, nachdem ich das Spiel starten will und geht auch nicht mehr zu.

Ich habe mich nich ohne Grund kürzlich auf die Suche nach einem simplen Web-Framework gemacht, wobei ich wie kürzlich erwähnt auf web.py gestoßen bin. Gebaut habe ich mir ein kleines Webinterface für Wake On Lan. So etwas lässt sich zwar auch einfacher mit wenigen Zeilen PHP, exec() und der Anwendung wol oder etherwake erledigen, aber man kann es auch anders machen.

Die kleine Webanwendung läuft bei mir auf einem RaspberryPi und dient im Moment nur dazu, zum Einschalten eines Rechners nicht aufstehen zu müssen. Eine einfache Benutzerverwaltung zu implementieren wäre noch sinnvoll, dann könnte ich die Anwendung auch aus dem Internet erreichbar machen. Bis dahin würde auch eine Basic Authentication ausreichen, aber bevor ich darüber nachdenke, sollte ich zuerst die Eingaben in der Anwendung vernünftig validieren.

Nichtsdestotrotz ist eine lauffähige Anwendung mit web.py entstanden, die dank Bootstrap sogar halbwegs modern aussieht. Hosts können mit einem beliebigen Hostnamen und der MAC-Adresse eingetragen werden. Sollten sich die Rechner nicht im gleichen Netz wie der Webserver mit der Anwendung befinden, kann optional noch die IP Adresse des Rechners angegeben werden. In Aktion sieht es dan so aus:

Übersichtsseite

webWOL_overview

Host hinzufügen

webWOL_add

Hosts bearbeiten oder löschen

webWOL_editlist

Einen Host bearbeiten

webWOL_edithost

Wer sich das Ganze mal ansehen möchte, kann dies bei GitHub tun.

Es existieren viele Programmiersprachen und Frameworks, mit denen sich Webnwendungen und Webseiten erstellen lassen. Die eierlegende Wollmilchsau gibt es natürlich auch hier nicht, aber meiner Meinung nach existieren gerade bei den JavaScript Frameworks einige Lösungen, die nah dran kommen. Da JavaScript inzwischen irgendwie gruselig mächtig geworden ist, habe ich ein simples Webanwendungs-Framework ohne JavaScript-Notwendigkeit gesucht. Gefunden habe ich web.py.

Das Framework

web.py ist, wie der Name schon vermuten lässt, ein Python Framework. Es sticht durch seine Einfachheit und teilweise recht geringe Abstraktion hervor. Die Entwicklung einer Webanwendung mit web.py zeichnet sich dadurch aus, dass man vom Framework nicht viel spürt und Python tatsächlich als Programmiersprache nutzt und nicht nur zum Handhaben der Objekte des Frameworks. web.py gibt einem ein einfaches URL-Mapping an die Hand und gibt gewisse Strukturen vor, mit denen GET/POST/PUT/DELETE Anfragen bearbeitet werden können. Das Rendering geschieht natürlich auch serverseitig und wird durch die Template-Engine Templetor unterstützt, womit einfache HTML Templates verwendet und mit ein wenig Logik versehen werden können.

Für komplexe und vor allem zeitgemäße Webanwendungen würde ich zu einem anderen Framework oder zumindest zum Einsatz von ein wenig JavaScript bzw. jQuery raten. Möchte man aber nur mal schnell ein paar Daten einer Datenbank im Webbrowser darstellen oder eine kleine Anwendung erstellen, die auch gut ohne JavaScript auskommt, dann kann man sich web.py ansehen. Mit web.py muss man sich zwar um vieles selbst kümmern, ist dadurch aber auch sehr flexibel.

Apache Integration

web.py bringt auch die Möglichkeit mit, einen integrierten Webserver zu starten oder alternativ bestehende Webserver zu verwenden. Ich habe mich für die Ausführung der web.py Anwendung durch den Apache Webserver mit dem Modul mod_wsgi entschieden. Bei den meisten Installation ist das Modul vielleicht schon geladen und aktiv, überprüfen kann man dies recht schnell, indem man sich die momentan geladen Module ansieht:

apachectl -M | grep wsgi

Dort sollte das wsgi_module nun erscheinen. Ansonsten kann dies nachinstalliert werden:

# Debian / Ubuntu
apt-get install libapache2-mod-wsgi
# CentOS / Fedora
yum install mod_wsgi

Nach einem Neustart des Apache Servers ist das Modul verfügbar. Eine simple VirtualHost-Konfiguration, die alle Aufrufe, mit Ausnahme des Verzeichnisses

/static
, an die web.py Anwendung weitergibt, kann so aussehen:
<VirtualHost *:80>
        ServerAdmin foobar@example.org
        ServerName foobar

        WSGIScriptAlias / /var/www/code.py
        # Unter /static können statische Inhalte ausgeliefert werden
        Alias /static   /var/www/wol/static

        ErrorLog ${APACHE_LOG_DIR}/error.log
        LogLevel warn
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        <Directory /var/www>
            # Während der Entwicklung sinnvoll, da Scripte sonst aus dem Cache geladen werden könnten.
            WSGIScriptReloading On
        </Directory>
</VirtualHost>

Hello World

Hiermit lässt sich das “Hello World” Beispiel, nun leicht modifiziert, mit dem Apache ausführen:

#!/usr/bin/env python
import web

urls = (
    '/(.*)', 'hello'
)
app = web.application(urls, globals())

class hello:        
    def GET(self, name):
        if not name: 
            name = 'World'
        return 'Hello, ' + name + '!'


app = web.application(urls, globals(), autoreload=True)
application = app.wsgifunc()

Einfach und praktisch. Meine erste kleine Anwendung ist bereits auch fertig. Dabei habe ich aber festgestellt, dass die Dokumentation von web.py weder vollständig noch gepflegt ist und man oft mehr herumprobiert als nachdenkt. Auch könnte das Templating besser sein, u.a. scheint das HTML der Formulare ziemlich in Stein gegossen zu sein. Man müsste wohl die entsprechende Klasse überschreiben, um des gewünschte Ergebnis zu erhalten, aber genau das ist eben web.py. Eine scheinbar aktuellere Alternative wäre dann wohl CherryPy, ein ebenfalls minimalistisches Python Framwork. Die Integration in den Apache ist ebenfalls vergleichbar.

Guideline für Open Source Software

 SLIDES

  1. Was ist Open Source Software?
    1. Geschichte
    2. Freie Software Open Source Software
    3. Lizenzen
    4. Geschäftsmodelle
  2. Wo veröffentliche ich Open Source Software?
  3. Welche Open Source Software Standards gibt es?
    1. Lizenz
    2. Quellcode-Organisatzion
    3. Dokumentation
    4. Kommunikation
    5. Versionsnummern
    6. Abhängigkeitsmanagement
    7. Testabdeckung
    8. Issue-Tracking-System
  4. Wie veröffentliche ich Open Source Software?
    1. Beispiel: npm
    2. Beispiel: bower
    3. Beispiel: composer
  5. Beispiel-Repository

1. Was ist Open Source Software?

Freiheit 0: Das Programm zu jedem Zweck auszuführen.

Freiheit 1: Das Programm zu untersuchen und zu verändern.

Freiheit 2: Das Programm zu verbreiten.

Freiheit 3: Das Programm zu verbessern und diese Verbesserungen zu verbreiten, um damit einen Nutzen für die Gemeinschaft zu erzeugen.

1.1 Geschichte

1893: AT&T wird gegründet

1911: IBM wird gegründet

1969: AT&T beginnt mit der Entwicklung eines quelloffenes Betriebssystem – Unix

1972: Dennis Ritchie veröffentlciht die Programmiersprache C

1975: Microsoft wird von Bill Gates und Paul Allen gegründet

1976: Apple wird von Steve Jobs, Steve Wozniak und Ron Wayne gegründet

1977: Universität von Kalifornien in Berkeley entwickelt einen Fork von Unix BSD

1980: Unix wird proprietär

1981: 86-DOS wird von Microsoft gekauft und an IBM verkauft ~ MS-DOS

1984: Richard Stallman beginnt mit der Entwicklung eines freien Betriebssystems – GNU

1985: Richard Stallman gründet eine gemeinnützliche Organisation Free Software Foundation

1985: NeXT wird von Steve Jobs gegründet

1987: IBM und Microsoft veröffentlichen ein proprietäres Betriebssystem – OS/2

1987: Andrew S. Tanenbaum Minix veröffentlichen ein freies Betriebssystem – Minix

1988: MIT-Lizenz wird veröffentlicht

1988: NeXT, Inc. veröffentlicht ein proprietäres Betriebssystem, ein Fork von BSD – NeXTStep

1989: Richard Stallman schreibt eine Lizenz für Freie Software: GNU General Public License

1991: Linus Torvalds entwickelt einen freien Kernel – Linux

1993: Ian Murdock beginnt mit der Entwicklung eines freien Betriebssystems – Debian (GNU/Linux)

1993: Open-Source-Community veröffentlicht ein freies unixoides Betriebssystem – FreeBSD 1.0

1993: Microsoft veröffentlicht ein proprietäres Betriebssystem – Microsoft_Windows_3.1

1995: Rasmus Lerdorf entwickelt eine Skriptsprache für Webanwendungen PHP

1995: Sun Microsystems entwickelt eine objektorientierte Programmiersprache Java

1995: Netscape entwickelt eine Skriptsprache für Client-Webanwendungen – JavaScript

1996: erste Version des Betriebssystems Debian wird veröffentlichtDebian 1.1 (GNU/Linux)

1998: Goolge wird von Larry Page und Sergey Brin gegründet – Google

1998: Organisation, zur Förderung von Open-Source-Software wird gegründet OSI

2000: Apple veröffentlicht ein freies unixoides Betriebssystem, einen Fork von NeXTStep (FreeBSD) – Darwin

2001: Microsoft veröffentlicht ein proprietäres Betriebssystem Microsoft Windows XP

2001: ein freies Onlinelexikon geht online Wikipedia

2001: gemeinnützliche Organisation für freie Software (Europa) wird gegründet FSFE

2001: gemeinnützliche Organisation für freie Lizenzen wird gegründente Creative Commons

2002: freie Software wird im deutschen Urhebergesetz rechtskräftig – Linux-Klausel

2003: ein freie Software zur Verwaltung von Websiten wird veröffentlicht WordPress

2005: Linux Torvalds beginnt mit der Entwicklung einer freien Versionsverwaltung – git

2008: Google Chrome (freeware) / Chromium (free) wird veröffentlicht Chrom[e|ium]

2008: Google veröffentlicht ein freies Betriebssystem – Android

2009: Joyent Inc. entwickelt freie serverseitige Plattform für Netzwerkanwendungen – NodeJS

2012: Microsoft veröffentlicht ein proprietäres Betriebssystem Microsoft Windows 8

2013: Mozilla veröffentlicht ein freies Betriebssystem – Firefox OS

2014: Open-Source-Community veröffentlicht ein freies unixoides Betriebssystem – FreeBSD 10.0

2015: Linus Torvalds veröffentlicht eine neue Version seines freien Kernels – Linux 4.0

Umsatz: Um zu verdeutlichen, wie viel Geld mit Software (Computer) verdient werden kann, auch mit Open Source Software …

Apple: 182,8 Mrd. USD (2014)
AT&T: 128,8 Mrd. USD (2013)
IBM: 92,8 Mrd. USD (2014)
Microsoft: 85,8 Mrd. USD (2014)
Google: 66 Mrd. USD (2014)
Red Hat: 1,33 Mrd. USD (2013)
Mozilla: 0,3 Mrd. USD (2013)
Canonical (Ubuntu): 0,065 Mrd. USD (2014)

1.2 Freie Software Open Source Software

Man kann „Freie Software“ als Teilmenge von „Open Source Software“ verstehen, wobei der Begriff „Open Source“ erst später eingeführt wurde, da man freie Software als geschäftsfreundlich und weniger ideologisch belastet darstellen wollte. Außerdem wollte man dem Begriffsproblem von „free software“ entgegenwirken, denn auch wenn viele freie Software kostenlos (free) ist, ist dies keine „freeware“.

Für die Definition von freier Software findet man folgenden Satz auf der GNU/GPL Webseite: To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”.

Freie Software gewährt demnach dem Nutzer Freiheiten, was bei proprietärer Software nicht der Fall ist: z.B.:

https://govtrequests.facebook.com/: Hier kann man nachlesen, wie viele Anfragen die entsprechenden Regierungen an Facebook gestellt haben, um an unsere Informationen zu kommen oder uns bestimmte Informationen vorzuenthalten.

http://www.heise.de/newsticker/meldung/Amazon-loescht-gekaufte-Kindle-eBooks-6887.html: Hier hat Amazon Kindle-eBooks („1984“ und „Animal Farm“ von George Orwell) von extern gelöscht, da der Verkäufer die nötigen Rechte zum verkaufen gar nicht besaß.

http://blogs.technet.com/b/mmpc/archive/2014/01/09/tackling-the-sefnit-botnet-tor-hazard.aspx: Hier wurde ebenfalls Software von extern gelöscht – Microsoft löscht Tor-Software nach Trojaner-Befall.

1.3 Lizenzen

Es gibt es mittlerweile (zu) viele verschiedene Open Source Lizenzen und Lizenz-Versionen, welche teilweise nicht einmal miteinander kompatibel sind, so z.B. bei GPLv2 und GPLv3 welche man nicht gemeinsam in einem Programm nutzen darf: https://www.gnu.org/philosophy/license-list.html

Allgemein kann man die verschiedenen Open Source Lizenzen jedoch in folgende Kategorien einteilen: Copyleft / Copyright

softwaremodels

Copyleft ist eine Form von freier Software, bei der die Freiheit des Endanwenders hervorgehoben wird und die Freiheit der Programmierer hinten anstellt, so kann (darf) man z.B. „Google APIs Client Library for PHP“ nicht für WordPress-Plugins verwenden, da diese Bibliothek nicht mit GPL kompatibel ist.

quick-guide-gplv3-compatibility.de

Art des Copyleft

Starkes Copyleft

Schwaches Copyleft

kein Copyleft

Kombinationsmöglichkeit
mit proprietärer Software

keine Einbindung in proprietären Code möglich

statisches und dynamisches Linken von Code mit proprietärer Software möglich. Eigen-Entwicklungen dürfen als proprietäre Software weitergegeben werden

darf auch in proprietäre Software verwendet werden

Beispiel-Lizenz

GPL

LGPL, MPL

BSD, Apache, MIT

1.4 Geschäftsmodelle

Beispiele:

– Adobe Systems veröffentlicht Flex (Apache License 2.0) und verkauft die Flash Builder IDE.
– Apple Inc. veröffentlicht Darwin (Apple Public Source License) und verkauft Mac OS X.
– Asterisk (PBX), verkauft Hardware auf welcher Open Source Software (GPL) läuft.
– Codeweavers verkauft CrossOver (proprietär + LGPL) und nutzt dafür als Grundlage Wine (LGPL)
– Canonical Ltd. bietet Ubuntu als Open Source an und bietet technischen Support gegen Zahlung an.
– Mozilla Foundation lässt sich von Google, Yahoo und anderen Unternehmen bezahlen, um z.B. die entsprechende Suchmaschine in Mozilla Firefox zu integrieren.
– Oracle bietet MySQL als Open Source Version (GPL) und als Enterprise Version (proprietär) mit Support und zusätzlichen Features an.

2. Wo veröffentliche ich Open Source Software?

Allein durch die Veröffentlichung von Quellcode entsteht zur noch keine Open Source Software, aber es bleibt die Grundvoraussetzung. Mittlerweile gibt es viele Plattformen, welche sich auf Quellcode-Repositories spezialisiert haben, dabei hat man sich inoffiziell bereits darauf geeinigt, dass „github.com“ als Standard für Open Source Software angesehen wird. Sowohl npm, composer als auch bower nutzen github.com als Standard-Repository.

3. Welche Open Source Software Standards gibt es?

Unix ist der Ursprung von Open Source und die Unix-Philosophie von ~1970 lässt sich noch immer auf heutige Software Projekte anwenden: „Mache nur eine Sache und mache sie gut.

– Schreibe Computerprogramme so, dass sie nur eine Aufgabe erledigen und diese gut machen. (Packages?)
– Schreibe Programme so, dass sie zusammenarbeiten. (REST?)
– Schreibe Programme so, dass sie Textströme verarbeiten, denn das ist eine universelle Schnittstelle. (JSON?)

Es gibt viele inoffizelle Standards bei Open Source Projekten, welche ggf. jedoch auch erst von der Community erstellt oder / und überhaupt erst im laufe des Projektes erstellt werden.

3.1 Open Source Lizenz für Software angeben (z.B.: LICENSE.txt)
     – kann man verwenden: GPL, LGPL, MIT, BSD3
     – sollte man ggf. vermeiden: Creative Commons, Beerware, WTFPL
     – CLA (Contributor License Agreement) beachten: z.B.: Zend Framework 1

3.2 Quellcode Organisatzion (z.B. „src/“, „tests/“, „lib/“)
     – Wie heißt das Verzeichnis für Tests?
     – Wo findet man die Abhänigkeiten (vendor)?
     – Wo findet man den Quellcode?

3.3 Dokumentation für Entwickler und Anwender
     – Beschreibung, Code-Beispiele, Testabdeckung, Version, Lizenz, … (z.B.: README.md)
     – Wie man mithelfen kann (z.B.: CONTRIBUTING.md)
     – Anwender-Dokumentation (nicht im Code-Repository), z.B.:
          – Beschreibung mit Beispielen / Bildern / Demos
          – Wie man Bugs melden sollte (yourbugreportsucks.com / Beispiel)
     – Entwickler-Dokumentation (nicht im Code-Repository), z.B.:
          – Wie man den Quelltext herunterlädt
          – Wie ist die Verzeichnis-Strucktur des Projektes
          – Wie installiert man das Build-System / Wie nutzt man das Build-System
          – Wie führt man die entsprechenden Tests aus
          – Wie sieht der Code-Style aus (z.B.: google-styleguide)

3.4 Plattform für Fragen und Kommunikation, z.B.:
    – Mailingliste / Forum
    – Stack Overflow
    – gitter.im
    – groups.google.com

3.5 Versionsnummern korrekt verwenden
     – Semantic Versioning via MAJOR.MINOR.PATCH
          – MAJOR: Hauptversion, wenn die API geändert wird
          – MINOR: neue Funktionen, welche keine API-Änderungen hervorrufen
          – PATCH: bei abwärtskompatibelen Bugfixes
     – Tag-Versionen in der Quellcodeverwaltung nutzen (z.B. git tag)
     – ggf. einen Changelog schreiben (z.B.: CHANGELOG.md)
     – Abhängigkeiten definieren (z.B.: package-versions with composer)

3.6 Abhängigkeitsmanagement für verwendete Bibliotheken nutzen, z.B.:
     – PHP: Composer (packagist.org)
     – JS / Node.JS: npm
     – HTML / CSS / JS: bower

3.7 Testabdeckung und automatische Tests bei jeder Änderung
     – Unit-Tests / BDD / TDD, z.B.:
          – PHP: PHPUnit / phpspec
          – JavaScript: mocha, Jasmine, qUnit
     – Frontend-Testing, z.B.:
          – CasperJS / DalekJS / Selenium
     – automatisierte Tests
          – Travis CI (Linux)
          – AppVeyor (Windows)

3.8 Issue-Tracking-System zur Verwaltung von Bugs verwenden
     – z.B.: github – Issue-Tracking aktivieren
     – Übersicht über Fehler und wer diese fixed
     – „Gruppenzwang“, da das Issue-Tracking für jeden einsehbar ist

3.9 Contributor-Model bei größeren Projekten, z.B.: yui3

4. Wie veröffentliche ich Open Source Software?

4.2 Beispiel: npm

# Installation von node.js, z.B.:
sudo apt-get install nodejs

# Konfiguriere npm
npm set init.author.name "Lars Moelleken"
npm set init.author.email "lars@moelleken.org"
npm set init.author.url "http://moelleken.org"

# npm User erstellen (~/.npmrc)
npm adduser

# interaktiv eine „package.json“-Datei erstellen
npm init

# Abhänigkeiten & Tests hinzufügen
npm install mocha --save-dev
npm install chai --save-dev

# Veröffentliche dein Paket
npm publish

4.2 Beispiel: bower

# Installation von node.js, z.B.:
sudo apt-get install nodejs

# Installation von bower
npm install -g bower

# interaktiv eine „bower.json“-Datei erstellen
bower init

# Veröffentliche dein Paket
bower register <my-package-name> <git-endpoint>

4.3 Beispiel: composer

# Installation von composer, z.B.:
curl -sS https://getcomposer.org/installer | php

# interaktiv eine „composer.json“-Datei erstellen
composer init

# Veröffentliche dein Paket
https://packagist.org/packages/submit

5. Beispiel-Repositories

https://github.com/voku/node-lettering

https://github.com/voku/bower-lettering

Quellen / Links:

– eine Liste von offiziellen „Open Source“ Lizenzen: http://opensource.org/licenses/alphabetical

– eine Liste von Programmiersprachen und deren Lizenzen: http://en.wikipedia.org/wiki/List_of_open-source_programming_languages

Gespräch: Unterstützen von Open Source Projekten: https://www.radiotux.de/index.php?/archives/7995-RadioTux-Sendung-Maerz-2015.html

– Support for Open-Source Software: https://www.bountysource.com/

– Easy Pick (einfach zu behebende Bugs) -> z.B.: https://github.com/symfony/symfony/issues?q=is%3Aopen+is%3Aissue+label%3A%22Easy+Pick%22

– Help your favorite open source projects: http://www.codetriage.com/

Statistik über freie Lizenzen auf github: http://ostatic.com/blog/the-top-licenses-on-github

– Erklärung zu freie Lizenzen: http://www.webmasterpro.de/management/article/freie-lizenzen.html

A Beginner’s Guide to Creating a README: https://thechangelog.com/a-beginners-guide-to-creating-a-readme/

Starting An Open-Source Project: http://www.smashingmagazine.com/2013/01/03/starting-an-open-source-project/

qUnit vs Jasmine vs Mocha: http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/

Which programming language has the best package manager?http://blog.versioneye.com/2014/01/15/which-programming-language-has-the-best-package-manager/

– Erstelle Packages via bower: http://bower.io/docs/creating-packages/

Open-Source-Lizenzen: http://www.heise.de/open/artikel/Open-Source-Lizenzen-224724.html

Think about the license! http://lucumr.pocoo.org/2009/2/12/are-you-sure-you-want-to-use-gpl/

– Linus Torvalds says GPL v3 violates everything that GPLv2 stood for: https://www.youtube.com/watch?v=PaKIZ7gJlRU

GNU – Free Software: https://www.gnu.org/philosophy/free-sw.en.html

GNU/GPL: https://www.gnu.org/copyleft/gpl.html

GNU/Packages: http://www.gnu.org/manual/blurbs

FreeBSD über Vor- und Nachteile von GPL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/gpl-advantages.html

– Geschäftsmodelle für Open-Source: http://t3n.de/magazin/geschaftsmodelle-open-source-unternehmer-welche-ansatze-221154/

– Open-Source-Finanzierung (Podcast): http://chaosradio.ccc.de/cr209.html

7. April 2015

Mein neues Netbook ist ein Chromebook! Die Suche nach einem ordentlichen Nachfolger für meinen EeePC war gar nicht so einfach. Am Ende wurde ich fündig, wo ich die Lösung zuletzt vermutet hätte: Bei Google.

Auf meinem alten EeePC hatte ich ernsthaft im Betrieb: Alle Ubuntu-Versionen seit 9.10, Moblin, Jolicloud, Android und zuletzt Elementary OS – dazu kommt mindestens noch einmal die gleiche Menge Linux-Derivate, die nicht so lange gehalten haben. Zusätzlich habe ich den EeePC mit Speicher nachgerüstet und die Festplatte gegen eine SSD ausgetausch. So ein Gerät wollte ich wieder haben: Eines, das wirklich mir gehört, mit dem ich machen kann, was ich will.

In der Elementary OS-Community bekam ich den Hinweis, dass das Acer C7 Chromebook eine gute Hardware für Elementary OS sei: Man kann mittels Skripten Ubuntu oder Elementary OS neben ChromeOS installieren. Man kann aber auch das BIOS mit Coreboot flashen und dann mit dem Notebook wirklich machen, was man will. Den Speicher kann man aufrüsten und die Festplatte wechseln. Zusätzlich ist das Gerät noch günstig bei Ebay zu bekommen.

Erste Experimente

Nachdem das C7 endlich per Post ankam, habe ich mir zunächst ChromeOS angeschaut. Das Betriebssystem von Google macht alles über den Browser und alles über die Dienste von Google. Ein echtes Cloud-System. Statt Programme, kann man die Apps aus dem Chrome-Store verwenden. Und die Tastatur des Geräts ist voll auf das Chrome OS ausgerichtet. Die Windows-Taste zum Beispiel ist hier eine Lupe, die zur Suchfunktion führt.

Ich habe aber keine Lust, alles über Google abzuwickeln. Also Chrubuntu installiert. Über das Script ist das nur eine Frage der Zeit. Können muss man dazu nichts. Nach der Installation hat man ein voll funktionierendes, aktuelles Ubuntu.

Das Problem: Man muss das Chromebook in den Developer-Modus versetzen, damit es das unbekannte Betriebssystem startet. Wenn man bei Start allerdings aus versehen die Leertaste drückt – wie es da steht, dann repariert sich ChromeOS und Ubuntu ist weg. Das war mir zu blöd. Das fühlt sich an, als wäre man nur Gast auf dem eigenen Laptop. Also musste ich das BIOS flashen.

Freies BIOS: Coreboot/SeaBIOS

Coreboot ist ein freies BIOS, das ohnehin schon auf dem Chromebook läuft. Allerdings in einer Variante, die ebenfalls voll auf ChromeOS ausgerichtet ist. Auch für das Flashen des BIOS‘ gibt es ein Script, das alles Nötige erledigt. Nervös hat mich da gemacht, dass man das Chromebook damit auch „bricken“ kann. Und dem Script muss man mit dem Abtippen eines ganzen Satzes bestätigen, dass man den Entwickler nicht dafür verantwortlich macht, wenn das passiert. Laut Homepage ist das allerdings vor über einem Jahr zum letzten Mal passiert. Das wiederum hat mich beruhigt.

Um das BIOS zu flashen muss man das Laptop aufschrauben und einen Jumper setzen. Dazu muss man das Garantiesiegel kaputt machen – kein Problem, das hatte ich ohnehin schon tun müssen, um den Speicher von 2GB auf 8 GB aufzurüsten. Da dann meine Jumper alle nicht passten, habe ich ein kleines Stück Alufolie in die Jumperhalterung gesteckt.

Nach einige Minuten war das erfolgreich BIOS geflasht und das Netbook startet neu mit einer Meldung von SeaBIOS. Coreboot kümmert sich nämlich nur um die aller grundlegensten Funktionen und lädt dann ein richtiges BIOS, das dann das Betriebssystem startet.

Die Systemfrage

Nur war natürlich keines der beiden Betriebssysteme auf dem Rechner so installiert, dass es jetzt noch startet. Der Vorteil der Situation jetzt: Man kann ganz einfach jedes Betriebsystem installieren – so wie es früher war. Es soll sogar Leute geben, die Windows installieren.

Ich habe mir dann erst einmal die aktuelle Beta von Elementary OS Freya installiert. Immerhin hatte das Betriebsystem auf dem EeePC gute Dienste geleistet und dabei auch noch gut ausgesehen.

Leider habe ich das Touchpad nicht zum Laufen bekommen. Im mitgelieferten Kernel sind die nötigen Treiber noch nicht enthalten und ich habe es auch mit Kernel-Updates nicht hinbekommen. Das Gleiche Problem hatte ich mit der aktuellen Version von Ubuntu und der Beta von 15.04.

Ich habe dann gedacht, ich sollte erst einmal ausprobieren, ob ich das Touchpad bei der Operation nicht aus Versehen geschrottet hatte. Mit Android sollte die Google-zertifizierte Hardware eigentlich funktionieren. Leider hing die Installation und Android lies sich nicht einmal komplett installieren.

Irgendjemand müsste doch mal einen Chromebook-Remix irgendeines Betriebssystems gemacht haben dachte ich mir und machte mich auf die Suche und wurde fündig: Von Bodhi-Linux gibt es einen Chromebook-Remix. Leider ist Bodhi nicht wirklich schön. Ich hätte damit nur gerne das Touchpad einmal ausprobiert. Auch Bodhi zeigte mir ewig nur das sich drehende Logo – installierte aber nicht.

Also der nächste Versuch: Auf Google Plus folge ich seit einiger Zeit dem Ozon OS – einem Fedora-Derivat, das sich zum Ziel gesetzt hat, besonders chic zu werden. Nun gab es vor Kurzem die erste Beta und die wollte ich nun ausprobieren. Und siehe da: Zum Einen was das endlich auch mal wieder ein System, das sich auch installieren ließ und zum Zweiten ging das Touchpad! Ein voll funktionstüchtiges Betriebssystem.

Klingt kompliziert? Ist es aber nicht, wenn man es richtig herum macht und nicht so viel experimentieren muss, wie ich:

  1. ChromeOS in den Developer-Modus versetzen.
  2. Im Terminal das Skript für Coreboot laden und damit das BIOS flashen. Danach kann man beliebige Betriebssysteme per USB-Stick installieren
  3. Ein Betriebsystem installieren, das einen möglichst aktuellen Kernel mitbringt. OzonOS lief zum Beispiel direkt problemlos.

Das Laptop war jetzt knapp zwei Tage alt, hatte neuen Speicher und ein neues BIOS bekommen und schon ein halbes Dutzend Betriebssysteme gesehen. Nur die SSD passt leider nicht. Da muss ich mir ein flacheres Modell suchen. Kurz: Ich bin rundum zufrieden mit meinem neuen Notebook.

6. April 2015

nginx wird bekanntlich in vielen Distributionsquellen, darunter Ubuntu-basierten, in mehreren Varianten zur Installation angeboten, die alle unterschiedlich viele Module und damit Funktionen mitbringen. Die folgende Tabelle liefert einen Überblick über die Module, die in den Ubuntu 14.04 LTS Trusty-Quellen enthalten sind.

nginx -extras -full -core -light
Standard HTTP Modules:
access
auth basic
auto index
browser
charset
core
empty gif
fastcgi
geo
gzip
headers
index
limit requests
limit zone
log
map
memcached
proxy
referer
rewrite
scgi
split clients
ssi
upstream
user id
uwsgi
Optional HTTP Modules:
addition
debug
embedded perl
flv
geoip
gzip precompression
http sub
image filter
ipv6
mp4
random index
real ip
secure link
spdy
ssl
stub status
substitution
webdav
xslt
Mail Modules:
imap
mail core
pop3
smtp
ssl
Third Party Modules:
auth pam
chunkin
dav ext
echo
embedded lua
fancy index
http push
http substitution filter
httpheadersmore
nginx development kit
upload progress
upstream fair queue

Update 06.04.15: Ich habe die Liste aktualisiert und ein Python3-Script geschrieben, das diese Informationen aus einem System ausliest und in einer Tabelle darstellt.

Vielleicht kennt ihr Redshift, ein Tool, das durch anpassen der Farbtemperatur des Computerbildschirms Augenschmerzen durch zu grelles Licht in Dunkeln verhindert und die Augen schont.

Nach der Installation auf meinem Arch Linux Rechner konnte Redshift mit folgender Fehlermeldung nicht starten:

Trying location provider `geoclue2'...
Dienst »geoclue2« wird benutzt.
Unable to start GeoClue client: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Access denied.
Unable to connect to GeoClue.
Konnte Standort nicht vom Dienst erhalten.

Auf GitHub habe ich eine Lösung für das Problem gefunden: Zur Konfigurationsdatei „/etc/geoclue/geoclue.conf” wurde ans Ende der Datei einfach folgendes hinzugefügt:

[redshift]
allowed=true
system=false
users=

Beim nächsten Versuch ist Redshift gestartet und hat meinen Bildschirm rötlich gefärbt.

Seit 2013 benutze ich Pinboard. Letztens flog auf GitHub allerdings ein Commandline Bookmark Manager vorbei. Den Gedanken fand ich eigentlich total toll. Die Syntax fand ich komisch, Ausgabe sah strange aus. Aber es kam auch noch erschwerend hinzu, dass es nicht mal gebaut werden konnte. Also hab ich weiter gesucht und einen ziemlich schönen gefunden.

bm ist in Bash geschrieben, sah schön aus, einfach gestrickt. Eigentlich super. Aber auch hier liess die Bedienung etwas zu wünschen übrig. Aber da das Zeug ja Opensource ist, fork it baby.

bm Fork

Was anfangs nur ein “ja ich passe mir das Teil ein klein bisschen an” war, wurde irgendwie zum Komplettumbau.

  • Der ganze Dropbox Folder Kack ist weg
  • HTML Preview im Browser mit webkit2png ist weg
  • Title wird automatisch mit curl beim adden eines Links hinzugefügt.
  • Syntax zum Bedienen stark umgeschrieben
  • Clean Funktion entfernt
  • Datum (wann wurde der Link geadded) wird automatisch hinzugefügt.
  • Farblich / Formatsmäßig umstrukturiert.

Das Repo: github.com/noqqe/bm

Eine Lizenz würde ich dem ganzen auch gerne hinzufügen, aber da der original Autor noch keine Lizenz hinzugefügt hat, muss ich damit erstmal warten.

Migration von Pinboard

Jetzt musste ich nur noch alle >1000 Bookmarks von Pinboard umziehen. Pinboard bietet einen json Export der eigenen Bookmarks mit allen Meta Informationen an.

Diesen hab ich mir per einfacher Download Funktion lokal gespeichert und mittels dieses Python Schnipsels in das “neue” bm Format umkonvertiert.

import json

with open('dump.json') as dataf:
  data = json.load(dataf)
    for x in data:
      print x["href"]+"|"+x["tags"]+"|"+x["time"]+"|"+x["description"]

Und wenn es beim Umleiten des STDOUT mit Python wegen des Encodings nicht klappt, export PYTHONIOENCODING=utf-8 benutzen. Saugeil. Damit hatte ich immer Probleme.

Ich weiss von ein paar Leuten, dass Sie den RSS Feed meines Pinboard Profils lesen. Für den Moment wird es dort keine neuen Dinge geben. Eventuell bastle ich mich in Python ein kleines Skript dass meine Bookmarks regelmäßig in RSS giesst. Da schau ich aber erstmal.

Ich rippe meine Audio-CDs ja mittels morituri als flac auf die Festplatte. Leider kann mein Autoradio keine flac-Dateien abspielen und ich muss diese zu mp3 umkodieren. Dabei ist das Script pacpl sehr hilfreich:

pacpl --to mp3 -p -r --bitrate 320 --outdir /home/martin/mp3 /home/martin/Musik

Mit --to mp3 gebe ich das Zielformat und über --bitrate die Bitrate an. Andere Formate (flac, ogg etc.) werden also in mp3-Dateien mit 320kbps umgewandelt. Über -p (--preserve) wird festgelegt, dass die Ordnerstruktur im Zielordner, der des Quellordners entspricht. -r sorgt dafür, dass das Quellverzeichnis rekursiv durchsucht wird und alle Musikdateien umgewandelt werden, nicht nur die Dateien, die sich direkt im Quellverzeichnis befinden.

Mit diesem Befehl sorge ich also dafür, dass meine Musiksammlung unter /home/martin/Musik noch mal als mp3 unter /home/martin/mp3 abgelegt wird.

Weiter Informationen können dem UU-Wiki oder der manpage entnommen werden.

Update 2016-08-26

Später fiel mir auf, dass pacpl mir die UTF8-Kodierung innerhalb der tags kaputt gemacht hat. Mit mid3iconv aus dem Paket python-mutagen konnte ich dies folgendermaßen reparieren:

find . -name "*.mp3" -print0 | xargs -0 mid3iconv -e UTF8 -d

Für das schalten von Aktoren kann wie in einem vorangegangenen Artikel die Anwesenheitserkennung verwendet werden. Durch eine Regel wird in einem bestimmten Zeitraum geprüft ob jemand zu Hause ist und die Aktoren werden eingeschaltet. Handelt es sich bei den Aktoren jedoch um Lampen, kann es vorkommen das Diese zu früh beziehungsweise zu spät geschaltet werden. Damit das Schalten zum richtigen Zeitpunkt erfolgt, kann der jeweilige Sonnenaufgang / Sonnenuntergang berechnet werden und mit in die Regel eingebunden werden.

Ich habe mich jedoch für einen Dämmerrungssensor entschieden, diesen gibt es für das fs20 System als Bausatz von ELV. Für das löten und zusammensetzen der einzelnen Komponenten benötigt man ca. 30 Minuten. Der Sensor bietet zwei Kanäle die einzeln konfiguriert werden können. Je nach Konfiguration und Helligkeit wird ein on bzw off gesendet. Zum auslesen des voreingestellten Hauscodes hatte ich bereits den Artikel http://www.itbasic.de/openhab-fs20-fernbedienung-und-switch-status-aktualisierung/ geschrieben.

Über die angepasste Regel wird das Licht nun in einem definierten Zeitraum ein bzw ausgeschaltet, wenn jemand zu Hause ist und der definierte Lichtwert erreicht wurde.

rule AnwesendFlur
when
Time cron "* */5 * * * ?"
then
if (now.getHourOfDay() >= 6 && now.getHourOfDay() <=22 && Presence.state == ON && FlurAutomatik.state == ON && fsda1.state == ON) {
if(FlurAlle.state == OFF){
sendCommand(FlurAlle, ON)
logInfo("PresenceCheck", "LICHT AN" )
}
} else {
if(FlurAlle.state == ON && FlurAutomatik.state == ON){
sendCommand(FlurAlle, OFF)
logInfo("PresenceCheck", "LICHT AUS" )
}
}
end

Die beiden Kanäle des Sensors wurden wie folgt in einer items Datei hinterlegt:
Switch fsda1 "Daemmer1 " (fstest) {fs20="C4A600"}
Switch fsda2 "Daemmer2 " (fstest) {fs20="C4A601"}

fs20-daemmer

die gelieferten Bauteile

 

Um Änderungen an der Konfiguration und den Dateien meines Blogs gefahrlos testen zu können, möchte ich eine Testinstanz meines Blogs einrichten. Die dazu erforderlichen Schritte werde ich in diesem Artikel dokumentieren.

Dieser Artikel ist keine Schritt-für-Schritt-Anleitung und kein Tutorial, welches man blind befolgen kann. So gehe ich hier z.B. nicht auf die allgemeine Webserverkonfiguration ein. Falls ihr hierzu Hilfe benötigt, schaut bitte in der offiziellen Dokumentation zu eurem Webserver nach.

Voraussetzungen

Ich betreibe meinen Blog bei einem deutschen Webhosting-Provider. Bei diesem habe ich über ein Kundencenter unter via FTP-Zugang Zugriff auf die Konfiguration und die Dateien meines Blogs.

Bei einem anderen deutschen Unternehmen betreibe ich noch einen Linux-Root-Server, welcher sich hervorragend eignet, um darauf eine Testinstanz einzurichten.

Daten sichern

Um die spätere Testinstanz mit den Daten des Live-Blogs füttern zu können, werden die Daten aus dem aktuellen Blog zuerst einmal gesichert.

Die Sicherung umfasst die Datenbank und das DocumentRoot des Blogs.

Zur Sicherung der Datenbank verwende ich das Tool MySQLDumper.1 Mit diesem Werkzeug kann man über eine einfach zu bedienende Weboberfläche ein Backup seiner Datenbank erstellen. Dieses Backup wird anschließend zur weiteren Verwendung auf den lokalen Rechner heruntergeladen.

Im zweiten Schritt wird das DocumentRoot-Verzeichnis des Blogs gesichert. Hierzu nutze ich den FTP-Client FileZilla.2

Serverkonfiguration

Auf dem Linux-Root-Server laufen Ubuntu Server 14.04 LTS und der Webserver NGINX.3

Für meine Webseiten verwende ich eine einheitliche Verzeichnisstruktur:

example.org/
├── logs
│   ├── access.log
│   └── error.log
└── public
    └── index.html

2 directories, 3 files

So wird für jede Webseite in separate Log-Dateien geschrieben, was eine Fehleranalyse deutlich erleichtern kann. Die Dateien der Webseite liegen im Verzeichnis public. Die Datei index.html stellt dabei aktuell nur einen Platzhalter dar, bis die gesicherten Daten des Live-Blogs eingespielt werden.

Den Platzhalter kann man nutzen, um zu testen, ob der Webserver korrekt konfiguriert ist und die im Verzeichnis public abgelegte Seite auch ausliefert.

Um die spätere Testinstanz über die gleiche URL aufrufen zu können, wie den Live-Blog, wird ein Eintrag in die /etc/hosts eingefügt. So erreicht man, dass die URL des Live-Blogs nun auf die IP-Adresse des Servers mit der Testinstanz zeigt.

Hat man alles richtig konfiguriert, wird man vom Webserver mit einem „Hallo Welt!“ begrüßt.

Zugriff beschränken

Während man eine neue Konfiguration testet, können Fehler passieren. Diese können zu Folge haben, dass der Blog nicht korrekt ausgeliefert wird. Für gewöhnlich ist nicht gewünscht, dass ein Benutzer dies sieht. Evtl. möchte man auch einfach nicht, dass Neuerungen zufällig schon von Besuchern entdeckt werden, bevor sie in den Live-Blog überführt wurden.

Daher scheint es sinnvoll den Zugriff auf die Testinstanz einzuschränken und einen Aufruf der Testinstanz erst nach erfolgreicher Authentifizierung mit Benutzername und Passwort zu erlauben.

Dazu eignet sich für NGINX-Benutzer das Modul ngx_http_auth_basic_module.4 Nutzer von Apache können .htaccess-Dateien5 verwenden. Da ich selbst einen NGINX betreibe, gehe ich im Folgenden auf das zuerst genannte Modul ein.

Zuerst wird die .htpasswd-Datei erstellt, welche Benutzernamen und Passwort für die Authentifizierung enthält.

sudo touch /etc/nginx/conf.d/.htpasswd

Um das Passwort in verschlüsselter Form speichern zu können wird das Paket apache2-utils benötigt. Dieses enthält das Programm htpasswd, mit welchem Benutzername und Passwort erzeugt werden.

:~$ sudo htpasswd -c /etc/nginx/conf.d/.htpasswd BENUTZERNAME
New password: 
Re-type new password: 
Adding password for user BENUTZERNAME

Der Benutzer, unter dessen Kontext der Webserver (NGINX) läuft, muss Zugriff auf die .htpasswd erhalten.

:~$ sudo chown www-data:www-data /etc/nginx/conf.d/.htpasswd

Nun öffnet man die Konfigurationsdatei für die Testseite, welche für gewöhnlich unterhalb von /etc/nginx/sites-available/ liegt. Hier ist folgende Konfiguration zu integrieren:

location / {
    auth_basic           "Authentifizierung erforderlich!";
    auth_basic_user_file conf.d/.htpasswd;
}

auth_basic aktiviert die Überprüfung von Benutzername und Passwort. auth_basic_user_file gibt den Pfad an, wo die .htpasswd-Datei liegt, gegen die geprüft wird.

Mit einem „configtest“ kann man seine Konfiguration auf syntaktische Fehler überprüfen und bei Bestehen der Prüfung die Konfiguration neu laden.

:~$ sudo service nginx configtest 
 * Testing nginx configuration                    [ OK ] 
jkastning@rs212997:~$ sudo service nginx reload
 * Reloading nginx configuration nginx            [ OK ]

Ab jetzt fragt NGINX nach einem Benutzernamen und Passwort, bevor er die Webseite mit dem „Hallo Welt.“-Slogan ausliefert.

Daten einspielen

Wenn der Webserver prinzipiell mit dem weiter oben erstellten vHost funktioniert und die „Hallo Welt.“-Seite ausliefert, werden als nächstes die Daten aus dem Live-Blog eingespielt.

Dazu werden der Datenbank-Dump und das im ersten Schritt gesicherte Verzeichnis auf den Linux-Root-Server hochgeladen. Ich habe dazu wieder FileZilla und das SFTP-Protokoll genutzt.

DocumentRoot

Die gesicherten Dateien und Verzeichnisse, müssen in das DocumentRoot-Verzeichnis der Testinstanz kopiert werden. In meinem Beispiel ist das das Verzeichnis /var/www/example.org/public/. Mit folgendem Befehl wird sichergestellt, dass der Webserver auch alle Dateien lesen kann.

sudo chgrp -R www-data /var/www/example.org/public

Die Datenbank

Bevor die Datenbanksicherung eingespielt werden kann, muss eine Datenbank und ein Datenbankbenutzer angelegt werden.

Wer hierbei Hilfe zur Syntax benötigte kann im Artikel „Häufig verwendete MySQL-Befele“ nachlesen.

Ist dies erledigt, kann die Datenbanksicherung mit folgendem Befehl eingespielt werden.

mysql -u root -p db_name &lt; db_sicherung.sql

Ober der angelegte Benutzer auch wirklich Zugriff auf die Datenbank hat, kann man mit dem folgenden Befehl überprüfen. Wenn alles stimmt, kann man sich so an der Datenbank anmelden.

mysql -u db_benutzer -p db_name

Fertig. Mein Testblog läuft und ich kann mich jetzt daran machen, mit der WordPress-Konfiguration zu experimentieren. :-)

  1. http://www.mysqldumper.de/
  2. http://www.filezilla.de/
  3. http://nginx.org/
  4. http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html
  5. .htaccess – Wikipedia

In anderthalb Wochen startet die Frühjahrstagung des DANTE e.V. in Stralsund. Leider ist aus den interessante Vorträgen bisher noch nicht so viel geworden. Das heißt, das was angeboten wurde, ist interessant, aber viel zu wenig.

Aktuell gibt es 8 Vorträge, die einen Freiraum von 15,25 Stunden füllen sollen. Daher hier einmal der Aufruf in die Linux- und LaTeX-Community, noch weitere Vorträge einzureichen. Daneben lohnt sich ein Besuch in Stralsund – vor allem, wenn das Wetter so wird, wie es scheint.

Ich bereite ja einen Workshop zum Thema „Eigene LaTeX-Arbeiten als E-Book veröffentlichen” vor. Ich könnte noch weitere Füllvorträge anbieten, habe aber aktuell keine Zeit, diese vorzubereiten, z.B.

Ich rippe meine Audio-CDs ja mittels morituri als flac auf die Festplatte. Leider kann mein Autoradio keine flac-Dateien abspielen und ich muss diese zu mp3 umkodieren. Dabei ist das Script pacpl sehr hilfreich:

    pacpl --to mp3 -p -r --bitrate 320 --outdir /home/martin/mp3 /home/martin/Musik

Mit --to mp3 gebe ich das Zielformat und über --bitrate die Bitrate an. Andere Formate (flac, ogg etc.) werden also in mp3-Dateien mit 320kbps umgewandelt. Über -p (--preserve) wird festgelegt, dass die Ordnerstruktur im Zielordner, der des Quellordners entspricht. -r sorgt dafür, dass das Quellverzeichnis rekursiv durchsucht wird und alle Musikdateien umgewandelt werden, nicht nur die Dateien, die sich direkt im Quellverzeichnis befinden.

Mit diesem Befehl sorge ich also dafür, dass meine Musiksammlung unter /home/martin/Musik noch mal als mp3 unter /home/martin/mp3 abgelegt wird.

Weiter Informationen können dem UU-Wiki oder der manpage entnommen werden.

Update 2016-08-26

Später fiel mir auf, dass pacpl mir die UTF8-Kodierung innerhalb der tags kaputt gemacht hat. Mit mid3iconv aus dem Paket python-mutagen konnte ich dies folgendermaßen reparieren:

    find . -name "*.mp3" -print0 | xargs -0 mid3iconv -e UTF8 -d