Anwendungen
Portal
Forum
Wiki
Ikhaya
Planet
Mehr
Anmelden

9. Dezember 2014

Spiele – Deponia

Permalink DevDiary

Deadalic ist unter anderem bekannt für seine guten Advanture Spiele wie Edna bricht aus, Harveys neue Augen und auch Deponia.
Dass Spiel ist seit ein paar Monaten auch für Linux verfügbar sodass auch ich endlich in den Genuss des Spielens komme.

Quelle - Bildschirmfoto von Deponia

Quelle – Bildschirmfoto von Deponia

Inhalt

Dass Spiel fängt erst mal klassisch mit einem kleinem Lied an welches uns einleitend die Welt von Deponia zeigt.
Als Rufus mal wieder einen seiner Fluchtversuche unternimmt erwarten seine Mitmenschen nicht viel und einige, darunter seine Ex-Freundin, sind belustigt darüber dass er sich mal wieder verletzt.

Doch diesmal, wenn auch mit einigen Problemen, gelingt die Flucht zunächst und er befindet sich auf einem der Organon Kreuzer wo er die Elysianerin Goal vor fiesen Schurken rettet.
Nun gilt es diese zu Retten und mit ihr sich auf den Weg nach Elysium zu machen.
Dabei passiert den beiden auf deren Weg einiges wobei ich hier euch nicht alles verraten möchte.

Die Charaktere in dem Spiel kommen gut herüber und verleihen der Welt von Deponia ihren eigenen Charme.
Teilweise haben sie sogar eine verständliche Hintergrundstory welches den Spieler an vielen stellen in die Spielwelt eintauchen lässt.

Quelle - Bildschirmfoto von Deponia

Quelle – Bildschirmfoto von Deponia

Grafik

Der Comic-artige Grafikstil von Deponia ist meiner Meinung nach gelungen und verleiht dem Spiel seinen eigenen Charme.
Dabei ist die Gestaltung der Level auch einsame spitze und teilweise wird an einigen stellen dass Level selbst zum Rätsel.
Hierbei sind sowohl die Charaktermodelle als auch die Levels sehr detailliert gezeichnet worden was aus meiner Sicht ein wichtiger Faktor für ein gutes Advanture ist.

Audio

Der Soundtrack von Deponia kann sich wirklich hören lassen und untermalt die grafische Darstellung von Deponia passend.
Jedoch hat er auf mich an manchen Plätzen nach einer gewissen Spielzeit ein wenig störend gewirkt.

Alleine die gelungenden Vertonung macht dies schon wieder Wett sodass man sich gerne bei Dialogen durch die verschiedenen Optionen klickt.
Auch sind alle Texte in verschiedenen Sprachen vertont worden sodass neben Deutsch auch Englisch für die Audioausgabe und Russisch, Französisch und Polnisch für die Untertitel zur Verfügung stehen.

Quelle - Bildschirmfoto von Deponia

Quelle – Bildschirmfoto von Deponia

Infos und Details

Die Spieldauer beträgt gute 10 Stunden wobei nicht einmal dass Gefühl von Langeweile aufkommt.
Es gibt immer was zu erledigen und die Rätsel haben genau den richtigen Schwierigkeitsgrad.

Deponia kommt von dem Deutschen Entwicklerstudio Daedalic Games welche für ihre Advantures bekannt sind und erschien erstmals 2012.
Dabei ist dies wieder ein Titel bei dem Jan Müller-Michaelis (Poki) mitgewirkt hat.
Ihn kennt man schon aus den Spielen Edna bricht Aus und Harveys neue Augen.

Das Spiel wird unter anderem über Steam vertrieben wo es derzeit 19.99 Euro kostet und für die Plattformen Linux, Mac und Windows gekauft werden kann.

Die Systemanforderungen sind ziemlich niedrig sodass man zum spielen nicht unbedingt ein Spiele PC benötigt.

Linux Systemanforderungen

– Betriebssystem: Linux x86_64
– Prozessor: 2.5 GHz Single Core oder 2 GHz Dual Core Prozessor
– Arbeitsspeicher: 2 GB
– Grafik: OpenGL 2.0 kompatible mit 256 MB RAM
– Festplatte: 1.8 GB freien Speicher
– Audio: OpenAL kompatible

Wertung

Kategorie Wertung
Grafik 9/10
Gestaltung 9/10
Inhalt 10/10
Gesamt 28/30

Fazit

Dass Spiel ist über die gesamte Spielzeit von etwa 10 Stunden spannend und erzählt eine gute Geschichte.
Auch wenn ich 2, 3 mal an ein paar stellen hing haben sich doch alle Rätsel in einer angenehmen Zeitspanne lösen lassen, wenn auch an den stellen mithilfe des Internets.
Damit fällt mein Fazit klar Positiv aus und ich empfehle es jedem ungeachtet der Altersklasse.

Radicale Kalender auf Ubuntu Server

Permalink Erfahrungen mit Ubuntu

Da ich einen eigenen Kalenderdienst nutzen möchte,
den ich auch auf dem eigenen Server betreibe habe ich
mich für Radicale entschieden. Davical benötigt ein Apache2 was
für meinen kleinen Ubuntu-Server (hier noch Version 11.10)
zu umfangreich währe.

Die Installation ist mit der Komandozeile schnell erledigt:

apt-get install radicale

Nun habe ich folgende Werte in der Config Datei

/etc/radicale/config

angepasst:

port = 5232
type = htpasswd
personal = true
filename = /etc/radicale/users
encryption = sha1
folder = /var/lib/radicale/collections


Kurz zur Erklärung:

port=5232 setzt den TCP Port auf den entsprechenden Wert, kann auch geändert werden je nach Bedarf. Wichtig: Auch im Router musste ich eine Portweiterleitung dafür einrichten.

type = htpasswd beschreibt in welchem Format die Kennwortdatei vorliegt.

personal=true bedeutet das private Kalender nur mit Kennwort erreichbar sind.

filename = /etc/radicale/users hier wird die Kennwortdatei gesucht.

encryption = sha1 Beschreibt die Verschlüsselungsvariante für die Kennwortdatei

folder = /var/lib/radicale/collections hier ist der Pfad zu den Kalendern hinterlegt. Ich habe mir für diesen Entschieden weil er kompatibel mit älteren Radicale Versionen ist.


Einbindung in anderen Programmen (hier Lightning):

Man  wählt als Kalenderformat caldav aus, und übergibt dann
folgenden Pfad zu dem Kalender:

http://serverip:5232/benutzername/kalendername.ics

Anschliessend gibt es im Verzeichnis
/var/lib/radicale/collections

ein Verzeichnis mit dem Namen "benutzername" und dem Kalender "kalendername.ics".

 Gestartet wird der Kalender mit:

radicale -f  

oder

radicale -d

Ersteres startet den Kalender im Vordergrund, der zweite Befehl als Dämon Prozess.



Anleitung ist für Ubuntu Server 11.10



ownCloud Konfiguration mit Nginx: Hosting und Reverse Proxy

Permalink debinux

Da die Einrichtung doch etwas zickiger verlief als erwartet, fasse ich kurz meine Erfahrung für die Nachwelt zusammen.

Artikel zur Installation finden sich zur Genüge, daher bleibt dieser Schritt bei mir aus.

Eingesetzt habe ich Debian Jessie (amd64), auf dem Reverse Proxy läuft ein nginx/1.7.7, auf dem ownCloud-Server ein nginx/1.6.2 sowie ownCloud selber in Version 7.0.3.

Ich war vom ownCloud-Client eher enttäuscht, werde ihn persönlich nicht benutzen.
Meine wunderschöne, vereinfachte Darstellung der Umgebung:

ownCloud Networking Example

ownCloud Networking Example

Die Nginx Konfiguration des Reverse-Proxys.
Wichtig: proxy_pass, proxy_set_header

server {
        listen 443 ssl;
        ssl_certificate /etc/ssl/www.crt;
        ssl_certificate_key /etc/ssl/www.key;
        add_header Strict-Transport-Security max-age=15768000; # six months
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA';
        server_name cloud.domain.tld;
        location / {
                proxy_pass http://10.0.0.40;
                proxy_set_header X-Forwarded-Host cloud.domain.tld;
                proxy_set_header X-Forwarded-Proto https;
                proxy_set_header X-Forwarded-For $remote_addr;
        }
}

Die Nginx Konfiguration auf Seite des ownCloud-Servers.
Ich hatte Probleme, wenn ein Servername gesetzt war, daher “Wildcard”:

server {
  listen 80;

  root /usr/share/nginx/html;
  index index.php index.html index.htm;

  server_name _;

  rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
  rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
  rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;

  error_page 403 /core/templates/403.php;
  error_page 404 /core/templates/404.php;

  location ~ ^/(data|config|db_structure\.xml) {
    deny all;
  }

  location / {
    rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
    rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
    rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
    rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;
    rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
    try_files $uri $uri/ index.php;
  }

  location ~ ^(.+?\.php)(/.*)?$ {
    try_files $1 =404;
    #fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param QUERY_STRING       $query_string;
    fastcgi_param REQUEST_METHOD     $request_method;
    fastcgi_param CONTENT_TYPE       $content_type;
    fastcgi_param CONTENT_LENGTH     $content_length;
    fastcgi_param SCRIPT_NAME        $fastcgi_script_name;
    fastcgi_param REQUEST_URI        $request_uri;
    fastcgi_param DOCUMENT_URI       $document_uri;
    fastcgi_param DOCUMENT_ROOT      $document_root;
    fastcgi_param SERVER_PROTOCOL    $server_protocol;
    fastcgi_param GATEWAY_INTERFACE  CGI/1.1;
    fastcgi_param SERVER_SOFTWARE    nginx/$nginx_version;
    fastcgi_param REMOTE_ADDR        $remote_addr;
    fastcgi_param REMOTE_PORT        $remote_port;
    fastcgi_param SERVER_ADDR        $server_addr;
    fastcgi_param SERVER_PORT        $server_port;
    fastcgi_param SERVER_NAME        $server_name;
    fastcgi_param REDIRECT_STATUS    200;
    fastcgi_param SCRIPT_FILENAME $document_root$1;
    fastcgi_param PATH_INFO $2;
    fastcgi_param HTTPS on;
  }

  location ~*.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
  }

  location ~ /\. {
    deny all;
  }
}

ownCloud Webroot, Datei “config/config.php”
Wichtig: overwritehost, overwritecondaddr, trusted_domains, overwrite.cli.url

<?php
$CONFIG = array (
  'instanceid' => 'instid',
  'passwordsalt' => 'salt',
  'trusted_domains' =>
  array (
    0 => '10.0.0.40',
    1 => 'cloud.domain.tld',
  ),
  'datadirectory' => '/usr/share/cloud_data',
  'overwrite.cli.url' => 'https://cloud.domain.tld',
  'dbtype' => 'mysql',
  'version' => '7.0.3.4',
  'dbname' => 'db',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'user',
  'dbpassword' => 'password',
  'installed' => true,
  'overwritehost'     => 'cloud.domain.tld',
  'overwriteprotocol' => 'https',
  'overwritewebroot'  => '/',
  'overwritecondaddr' => '^10\.0\.0\.10$',
);

8. Dezember 2014

Call for Places: Veranstaltungsort für die Ubucon 2015 gesucht – Teil 2

Permalink Ubucon

Ende Oktober gab es einen Call for Places für die Ubucon im nächsten Jahr. Hierbei wird ein Veranstaltungsort gesucht an dem die Ubucon im nächsten Jahr stattfinden kann. Leider konnte noch kein Ort gefunden werden, bei dem eine sichere Zusage gemacht werden konnte. Deshalb haben wir beschlossen, dass wir die Frist bis zum 11. Januar 2015 verlängern, um noch einen Ort zu finden bei dem wir in 2015 zu Gast sein dürfen. Einsendungen und Nachfragen können unter der E-Mail team@ubucon.de eingesendet werden.

Die Anforderungen an den Ort und an die Räumlichkeiten sind im Artikel Call for Papers: Veranstaltungsort für die Ubucon gesucht beschrieben.

Debian Basics mit systemd

Permalink debinux

Mit dem Release von Jessie wird Debian um systemd erweitert, wie wohl endlich feststeht.
Vorab möchte ich drei systemd Dienste vorstellen, die meiner Meinung nach eine große Bereicherung- und jetzt schon ein Teil Debians sind.

timesyncd, resolved und networkd.

Besonders der networkd erleichtert und – vorallem – vereinheitlicht die Konfiguration komplexer Netzwerke deutlich.
Holt die Mistgabeln raus und jagt mich, aber ich finde systemd gelungen…

Bevor es losgeht, werfe ich noch kommentarlos zwei ctl’es in den Beitrag:

timedatectl set-timezone Europe/Berlin
hostnamectl set-hostname meinhostname

systemd-timesyncd

Mit dem timesyncd bringt systemd ein einfaches Werkzeug zu Synchronisation der Zeit mit.
In der Konfigurationsdatei einige Zeitserver nach Bedarf ändern, hinzufügen oder entfernen:

nano /etc/systemd/timesyncd.conf

[Time]
Servers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

Der Dienst wird im Anschluss aktiviert und gestartet:

systemctl enable systemd-timesyncd
systemctl start systemd-timesyncd
“systemctl enable” entspricht etwa dem bekannten “update-rc.d xyz defaults”

Admins virtualisierte Computer überschreiben den Parameter “ConditionVirtualization” des Dienstes, falls wirklich gewünscht, mit einer Konfigurationsdatei:

mkdir /etc/systemd/system/systemd-timesyncd.service.d
nano /etc/systemd/system/systemd-timesyncd.service.d/virt.conf
echo -e "[Unit]\nConditionVirtualization=" > /etc/systemd/system/systemd-timesyncd.service.d/virt.conf
systemctl daemon-reload
systemctl restart systemd-timesyncd.service
Das Delta aller überschriebenen Parametern wird im Diff-Format durch “systemd-delta” ausgegeben.

Mit dem Befehl timedatectl nach Bedarf die Gültigkeit der Einstellungen überprüfen.

systemd-resolved

Bevor ich zur eigentlichen Konfiguration des Netzwerks komme, ein paar Worte zur Besonderheit des networkd.

Die Datei “/etc/resolv.conf” wird vom networkd nicht berührt. Stattdessen kommt der Dienst resolved zum Einsatz, der eine dynamische “resolv.conf”-Datei generiert und unter “/run/systemd/resolve/resolv.conf” bereitstellt. Für Kenner des Paketes “resolveconf” nichts neues.
Diese Datei wird im Anschluss nach “/etc/resolv.conf” verlinkt.

Vielleicht doch noch ein paar Worte dazu… Ich denke, dass sich viele User schwer mit dem Gedanken tun, dass Nameserver nicht Bestandteil einer TCP/IP-Konfiguration sind, auch wenn es die Windows-Netzwerkkonfiguration suggeriert.
DNS ist ein eigener Dienst, “nice to have”, aber für den Transport nicht notwendig. Im Gegensatz zu TCP und IP (Vermittlung und Transport), baut DNS als Anwendung (!) auf diese auf. Ein Mailserver hätte hier einen ähnlichen Stellenwert.

Zuerst aktiviere und starte ich den Dienst:

systemctl enable systemd-resolved.service
systemctl start systemd-resolved.service

Nun zur Konfiguration.

nano /etc/systemd/resolved.conf

[Resolve]
DNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844

Alle hier definierten DNS-Server unterliegen in ihrer Priorität denen, die ich in einer network-Datei im Verlauf festlege.
Die hier definierten Einträge werden jedoch als alternative Server hinter die primären DNS-Server angestellt.

Beispiel: Ich konfiguriere einen statischen DNS “192.168.1.1” in einer Datei “my.network”, habe in der Datei “/etc/systemd/resolved.conf” zusätzlich die DNS-Server “8.8.8.8 8.8.4.4″ eingetragen, so erhalte ich:

192.168.1.1
8.8.8.8
8.8.4.4

In späteren Systemd-Versionen wird resolved noch zwischen “DNS” und “FallbackDNS” unterscheiden können. Ein FallbackDNS käme nur zum Einsatz, wenn ansonsten keine Server definiert werden. Für das obige Beispiel würde das bedeuten, dass nur der DNS-Server 192.168.1.1 verwendet wird.

Im Anschluss erstelle ich den erwähnten Symlink und überschreibe eine evtl. vorhandene Datei “resolv.conf”:

ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

Den Dienst noch einmal neu starten:

systemctl restart systemd-resolved.service

Abschließend noch ein Hinweis zum Caching: Interessant wird es erst mit Systemd v216 (aktuell in Jessie: v215). Zudem stellte man Mitte November fest, dass das Caching des resolved angreifbar ist und daher vorert nicht eingesetzt werden sollte…

systemd-networkd

Die Netzwerk-Konfiguration findet in “/etc/systemd/network/” statt.
Hier reicht eine network-Datei für ein funktionierendes Netzwerk aus.

Angenommen mein Device “eth0″ möchte ans Netz:

nano /etc/systemd/network/einbeliebigername.network

# Was muss zutreffen, damit die Konfiguration vorgenommen wird?
[Match]
# Wildcards sind möglich! "Name=eth*" für die gleichzeitige Konfiguration vieler Interfaces ist denkbar, aber nur selten sinnvoll (Beispiel: DHCP)
Name=eth0

# Die Netzwerkkonfiguration
[Network]
# Wenn ich kein DHCP verwende...
#DHCP=v4
# ...lege ich statische Einträge fest.
Address=192.168.1.2/24
Gateway=192.168.1.254
DNS=192.168.1.1

Als Debian-User entferne ich die gesamte vorherige Konfiguration und Konfigurations-Methodik des Adapters…

ifdown eth0
cp /etc/network/{interfaces,interfaces_bak}
cat /dev/null > /etc/network/interfaces
update-rc.d networking remove

…um networkd zu aktivieren und zu starten:

systemctl enable systemd-networkd.service
systemctl start systemd-networkd.service

Im Verzeichnis “/etc/systemd/network/” sind außer network-Dateien noch netdev- und link-Dateien möglich.
netdev-Dateien erstellen virtuelle Geräte. Etwa Bridges, VLANs etc. link-Dateien
Eine link-Datei beschreibt Eigenschaften eines Netzwerkgerätes, etwa MACAddress, Duplex Modus etc.

Ein Blick in die Hilfe lohnt sich unbedingt: http://www.freedesktop.org/software/systemd/man/
Es gibt sehr viele Einstellungsmöglichkeiten, die ich nicht erwähnt habe, welche aber ausführlich in obigen Manpages beschrieben sind. Da Systemd sich in aktiver Entwicklung befindet, können durchaus Parameter auftauchen, die im eigenen System noch nicht erkannt werden.

7. Dezember 2014

Mozilla veröffentlicht Thunderbird 31.3

Permalink Sören Hentzschel

Mozilla hat in der vergangenen Woche nicht nur seinen Firefox-Browser aktualisiert, sondern mit Version 31.3 auch eine neue Version des E-Mail-Clients Thunderbird zum Download bereitgestellt.

Download Mozilla Thunderbird 31.3 für Windows, OS X und Linux

Die vergangene Woche veröffentlichte Version 31.3 behebt sechs Sicherheitslücken, von denen drei von Mozilla mit der höchsten Gefahrenstufe versehen worden sind. Darüber hinaus wurden wieder diverse Bugs behoben, unter anderem ein Problem mit der LDAP-Autovervollständigung, welche unter Umständen auf leere Einträge vervollständigen und dadurch Eingaben in das Empfängerfeld entfernen konnte. Außerdem behoben wurde der Fehler, dass IRC-Teilnehmer nicht aus der Teilnehmerliste entfernt worden sind, nachdem sie den Kanal verlassen haben.

Acer C720: Debian Kernel 3.17.5

Permalink blog.mdosch.de - Dies & Das

Der aktuelle Kernel für das C720 steht wieder hier zum Download bereit.

md5sum linux-image-3.17.5-c720_20141207_amd64.deb 
c535a14e721d01ba8ac7433680234e68  linux-image-3.17.5-c720_20141207_amd64.deb

sha1sum linux-image-3.17.5-c720_20141207_amd64.deb 
ac69b2de40c4fcb759bcd1a4996ff53cb4d34f99  linux-image-3.17.5-c720_20141207_amd64.deb

openSUSE 13.2 und das Heimnetzwerk (oder YaST, YaST, YaST)

Permalink (Mer)Curius

Einer der wesentlichen Vorteile der Linux-Welt ist ihre Vielfalt. Eine Vielfalt die man sich am besten zu Nutze macht, indem man sie möglichst auch benutzt. In diesem Sinne bin ich inzwischen gegen jede Form von Distributiondogmatismus, wenngleich die Überzeugung “das einzig wahre Linux einzusetzen” bei vielen Anwendern leider noch weit verbreitet ist. Besonders angetan hat es mir momentan openSUSE, das mit seinem 13.2er Release, den subjektiv besten Release seit Jahren hinbekommen hat. Eine Version, die mich mit dem Gecko wieder versöhnt hat, nachdem ich noch im September behauptet habe, dass ich den Weg zu openSUSE irgendwie nicht zurück gefunden habe.

Wenn man openSUSE einsetzt, merkt man das die Linux-Welt inzwischen ziemlich von Debian und seinen Derivaten dominiert wird. Letztlich funktionieren Mint, Ubuntu und Debian irgendwie ziemlich gleich. Abgesehen von der zugrunde liegenden Projektstruktur, den Releasezeitpunkten und Supportzeiträumen. OpenSUSE funktioniert in vielerlei Hinsicht anders und man muss sich darauf einlassen, um nicht enttäuscht zu werden. Dafür wird man aber auch belohnt mit einer sehr gut funktionierenden Distribution, die irgendwie gleichzeitig konservativ und progressiv ist. Einerseits beharrt man auf seinen Eigenheiten und liefert von Haus aus eine sehr konservative Softwareauswahl aus, andererseits sind Btrfs und XFS die Standarddateisysteme. Aber ich schweife ab…

Im Gegensatz zu den debianoiden Systemen hat openSUSE eine aktivierte Firewall. Persönlich finde ich das gar nicht so schlecht, da der einfache Nutzer, der ggf. über Abhängigkeiten ausversehen “Serversoftware” auf sein System holt gewissermaßen vor sich selbst beschützt wird. Leider blockiert diese Firewall auch die Anleitungen zum Heimnetzwerk mittels Samba und KDEConnect, die hier vor einiger Zeit thematisiert wurden. Als Anwender vermisst man hier schmerzlich die gute Ubuntu-Community, denn die Suche nach einer Lösung brachte vor allem viele Vorschläge aus dem Jahr ~2005 hervor.

Samba durch die Firewall lassen

Die Lösung besteht erst einmal darin die Firewall für Samba zu öffnen. Dies funktioniert am einfachsten im zugehörigen YaST-Modul.

YaST Portfreigabe

Im Bereich “Externe Zone” müssen die Dienste Samba-Client, Samba-Server und Netbios-Server  erlaubt werden. Sofern danach z.B. smb4k immer noch kein Heimnetz anzeigt, sollte man nicht verzweifeln, sondern das System einmal komplett neu starten. Der gute alte Windows-Trick tut es halt auch ab und an mal unter Linux.

Die Freigabeverwaltung erledigt man nun am besten auf die openSUSE-Art mittels des Samba-Modul in YaST. Das ist eigentlich selbsterklärend.

YaST Samba

Die Freigabe mittels Dolphin konnte ich bisher nicht zum laufen bekommen. Der Debian-Weg über das Anlegen der Gruppe sambashare und das Hinzufügen des eigenen Benutzers zur selbigen funktioniert unter openSUSE scheinbar nicht. Hier vermisst man manchmal das hervorragende ubuntuusers-Wiki. Evtl. kennt ja ein Leser die Lösung.

KDE Connect

KDE Connect muss man auf dieselbe Art durch die Firewall lassen, wie man dies mit Samba getan hat. Der Dienst heißt passenderweise KDE Connect. Danach findet das Smartphone das openSUSE System bzw. umgekehrt. Zu beachten ist, dass KDE Connect nur im Extras-Repo enthalten ist, das manuell hinzugefügt werden muss. Dank der Paketquellenverwaltung in YaST kein Hexenwerk.

Danach hat man wieder ein funktionsfähiges Heimnetzwerk, das Smartphone, Notebook und Rechner miteinander verbindet.

Wochenrückblick 49/2014

Permalink deesaster.org

Der Wochenrückblick lässt das Geschehen der vergangenen Woche rund um Ubuntu, Linux und Open Source Revue passieren.

Rund um Ubuntu

Ubuntu Core Apps Hack Days

Zum Ende des Jahres veranstalten die Ubuntu-Entwickler ein weiteres Mal die „Ubuntu Core Apps Hack Days“. Von Montag, den 8. Dezember, bis Freitag, den 12. Dezember 2014, jeweils von 10 bis 22 Uhr treffen sich interessierte Ubuntu-Entwickler und Menschen, die es werden wollen, um gemeinsam die Core Apps von Ubuntu Touch weiter zu entwickeln und zu verbessern. Zu den Core Apps zählen Kalender, Terminal, Uhr, Dateimanager, Musik-Player, Wetter und Dokumentenanzeige.

Die Treffen finden im IRC im Raum #ubuntu-app-devel auf irc.freenode.net statt. Daneben gibt es am Mittwoch einen Qualitätsworkshop mit Nicholas Skapps, bei dem man über Ubuntu On-Air live Fragen stellen kann.

Quelle: Ubuntu Developer Blog

Neues rund um Linux

Creative-Commons-Lizenzen sorgen für Ärger bei Flickr

Viele Flickr-Nutzer stellen ihre Fotos und Bilder unter einer Creative-Commons-Lizenz in dem Portal online, was prinzipiell positiv für die Community ist. Einige Urheber nutzen dazu die sehr freizügige CC-BY-SA-Lizenz, die auch explizit eine kommerzielle Nutzung der Bilder erlaubt.

Dies sorgt nun für Ärger, weil Flickr einen Dienst anbietet, über den man diese Fotos ausdrucken und kaufen kann. Das Geld geht dabei aber an Yahoo und nicht an die Urheber. Einige Fotografen fühlen sich dadurch benachteiligt, obwohl die CC-Lizenz genau dieses Vorgehen seitens Flickr erlaubt.

Ob sich Flickr mit dieser Aktion einen Gefallen tut und einige Fotografen ihre Bilder nicht lieber woanders einstellen, ist unklar.

Quelle: Golem

Bereitstellung aller EU-Dokumente in offenen Formaten

Mit FixmyDocuments soll den europäischen Ämtern etwas unter die Arme gegriffen werden, was die Veröffentlichung ihrer Dokumente mit einem offenen Standard angeht. Seitens der Europäische Kommission gibt es eine Empfehlung, Dokumente als OpenDocument oder OOXML zu veröffentlichen, woran sich aber nicht alle Ämter halten.

Maël Brunet, der Organisator der Kampagne, fordert die EU auf, dies nun umzusetzen und will dabei auch unterstützen. Dabei will er aber nur ODF als Standard zulassen, da die Implementierung des Microsoft'schen Standard OOXML nicht vollständig geklärt ist.

Quelle: Pro-Linux

Hardware und Mobiles

UbuTab – Das Ubuntu Tablet

Nachdem Jolla erfolgreich ein Tablet finanziert hat, soll es nun auch ein Tablet mit Ubuntu Touch geben. Das UbuTab wird aktuell noch bei Indiegogo finanziert, ob es tatsächlich das Ziel erreicht, ist noch unklar. Als Lieferzeitpunkt wird April 2015 angegeben, was angesichts der Tatsache, dass es noch kein einziges massentaugliches Mobilgerät mit Ubuntu Touch gibt, sehr gewagt erscheint.

Quelle: Pro-Linux

freiesMagazin 12/2014 erschienen

Permalink deesaster.org

freiesMagazin 12/2014 Titelseite

Heute ist die Dezemberausgabe von freiesMagazin erschienen und bringt viele spannende Artikel aus den Bereichen Linux und Open Source mit.

Inhalt der Ausgabe 12/2014

  • Ubuntu und Kubuntu 14.10
  • State of the Commons – Zustand der Creative-Commons-Lizenzen
  • Der November im Kernelrückblick
  • Git-Tutorium – Teil 1
  • Shellskript podfetch – Podcasts automatisch herunterladen
  • Broken Age
  • Eine Einführung in Octave
  • Ubucon 2014 in Katlenburg-Lindau
  • Interview mit den Musikpiraten
  • Rezension: Schrödinger lernt HTML5, CSS3 und JavaScript
  • Rezension: Java – Eine Einführung in die Programmierung
  • Die dritte Katastrophe – Teil 2
  • FAQ zum siebten freiesMagazin-Programmierwettbewerb
  • Leserbriefe und Veranstaltungen

Downloads

Unter der Adresse http://freiesmagazin.de/mobil/ findet man immer die aktuelle und alle bisher erschienenen HTML- und EPUB-Ausgaben. Auf der Magazin-Seite können die letzten drei Ausgaben von freiesMagazin abgerufen werden, ältere Ausgaben findet man im Archiv.

Kontakt

Wer jeden Monat an die neue Ausgabe erinnert werden will, kann auch den RSS-Feed abonnieren. Leserbriefe mit Lob, Kritik, Anregungen oder Fragen und neue Artikelvorschläge können an die Redaktion geschickt werden.

6. Dezember 2014

KurzeTipps – Die Befehle diff und patch

Permalink DevDiary

Wer sich mit Programmieren beschäftigt stößt garantiert irgendwann auf dass Thema Versionskontrolle.
Die nützliche Methode ermöglicht eine leichte Verwaltung von Quellcode und wird über kurz oder lang zu eines der Standard Werkzeuge eines jeden Programmierers.
Neben der Möglichkeit sich Systeme wie Git, Bzr und weite zu installieren ist aber jeder Linux-Standardinstallation schon die Basis für die Quellcodeverwaltung schon enthalten.

Die Befehle diff und patch ermöglichen die Änderungen von einer modifizierten Version der Originaldatei in dass Original zu übernehmen.
Dabei können bei jedem Vorgang auch Backups angelegt werden und Änderungen auch wieder rückgängig gemacht werden.

Schritt 1

Als erstes muss eine diff Datei über den Befehl diff angelegt werden.
Dazu benutzt man den folgenden Befehl und ändert die Namen in diesem auf die eigenen.

diff -uNr „main.c“ „main_patch.c“ > „main_patch.diff“

Argumente

Argument Beschreibung
-u (unified) Es werden NUM (Standard 3) von unveränderten Zeilen ausgeben.
-N (New) Die fehlenden Dateien werden erstellt.
-r (rekursiv) falls vorhanden werden die Unterverzeichnisse verglichen.

Der Befehl bewirkt dass die Änderungen von der Datei „main_patch.c“ gegenüber der Ursprungsdatei „main.c“ in „main_patch.diff“ geschrieben werden.

Schritt 2

Nun wird die Originaldatei mithilfe der diff Datei gepatcht.
Dazu wird der Befehl patch verwendet wobei auch hier die Dateinamen auf die eigenen abgeändert werden müssen.

patch -p1 „main.c“ 

Argumente

Argument Beschreibung
-pNUM Zieht von dem Dateinahmen NUM führende Komponenten ab.
-R Macht ein zuvor angewendeten Patch wieder rückgängig.

Nun werden die Änderungen welche in der Datei „main_patch.diff“ protokolliert wurden in die Ursprungsdatei „main.c“ übernommen.

Schritt 3

Um dass ganze wieder rückgängig zu machen braucht man nur die Ursprungsdatei und die jeweilige diff Datei.
Die Befehlsstruktur ist ähnlich der von Schritt 2 und hat vor der Angabe der Anzahl von Striplevel (-p1) noch dass Argument „-R“.

patch -R -p1 „main.c“ 

Nun wird genau dass Gegenteil von Schritt 2 gemacht und z.b. alle Änderungen die in der diff Datei stehen und etwas hinzufügen sollen gelöscht.

Gnome Screenshot Tool: Ganzer Bildschirm wird farbig gefüllt

Permalink thomas-leister.de

Über die letzten Monate hinweg hatte ich ein nerviges Problem mit dem Gnome Screenshot Tool. Über die Tastenkombination SHIFT + DRUCK kann man Screenshots von beliebigen Bereichen des Desktops machen. Mit einem Cursor zieht man die Fläche auf, die abgelichtet werden soll. Das Problem war, dass ausgerechnet in diesem Screenshot-Modus der gesamte Bildschirm mit einem farbigen Layer überdeckt wurde, sodass man nicht mehr sehen konnte, wo man den Cursor gerade ansetzt. Erst durch das Aufziehen der Fläche wurden wieder Teile des Desktops freigelegt. Man konnte also nicht erkennen, wo man gerade den Cursor ansetzt und musste den fotografierten Bereich abschätzen.

Jetzt habe ich endlich die Ursache für das Problem gefunden:

Um die Gnome-Performance zu verbessern, wird manchmal empfohlen, in der Datei /etc/environment diese Einstellung zu setzen:

CLUTTER_PAINT=disable-clipped-redraws:disable-culling

… leider hat sie die Nebenwirkung, dass gerade dieser farbige Layer über den Bildschirm gelegt wird, der einem die Sicht bei der Bereichsauswahl verdeckt. Wird die Zeile wieder auskommentiert, funktioniert das Screenshot Tool wieder einwandfrei.

Ubuntu: Eigenen Firefox Syncserver 1.5 und Accountserver installieren

Permalink thomas-leister.de

Seit Firefox Version 29 ist das neue Mozilla Sync 1.5 verfügbar. Während beim alten Sync 1.0 ein einzelner Syncserver noch ausgereicht hat, ist das beim neuen Sync v1.5 nicht mehr der Fall. Neben einem Syncserver ist nun auch ein separater „Accountserver” für den Betrieb notwendig. Das macht ein komplett selbst gehostetes Sync-Setup zwar komplexer, aber nicht unmöglich – denn natürlich sind auch die neuen Serverkomponenten unter einer freien Softwarelizenz verfügbar.

Es gibt zwei Möglichkeiten, seine Sync-Daten selbst zu hosten:

  • Einfaches Setup: Nur der Syncserver wird auf dem eigenen Server installiert. Für die Authentifizierung wird auf die offiziellen Mozilla Accountserver zugegriffen.
  • Vollständig selbst gehostete „Firefox Cloud”: Wer keine halben Sachen mag und seine Firefox Cloud gerne komplett selbst kontrollieren will, kann auch einen eigenen Accountserver zusätzlich zum Syncserver installieren.

In diesem Artikel soll es um eine vollständig selbst eingerichtete Firefox Cloud unter Ubuntu Server 14.04 gehen. Sowohl Syncserver als auch Accountserver werden selbst gehostet. Wer lieber das einfachere Setup hat, überspringt einfach die entsprechenden Stellen in dieser Anleitung und stimmt sie ggf. auf den alleinigen Betrieb des Syncservers ab.

Damit der Verknüpfung der einzelnen Serverkomponenten verständlicher ist, habe ich diese Grafik erstellt:

Mozilla Sync Server Schema

Mozilla Sync Server Schema

Die Kommunikation der einzelnen Komponenten findet über z.T. lokal geöffnete TCP Ports statt. (In der Grafik eingezeichnet). Da jegliche Kommunikation mit der Außenwelt über einen Nginx Reverse-Proxy stattfinden soll, werden alle Ports nur an die lokale Adresse 127.0.0.1 gebunden. Letztendlich wird von außen nur über die drei links eingezeichneten HTTP-Schnittstellen bzw. Subdomains auf die Firefox Cloud zugegriffen.

Für den Accountserver kommt Node.js zum Einsatz. Der Syncserver basiert auf Python.

sudo apt-get install nodejs nodejs-legacy npm python

Für den Download der Serverkomponenten wird Git benötigt:

sudo apt-get install git-core

Vorausgesetzt werden: MySQL Datenbankserver, Nginx Webserver und ein SMTP-Mailserver (z.B. Postfix) für den E-Mail Versandt – jeweils bereits installiert und grundlegend konfiguriert.

Bevor ihr mit der Installation beginnt, noch ein Hinweis: Diese Anleitung ist während meiner Recherche und Installation eines eigenen Setups entstanden. Zum gegenwärtigen Zeitpunkt hat sie also experimentellen Status, weil sie als Gesamtwerk noch nicht „in einem Zug” getestet wurde. Solltet ihr Fehler oder eine Lösung für mögliche Probleme finden, wäre ich dankbar, wenn ihr mir diese kurz via E-Mail melden könntet (Kontaktdaten siehe oben im Menü „Kontakt”). Umgekehrt wäre es toll, wenn ihr mir auch bei erfolgreicher Installation kurz in den Kommentaren Bescheid geben könntet, damit ich weiß, ob die Anleitung in dieser Form funktioniert. Mein eigenes Setup funktioniert schon seit 2 Wochen wunderbar, dennoch kann es sein dass ich bei der Beschreibung der einzelnen Einrichtungsschritte etwas vergessen habe.

So. Jetzt geht’s aber los …

„Firefox Cloud”-Umgebung schaffen

Alle Firefox Cloud Server sollen unter einem eigens dafür eingerichteten Benutzer (fxcloud) laufen, damit bei Sicherheitsproblemen in der Serversoftware nicht das gesamte System kompromittiert werden kann. Auf keinen Fall sollten die Server als root ausgeführt werden!

Separaten Systembenutzer erstellen:

adduser --disabled-password --disabled-login fxcloud

Als Benutzer „fxcloud” einloggen:

sudo -i -u fxcloud

Einrichtung des Auth-DB Servers

Für die Kommunikation mit dem MySQL Datenbankserver wird der sog. „FXA Auth DB Server” benötigt. Er bildet die Schnittstelle zwischen Auth-Server und der Datenbank, die die Accountdaten enthält.

Zuerst sollte eine neue MySQL Datenbank erstellt werden inkl. eigenem, neuen Benutzer, der nur Zugriff auf diese Datenbank hat. Die Datenbank und den Benutzer für den Auth-Server nenne ich „fxacc”. Sobald Datenbank und Benutzer auf dem MySQL Server eingerichtet sind, kann mit der Installation des Auth-DB-Servers begonnen werden:

Installation

Herunterladen des Servers von GitHub:

git clone https://github.com/mozilla/fxa-auth-db-server.git
cd fxa-auth-db-server

Installieren der notwendigen Node.js -Komponenten

npm install

(dieser Vorgang kann einige Minuten dauern)

Konfiguration

Eine neue Konfigurationsdatei „prod.json” wird erstellt:

cd config
nano prod.json

Inhalt der neuen Datei sind die Zugangsdaten zur vorher eingerichteten Datenbank, z.B.:

{
  "master": {
    "user": "fxacc",
    "password": "passwort",
    "database": "fxacc"
  },
  "slave": {
    "user": "fxacc",
    "password": "passwort",
    "database": "fxacc"
  }
}

Zum Testen der Datenbankverbindung kann der Server kurz gestartet werden:

cd ../
npm start

Entsprechende Ausgaben über eine erfolgreiche oder fehlgeschlagene Verbindung sollten in der Konsole erscheinen.

Beenden des Servers via:

STRG + C

(evtl. zusätzlich ENTER, um zurück Prompt zu gelangen)

Einrichtung des Auth-Servers

Der Auth-Server stellt die API zur Authentifizierung der Benutzer bereit.

Installation

cd ~

Für den Auth-Server werden zwei Bibliotheken auf dem Server nachinstalliert:

sudo apt-get install libgmp10 libgmp-dev

(Für das „sudo” Kommando muss der aktuelle fxcloud-User möglicherweise kurz verlassen werden)

FXA-Auth-Server herunterladen:

git clone git://github.com/mozilla/fxa-auth-server.git
cd fxa-auth-server

Node.js-Abhängigkeiten installieren:

npm install

(der Vorgang kann einige Minuten dauern)

Um zu sehen, ob die Installation vollständig ist, kann folgendes Kommando zum Testen ausgeführt werden:

npm test

Erscheint am Ende ein „Done, without errors.”, ist die Installation komplett.

Konfiguration

Die bereits bestehende Konfigurationsdatei „dev.json” wird bearbeitet:

cd config
nano dev.json

„publicUrl” wird auf die URL gesetzt, über die der Auth-Server (API) später via Nginx erreichbar sein soll. (Vgl. Grafik oben). Die URL des Contentservers wird ebenfalls entsprechend angepasst.

Außerdem werden die SMTP-Server (Postausgang) Zugangsdaten zu einem E-Mail Account angegeben, über den später die E-Mails zur Accountbestätigung verschickt werden. Die Einrichtung dieses E-Mail Servers ist notwendig, weil sonst keine Neuregistrierungen auf dem Accountserver möglich sind.

{
  "env": "prod",
  "publicUrl": "https://fxaccount-api.domain.tld",
  "contentServer": {
    "url": "https://fxaccount.domain.tld"
  },
  "smtp": {
    "host": "smtp.domain.tld",
    "port": 25,
    "user": "fxacc@domain.tld",
    "password": "mailpassword",
    "secure": false,
    "sender": "Firefox Accounts Server <fxacc@domain.tld>"
  },
  "log": {
    "level": "info"
  },
  "customsUrl": "none"
}

Contentserver installieren

Der Contentserver liefert die HTML-Seiten aus, die z.B. für die Registrierung eines neuen Accounts, das Ändern des Passworts oder die Löschung des Accounts notwendig sind.

Installation

cd ~
git clone https://github.com/mozilla/fxa-content-server.git
cd fxa-content-server

Installieren der Abhängigkeiten:

npm install

(kann einige Minuten dauern)

Konfiguration

cd server/config/

Die Beispieldatei wird kopiert:

cp local.json-dist local.json
nano local.json

In der local-json-Konfigurationsdatei werden die eigene URL (public_url) sowie die URL zum API Server (fxaccount_url) festgelegt. Das „secret” wird auf einen beliebigen, zufälligen Wert gesetzt.

{
  "public_url": "https://fxaccount.domain.tld",
  "fxaccount_url": "https://fxaccount-api.domain.tld",
  "api_proxy": {
    "enabled": true
  },
  "oauth_client_id": "98e6508e88680e1a",
  "oauth_url": "http://127.0.0.1:9010",
  "profile_url": "http://127.0.0.1:1111",
  "profile_images_url": "http://127.0.0.1:1112",
  "client_sessions": {
    "cookie_name": "session",
    "secret": "thisis8735ara545nd4omstring",
    "duration": 86400000
  },
  "env": "production",
  "use_https": false,
  "static_max_age" : 0,
  "i18n": {
    "supportedLanguages": ["af", "an", "ar", [...] "zu"]
  },
  "route_log_format": "dev_fxa",
  "static_directory": "app",
  "metrics": {
    "sample_rate": 0
  }
}

Sync Server einrichten

Der Sync Server nimmt nach erfolgreicher Authentifizierung des Nutzers dessen Daten entgegen und legt sie in einer MySQL Datenbank ab.

sudo apt-get install python-dev python-virtualenv

(Für das „sudo” Kommando muss der aktuelle fxcloud-User möglicherweise kurz verlassen werden)

Installation

Sync Server herunterladen und installieren:

git clone https://github.com/mozilla-services/syncserver.git
cd syncserver
make build

Konfiguration

Die Syncserver-Konfiguration befindet sich in der Datei „syncserver.ini”. Zunächst muss eine weitere Datenbank mit einem dazugehörigen Nutzer angelegt werden, der vollen Zugriff auf diese Datenbank hat. (To do!)

In meinem Beispiel: Die Datenbank „fxsync” mit dem Nutzer „fxsync” und dem Passwort „passwort”. Die Zugangsdaten werden wie folgt in die Konfiguration eingetragen:

sqluri = pymysql://fxsync:passwort@127.0.0.1/fxsync

Der Datenbankserver läuft hierbei lokal (127.0.0.1). Evtl. muss die Adresse angepasst werden. In der Konfigurationsdatei wird außerdem ein „secret” festgelegt – eine geheime, zufällige Zeichenkette die vom Server gebraucht wird. Eine passende Zeichenkette kann z.B. mit dem Befehl

head -c 20 /dev/urandom | sha1sum

erzeugt werden.

Für bessere Performance soll der Gunicorn WSGI Server zusammen mit Nginx genutzt werden. Dafür muss Gunicorn zunächst installiert werden:

./local/bin/easy_install gunicorn

Der obere Teil der Konfiguration wird an Gunicorn angepasst:

[server:main]
use = egg:gunicorn
host = 127.0.0.1
port = 5000
workers = 2
timeout = 60

#[server:main]
#use = egg:Paste#http
#host = 0.0.0.0
#port = 5000

(Die alte Konfiguration wurde auskommentiert.)

Weiter unten wird „public_url” angepasst. In meinem Beispiel soll der Sync Server unter der Adresse „https://fxsync.domain.tld” verfügbar sein. Die untersten drei Zeilen („[browserid] und folgende) werden auskommentiert.

Eine vollständige Konfigurationsdatei sieht z.B. so aus:

[server:main]
use = egg:gunicorn
host = 127.0.0.1
port = 5001
workers = 2
timeout = 60

[app:main]
use = egg:syncserver

[syncserver]
public_url = https://fxsync.domain.tld/
sqluri = pymysql://fxsync:passwort@127.0.0.1/fxsync
secret = 484873d057hj30968b52c3chh30ks3012aeff4jja

# allow_new_users = false

[browserid]
backend = tokenserver.verifiers.LocalVerifier
audiences = https://fxsync.domain.tld

Nginx Reverse Proxy konfigurieren

Einen installierten Nginx Webserver und die entsprechenden Grundkenntnisse setze ich hier voraus.

Da sich die Server allesamt über verschiedene Ports laufen und man diese bei der späteren Firefox-Konfiguration für den Zugriff mit angeben müsste, ist es eleganter, die Server hinter einer Proxyserver und getrennte Subdomains laufen zu lassen. Wie schon aus der zu Beginn gezeigten gezeigten Grafik hervorgeht, werden den folgenden Subdomains diese Ports / Server zugeordnet:

  • https://fxaccount-api.domain.tld => Port 9000 (FX Auth API)
  • https://fxaccount.domain.tld => Port 3030 (FX Auth Content Server)
  • https://fxsync.domain.tld => Port 5000 (FX Sync Server)

Natürlich könnte man auch via domain.tld:9000 z.B. auf die API zugreifen – das ist aber nicht besonders schön und auch nicht so leicht zu merken. Deshalb bekommen die drei öffentlichen Ports nun je eine passende Subdomain zugewiesen.

Die drei Konfigurationsdateien für Nginx sehen ähnlich wie diese aus (Beispiel für https://fxaccount.domain.tld):

server {
  listen 443 ssl;
  listen [::]:443 ssl;
  server_name fxaccount.domain.tld;
  
  ssl_certificate /etc/myssl/public.pem;
  ssl_certificate_key /etc/myssl/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:3030/;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_redirect off;
    proxy_read_timeout 120;
    proxy_connect_timeout 10;
  }
}

Angepasst werden müssen jeweils der server_name, die Pfade zu den SSL Zertifikaten und der Port, auf den der Proxy verweisen soll. Die Ports der einzelnen Server können auch in den Konfigurationen angepasst werden. Wichtig ist nur, dass ggf. auch in fremden Konfigurationen die richtigen Ports angegeben sind! ;)

Upstart Scripte erstellen

Zum Starten der Server werden Upstart-Scripte angelegt. Sie werden beim Serverstart automatisch ausgeführt, sodass man nicht jeden Dienst einzeln von Hand starten muss.

Unter /etc/init/ werden mit root-rechten drei Dateien angelegt: fxa-auth-db-server.conf, fxa-auth-db-server.conf fxa-content-server.conf und fx-sync-server.conf. Die Inhalte der Dateien:

fxa-auth-db-server.conf:

# description "Start the fxa-auth-db-server"

start on runlevel [2345]
stop on runlevel [^2345]

console log
chdir /home/fxcloud/fxa-auth-db-server
setuid fxcloud
setgid fxcloud

env HOME=/home/fxcloud
respawn
respawn limit 20 5

exec npm start

fxa-auth-server.conf:

# description "Start the fxa-auth-server"

start on runlevel [2345]
stop on runlevel [^2345]

console log
chdir /home/fxcloud/fxa-auth-server
setuid fxcloud
setgid fxcloud

env HOME=/home/fxcloud
respawn
respawn limit 20 5

exec npm start

fxa-content-server.conf:

# description "Start the fxa-content-server"

start on runlevel [2345]
stop on runlevel [^2345]

console log
chdir /home/fxcloud/fxa-content-server
setuid fxcloud
setgid fxcloud

env HOME=/home/fxcloud
respawn
respawn limit 20 5

exec npm start

fx-sync-server.conf:

# description "Start the fx-sync-server"

start on runlevel [2345]
stop on runlevel [^2345]

console log
chdir /home/fxcloud/syncserver
setuid fxcloud
setgid fxcloud

env HOME=/home/fxcloud
respawn
respawn limit 20 5

exec make serve

Nachdem die Scripte angelegt wurden, können sie auch manuell gestartet werden:

sudo start fxa-auth-db-server
sudo start fxa-auth-server
sudo start fxa-content-server
sudo start fx-sync-server

Alle Server sollten jetzt über die jeweilige Subdomain erreichbar sein.

Server im Firefox einrichten

Firefox

Damit Firefox nicht die offiziellen, sondern die eigenen Server für den Account und die Synchronisierung verwendet, müssen ein paar Einträge in der Konfiguration geändert werden. Gebt „about:config” in die Adressleiste ein, um auf die Konfigurationseinträge von Firefox zuzugreifen. Sucht nach folgenden Einträgen und ändert ihre Werte:

  • identity.fxaccounts.auth.uri
    https://fxaccount-api.domain.tld/v1
  • identity.fxaccounts.remote.force_auth.uri
    https://fxaccount.domain.tld/force_auth?service=sync&context=fx_desktop_v1
  • identity.fxaccounts.remote.signin.uri
    https://fxaccount.domain.tld/signin?service=sync&context=fx_desktop_v1
  • identity.fxaccounts.remote.signup.uri
    https://fxaccount.domain.tld/signup?service=sync&context=fx_desktop_v1
  • identity.fxaccounts.settings.uri
    https://fxaccount.domain.tld/settings
  • services.sync.tokenServerURI
    https://fxsync.domain.tld/token/1.0/sync/1.5

Achtet bei der letzten URL auf das eingefügte „token/”!

Firefox für Android

Für die Firefox Android App gibt es ein spezielles Addon, über das die eigenen Server eingerichtet werden. Installiert über „Menü => Extras => Addons” das Addon „fxa-custom-server-addon”. Nach der Installation erscheint im Menü ein neuer Punkt „Custom Firefox Account”. In den Account- und Sync-Einstellungen werden diese Adressen angegeben:

  • https://fxaccount-api.domain.tld/v1
  • https://fxsync.domain.tld/token/1.0/sync/1.5

Danach werden die Einstellungen abgespeichert und das Sync-Setup gestartet. („Menü => Einstellungen => Sync” oder Start direkt über das Addon)

Registrieren und Einloggen

Die Registrierung eines neuen Accounts sollte selbsterklärend sein. E-Mail-Adresse, Passwort und das Geburtsdatum müssen angegeben werden. Danach wird eine E-Mail zur Accountbestätigung verschickt. (Sollte diese E-Mail nicht eintreffen, müssen die Mailserver-Einstellungen nochmals geprüft werden! Ohne E-Mail: Kein Account!). Nach der Bestätigung kann sich der Benutzer über die Firefox Sync Einstellungen einloggen oder die Weboberfläche direkt aufrufen: https://fxaccount.domain.tld.

Neuregistrierungen verhindern

Falls sich keine fremden User auf den eigenen Servern registrieren sollen, kann die Einstellung „# allow_new_users = false” in der Syncserver-Konfiguration einkommentiert werden. Nach einem Neustart des Syncservers wird die Einstellung aktiv und verhindert, dass neue User ihre Daten auf den Server hochladen.

 

Quellen: https://docs.services.mozilla.com/howtos/run-fxa.html  |  https://docs.services.mozilla.com/howtos/run-sync-1.5.html

5. Dezember 2014

Sound-Cloud oder MP3-Recycling à la Steve

Permalink Intux

soundsearchVor einigen Jahren, in Zeiten als Speicherplatz noch recht teuer war, rippte ich meine CDs noch mit dem Audiograbber unter Windows. Die Zeiten ändern sich ja bekanntlich. Die Speicher-Preise verfielen zusehens. Musik kauft man inzwischen online. CD-Sammlungen sind out. Auch die vorherrschende Meinung eine höhere Bitrate von 192kBit/s macht keinen Sinn, da das menschliche Gehör das eh nicht wahrnimmt hat sich bei den Experten geändert. Online gekaufte Musik hat in der Regel heutzutage eine bessere Qualität. Inzwischen ist bei mir Windows einem Linux gewichen.

Meine MP3s wurden damals auch so von mir mühsam mit 192kBit/s erzeugt. Da ich nun mittlerweile Musik über Google Play kaufe und diese dann zu Hause problemlos via WLAN auf mein Smartphone lade, wird für mich privat die Google Sound-Cloud immer wichtiger. Man muss dazu sagen: es geht auch anders, via ownCloud etc.

Als ich vor zwei Jahren die Biographie von Steve Jobs las, fand ich diesbezüglich eine Passage interessant. Und zwar ging es um die private Musik, mit der man iTunes füttert. Läd man seine Musik in iTunes in schlechterer Qualität hoch als diese dort in den Bibliotheken vorhanden ist, so hat man später Zugriff auf die beste Qualität die iTunes zu bieten hat.

Nun zurück zur Sound-Cloud von Google. Ich dachte mir, warum soll Google das nicht auch bieten? Also begann ich meine komplette private Musik hochzuladen. Zum einen kann ich auf Android-Endgeräten diese nun streamen, zum anderen direkt auf das Gerät laden. Hierbei merkte ich, dass Google den gleichen Weg wie iTunes geht und ich nun meine Musik, wenn diese in Google Play vertrieben wird, in bester Qualität zurück erhalte. Selbst wenn ich diese Musik wieder als MP3 downloade, bekomme ich die Titel in der Regel mit 320kBit/s.

So konnte ich nun Platz auf meinem Notebook schaffen und verwalte meine Musik jetzt online. In der Regel werden hier auch die entsprechenden Cover hinzugefügt. Für mich ist das eine runde Sache.

Zu erwähnen wäre aber noch, dass man um diesen Dienst zu nutzen eine Kreditkarten-Nummer hinterlegen muss. So kann man dann auch bequem später Musik online kaufen. Des Weiteren wird der Google Music Manager benötigt, um die Stücke in die Sound-Cloud zu laden. Hierbei ist es möglich bis zu 20.000 Titel dem Account hinzuzufügen. Der Google Music Manager ist für Linux, Windows und Mac OS erhältlich und kann hier herunter geladen werden.

Literaturverwaltung: Gedanken über Programme, Synchronisation und Datenschutz

Permalink (Mer)Curius

Wenn das Thema auf Literaturverwaltung & Co kommt, kann man eigentlich nur vom Einsatz von Linux abraten. Literaturverwaltung, Wissensmangement und alles was damit zusammen hängt gehört nicht zu den Stärken des Linux-Desktops. Man muss schon enorme anderweitige Vorteile durch den Einsatz von Linux erzielen, damit man die Abstriche in diesem Bereich in Kauf nimmt. Die beiden großen Platzhirsche des Bereiches, EndNote und Citavi, lassen sich nicht unter Linux einsetzen. Für Citavi gibt es zwar eine Wine-Lösung, basierend auf der älteren Version 3.x, aber das kann je nach Wine- und/oder Citavi Update auch wieder nicht funktionieren. Ein Zustand, der bei langfristigen Projekten nicht in Frage kommt. Zumal man sich von einer Lösung abhängig macht, da der Im- und Export der Daten immer verlustbehaftet ist.

Der geneigte Anhänger der Unix-Philosophie würde hier zwar mit Phrasen  um sich werfen um die Diskussion im Keim zu ersticken (“Schreibe Computerprogramme so, dass sie nur eine Aufgabe erledigen und diese gut machen.“). Das Problem ist nur, dass man Citavi noch nicht mal mit drei Softwarelösungen unter Linux ersetzen kann. Nun aber genug der Worte über nicht vorhandene Software und Philosophien, deren aktuelle Auslegungen zum Ziel haben den Status quo zu zementieren.

Möglichkeiten der Literaturverwaltung unter Linux

Dadurch bleiben für den Linux-Desktop eigentlich nur zwei bzw. drei Lösungen übrig. Erstens webbasierte Lösungen, ggf. mit einem lokalen Client (z.B. Mendeley), zweitens Frontends für das BibTeX Format (z.B. JabRef oder KBibTeX) und drittens Zotero. Letzteres gibt es als Firefox-Addon oder als Standalone-Version. Alle Lösungen sind mit enormen Abstrichen gegenüber den führenden Windows-Produkten zu nutzen, aber eine dauerhafte Literaturverwaltung in einer virtualisierten Windows-Umgebung ist ebenfalls mit deutlichen Komfortverlusten verbunden und deshalb keine wirkliche Alternative.

Die für Linux vorhandenen Softewarelösungen haben alle Stärken und viele Schwächen:

  • Die mächtigste Lösung ist hier zur Zeit Zotero. Dieses kann Literatur verwalten, zugehörige Notizen sicher gruppieren und an Literaturtitel angehängte Dateien verwalten. Zudem gibt es eine Reihe von Addons (z.B. für Microsoft Office und LibreOffice) und Zitationsstilen, die eine schnelle Übernahme in das Office-Programm der Wahl ermöglichen.
  • Mendeley spielt seine Stärken hingegen eher in der PDF-Verwaltung aus. Durch die Synchronisation von Anmerkungen über den Webaccount, ist es vor allem für PDF-gestützte Arbeiten von großem Wert. Wer hingegen klassisch mit Büchern (das waren diese in Leinen gebundene Dinger, mit Papier dazwischen) und Kopien arbeitet, wird mit Mendeley kaum Freude haben.
  • Die klassischen BibTeX-Lösungen bieten am wenigsten Komfort und fokussieren sich primär auf die Verwaltung von Literaturtiteln. Der Programmumfang von JabRef (Java-basiert, plattformübergreifend) und KBibTex (KDE-Program) ist hier annähernd identisch. Dafür haben sie den Vorteil, dass sie anstelle einer kryptischen Datenbank ein lesbares Dateiformat ausgeben, dass hinreichend standardisiert ist. Gerade bei Projekten, die über viele Jahre gehen, ist das ein unschlagbares Argument. Man möchte ja nicht wie manch altgedienter Wissenschaftler enden, der erstmal seine virtualisierte Windows 95 Umgebung startet, wenn er die Literaturdatenbank durchsuchen will.

Synchronisation und Datenschutz

Die Welt war noch so einfach, als man nur einen PC hatte. Man hatte seine Literaturdatenbank zwar nicht immer dabei, aber dafür wenigstens auch nur eine Version selbiger. Den Rest erledigte man mit Papier und Stift und trug es bei Gelegenheit ein. Das kann man theoretisch auch heute noch so machen, aber in Zeiten, in denen man eine wachsende Anzahl an Endgeräten sein Eigen nennt, erwartet man etwas mehr von seiner Literaturverwaltung. Zumal, da die Übertragung von Titel mühevoll und zeitfressend ist. Dies ist übrigens ein Punkt, in dem auch Citavi nicht glänzt. Zwar kann man die Software auf mehreren Geräten installieren (oder portabel), aber man hat dennoch immer nur eine Datenbank, die man nach jedem Arbeitsvorgang übertragen muss. Eine automatische Cloudsynchronisation funktioniert aufgrund des automatischen Speichersystems nicht. Letztlich hat man dann immer genau auf dem Gerät, an dem man gerade sitzt keine aktuelle Datenbank.

Wo wir auch schon beim Thema wären. Die Lösung der Wahl ist meist eine Synchronisation über die Hersteller-eigene Cloud. So zumindest bei Zotero, EndNote und Mendeley. Das Problem ist hier offensichtlich. In einer gut gepflegten Literaturdatenbank besteht je nach Wissenschaftzweig annähernd die ganze Arbeitsleistung. Diese Daten in die Cloud zu schieben, ohne genau zu wissen was die Hersteller damit anfangen ist waghalsig. EndNote ist ein kommerzielles Produkt und lässt sich nach Lizenzen bezahlen, Zotero wird nach besser Open Source Manier an einer Universität entwickelt, aber z.B. Mendeley (oder andere Freemium-Produkte) gehört einem Verlag und muss irgendwann mal Geld erwirtschaften. Hier ist es wie bei vielen anderen Bereichen: Bezahlt man keine Euros, bezahlt man mit seinen Daten.

KBibTex

An diesem Punkt kommt das gute (alte) BibTeX Format ins Spiel. Die Datei lässt sich Problemlos auf dem heimischen Cloudspeicher (z.B. ownCloud) ablegen und darüber synchronisieren. Diese Lösung liegt so nah, wird aber oft nicht gesehen oder durch die Programme und ihre fixen Dateipfade torpediert. Insbesondere bei KBibTeX¹ lassen sich angehängte Dateipfade relativ zur Datenbank angeben, wodurch die Struktur (und integrierte Vorschau) auch bei größeren Umstrukturisierungsvorgängen erhalten bleibt. Die Dateibenennung bleibt zwar Handarbeit, aber ein bisschen händische Verwaltung schadet nicht, weil man dadurch die Kontrolle behält. Nichts ist ärgerlicherer, als eine undurchsichtige Ablagestruktur, die bei einem Ausfall des Programms vollkommen unverständlich ist (selbst wenn man die PDFs noch einzeln aufrufen kann).

KBibTex_DatenbankverwaltungMit KBibTex lassen sich sich zudem verschiedene .bib Datenbanken einfach verwalten, was die komplexe Kategoriestruktur von Citavi wenigstens teilweise ersetzen kann. So lässt sich zwischen verschiedenen Datenbanken hin- und herwechseln und Literaturtitel beliebig verschieben.

Als KDE-Programm besteht KBibTex aus einer Reihe frei platzierbarer Elemente (Reference Preview, Document Preview, List of Values, List of Document etc. pp.)., die sich je nach Bildaufschirmformat und Auflösung beliebig anordnen lassen. Meiner Ansicht nach ist dies die einzige zeitgemäße Lösung, da ein Programm bei derselben Platzaufteilung einfach nicht gleichzeitig auf einem 24″ Monitor und einem Notebook mit mieser 1368er Auflösung gut funktionieren kann.

Mit KBibTeX bewegt man sich nach Jahren mit Citavi zwar gefühlt in der Literaturverwaltungs-Bronzezeit (Steinzeit waren die Karteikarten), aber wenigstens kann man sich damit trösten, ein Format zu verwenden, das einen voraussichtlich nicht in wenigen Jahren im Stich lässt oder vollständig von einer Firma abzuhängen. Wissensmanagement muss man leider anderswo betreiben, aber das sind halt die Limitierungen des Linux-Desktops mit denen man entweder leben kann, oder zu Windows / MacOSX wechseln muss.


Zu 1: Wer KBibTeX nutzen möchte, sollte sich entweder eine Distribution suchen, die nicht von Debian abhängt, oder gleich selbst kompilieren. Der Entwickler macht zwar nur kleine Versionssprünge 0.x, aber die Unterschiede zwischen 0.4 und 0.5 sind gewaltig. Leider hat das Debian Science Team es in zwei Jahren nicht geschafft, die Version anzupassen. So viel auch zur vermeintlichen Sicherheit und Stabilität von Debian. OpenSUSE Nutzer können eine dauerhaft aktuelle Version über das KDE Extra Repo beziehen und Fedora-Anwender über die regulären Updates. CentOS/Scientific Linux/RHEL-Anwender müssen sich bei Fedora bedienen. Das sollte aber aufgrund der schmalen Abhängigkeiten kein Problem sein.


Artikelbildquelle: Books von Moyan Brenn unter CC 2.0 auf Flickr

Erste Schritte in Pyhton

Permalink Erfahrungen mit Ubuntu

Seit langem auf dem Wuschzettel,
jetzt gehe ich es mal so langam an.
Die Programmiersprache Python.

So mit als erstes kommmt natürlich ein "Hallo Welt", das sieht bei
mir in Python nun so aus:

    #!/usr/bin/env python
    # -*- conding: utf-8 -*-
    print("Hallo Welt")


Ganz einfach und Schnörkellos.

Bearbeitet habe ich es mit dem Texteditor joe,
aufruf z.b.:
joe helloworld.py

und ausführbar gemacht mit:
chmod +x helloworld.py

Wenn wir  nun eine Variable einlesen wollen,
z.b. ein Namen nutzen wir dafür raw_input.
In diesem Beispiel wird der Variable "meinname"
mittels raw_input ein Wert zugewiesen,
und dieses dann mit dem Wort "Hallo" zusammen in
der print Anweisung ausgegeben.


    #!/usr/bin/env python
    # -*- conding: utf-8 -*-
    print "Bitte gebe deinen Namen ein";
    meinname = raw_input();
    print "Hallo", meinname;


Eine Zahlenvariable wird mit int(input()) eingelesen.
Als Beispiel dieses kleine Programm.
Es fragt nach dem Namen, liesst dann das aktuelle Datum
und das Geburtsdatum mittels int(input()) ein und weisst
es als Integer Wert der Variable zu. Anschliessend wird das
aktuelle Datum vom Geburtsdatum subtrahiert und das
Ergebnis ausgegeben.

    #!/usr/bin/env python
    # -*- conding: utf-8 -*-
    print "Bitte gebe deinen Namen ein";
    meinname = raw_input();
    print "Hallo", meinname;
    print "Welches Jahr haben wir grade?";
    aktuellesjahr = int(input());
    print "Und wann bist du geboren?";
    geburtsjahr = int(input());
    alter = aktuellesjahr-geburtsjahr;
    print "Dann bist du jetzt ",alter," Jahre alt";


Diese grundlegenden Programme (bisher ohne Kontrollstrukturen)
habe ich aus gewohnheit immer mit einem ; abgschlossen.
bei den input Befehlen hätte man gleich auch noch einen Text mit ausgeben
können, das habe ich für eine bessere Übersichtlichkeit erstmal weggelassen.


Aktuelle php.ini herausfinden

Permalink Erfahrungen mit Ubuntu

Um unter Ubuntu 14.04 mal schnell die aktuell benutze
php.ini Datei heraus zu finden kann man folgenden Befehle benutzen:

    sudo php -i | grep 'Configuration File'

Dann bekommt man als Ergebnis:

    Configuration File (php.ini) Path => /etc/php5/cli
    Loaded Configuration File => /etc/php5/cli/php.ini


Womit der Speicherort der Datei ersichtlich ist.

Um den Webserver nach Änderungen neu zu starten benutzt man:

    sudo service apache2 restart






4. Dezember 2014

Mozilla veröffentlicht Firefox 34.0 / 34.0.5 mit Firefox Hello

Permalink Sören Hentzschel

Mit Firefox 34.0 steht eine neue Ausgabe des Mozilla-Browsers zum Download bereit. Eines der Highlights von Firefox 34.0 ist Firefox Hello, eine in den Browser integrierte Möglichkeit zur Videotelefonie.

Download Mozilla Firefox 34 für Windows, OS X und Linux

Mehr Sicherheit für Firefox-Nutzer

Mit einer angekündigten Verspätung von knapp einer Woche hat Mozilla Firefox 34 veröffentlicht. Auch in dieser Version behebt Mozilla wieder acht Sicherheitslücken, von denen Mozilla drei als besonders kritisch einstuft.

Mozilla entfernt mit Firefox 34 außerdem die Unterstützung des veralteten TLS-Standards SSL 3.0 als Konsequenz aus der Sicherheitsproblematik rund um die als Poodle bekannt gewordene Sicherheitslücke in SSL 3.0.

Suchen über die in Firefox integrierte Wikipedia-Suche finden ab sofort über eine verschlüsselte HTTPS-Verbindung statt.

Firefox 34.0 und Firefox 34.0.5

Parallel zu Firefox 34.0 gibt es auch noch eine Version 34.0.5, welche die Standard-Suchmaschine für Nutzer in Nordamerika auf Yahoo! ändert. Mozilla hat den Suchmaschinenvertrag mit Google nach zehn Jahren Zusammenarbeit nicht verlängert und setzt nun auf regionale Entscheidungen und Yahoo! als Standard-Suchmaschine in den USA. Die Standard-Suchmaschine wurde dagegen für die russische, kasachische sowie weißrussische Edition auf Yandex umgestellt. In der deutschen Version bleibt wie in allen anderen Sprachversionen von Firefox vorerst Google Standard. Mit DuckDuckGo gibt es bereits seit Firefox 33.1 eine zusätzliche Option als direkt mit Firefox mitgelieferte Suchmaschine.

Bildquelle: venturebeat.com

Verbesserte Verwendung mehrerer Suchmaschinen (en-US, optional auch in anderen Sprachen)

Ebenso wie die Umstellung der Standard-Suchmaschine auf Yahoo! betrifft auch die Einführung einer neuen Suchleiste nur Nutzer der US-Version von Firefox. Dabei schmückt das Logo der aktuell eingestellten Suchmaschine nicht länger die Suchleiste, dafür kann hier nach Eingabe eines Suchbegriffs jede aktivierte Suchmaschine ausgewählt werden, ohne dass die Suchmaschine zunächst umgestellt werden muss, womit man bei der Verwendung anderer Suchmaschinen als der Standard-Suchmaschine schneller an das Ziel kommt.

Welche Suchmaschinen dabei angezeigt werden, kann über die Suchmaschinen-Einstellungen eingestellt werden, welche in die Oberfläche der anderen Firefox-Einstellungen integriert worden sind. Die neue Suchmaschinen-Verwaltung bietet noch nicht alle ehemals bekannten Features, beispielsweise zum Bearbeiten von Schlüsselwörtern, aber es ist davon auszugehen, dass dies noch folgen wird.

Nutzer anderer Sprachversionen von Firefox als der englischsprachigen werden ab einer der kommenden Firefox-Versionen in den Genuss der neuen Suchleiste kommen. Wer nicht warten will, kann über about:config nach dem Schalter browser.search.showOneOffButtons suchen und per Doppelklick auf true schalten. Nach einem Neustart des Browsers erscheint Firefox mit der neuen Suchleiste.

Ungewollte Suchmaschinen-Änderungen durch Drittanwendungen werden erschwert

Dies sind noch nicht alle Verbesserungen in Bezug auf Suchmaschinen. Das Umleiten von Suchanfragen ist ein sehr profitables Geschäft, Suchtraffic führt über angezeigte Werbung zu Geld für den Betreiber der jeweiligen Suchmaschine. Aus diesem Grund verändern diverse Anwendungen gerne die im Browser eingestellte Suchmaschine. Das Problem: Oft geschieht dies gegen den ausdrücklichen Willen der Nutzer, zum Beispiel durch das Platzieren einer entsprechenden user.js-Datei im Firefox-Profil des Nutzers oder durch Installation eines Add-ons, welches die zuständige Einstellung verändert.

Ab Firefox 34 speichert Firefox die eingestellte Suchmaschine in der Datei search-metadata.json im Benutzerprofil statt gemeinsam mit den anderen Einstellungen. Zusätzlich zur eingestellten Suchmaschine beinhaltet diese Datei einen eindeutigen Hash, welcher aus dem Namen des Profilverzeichnisses generiert wird und den Firefox zur Verifizierung der Suchmaschine einliest. Dies soll verhindern, dass Drittanwendungen einfach die gleiche search-metadata.json-Datei in jedes Profil kopieren, um so die ausgewählte Suchmaschine zu verändern.

Firefox Hello: Video-Telefonie in den Browser integriert

Mit Firefox Hello integriert Mozilla eine auf WebRTC basierende Möglichkeit zur Video-Telefonie in Firefox, welche in Zusammenarbeit mit der Telefónica-Tochter Tokbox entwickelt worden ist. Die Sichtbarkeit von Firefox Hello ist derzeit noch gedrosselt, so dass nur ein Teil der Firefox-Nutzer das neue Sprechblasen-Symbol sieht. Aber auch hier können Ungeduldige wieder sofort an die Neuerung gelangen. Dazu muss über about:config der Schalter loop.throttled gesucht und per Doppelklick auf false umgeschaltet werden. Nach einem Neustart von Firefox befindet sich die Sprechblase in der Oberfläche zm Anpassen von Firefox, worüber das Symbol in die Symbolleiste oder das Menü geschoben werden kann.

Die Funktionsweise von Firefox Hello ist denkbar einfach: Sprechblase anklicken, Link an den Gesprächspartner schicken und nach erfolgreicher Bestätigung miteinander unterhalten. Firefox Hello funktioniert mit jedem WebRTC-kompatiblen Browser, der Gesprächspartner muss nicht zwingend Firefox nutzen.

Auch ein Benutzerkonto ist nicht notwendig. Die Anmeldung mit seinen Firefox Account Zugangsdaten ist aber möglich, dann steht ein Adressbuch mit Importfunktion seiner Google-Kontakte zur Verfügung. In diesem Fall kann der Gesprächspartner einfach aus der Liste der Kontakte ausgewählt werden, um ihn anzurufen, das Weitergeben eines Links ist dann nicht mehr notwendig. Der Nutzer hat außerdem die Möglichkeit, seinen Status auf Bitte nicht stören zu setzen. In dem Fall erhält man keine Anrufe.

Firefox Hello trägt selbst noch einen Beta-Schriftzug. Hier wird sich in den kommenden Monaten noch einiges tun. Darüber hinaus werden Mozilla und Telefónica eine Hello-App für Firefox OS veröffentlichen, auf welche ich im August eine erste Vorschau gegeben habe.

Passwörter können auch mit aktiviertem Master-Passwort synchronisiert werden

Mit dem Erscheinen von Firefox 29 hat Mozilla die Firefox Accounts plus neuem Sync eingeführt. Was dem neuen Sync bislang gefehlt hat, ist die Möglichkeit der Passwort-Synchronisation bei aktiviertem Master-Passwort. Diese Möglichkeit rüstet Mozilla mit Firefox 34 nach.

Theme-Vorschläge und Live-Vorschau in Anpassen-Oberfläche

Firefox ist ein Browser, welcher sich vor allem durch seine einzigartige Anpassungsfähigkeit auszeichnet. Mozilla unterstreicht dies durch die Integration von fünf Theme-Vorschlägen inklusive Live-Vorschau bei Herüberfahren mit der Maus in der Oberfläche zum Anpassungen von Firefox.

Windows: Aktiver Firefox-Prozess kann per Knopfdruck beendet werden

Manche Windows-Nutzer werden die Meldung kennen, dass Firefox bereits ausgeführt wird und deshalb nicht gestartet werden könnte, wie es unter gewissen Umständen passieren kann. Ab Firefox 34 bietet Firefox in dieser Situation an, den laufenden Prozess zu beenden.

(Bildquelle: gHacks)

WebIDE ersetzt App Manager

Der App Manager ist ein in Firefox integriertes Werkzeug, welches das Testen und Debuggen von Firefox OS-Apps mittels Simulator Add-ons oder aber auch auf einem realen Gerät erlaubt. Mit Firefox 34 wird dieser durch die sogenannte WebIDE ersetzt. Dies bedeutet nicht nur ein vollkommen neues Design, auch ist es darüber möglich, eigene Apps für Firefox OS zu erstellen. App-Vorlagen und im Editor Syntax-Highlighting, Autovervollständigung sowie Inline-Dokumentation inklusive.

Storage Inspector

Mit dem Storage Inspector bekommt Firefox ein neues Entwickler-Werkzeug, welches das Betrachten von Cookies und Inhalten aus IndexedDB, Local Storage sowie Session Storage erlaubt. Das Anlegen, Bearbeiten und Löschen ist in der aktuellen Version noch nicht möglich, wird aber in einer späteren Version dazukommen.

Verbessertes Performance-Werkzeug

Das Entwickler-Werkzeug Laufzeitanalyse erscheint mit Firefox 34 in vollkommen neuem Glanz und stellt die Daten nun wesentlich informativer dar.

Weitere Features für Webentwickler

Fährt man im Regeln-Tab des Inspektors über einen CSS-Selektor, werden auf der Webseite alle zutreffenden Elemente hervorgehoben. Neu ist auch die Unterstützung von console.table() in der Webkonsole. Das Eventlistener-Popup im Inspektor unterstützt außerdem auch jQuery-Events. Darüber hinaus gibt es nun die Möglichkeit, auf mit Frames gestalteten Webseiten einen Frame zum Bearbeiten auszuwählen.

Unterstützung für HTTP/2.0 Draft 14 und ALPN

Der HTTP-Standard HTTP/1.1 datiert bereits aus dem Jahr 1999, mit Firefox 34 implementiert Mozilla den Draft 14 von HTTP/2.0. Außerdem unterstützt Firefox ab Version 34 die TLS-Erweiterung Application-Layer Protocol Negotiation (ALPN).

Weitere verbesserte Unterstützung von Webstandards

Mit Firefox 34 erhält Firefox Unterstützung für viele neue WebCrypto-Funktionen. Die in Firefox 33 entfernten window.crypto-Funktionen und -Eigenschaften kehren mit Firefox 34 zurück, werden allerdings voraussichtlich mit Firefox 35 endgültig entfernt werden. Außerdem unterstützt Firefox 34 ECMA6Script 6 WeakSet, JavaScript Template Strings, weitere CSS3 Font Features, die matches() DOM-API und weiteres, was sich im Mozilla Developer Network nachlesen lässt.

Anpassungen für Apple OS X

Mit Firefox 34 hat Mozilla optische Anpassungen an die neuste Version von Apples Desktop-Betriebssystem OS X 10.10 Yosemite vorgenommen, was besonders an der URL- und Suchleiste auffällt. Außerdem wurde die Paketstruktur zur Unterstützung des mit OS X 10.9.5 und 10.10 eingeführten v2-Signings angepasst.

2. Dezember 2014

Raspbmc-Installation unter Ubuntu

Permalink Intux

Ich habe mich mal wieder an eine frische Installation von Raspbmc gewagt. Raspbmc ist ein auf XBMC basierendes Media-Center für den Raspberry Pi. So ist es möglich einen älteren Flatscreen zu einer Art Smart-TV zu machen, um z.B. eigene Bilder, Musik oder Videos abzuspielen. Das Streamen von Musik oder Filmen sollte Raspbmc genauso interessant machen, wie der Anschluss einer externen Festplatte. Steuern lässt sich das Ganze via App am Smartphone. Hier gibt es einige Vertreter wie z.B. Official XBMC Remote. Zu erwähnen wäre noch, dass es durchaus ausreichen kann, wenn alle HDMI-Steckdosen am Fernseher belegt sind, den Composite-Anschluss zu verwenden. Natürlich muss man sich über die zu erwartende Auflösung im Klaren sein. Zur Verwendung von Raspbmc in Verbindung mit dem Composite-Anschluss kommt jedoch nur der Raspberry Pi Modell B in Frage. Beim Modell B+ musste der entsprechende Video-Ausgang den zwei zusätzlichen USB-Buchsen weichen, wobei aber beide Modelle jeweils über eine HDMI-Schnittstelle verfügen.

Nun zur Installation! Zuerst läd man das Image von http://www.raspbmc.com/ herunter. Ich greife in diesem Fall zum Network Image.

Dieses liegt nun im Downloads-Verzeichnis, in welches wir wechseln (Benutzer-Verzeichnis bitte anpassen). In meinem Fall ist es /home/intux/Downloads.

cd /home/intux/Downloads

Nun wird das Image entpackt.

gunzip installer.img.gz

Im Anschluss wird das Image auf die am PC eingesteckte SD-Karte gespielt. Ich verwende dazu eine 4GB-Karte. Zu beachten wäre noch den Quell- und Zielpfad entsprechend anzupassen. Bei mir sieht das Ganze so aus:

sudo dd if=/home/intux/Downloads/installer.img of=/dev/mmcblk0 bs=1M

Wenn die Daten vollständig kopiert wurden nimmt man die SD-Karte aus dem PC, steckt sie in den RasPi, der mit dem Fernseher verbunden ist und versorgt den Mini-Computer mit Spannung um die Installation von Raspbmc zu beginnen. Dazu sollte der RasPi mit dem Internet über ein LAN-Kabel verbunden sein. Dies dauert ca. 15-20 Minuten. Dabei werden u.a. die erforderlichen Pakete aus dem Internet geholt.

news-403

Die eigentliche Installation läuft ganz automatisch am Fernseher ab. Kennt man nun die IP (diese wird kurzzeitig nach Neustart unten rechts eingeblendet) des neuen Media-Centers, stellt man blitzschnell eine Verbindung mit dem Smartphone her und kann das XBMC so voll bedienen. Wem das am Anfang zu fummelig ist, kann z.B. auch auf eine Funktastatur zurückgreifen. Der Preis für solch ein  Eingabegerät liegt hier ca. bei 30€.

Viel Spaß!

KDE 4 ein modernes Aussehen verpassen (Teil III)

Permalink (Mer)Curius

KDE SC 4 ist eine sehr gute Desktopumgebung – meiner Meinung nach sogar zur Zeit die beste für Linux zur Verfügung stehende. Jedenfalls sofern man Wert auf eine integrierte Desktopumgebung mit zugehörigen Programmen legt, deren Entwickler den Nutzer nicht für ein Kind halten, das man bevormunden muss. KDE SC 4.14 ist jedoch zusammen mit dem Plasma Desktop 4.11 im LTS-Stadium angekommen und wird nur noch gepflegt bis Version 5 fertig für den Produktiveinsatz ist. Leider sieht man der 4er Version an, dass ihr Design in der Hochzeit der 3D Spielereien entwickelt und seitdem – in Erwartung der 5er Reihe – keiner großen Änderung unterzogen wurde. Die Bennenung des neuen Designschemas “Breeze” ist somit äußerst passend.

Während man früher also Fehler meldete und mit Abstürzen zu kämpfen hatte, besteht heute die Arbeit darin KDE ein Aussehen zu verpassen, das mit den anderen Desktopumgebungen mithalten kann. In Teil I der Serie hatte ich dafür noch QtCurve verwendet, während sich Teil II mit KSplash (es gibt übrigens seit neuestem eine Adaption des 5er-KSplash Themes für KDE 4.) und dem Loginmanager beschäftigte.

Eine frische Brise

Die Entwicklung an QtCurve wurde zwar wieder aufgenommen, aber irgendwie sieht man den Designs immer an, dass sie “zusammen geklickt” wurden. Vieles wirkt nicht richtig stimmig und einige alte Fehler schleppt man seit Versionen mit sich herum. Die KDE Entwickler haben deshalb auch das neue Breeze-Design als eigenständiges Theme implementiert, ohne QtCurve-Unterbau. Wer eine modern wirkende, flache Optik mit großen Abständen mag wird dieses Design lieben.

Dolphin_Breeze

Während man Breeze unter openSUSE 13.2 einfach aus den Paketquellen heraus installieren kann, muss man bei Debian 8.0 und Kubuntu 14.04/14.10 noch ein wenig frickeln. Eine Option besteht sicherlich darin, das Design aus dem Code heraus zu bauen. Das dauert mir aber zu lange und ich bin im kompilieren auch nicht geübt genug. Einfacher ist es sich einfach bei den Paketquellen des kommenden Kubuntu 15.04 zu bedienen.

Das zugehörige Paket heißt kde-style-breeze-qt4 und lässt sich als .deb Paket passend für die eigene Architektur herunterladen. Leider wurde eine Abhängigkeit auf die Qt 5 Version des Breeze Designs gesetzt (die eigentlich überflüssig ist), weshalb man eine ganze Abhängigkeitskette hin zu den neuen KDE Frameworks nach sich zieht.

Abhängigkeiten eines Debian Pakets modifizieren

Die folgende Anleitung wurde unter Kubuntu 14.04 und Debian “Jessie” 8.0 getestet. Alle anderen Versionen und Distributionen können ebenfalls funktionieren, müssen aber nicht.

Allerdings lassen sich Abhängigkeiten eines Debian Paketes relativ leicht modifizieren. Zuerst lädt man das zu bearbeitende Paket herunter, z.B. nach Downloads. Dort benötigen wir ein provisorisches Verzeichnis, sowie ein Verzeichnis mit dem Namen DEBIAN.

$ mkdir pkgtemp

$ mkdir pkgtemp/DEBIAN

Danach entpackt man das heruntergeladene Paket mittels:

$ dpkg -x kde-style-breeze-qt4_5.1.1-0ubuntu1_amd64.deb pkgtemp/

$ dpkg -e kde-style-breeze-qt4_5.1.1-0ubuntu1_amd64.deb pkgtemp/DEBIAN

Im Verzeichnis pkgtemp/DEBIAN befindet sich eine Datei namens control. In dieser sind die Abhängigkeiten festgelegt. Dort löscht man die unnötige Abhängigkeit auf das Qt5 Paket (ist die letzte Abhängigkeit in der entsprechenden Zeile).

Depends: […] kde-style-breeze

Nun muss man das auseinander genommene Archiv wieder zusammen bauen.

$ dpkg -b pkgtemp kde-style-breeze-qt4_5.1.1-0ubuntu1_amd64.deb

Dieses lässt sich danach einfach mittels

$ sudo dpkg -i kde-style-breeze-qt4_5.1.1-0ubuntu1_amd64.deb

installieren und sollte keine Abhängigkeiten nach sich ziehen.

Mit dem neuen Design und den bereits in Teil I und II aufgezeigten Tricks sollte man die Wartezeit bis zu einer stabilen 5er Version überstehen. Meine Prognose: Das dauert noch mindestens bis 2016.

Netwerkstatistiken nach Protokollen separiert anzeigen

Permalink Invictus deus ex machina

Vor einigen Tagen war ich auf der Suche nach einem Kommando um die Netzwerkaktivität eines Rechners nach Protokollen separiert anzeigen. Wie nicht anderes zu erwarten bin ich dann bei Netstat gelandet. Mittels:

netstat -s

kann man sich einen Report aufgeteilt nach Protokollen anzeigen lassen. Das könnte dann z.B. so aussehen:

Ip:
    20715767 Pakete insgesamt empfangen
    0 weitergeleitet
    0 eingehende Pakete verworfen
    20713510 eingehende Pakete ausgeliefert
    12353060 Anforderung gesendet
Icmp:
    720 ICMP-Meldungen empfangen
    0 Input-ICMP-Meldung fehlgeschlagen.
    ICMP-Eingabehistogramm:
        Ziel unerreichbar: 304
        Echo Anfragen: 416
    9238 ICMP Nachrichten gesendet
    0 ICMP Nachrichten fehlgeschlagen
    ICMP-Ausgabehistogramm:
        Ziel unerreichbar: 8822
        Echo Antworten: 416
IcmpMsg:
        InType3: 304
        InType8: 416
        OutType0: 416
        OutType3: 8822
Tcp:
    364 aktive Verbindungsöffnungen
    298756 passive Verbindungsöffnungen
    6285 fehlerhafte Verbindungsversuche
    57555 Verbindungsrücksetzungen empfangen
    1 Verbindungen aufgebaut
    10493162 Segmente empfangen
    15405980 Segmente ausgesendet
...

Ubuntu Server: Logs in Echtzeit auslesen mit Log.io

Permalink thomas-leister.de

Log.io Webinterface

Log.io Webinterface

Mit der freien Node.js Anwendung Log.io könnt ihr eure Serverlogs in Echtzeit auslesen und auf einem Web-Frontend gesammelt anzeigen lassen. Einfache Filter sind ebenfalls verfügbar. Die Basisinstallation ist schnell erledigt und auch für Einsteiger kein Problem.

Log.io installieren

Für Log.io wird ein eigener Benutzer erstellt, unter dem die Anwendung laufen wird. Damit wird ausgeschlossen, dass ein Angreifer über Sicherheitslücken in der Anwendung direkt root-Rechte erlangen kann.

sudo adduser --disabled-password --disabled-login --ingroup adm logio

Außerdem wurde der neue Benutzer „logio” der Gruppe „adm” zugeordnet. Die Gruppe kann auf verschiedene Log-Dateien Zugreifen – das ist mit einem normalen Benutzer nicht möglich.

Node.js und NPM installieren:

sudo apt-get install nodejs nodejs-legacy npm

Log.io kann über den Node.js Paketmanager npm installiert werden.

sudo npm install -g log.io --user "logio"
Loggt euch als logio-User ein:
sudo -i -u logio

Konfiguration

Log.io besteht aus drei Komponenten:

  • Log Server (Nimmt Logzeilen von Harvester entgegen)
  • Web Server (Stellt Weboberfläche und Websocket zur Verfügung)
  • Harvester (Öffnet Logdateien und sendet neue Logzeilen an Log-Server)

Navigiert in das Konfigurationsverzeichnis:

cd ~/.log.io/

Log Server

Wir beginnen mit der Datei „log_server.conf”. Hier können Interface und Port eingestellt werden, über die der Log-Server erreichbar sein wird. Standardmäßig bindet sich der Server an die Adresse „0.0.0.0”, also jedes verfügbare Netzwerkinterface. Das bedeutet: Auch von außen (über die öffentliche Server-Schnittstelle) könnten Log-Inhalte an den Server geschickt werden. Um Missbrauch zu verhindern, setzt man die Einstellung auf den lokalen Port „127.0.0.1”. Jetzt ist der Log-Server nur noch über Harvester erreichbar, die sich auf demselben Server befinden.

Der Port wird auf der Standardeinstellung belassen.

Web Interface

Weiter geht es mit der Konfiguration der Weboberfläche und des Websockets (Datei: „web_server.conf”). Für den einfachen Betrieb können alle Einstellungen auf dem Standard bleiben. Wer neugierige, fremde Benutzer aussperren will, kann den Block unter „auth” auskommentieren und eigene Zugangsdaten für die Weboberfläche festlegen. (Zum Auskommentieren „/*” und „*/”  vor und nach dem Block entfernen.)

Außerdem können für eine verschlüsselte Verbindung die Dateipfade zu SSL-Zertifikat und -Key angegeben werden.

Harvester

Der Harvester greift auf die Logdateien zu und schickt neue Inhalte an den Log Server. Deshalb müssen in seiner Konfigurationsdatei „harvester.conf” die Pfade zu den Log-Dateien und ihre Namen festgelegt werden.

Hier ein Beispiel für die Überwachung der Logs von Nginx Webserver, Mailserver und der Linux Authentifizierung:

exports.config = {
  nodeName: "meinserver.tld",
  logStreams: {
    nginx: [
      "/var/log/nginx/access.log",
      "/var/log/nginx/error.log"
    ],
    mailserver: [
      "/var/log/mail.log",
      "/var/log/mail.err"
    ],
    auth: [
      "/var/log/auth.log"
    ]
  },
  server: {
    host: '127.0.0.1',
    port: 28777
  }
}

Unter „server” wird angegeben, an welchen Log-Server die Ergebnisse geschickt werden sollen bzw welchen Port. Es ist auch möglich, mehrere Harvester auf andere Linux-Server zu verteilen und sie so einzustellen, dass sie ihre Ergebnisse jeweils an einen zentralen Log-Server schicken. Dafür müsste die „host”-Adresse jedes Harvesters angepasst werden und die Host-IP des Log-Servers von „127.0.0.1” zurück auf „0.0.0.0” gestellt werden.

In dieser Anleitung soll jedoch ein Harvester genügen, sodass nur die Log-Quellen konfiguriert werden müssen.

Log.io starten

Log.io ist jetzt fertig konfiguriert und kann gestartet werden. Zuerst wird der Log-Server inkl. Webserver / Websocket-Server gestartet:

log.io-server

… danach folgt der Harvester:

log.io-harvester

Zum starten der beiden Komponenten empfehle ich screen. => Das Terminal wird dann nicht durch Ausgaben blockiert.

Die Weboberfläche wird über ip.des.ser.vers:28778 aufgerufen und sollte je nach Auslastung des Servers einige Log-Zeilen anzeigen. Gff. müssen die Log-Quellen auf der linken Seite zuerst aktiviert werden.

Log.io Dienste über Uptime starten

[Update am 03.12.2014:] Alex war so freundlich und hat zwei Scripte für Upstart bereitgestellt, über die der Log-Server und der Harvester automatisch beim Systemstart gestartet werden können.

Upstart Script für Log-Server (log.io-server):

# description "start and stop the logio-server"

start on runlevel [2345]
stop on runlevel [^2345]

console log
chdir /home/logio/
setuid logio
setgid logio

env HOME=/home/logio
respawn
respawn limit 20 5

exec log.io-server

Upstart Script für den Log Harvester:

# description "start and stop the logio-harvester"

start on runlevel [2345]
stop on runlevel [^2345]

console log
chdir /home/logio/
setuid logio
setgid logio

env HOME=/home/logio/
respawn
respawn limit 20 5

exec log.io-harvester

Die Upstart-Scripte werden in /etc/init/ als [name].conf Dateien abgelegt und neu eingelesen:

sudo initctl reload-configuration

Log.io mit Nginx-Proxy

Wer sowieso schon einen Nginx-Server laufen hat, kann Log.io damit verbinden. So kann dem Webinterface z.B. eine eigene Subdomain zugeteilt werden (=> Reverse Proxy). Leider ist es mit der Standard-HTTP-Proxy Konfiguration nicht getan. Da für erhöhte Effizient weiterhin WebSockets (ws:// – Protokoll) genutzt werden sollen, muss die Konfiguration erweitert werden.

Eine Nginx-Konfiguration könnte beispielsweise so aussehen:

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    
    server_name logio.domain.tld;

    ssl_certificate /etc/myssl/public-combined.pem;
    ssl_certificate_key /etc/myssl/privkey.pem;

    # Aufrufe der Logio Weboberfläche nicht loggen.
    access_log off;

    location / {
        access_log off;
        proxy_pass http://127.0.0.1:28778;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # WebSocket support (nginx 1.4)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Da nun auch über den Nginx-Proxy auf das Webinterface zugegriffen werden kann, kann die Erreichbarkeit des Log.io Webinterfaces auf die lokale Adresse beschränkt werden. („127.0.0.1″ statt „0.0.0.0” in web_server.conf)

 

Nginx als TCP-Proxy (Beispiel Dovecot)

Permalink debinux

Hintergrund

Ich betreibe zwei Dovecot-Installationen, die sich untereinander replizieren. Änderungen werden sofort/mit minimaler Verzögerung im entfernten Maildir übernommen. Ein master/master Szenario. (http://wiki2.dovecot.org/Replication)
Weil mir die Zeit fehlt, mich mit echten IMAP-Proxys auseinanderzusetzen, habe ich mich für das Nginx Modul nginx_tcp_proxy_module entschieden.

Ich war ein wenig überrascht, dass das Modul in keinem Pre-Build auftaucht und musste Nginx kurzerhand selber bauen. Das ist vielleicht gar nicht so verkehrt, immerhin kann so ein großer Teil der HTTP-Module deaktiviert werden.

Das Modul liefert außer der reinen TCP-Proxy-Funktionalität noch eine HTTP-Statusseite aus und verwendet weiterhin die “Upstream”-Funktion des Nginx. So ist es leider nicht möglich, HTTP mit dem Switch “–without-http” komplett zu deaktivieren.

Der Proxy unterstützt zur Zeit die Modi “Round-Robin” sowie “Busyness”.
Round-Robin: Verfügbare Server im Upstream werden der Reihe nach verwendet.
Busyness: Der Proxy erkennt aktive TCP-Verbindungen zu einem Server im Upstream und wertet “busyness = n-Verbindungen”. Der Server mit den wenigsten Verbindungen wird ausgewählt.

Und UDP? UDP ist ein verbindungsloses Protokoll. Ein Proxy kann diese Verbindung nicht annehmen und weiterleiten, da es den Sender nicht interessiert, ob das Paket angenommen wurde oder überhaupt ankam.

Installiert habe ich den Proxy auf einem Debian Jessie System, wobei der Artikel auf beinahe alle Derivate übertragbar sein sollte.

Let’s build Nginx

Vorab die Abhängigkeiten installieren:

apt-get install libssl-dev build-essential git
Sollten im Verlauf Probleme auftreten, bitte die gesamten “build-deps” laden (“apt-get build-dep nginx”).

Die zur Zeit des Artikels als stabil gekennzeichnete Ningx Version ist 1.6.2, diese lade ich in den Ordner “~/build” herunter, den ich vorab erstelle. Ebenso in “~/build” landet das Proxy-Modul, welches aus dem Git-Repository geklont wird:

mkdir ~/build ; cd ~/build
wget -O - http://nginx.org/download/nginx-1.6.2.tar.gz | tar xfvz -
git clone git://github.com/yaoweibin/nginx_tcp_proxy_module

Nginx muss an dieser Stelle durch einen Patch aus dem Proxy-Modul verändert werden:

cd nginx-1.6.2/
patch -p1 < ../nginx_tcp_proxy_module/tcp.patch

Die minimalste Konfiguration, die mir möglich war. Im Anschluss findet der Build-Vorgang statt:

./configure --add-module=../nginx_tcp_proxy_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --without-http_rewrite_module --without-http_charset_module --without-http_gzip_module --without-http_ssi_module --without-http_userid_module --without-http_access_module --without-http_auth_basic_module --without-http_autoindex_module --without-http_geo_module --without-http_map_module --without-http_split_clients_module  --without-http_referer_module --without-http_proxy_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_scgi_module --without-http_memcached_module --without-http_limit_conn_module --without-http_limit_req_module --without-http_empty_gif_module --without-http_browser_module --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
make
make install

Obige Konfiguration verwendet die Pfade der Nginx-Installation aus dem offiziellen Repository.

nginx -V gibt die verwendeten Build-Konfiguration aus

Einige Verzeichnisse müssen evtl. noch angelegt- oder die Berechtigungen korrekt vergeben werden:

mkdir -p /usr/share/nginx/logs
mkdir /var/log/nginx
mkdir -p /var/lib/nginx/body
touch /var/log/nginx/error.log /var/logs/nginx/access.log
touch /var/log/nginx/access.log
touch /usr/share/nginx/logs/tcp_access.log
chown -R www-data: /var/{lib,log}/nginx /usr/share/nginx/logs

Das Verzeichnis “/usr/share/nginx/logs” wird vom Proxy verwendet.
Das Konfigurationsverzeichnis darf geleert- und auf das Notwendigste beschränkt werden:

rm -r /etc/nginx/*
nano /etc/nginx/nginx.conf

Hier nun der Inhalt einer Beispielkonfiguration:

user  www-data;
worker_processes  1;
events {
    worker_connections  1024;
}
http {
        server {
                listen 901;

                location /status {
                        tcp_check_status;
                }
        }
}
tcp {
        upstream cluster_imaps {
                server 192.168.2.10:993;
                server 192.168.2.11:993;
                check interval=2000 rise=2 fall=5 timeout=1000 type=tcp;
        }

        server {
                listen 993;
                proxy_pass cluster_imaps;
        }

        upstream cluster_imap {
                server 192.168.2.10:143;
                server 192.168.2.11:143;
                check interval=2000 rise=2 fall=5 timeout=1000 type=imap;
                busyness;
        }

        server {
                listen 143;
                proxy_pass cluster_imap;
        }
}

Im “http”-Block befindet sich die angesprochene HTTP-Statusseite. Ich möchte euch diese Übersicht nicht vorenthalten und habe sie via Reverse-Proxy veröffentlicht: http://mailstatus.debinux.de/

Ein Upstream-Cluster besteht immer aus einem eindeutigen Namen, die Server in diesem Cluster beschreibe ich untereinander, einschließlich des Ports.
Ohne die Angabe des Parameters “busyness” im “upstream”-Block, wird Nginx die Auswahl nach dem Round-Robin Prinzip treffen (siehe oben).

Innerhalb des “tcp”-Blocks gibt es weiterhin den “server”-Block. Hier wird nun der Port eingetragen, auf dem Nginx Verbindungen für das darunter beschriebene Cluster in “proxy_pass” entgegen nimmt.

Zum “check”-Parameter im “upstream”-Block:

check 
interval=2000 # Überprüfungsintervall, 2s
rise=2 # Wie viele Überprüfungen müssen positiv verlaufen, damit der Server als online erkannt wird?
fall=5 # Wie viele Überprüfungen müssen negativ verlaufen, damit der Server als offline erkannt wird?
timeout=1000 # Zeitüberschreitung einer Überprüfung: Wann schlägt eine Überprüfung fehl? Hier: 1s.
type=imap; # Die Art der Überprüfung 

Eine Übersicht der “types” aus dem Git:

1. *tcp* is a simple tcp socket connect and peek one byte.
2. *ssl_hello* sends a client ssl hello packet and receives the server ssl hello packet.
3. *http* sends a http request packet, receives and parses the http response to diagnose if the upstream server is alive.
4. *smtp* sends a smtp request packet, receives and parses the smtp response to diagnose if the upstream server is alive. The response begins with ‘2’ should be an OK response.
5. *mysql* connects to the mysql server, receives the greeting response to diagnose if the upstream server is alive.
6. *pop3* receives and parses the pop3 response to diagnose if the upstream server is alive. The response begins with ‘+’ should be an OK response.
7. *imap* connects to the imap server, receives the greeting response to diagnose if the upstream server is alive.

Obige Konfiguration ist wirklich nur ein sehr einfaches Beispiel, weitere Optionen bitte unbedingt aus dem Git herauslesen!

1. Dezember 2014

OwnCloud: “Kein E-Tag vom Server empfangen”

Permalink thomas-leister.de

.. diese Fehlermeldung habe ich in den letzten Tagen mehrmals während der OwnCloud Synchronisierung bekommen. Verschiedene Dateien wurden nicht synchronisiert. Nach etwas Recherche konnte ich das Problem finden: GZIP-Komprimierung auf der Webserver-Seite.

Letzte Woche hatte ich die Einstellungen meines Nginx Webservers optimiert und dabei die Einstellungen zur GZIP-Komprimierung verändert. Anscheinend so, dass die OwnCloud Sync Clients diverse Dateien wegen des fehlenden HTTP E-Tags nicht synchronisieren konnten. Die Lösung war ganz einfach: GZIP für OwnCloud deaktivieren.

Dazu wird in die Konfiguration des OwnCloud Virtual Servers einfach ein

gzip off;

eingefügt.

Und schon funktioniert die Synchronisierung wieder! :)

SMTPS OpenSMTPD

Permalink noqqe.de

Mein Mailprovider ist mittlerweile ein halbes Jahr neomailbox.net. Seit einiger Zeit hatte ich aber Probleme beim Einliefern von Mails zum SMTP Server. Mutt resettet beim SMTP mit CRAM-MD5 über SSL immer wieder die Verbindung. Kein Einliefern möglich.

Eigentlich ist die .muttrc ziemlich straight-forward was das betrifft

1
2
3
4
5
set smtp_url="smtp://user@neomailbox.net"
set smtp_pass="PW"
set ssl_starttls = yes
set smtp_authenticators = "cram-md5"
set ssl_force_tls = yes

Debugging

Also erstmal openssl angeworfen um damit zu schauen was die Serverseite so erzählt. Zuvor aber Username und Password in BASE64 encodiert vorbereiten:

1
2
perl -MMIME::Base64 -e 'print encode_base64("passwort");'
perl -MMIME::Base64 -e 'print encode_base64("username");'

Dann Verbindung zum SMTPS aufbauen und bisschen Tippern.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
openssl s_client -connect 5.148.176.58:465
---
220 s3.neomailbox.net ESMTP
ehlo noc.n0q.org
250-s3.neomailbox.net Hello noc.n0q.org [127.0.0.1]
250-SIZE 52428800
250-PIPELINING
250-AUTH CRAM-MD5 PLAIN LOGIN
250-STARTTLS
250 HELP
AUTH LOGIN
334 VXNlcm5hbWU6
XYZABCDEFGHIJ
334 UGFzc3dvcmQ6
ABCDEFGHIJKLMNO
235 Authentication succeeded
MAIL FROM:example@example.org
250 OK
RCPT TO:example@example.org
RENEGOTIATING
depth=1 C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2
verify error:num=20:unable to get local issuer certificate
verify return:0

Ich bin mir bis jetzt nicht sicher ob das renegotiaten nach MAIL FROM: normal ist. Danach war jedenfalls auch meine Plaintext-Session vorbei. Fand ich komisch. Ich dachte auch ob es vielleicht am LibreSSL des OpenBSD auf der Kiste liegt, die ich benutze. Ein Test mit Debian bewies aber dann das Gegenteil.

OpenSMTP als lokaler MTA

So konnte das ja auch nicht bleiben. Mails verschicken können wär schon schön. Da es sowieso ein OpenBSD ist, auf der mein mutt läuft war der OpenSMTPD schon da.

Was folgt ist eine kurze Anleitung, alle Mails an einen remote SMTP Server mit Authentifizierung weiterzuleiten.

Das secrets File erstellen

1
2
3
4
$ echo "neo user:pw" > /etc/mail/secrets 
$ chown root:_smtpd /etc/mail/secrets 
$ chmod 640 /etc/mail/secrets 
$ makemap /etc/mail/secrets

und die smtpd.conf wie folgt anpassen:

1
2
3
4
5
listen on lo0
table aliases db:/etc/mail/aliases.db
table secrets db:/etc/mail/secrets.db
accept for local alias <aliases> deliver to mbox
accept for any relay via secure+auth://neo@neomailbox.net:465 auth <secrets>

Die .muttrc auf localhost umbiegen

1
set smtp_url="smtp://localhost:25"

Das hat jetzt nicht nur den Vorteil, dass ich wieder Mails versenden kann. Mir gefällt auch, dass ich jetzt bei eventualler nicht-Verfügbarkeit des Provider-SMTPs eine queuende Instanz habe. Ausserdem Logfiles in denen ich wirklich sehen kann wann eine Mail mein System verlassen hat. Negativ: Eine Komponente mehr die potentiell kaputt gehen kann.