ubuntuusers.de

13. April 2015

sandisk SDSDQXN 016G FFPA - Raspberry Pi 2 - Benchmark - SanDisk Extreme 16GB microSDHC UHS-I Class 10 U3Bei SD-Karten für den Raspberry Pi (1) habe ich mir angewöhnt, wenn ich eine neue verwenden wollte, einen Artikel mit Benchmark und Geschwindigkeitsvergleich zu schreiben. Diese Vergleiche möchte ich euch auch zukünftig, beim Raspberry Pi 2, nicht vorenthalten. Bisher kann ich die microSD-Karte allerdings nur mit normalen SD-Karten von RPi (1) vergleichen. Ich habe mich beim RPi 2 … Raspberry Pi 2 – Benchmark – SanDisk Extreme 16GB microSDHC UHS-I Class 10 U3 weiterlesen
SanDisk - SDSDQXN-016G-FFPA

Bei SD-Karten für den Raspberry Pi (1) habe ich mir angewöhnt, wenn ich eine neue verwenden wollte, einen Artikel mit Benchmark und Geschwindigkeitsvergleich zu schreiben.

Diese Vergleiche möchte ich euch auch zukünftig, beim Raspberry Pi 2, nicht vorenthalten. Bisher kann ich die microSD-Karte allerdings nur mit normalen SD-Karten von RPi (1) vergleichen.

SanDisk Extreme 16GB microSDHC UHS-I Class 10 U3

Ich habe mich beim RPi 2 für eine “SanDisk Extreme 16GB microSDHC UHS-I Class 10 U3” mit der Modellnummer “SDSDQXN-016G-FFPA” entschieden.

Im Vergleich zu den normalen SDHC-Karten schneidet die MicroSDHC-Karte, im 4K-Bereich, etwas besser ab.

Vergleich - SanDisk Extreme 16GB microSDHC UHS-I Class 10 U3

Wie fandet ihr den Leistungssprung vom RPi 1 zum 2? Was nutzt ihr für eine microSDHC-Karte?


© loggn.de, 2015. | Permalink | kein Kommentar
_nico bei Twitter und Google+ | loggn.de bei Facebook und Google+

Copyright © 2009-2015
Dieser Feed ist ausschließlich für den privaten Gebrauch bestimmt. Der gewerbliche Gebrauch, in gedruckter oder digitaler Form, ist ohne ausdrückliche Zustimmung des Betreibers nicht erlaubt.

Vor einigen Tagen ist mir ein Mailserver (bestehend aus Postfix und Dovecot) begegnet, welcher in der mail.err regelmäßig folgende Ausgabe wiederholte:

Apr 2 13:16:35 service dovecot: lda(root): Error: chdir(/root/) failed: Permission denied (euid=65534(nobody) egid=65534(nogroup) missing +x perm: /root, dir owned by 0:0 mode=0700)
Apr 2 13:16:35 service dovecot: lda(root): Error: chdir(/root) failed: Permission denied
Apr 2 13:16:35 service dovecot: lda(root): Error: user root: Initialization failed: Namespace '': stat(/root/Maildir) failed: Permission denied (euid=65534(nobody) egid=65534(nogroup) missing +x perm: /root, dir owned by 0:0 mode=0700)
Apr 2 13:16:35 service dovecot: lda(root): Fatal: Invalid user settings. Refer to server log for more information.

Der Dovecot-Service versucht auf einen Maildir–Ordner im Nutzerverzeichnis des Nutzers root zuzugreifen, was allerdings nicht gelingt. Einfach lösen lässt sich dieses Problem in dem man einen Alias für die Mailzustellung zum Nutzer root anlegt. Dazu wird im ersten Schritt die Datei /etc/aliases bearbeitet. In dieser Datei kann der entsprechende Alias eingetragen werden:

root: webmaster@example.com

Nachdem die Datei gespeichert wurde, muss die Datei in ihre binäre Form überführt werden und die entsprechenden Services neugestartet werden:

newaliases
service dovecot restart
service postfix restart

Damit werden die Mails von root im entsprechenden Postfach hinterlegt und die Fehlermeldung gehört der Vergangenheit an.

Im Unternehmensumfeld kann es durchaus die Anforderung geben, aus Mails die Anhänge automatisiert zu speichern um irgendwelche weiteren Schritte damit durchzuführen. Hier wäre beispielsweise ein Mail-to-Fax System zu nennen.

Mit Hilfe von Postfix ist so etwas recht einfach zu realisieren. Innerhalb der /etc/aliases kann ein Skript als Ziel für einen Mailempfänger angegeben werden. Zum Beispiel:

mail2fax: |/home/mail2fax/bin/mail2fax_worker.sh

Die komplette Mail wird per STDIN an das Skript übergeben, kann gespeichert und weiter bearbeitet werden.

Und wie nun „Raus damit“?

Die Anhänge sind innerhalb der Mail base64 kodiert. Dazu ist das ganze in diverse Abschnitte aufgeteilt. Theoretisch könnte man nun die Mail per Skript auseinander nehmen und die kodierten Teile per cli und dem Befehl „base64 -d“ dekodieren. Aber(!) das macht natürlich keinen Sinn, weil es dafür nützliche Tools gibt.

Den Standard dürfte „munpack“ darstellen – unter Debian enthalten in dem Paket „mpack“. Funktioniert prima, bis auf eines. Leerzeichen und andere Sonderzeichen werden beim Speichern der jeweiligen Datei durch ein „X“ ersetzt. Das ist soweit ok. Sind innerhalb der Mail allerdings die Dateinamen kodiert (ebenfalls base64) – weil sie bspw. Umlaute enthalten, so speichert munpack die Datei unter dem kodierten Namen. Dabei ist auch die Dateiendung kodiert, was unter M$ Benutzern dann schnell zu Problemen führt.

Auf meiner Suche nach einer Alternative habe ich ripMIME gefunden. ripMIME arbeitet prinzipiell genauso wie munpack – bis auf die Dateinamen. Diese werden korrekt übernommen und ggf. auch dekodiert. Möchte man nun keine Umlaute etc. im Dateinamen haben, so kann man sich mit einem einfachen

# das -n steht für "nothing is done"

rename -n "s/[^a-zA-Z0-9.-]/_/g" *.xyz

helfen. Mit Hilfe dieses Befehls werden alle Zeichen die nicht a-z, A-Z, 0-9, „.“ oder „-“ sind durch ein „_“ ersetzt.

Natürlich gibt es Module für Python, Perl etc. um solche Mails auszulesen und auch die Attachments zu speichern. Wir sind hier rein auf der bash unterwegs </div>
                <div class= Permalink

Ein Nachteil von OzonOS ist, dass es speziell dazu noch kaum Doku gibt. Es basiert aber auf Fedora und dafür gibt es wesentlich mehr. Allerdings ist Fedora eine Distribution, die auf sehr aktuelle Software setzt. Und dann wird es auch schon wieder knapp. Fedora nutzt zum Beispiel systemd – und dafür habe ich bisher nur Grundsätzliches gefunden. Im Prinzip funktioniert der Client von OpenVPN unter Ubuntu, Fedora und OzonOS ähnlich: Erst muss man den Dienst installieren und konfigurieren und dann die Steuerung per grafischer Oberfläche nachrüsten.

Also erst einmal Terminal auf und das OpenVPN-Paket installieren:

1
2
3
sudo su
yum update
yum install openvpn

Dann musst Du die beiden Zertifikate, das Key-File und die .opvn-Datei, die Du auf dem Server erzeugt oder vom Anbieter bekommen hast, ins Konfigurationsverzeichnis von OpenVPN (etc/openvpn/) kopieren. Die .opvn-Datei benennst Du um in client.conf. Am Ende der client.conf fügst Du die Zeile ein:

1
dhcp-option DNS 8.8.8.8

Ich hatte sonst immer das Problem, dass OpenVPN die Dyn-DNS-URL meines VPNs nicht auflösen. Wenn Du eine IP angegeben hast, ist das egal. Jetzt kannst Du den Dienst starten:

1
systemctl -l start openvpn@client.service

Wenn das fehlerlos klappt, kannst Du den Dienst so eintragen, dass er bei jedem Systemstart mit gestartet wird:

1
systemctl -l enable openvpn@client.service

Nun musst Du das Frontend nachrüsten:

1
yum install NetworkManager-openvpn-gnome

Nun kannst Du unter Einstellungen > Netzwerk unten links das + klicken und manuell ein VPN, dann Open VPN hinzufügen. In der Maske stellst Du dann ein:

  • Gateway: DEINE VPN-IP/URL 1194 udp
  • Art: Zertifikat
  • Zertifikat des Benutzers: client.crt
  • Zertifikat der Zertifizierungsstelle: ca.crt
  • Privater Schlüssel: client.key

Anwenden. Fertig.

Du kannst jetzt oben links bei den Einstellungen die Verbindung zum VPN herstellen.

Ich werde das jetzt mal als Feature-Request einreichen. Mit den Clients unter Android und Windows ist das wesentlich einfacher. Und eigentlich passiert hier nicht viel. Ein paar Dateien werden kopiert. Zwei Pakete werden installiert. In der heutigen Zeit sollte VPN einfacher nutzbar sein.

Hinweise für Ubuntu-Nutzer

Für Ubuntu sind die Schritt im Prinzip die gleichen. Teil 1 findest Du hier im Abschnitt „Client“. Den Frontendteil findest Du hier. Da ich mein Problem

12. April 2015

Heute nur als Linksliste:

Und das war's auch schon mit dem Rückblick. Wer will, kann nächstes Wochenende nach Stralsund zur DANTE-Tagung kommen. wenn das Wetter so ist, wie diese Woche, sind sogar die Vorträge egal. ;)

Wer häufiger öffentliche WLANs nutzt, sollte sich darüber im Klaren sein, dass die Verschlüsselung und das Passwort nur nach Außen abschirmen. Innerhalb des WLANs ist der unverschlüsselte Internet-Verkehr für alle anderen Teilnehmer potentiell mitlesbar. Wer das nicht will, sollte seine Verbindung verschlüsseln. Eine Möglichkeit dazu ist ein eigenes VPN auf dem heimischen Raspberry Pi.

Am einfachsten startest Du mit einem frisch installierten Raspbian. Du musst den dann aber erst einmal auf den aktuellen Stand bringen – bei mir ist die Installation am Ende gescheitert. Also:

1
2
3
sudo apt-get update
sudo apt-get upgrade
sudo rpi-update

Mein Raspberry Pi hängt direkt per Kabel direkt am Router. Dadurch spare ich mir die Konfiguration des WLANs und ich schalte damit auch eine potentielle Fehlerquelle aus.

Bei Jan Karres habe ich eine sehr gute Anleitung gefunden, mit der OpenVPN auf dem Raspberry Pi einfach zu installieren ist. Die Anleitung ist so einfach, dass man den einzigen Schritt fast übersieht, bei dem man selbst denken muss: Bei Step 12 muss man die eigene IP oder die eigene DynDNS-URL eintragen. Ansonsten ist es copy & paste.

In den nächsten Tagen schreibe ich noch auf, wie man OpenVPN unter den verschiedenen Betriebssystemen nutzt. Relativ einfach ist das unter Android – da gibt es einfach eine OpenVPN-Client-App. Und so ähnlich geht das auch unter Windows. Leider ist es unter Ubuntu und Fedora noch nicht so einfach.

Wenn es mal nicht funktioniert

Wenn Du aus einem öffentlichen WLAN mal nicht auf Dein VPN zugreifen kannst, dann kann das daran liegen, dass der Anbieter die Nutzung des Internets auf Web und E-Mail beschränkt hat. Bei Fritz-Boxen ist das zum Beispiel ein Häkchen, das vermutlich viele Leute machen, die einen Gastzugang anbieten.

Links

Für meinen kleinen Backup Rechner habe ich zufällig ein neues Mainboard samt CPU erhalten. Anstelle eines 1,2 GHz Single Core Celeron arbeitet nun ein AMD Athlon Dual Core 5400B mit 2,8 GHz in dem Rechner. Bei der Gelegenheit habe ich noch vier Riegel DDR2 Arbeitsspeicher mit je 512 MB gefunden, die mir aber einige Probleme bereitet hatten. Das Tool 

lshw
  hat mir dabei schnell aus der Patsche geholfen.

Mit lshw, wie der Name bereits vermuten lässt, lassen sich Hardwareinformationen anzeigen. Mein Problem war, dass von den 4 Riegeln des Arbeitsspeichers nur 3 erkannt wurden. Der Rechner fuhr zwar normal hoch, aber ich wollte den defekten Riegel entfernen und entsorgen, damit dieser keine Probleme verursachen kann. Ein Umstecken der Riegel brachte das gleiche Ergebnis. Da ich nur per SSH Zugriff hatte und keine Tastatur und Monitor anschließen wollte, hab ich schnell 

lshw
installiert:
# Debian / Ubuntu
apt-get install lshw
# CentOS / Fedora
yum install lshw

Am meisten Informationen erhält man, wenn man lshw als root oder mit sudo ausführt. Die Ausgabe ist sehr lang, darum bietet es sich an, die Ausgabe eventuell auf das Gesuchte zu begrenzen:

# Vollständige Ausgabe
lshw
# Vollständige Ausgabe mit more betrachten
lshw | more
# Vollständige Ausgabe in Datei umleiten
lshw > /tmp/lshw.txt
# Ausgabe auf Arbeitsspeicher-Informationen beschränken
lshw -class memory
# Kurze Ausgabe erzeugen
lshw -short

Das ist natürlich weder Hexenwerk noch ein Geheimtipp, aber praktisch ist es auf jeden Fall. Den defekten Arbeitsspeicher-Riegel konnte ich damit schnell identifizieren, da 

lshw
die Informationen über den Arbeitsspeicher pro Bank anzeigt und einer hiervon als “empty” erkannt wurde.

Nachdem ein Diaspora* Pod Update mal wieder völlig fehlgeschlagen war und mir die Fehler nur so um die Ohren geflogen sind, habe ich jetzt genug. Ich werde zumindest in naher Zukunft keinen eigenen Diaspora* Pod mehr hosten. Auf die ständigen Probleme bei Updates und den exorbitanten RAM Verbrauch während der Laufzeit habe ich einfach keine Lust mehr. Es kann doch nicht normal sein, wenn ein Diaspora Pod mit gerade einmal 2 aktiven Usern einen RAM Verbrauch von mehr als 700 MB hat.

Ich werde mir ein Profil auf einem fremd gehosteten Server anlegen und von dort aus meinen Senf ins Internet posten. Das ist zwar nicht förderlich für das Netzwerk, aber weniger Stress und Ärger für mich.

11. April 2015

In meinem Artikel über moderne Browser war es am Ende Servo, der mich am meisten interessiert hat. So unfertig wie es ist, so interessant ist das Konzept. Und natürlich gibt es einen Weg, ihn schon jetzt als Browser zu nutzen: servo-shell.

Man muss nur Servo herunterladen, kompilieren (beides dauert lange) und dann mit der Shell starten:

git clone git@github.com:servo/servo.git --depth 1
git clone https://github.com/glennw/servo-shell --depth 1
cd servo
./mach build --release
./mach run --release ../servo-shell/index.html -e

Allerdings verwandelt die Shell Servo nicht in einen fertigen Browser. Es ist immer noch unfertig, und unfertig meint hier: Das Interface ist kaum benutzbar, Seiten werden falsch dargestellt, Eingaben funktionieren nicht und er stürzt reproduzierbar ab. Das ist nur zum Testen, was da kommen könnte.

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.