Anwendungen
Portal
Forum
Wiki
Ikhaya
Planet
Mehr
Anmelden

heute

Python 3 – Lernen und professional anwenden

Permalink Intux

978-3-8266-9456-1

Heute möchte ich das Buch “Python 3 – Lernen und professional anwenden” vorstellen. Das Buch von Michael Weigend ist im mitp-Verlag bereits in der 5. Auflage 2013 erschienen. Auf 793 Seiten wird dem Leser das programmieren mit Python 3 beigebracht. Zu diesem Buch liegt noch eine CD-ROM bei, die die Systemsoftware Python 3 beinhaltet. Diese kann man jedoch auch aus dem Internet laden. Auf der CD befinden sich noch die Beispielskripte, die im Buch behandelt werden.

In der Einleitung werden erstmal Argumente geliefert, warum man Python gern verwendet. In den Grundlagen werden Begriffe erklärt, wie z. B. “Was ist programmieren ?” oder “Was ist ein Algorithmus?”.

Nach jedem Kapitel gibt es Aufgaben zur Festigung der vorherigen Themen. Die Lösungen sind gleich nach den Aufgaben zu finden.

In den nächsten Kapitel des Buches wird einem vermittelt, wie man die Systemsoftware Python auf dem PC installiert und wie man die Programmoberflächen verwendet. Außerdem wird einem erklärt was Klassen und Objekte sind und wie man Funktionen in Python benutzt.

Mit weiteren voranschreiten des Buches lernt man auch das Objektorientierente programmieren kennen und anwenden. Dazu gehört natürlich auch die Gestaltung von den Benutzungsoberflächen.

In “Python 3 – Lernen und professional anwenden wird ausführlich auf die Fehlersuche eingegangen, was sehr positiv ist. Desweiteren werden nützliche und praktische Tipps zur Fehlervermeidung gegeben.

Am Ende des Buches wird noch auf die CGI-, und Internetprogrammierung, Datenbanken, Programmiertechniken und XML eingegangen.

Die einzelnen Kapitel in der Gesamtübersicht:

  • Grundlagen
  • Der Einstieg – Python im interaktiven Modus
  • Python-Skripte
  • Standard-Datentypen
  • Kontrollstrukturen
  • Funktionen
  • Sequenzen, Mengen und Generatoren
  • Dictionaries
  • Ein- und Ausgabe
  • Definition eigener Klassen
  • Klassenbibliotheken in Modulen speichern
  • Objektorientiertes Modellieren
  • Verarbeitung von Zeichenketten
  • Systemfunktionen
  • Gestaltung von grafischen Benutzungsoberflächen
  • Layout/Grafik
  • Event-Verarbeitung
  • Komplexe Benutzungsoberfläche
  • Threads
  • Fehler finden und vermeiden
  • CGI- und Internetprogrammierung
  • Datenbanken
  • Fortgeschrittene Programmiertechniken – Testen und Tuning
  • XML
  • Modellieren mit Kellern, Schlangen und Graphen

Fazit:

Alles in allem finde ich, dass das Buch ein sehr gutes Nachschlagewerk für Programmieranfänger ist, sowie für diejenigen, die schon länger mit Python zu tun haben. Am Anfang wird alles Stück für Stück sehr gut erklärt, sodass Anfänger sich gute Grundlagen aneignen und Fortgeschrittene ihr Wissen erweitern können. Jeder Begriff wird gut bis sehr gut erklärt, teils auch schematisch gut veranschaulicht.

“Python 3 – Lernen und professional anwenden” ist aus meiner Sicht somit sehr zu empfehlen!

gestern

ownCloud’s Federated Cloud kurz erklärt

Permalink My-IT-Brain

Federated Cloud Sharing1 ist eine Funktion von ownCloud. Mit dieser Funktion ist es möglich, Dateien und Verzeichnisse der eigenen ownCloud mit anderen ownClouds zu teilen.

Dies ist angeblich so einfach wie eine E-Mail zu schreiben. Man nutzt dazu die sogenannte Federated Cloud ID. Diese entspricht dem Muster username@example.com/owncloud.

Bildquelle: https://owncloud.org/federation/
Bildquelle: https://owncloud.org/federation/

Die Dokumentation2 erklärt, wie es funktioniert. Dies möchte ich hier kurz wiedergeben.

Bei den zu teilenden Dateien bzw. Verzeichnissen klickt man auf das Icon zum Teilen des Elements und trägt die Federated Cloud ID der Ziel-ownCloud ein. Also z.B. username@example.com/owncloud. Wenn der eigene ownCloud-Server erfolgreich eine Verbindung zum Zielserver aufbauen kann, wird die Berechtigung in der eigenen ownCloud gespeichert.

Die empfangende ownCloud zeigt dem Benutzer einen Hinweis, den der Benutzer bestätigen muss, um die Freigabe seiner ownCloud hinzuzufügen.

Bildquelle: https://doc.owncloud.org/server/8.0/user_manual/files/federated_cloud_sharing.html
Bildquelle: https://doc.owncloud.org/server/8.0/user_manual/files/federated_cloud_sharing.html

Damit ist auch schon alles getan. Die geteilte Datei bzw. das geteilte Verzeichnis erscheint nun in der ownCloud des Empfängers. Ich würde sagen, dies ist wirklich so einfach wie E-Mail.

  1. Federated Cloud Sharing – Share across ownClouds!
  2. Using Federated Cloud Sharing

ownCloud Client in Version 2

Permalink Invictus deus ex machina

Vor einigen Tagen wurde die zweite Version des ownCloud-Clients veröffentlicht. Der Client wird benötigt um die Dateien welche in der ownCloud liegen auf den eigenen Rechner zu sychronisieren. Das Killerfeature der zweiten Version ist dabei die Unterstützung für mehrere Konten (bzw. Server).

Die Einstellungen des neuen ownCloud-Clients

Die Einstellungen des neuen ownCloud-Clients

Früher war dies nur über Umwege möglich, so musste der ownCloud–Client an einen anderen Ort kopiert werden und konnte dann gestartet werden. Mit der neuen Version entfällt dieser umständliche Weg. Bezogen werden kann der Client über die offizielle Seite des Projektes.

Ubuntu in der Firma

Permalink Erfahrungen mit Ubuntu

Seit gut einem Jahr setzen wir in der Firma Ubuntu ein und ich nutze die Gelegenheit, mal eine kleine Projektübersicht zu geben.

Meine Aufgabe in der Firma bestand 2012 darin die Server-Struktur von dem Windows Server zu einer Linux Landschaft zu bringen. Zunächst habe ich mich hier für Debian entschieden was auch eine gute Wahl war.

Es galt einen Windows Server2003, der auch als Exchange und Dateiserver fungierte zu ersetzen. Grade als eMail Server hatte der Exchange Server einige lästige Begrenzungen die man mit dem Mailserver auf Linux Basis leichter umgehen kann. Dazu ist eine Linux Lösung wesentlich flexibler in der Handhabung.

Der erste Server wurde auf Basis von Debian 6.0 realisiert. Als Mailsystem kam die Kombination von Postfix, Fetchmail und uwimap zum Einsatz. Für das Intranet habe ich ein fertiges "xampp" Paket genommen und das im Verzeichnis /opt entpackt&gestartet. Der Kalender wurde von radicale bereitgestellt.


Mitte 2014 haben wir den Server auf Ubuntu 14.04.1
 umgestellt. Nachdem ich im privaten Bereich damit sehr gute Erfahrungen gemacht habe nutze ich die Gelegenheit von Debian 6 nicht auf 7 sondern direkt zu Ubuntu Server zu wechseln.
Mit dem Wechsel zu der Ubuntu-Server Version habe ich auch die Softwarelandschaft etwas geändert.



Die Kernfunktion des Mailservers wird nun durch die Kombination Postfix, Fetchmail, Dovecot realisiert. Dazu hat der Server nun die Rolle eines Datenbankservers übernommen, um die mySQL
Datenbank für die Warenwirtschaft bereit zu stellen. Mittels Samba bietet er die Dateifreigaben an und das Intranet welches vorher auf xampp lief habe ich nun auf einen normalen Apache Webserver aus den Ubuntu Paketquellen aufgesetzt.
Der Kalenderdienst kommt nun von davical, welches wesentlich besser mit den Mobilgeräte zusammenarbeitet wie radicale.
Der Server wurde mit einem VPN ausgestattet so das es den Mitarbeitern auch möglich ist von einem Heimarbeitsplatz aus zu arbeiten.

Auf dem Server laufen zusätzlich zwei selbstprogrammierte Webanwendungen der Firma Senft. Bedaplan ermöglichst die Arbeitszeite und Projektzeiterfassung der Mitarbeiter sowie die Projektplanung. Lemoplan unterstützt bei der Projektplanung der Wohnungsverwaltung.
Da Bedaplan unter der GPL verfügbar ist kann der Quellcode hier eingesehen werden:
https://github.com/SenftGmbH/bedaplan2

Auf den Clients laufen verschiedene Windows Versionen (7, 8, 8.1) sowie Firefox, Thunderbird und auf einigen Rechnern Outlook 2013.
Bei Thunderbird habe ich noch den SoGoConnecor installiert, bei Outlook Evo Collaborator damit die Programme auch den Kalender bzw. Adressbuch korrekt mit Davical abgleichen.

Weitere Details auf der Firmenseite:
http://www.senft-betonbohren.de
http://senft-bauunternehmung.blogspot.de/


27. August 2015

Mozilla veröffentlicht Sicherheitsupdate Firefox 40.0.3

Permalink Sören Hentzschel

Mozilla hat heute mit Firefox 40.0.3 ein außerplanmäßiges Update veröffentlicht, welches neben anderen Fehlern auch zwei Sicherheitslücken behebt. Die entsprechenden Sicherheitslücken existierten auch in der ESR-Version und wurden in Firefox ESR 38.2.1 behoben. Ebenso hat Firefox für Android ein Sicherheitsupdate erhalten.

Dowload Firefox 40.0.3 für Windows, OS X und Linux

Mit Firefox 40.0.3 behebt Mozilla zwei Sicherheitslücken, deren Gefahrenpotential als hoch respektive kritisch eingestuft wird. Die eine Sicherheitslücke betrifft die Installation von Add-ons in Firefox, die andere das canvas-Element auf Webseiten.

Darüber hinaus deaktiviert Mozilla mit Firefox 40.0.3 die mit Firefox 40 erst eingeführte asynchrone Plugin-Initialisierung aufgrund von Kompatibilitätsproblemen auf diversen Webseiten. Der Großteil der Nutzer sollte von diesem Problem unabhängig von dem Update nicht mehr betroffen sein, da Mozilla die Deaktivierung bereits vor ein paar Tagen per Hotfix-Add-on durchgeführt hat.

Außerdem behebt Firefox 40.0.3 eine mögliche Linux-spezifische Absturzursache in Zusammenhang mit GStreamer sowie eine mögliche Absturzursache bei Programmstart auf Windows-Systemen.

Weitere Bugfixes betreffen die Darstellung von input-Feldern mit japanischen Schriftarten, die Auswahl in select-Feldern mit der Maus sowie ein fehlender Partnercode im Yahoo!-Suchplugin.

Auch die ESR-Version von Firefox sowie Firefox für Android haben ein entsprechendes Sicherheitsupdate (ohne weitere Bugfixes) erhalten.

Postfix Mail Server um DANE Validierung erweitern

Permalink Finns Blog

Für den Mail-Server Postfix lässt sich glücklicherweise sehr einfach die DANE Validierung aktivieren. Voraussetzung ist ein DNSSEC validierender DNS Resolver wie z.B. Unbound und die passenden TLSA Einträge in der DNS Zone, damit andere Mail-Server das eigene Zertifikat valideren können.

Die Postfix-Konfiguration

/etc/postfix/main.cf
  muss um folgende Zeilen ergänzt werden:
#DNSSEC
smtp_dns_support_level = dnssec
#DANE
smtp_tls_security_level = dane

Zusätzlich empfiehlt es sich, die TLS-Loglevel für das Senden und Empfangen auf 1 zu setzen, so dass man die korrekte Funktion der DANE Validierung auch nachvollziehen kann:

# TLS Loglevels
smtp_tls_loglevel = 1
smtpd_tls_loglevel = 1

Nach einem Neustart mit

service postfix restart
  wird das Mail-Log Einträge wie “Verified TLS connection established to …” enthalten, wenn eine mit DANE verifizierte Verbindung zu einem anderen Mail-Server hergestellt wurde.

Temperaturaufzeichnung des DS18B20-Sensors

Permalink Intux

news-574

Wie man die Temperatur mit einem Sensor Dallas DS18B20 messen kann, hatte ich im Artikel “Temperaturanzeige in der Webcam des RasPi” kurz erklärt. Um diese Temperatur in einem Diagramm darzustellen, habe ich mich ein weiteres Mal dem Round-Robin-Database-Tool bedient. Die ersten Versuche hatte ich mit dem TEMPer1 unternommen. Leider lieferte der TEMPer nicht bei jeder Messung einen Wert, wie im Artikel “Temperaturmessung mit dem Raspberry Pi” zu sehen ist.

Nun wollte ich das Ganze mit dem DS18B20 nachbauen. Dazu muss man auf dem Pi das RRD-Tool installieren.

news-565

sudo apt-get install rrdtool

Dann erstellt man eine entsprechende RRD-Datenbank.

rrdtool create /home/pi/.temp/temp.rrd --step 60 DS:tempsensor1:GAUGE:120:-20:50 RRA:AVERAGE:0.5:1:10080

Im folgenden Beispiel wird nun eine Messreihe sieben Tage lang in einer Schleife aufgezeichnet und abgebildet. Die genauen Zusammenhänge hierzu werden in den zuvor erwähnten Artikeln erklärt.

Zwei Skripte werden nun benötigt. In das Skript diagramm3.sh, welches in /home/pi gespeichert wird, trägt man folgenden Inhalt ein. Hier wird die Temperatur am Sensor gemessen und an die RRD-Datenbank übergeben.

#!/bin/sh
# Auslesen der Temperatur
temperatur=`cat /sys/bus/w1/devices/28-0000067c28ce/w1_slave | sed -n "s/.*t=\($
# Ausgabe mit zwei Stellen nach dem Komma
temperatur2=`echo "scale=2; $temperatur / 1000" | bc`
# Übergabe an das Round-Robin-Tool
rrdtool update /home/pi/.temp/temp.rrd N:$temperatur2

In das Skript diagramm4.sh, welches ebenfalls in /home/pi abgespeichert wird, kopiert man den nachfolgenden Inhalt. Dieser erstellt dann ein Diagramm als PNG (temp.png) im von mir zuvor angelegten Verzeichnis /var/www/sensor_ext. Der Speicherort kann natürlich auch woanders liegen wie z.B. im Home-Verzeichnis. Das muss dann natürlich im Skript entsprechend berücksichtigt werden.

#!/bin/sh
# Darstellung im Diagramm
rrdtool graph /var/www/sensor_ext/temp.png -a PNG \
--title="Temperatur Balkon-Cam" \
--start -604800 \
--vertical-label "Grad Celsius" \
--watermark "`date`" \
'DEF:probe1=/home/pi/.temp/temp.rrd:tempsensor1:AVERAGE' \
'AREA:probe1#009bc2:Temperaturverlauf' \
'GPRINT:probe1:LAST:Letzte Messung\: %2.1lf'" °C" \
COMMENT:"\l" \
'GPRINT:probe1:MIN:Min\: %2.1lf'"°C\n" \
'GPRINT:probe1:MAX:Max\: %2.1lf'"°C\n"

Beide Diagramme sind dann

sudo chmod +x /home/pi/diagramm3.sh
sudo chmod +x /home/pi/diagramm4.sh

ausführbar zu machen.

Nun wird die ganze Sache noch mit einem Cron-Job automatisiert. Dazu öffnet man

sudo nano /etc/crontab

und trägt Folgendes ein.

* * * * * pi /home/pi/diagramm3.sh
*/5 * * * * pi /home/pi/diagramm4.sh

Hierbei wird jede Minute die Temperatur gemessen und alle fünf Minuten ein Diagramm hierzu gezeichnet. Nun wird der Cron neu gestartet.

sudo /etc/init.d/cron restart

Das Skript diagramm4.sh arbeitet hier jeweils mit den Durchschnittswerten (AVERAGE), wobei man hier auch Minimal- und Maximalwerte ausgeben kann. Dazu sollte man sich aber mit dem RRD-Tool näher auseinander setzen.

Der Kampf geht weiter!

Prosody Jabber Server um DANE Validierung erweitern

Permalink Finns Blog

Mit der Verwendung von DNSSEC für meine Domain ergibt sich die schöne Möglichkeit, TLSA Records im DNS einzutragen, mit denen die DANE Authentifizierung durchgeführt werden kann. Vereinfacht gesprochen garantiert DNSSEC die Echtheit der DNS Einträge einer Domain und mit DANE/TLSA kann überprüft werden, dass für die verschlüsselte Verbindung auch das korrekte Zertifikat verwendet wird.

Für die DANE Validierung ist das Modul mod_s2s_auth_dane notwendig, welches wiederrum ein paar Abhängigkeiten besitzt. Grundvoraussetzung für DANE ist eine mit DNSSEC gesicherte Zone und ein DNSSEC validierender DNS Resolver wie z.B. Unbound. Prosody nutzt allerdings einen internen DNS Resolver, welcher kein DNSSEC unterstützt, weshalb dieser durch eine LUA-Bibliothek von Unbound ersetzt werden muss.

Die Installationsschritte sind zusammengefasst folgende:

# Abhängigkeiten und mercurial zum Klonen der Repositories installieren:
yum install mercurial unbound-libs unbound-devel

# Das Klonen der Repositories kann z.B. in /usr/local/src geschehen:
cd /usr/local/src
# Prosody-Modules Repo klonen
hg clone http://hg.prosody.im/prosody-modules/
# Modul kopieren
cp prosody-modules/mod_s2s_auth_dane/mod_s2s_auth_dane.lua /usr/lib64/prosody/modules/

# Luaunbound Repo klonen
hg clone http://code.zash.se/luaunbound/
cd luaunbound
# Luaunbound bauen und installieren
./squish.sh > use_unbound.lua
make
install lunbound.so /usr/lib64/prosody/util/
# Dorthin kopieren, wo die prosody.cfg.lua liegt, da diese Datei dort verwendet wird
cp use_unbound.lua /etc/prosody/
# Prosody Konfiguration im global-Bereich erweitern, z.B. mit vim:
vim /etc/prosody/prosody.cfg.lua
# dort einfügen:
RunScript "use_unbound.lua"
# Prosody neustarten
service prosody restart

Für die Erstellung der TLSA Records kann mein vorheriger Beitrag zu Rate gezogen werden, der TCP Port für die s2s Verbindungen ist 5269. Für die Clients (c2s nutzt Port 5222) sollte ebenfalls ein TLSA Record erstellt werden, damit nicht nur die Server ihre SSL Verbindung validieren können, sondern auch die Clients.

Anschließend sollten die Logdateien von Prosody im Auge behalten werden, um eventuelle Konfigurationsfehler erkennen zu können.

TLSA Records für DANE erstellen

Permalink Finns Blog

Mit DANE (DNS-based Authentication of Named Entities) lassen sich SSL Zertifikate (bzw. deren Hashes) in einer mit DNSSEC gesicherten Zone hinterlegen. Damit kann zusätzlich überprüft werden, dass das Zertifikat des Servers auch wirklich das Zertifikat ist, welches vom Betreiber eingesetzt wird.

Normalerweise wird die Vertrauenswürdigkeit eines Zertifkates dadurch bestimmt, dass es durch einen Certificate Authority (CA) ausgestellt wurde. Eine CA nutzt verschiedene Verfahren, um zu überprüfen, dass der Beantrager des Zertifikates auch bevollmächtigt ist, Zertifikate für den Domainnamen zu beantragen. Ein Browser kennt die CAs und kann somit Zertifikate, welche von diesen CAs ausgestellt wurden, als vertrauenswürdig einstufen.

Zusätzlich muss der eingetragene Hostname (Common Name, z.B. example.org) auch mit der aufgerufenen Webseite bzw. dem Server übereinstimmen. Das Zertifikat darf auch nicht abgelaufen sein, aber das soll hier keine Rolle spielen. Das Problem ist nämlich, dass es unseriöse oder schlampig validierende CAs gibt. In der Vergangenheit ist es dadurch bereits mehrfach vorgekommen, dass fremde Personen gültige Zertifikate für Domains erhalten haben, die Ihnen nicht gehört haben. DANE kann die Nutzer vor diesem Problem schützen, indem in der DNS Zone ein TLSA Record hinterlegt wird, in dem steht, welches Zertifikat das richtige bzw. echte Zertifikat ist.

Ich möchte hier kurz zeigen, wie ein TLSA Eintrag für https://www.finnchristiansen.de (also Port 443 / HTTP mit SSL) erstellt werden kann. Zusätzlich zu dem Hash des Zertifikates muss auch der Typ des Zertifikates und der Typ des Hashes angegeben werden. Der Aufbau ist wie folgt, die Übersicht habe ich dem Wiki von basti79.de entnommen:

Usage Selector Matching-Typ HASH

Usage:
0 = PKIX-TA: CA Constraint
1 = PKIX-EE: Service Certificate Constraint
2 = DANE-TA: Trust Anchor Assertion
3 = DANE-EE: Domain Issued Certificate

Selector:
0 = Cert: Use full certificate
1 = SPKI: Use subject public key

Matching-Typ:
0 = Full: No Hash
1 = SHA-256: SHA-256 hash
2 = SHA-512: SHA-512 hash

Für die üblichen Domain-gebundenen Zertifikate wählt man als Usage die 3, als Selector empfiehlt sich die 0 für den Hash über das ganze Zertifikat und als Matching-Typ nehme ich 1, da ich den SHA-256 Hash des Zertifikates verwenden möchte. Hieraus ergibt sich 3 0 1, es fehlt also nur noch der Hash selbst. Diesen kann man schnell erzeugen:

openssl x509 -noout -fingerprint -sha256 < /etc/pki/tls/certs/finnchristiansen.de.crt | tr -d : | sed 's/SHA256 Fingerprint=//'
1BD4702EFFD8F42831D261C8ABCD6E665CB1581F944732AF76532D0B0012DF2B

Damit wäre der Inhalt des TLSA Records fertig:

3 0 1 1BD4702EFFD8F42831D261C8ABCD6E665CB1581F944732AF76532D0B0012DF2B

Der Name des Records ergibt sich aus dem verwendeten Internet-Protokoll, dem Port und dem Host- bzw. Domainnamen:

tlsa _443._tcp.www.finnchristiansen.de

Für die Verwaltung meiner DNS Zonen verwende ich übrigens Poweradmin. Nach dem Eintragen kann der Eintrag mit dig überprüft werden:

dig in tlsa  _443._tcp.www.finnchristiansen.de +short
3 0 1 1BD4702EFFD8F42831D261C8ABCD6E665CB1581F944732AF76532D0B 0012DF2B

Die eigentliche Überprüfung bleibt dann den Anwendungen überlassen. Die Anzahl der Anwendungen, die dies nativ unterstützen, wächst langsam, aber stetig. Für Firefox oder Chrome ist beispielsweise noch dieses Addon notwendig.

26. August 2015

Firefox 42: Datenimport aus Chromium und Chrome Canary

Permalink Sören Hentzschel

Firefox kann bestimmte Daten wie Lesezeichen oder die Chronik aus anderen Browsern importieren, darunter auch Chrome. Mit Firefox 42 erweitert Mozilla den Importer, um auch aus Chrome Canary und Chromium Daten importieren zu können.

Firefox kann die Lesezeichen, Chronik und Cookies aus anderen Browsern importieren, was sich vor allem dann als vorteilhaft erweist, wenn man bislang einen anderen Browser genutzt hat, frisch zu Firefox gewechselt ist und nicht auf wichtige Daten verzichten möchte. Nachdem die Daten bislang bereits aus Chrome importiert werden konnten, ist dies ab Firefox 42 auch aus Chrome Canary (vergleichbar mit Firefox Nightly) sowie der Open Source-Variante Chromium möglich.

Auf Windows ist es ab Firefox 42 auch möglich, Passwörter aus Chrome zu importieren.

Migration von gummiboot nach systemd-boot

Permalink [ENC]BladeXP's Blog

Auf UEFI-Installationen verwende ich schon seit einiger Zeit dem schlanken Bootloader gummiboot. Doch so wie aus Raider einst Twix wurde, nennt sich gummiboot jetzt systemd-boot.

Wer Arch Linux oder eine vergleichbar moderne Distribution nutzt, kann auch schon direkt auf den neuen Bootloader umstellen, was konkret wie folgt aussieht:

sudo gummiboot remove
sudo pacman -R gummiboot # Paketverwaltung deiner Distribution
sudo bootctl install

Der frühere Befehl gummiboot nennt sich jetzt bootctl, an der Konfiguration und Verwendung hat sich jedoch nichts geändert. Die Namensänderung vom Projekt ist übrigens in der vollständigen Integration in das systemd Paket (ab Version 220) begründet, es gibt also kein gummiboot mehr, aber es gibt auch nur noch Twix und kein Raider ;)

SPF und DKIM mit DMARC abrunden

Permalink Finns Blog

Nachdem ich für meinen Postfix Mail-Server SPF und nun kürzlich DKIM konfiguriert habe, möchte ich die Sache mit DMARC (Domain-based Message Authentication, Reporting and Conformance) abrunden. Mit SPF lässt sich verhindern, dass andere Mail-Server meine Domain als Absender verwenden. DKIM hingegen dient dazu, die E-Mails zu signieren, damit der Empfänger prüfen kann, dass die E-Mail tatsächlich vom Absender(-server) stammt und nicht unterwegs verändert wurde.

DMARC ergänzt SPF und DKIM, indem festgelegt wird, was der empfangende Mail-Server mit einer E-Mail tun soll, welche die SPF oder DKIM Prüfung nicht erfolgreich bestanden hat. Hierfür sind zwei Dinge notwendig:

  1. Ein DNS TXT Record, der dem empfangenden Mail-Server sagt, was zu tun ist.
  2. OpenDMARC auf dem eigenem Mail-Server, damit dieser selbst die laut DMARC definierten Aktionen ausführen kann.

Der DNS Record mit dem Namen

_dmarc.finnchristiansen.de
  vom Typ TXT ist schnell gesetzt und lässt sich mit anschließend mit dig überprüfen:
dig txt _dmarc.finnchristiansen.de +short
"v=DMARC1\;p=quarantine\;pct=100\;rua=mailto:postmaster@finnchristiansen.de\;ruf=mailto:postmaster@finnchristiansen.de\;adkim=s\;aspf=s"

Details zu den DMARC Parametern können dem RFC 7489 entnommen werden, die wichtigsten Parameter sind grob diese:

# Protokollversion
v=DMARC1

# Policy für die Domain: Weist den Mail-Server an, die Mail in die Quarantäne zu verschieben oder zu markieren
p=quarantine
# Lehnt die Mail ab
p=reject

# Policy für eine Subdomain: Weist den Mail-Server an, die Mail in die Quarantäne zu verschieben oder zu markieren
sp=quarantine
# Lehnt die Mail ab
sp=reject

# Prozentualer Anteil der zu prüfenden Mails
pct=100

# Empfänger für den aggregierten Report
rua=mailto:postmaster@finnchristiansen.de

# Empfänger für den forensichen Report
ruf=mailto:postmaster@finnchristiansen.de

# Relaxed SPF Abgleichmodus, From-Kopfzeile darf auch Subdomains enthalten
aspf=r
# Strict SPF Abgleichmodus, From-Kopfzeile muss exakt die Domain enthalten
aspf=s

# Relaxed DKIM Abgleichmodus, From-Kopfzeile darf auch Subdomains enthalten
adkim=r
# Strict DKIM Abgleichmodus, From-Kopfzeile muss exakt die Domain enthalten
adkim=s

An die angegebenen E-Mail Adressen werden dann die Reports (meist einmal täglich) gesendet. OpenDMARC selbst ist schnell installiert und gestartet:

yum install opendmarc
chkconfig opendmarc on
service opendmarc start

Die Konfigurationsdatei

/etc/opendmarc.conf
  muss nicht zwangsläufig angepasst werden, aber dort kann beispielsweise der Parameter
CopyFailuresTo
  verwendet werden, um eine eigene E-Mail Adresse für eine Kopie der Fehlerberichte anzugeben. Das generelle Versenden der Reports möchte ich natürlich auch aktivieren:
AuthservID mail.finnchristiansen.de
FailureReports true
CopyFailuresTo postmaster@finnchristiansen.de
HistoryFile /var/spool/opendmarc/opendmarc.da

Die Postfix-Konfiguration

/etc/postfix/main.cf
  wird nun um den Milter
inet:localhost:8893
  ergänzt:
# DKIM / DMARC
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891, inet:localhost:8893
non_smtpd_milters = inet:localhost:8891, inet:localhost:8893

Wie zu sehen ist, ist der auch bereits der DKIM Milter (Port 8891) konfigutiert. Mehrere Milter werden mit Komma getrennt angegeben. Nach einem Neustart von Postfix mit

service postfix restart
  ist die Konfiguration aktiv und solche Zeilen sollten beim Start im Mail-Log zu sehen sein:
opendmarc[32435]: OpenDMARC Filter v1.3.1 starting (args: -c /etc/opendmarc.conf -P /var/run/opendmarc/opendmarc.pid)
opendmarc[32435]: additional trusted authentication services: (none)

Zum Testen kann wieder mail-tester.com empfehlen oder schreibt eine E-Mail an checkmyauth@auth.returnpath.net.

25. August 2015

FrOSCon

Permalink svij | Blog

Vergangenes Wochenende, am 22. und 23. August, fand die FrOSCon in St. Augustin statt und ich war dieses Jahr zum ersten Mal da. Kurz zusammengefasst: Die Veranstaltung war super! Es gab sehr viele interessante Vorträge, viele davon auch leider gleichzeitig, was sich nicht vermeiden lässt. Alle Vorträge wurden dankenswerterweise aufgezeichnet.

Ich selbst war zunächst am Samstagmorgen in den beiden Vorträgen, die ich gehalten habe. Zunächst über Snappy Ubuntu Core und anschließend über Ubuntu Phone. Beide Vorträge waren gut besucht, im Ubuntu Phone Vortrag waren aber letztendlich noch ein wenig mehr Leute da als beim Snappy Vortrag. Der Ubuntu Phone Vortrag lässt sich hier anschauen, während man den Snappy Vortrag hier findet.

Am Samstag war ich sonst in keinen anderen Vorträgen, am Abend gab es dann das Social Event, wo es kostenlos Essen vom Grill gab. Auch der Eintritt war für jeden Besucher in diesem Jahr frei!

Sonntag ging es dann los mit „Access Without Empowerment“ von Benjamin Mako Hill. Später war ich in dem äußerst interessanten und auch unterhaltsamen Vortrag „Was ist Cloud?“ von Kristian Köhntopp, der sehr sehenswert ist. Der Talk über „Ansible“ hat einen kurzen und guten Einblick in die Nutzung von Ansible als Deployment-Tool gegeben. Die übrige Zeit stand ich vor oder hinter dem Ubuntu-Stand, hauptsächlich wollten wo ich mit vielen Besuchern vor allem über Ubuntu Phone gesprochen habe. Auch gab es ein kleines Taskwarrior-Meetup mit Lynoure Braakman, Wim Schürmann, Dirk Deimeke und mir; ein Foto davon gibt es bei Dirk im Blog. Mit Niklas Wenzel und Christian Dywan hab ich zufällig auch noch zwei weitere Personen aus der Ubuntu-Community getroffen, die ich bisher noch nicht getroffen habe.

Nächstes Jahr geht es jedenfalls für mich definitiv wieder dorthin. Bis dahin steht dieses Jahr noch die Ubucon und die OpenRheinRuhr an.

Mit OpenDKIM und Postfix E-Mails signieren und verifizieren

Permalink Finns Blog

Es gibt jede Menge zusätzliche Validierungs- und Authentifizierungsmechanismen, die ein Mail-Server verwenden kann. Um zu gewährleisten, dass eine E-Mail tatsächlich von dem richtigen Mail-Server stammt, wurden DomainKeys Identified Mail (DKIM) Signaturen eingeführt, welche in den Header einer E-Mail platziert werden und vom Empfangenden Mail-Server verifiziert werden können. Als treuer Postfix Nutzer möchte ich kurz die notwendigen Schritte zeigen, damit Postfix erstens Mails mit einer DKIM Signatur verifiziert und zweitens selbst ausgehende E-Mails signiert.

Meine Installationsschritte beziehen sich auf CentOS 6.7, da ich dies derzeit auf meinem Mailserver verwende. Postfix verwende ich in Version 2.11, aber die Unterschiede zu anderen Distributionen sind in der Regel nur eine andere Art der Installation der Pakete (z.B. apt-get anstelle von yum). Der wesentliche Teil, die Konfiguration, ist gleich.

OpenDKIM vorbereiten

Bevor Änderungen an Postfix selbst vorgenommen werden, sollte OpenDKIM installiert werden, für die zu sicherende Domain ein Schlüsselpaar erzeugt und die OpenDKIM Konfiguration den Bedürfnissen entsprechend angepasst werden.

Die Installation selbst ist simpel:

# Installieren:
yum install opendkim
# Autostart:
chkconfig opendkim on

Die Hauptkonfigurationsdatei ist

/etc/opendkim.conf
  und im Verzeichnis
/etc/opendkim
  liegen weitere Konfigurationsdateien. Es ist zwar auch möglich, ein paar Zeilen in der Konfiguration zu sparen, wenn man OpenDKIM nur zur Signierung einer Domain verwendet, aber das werde ich hier nicht tun. Momentan lasse ich zwar nur eine Domain signieren, es werden aber weitere hinzu kommen.

Als erstes wird ein Schlüsselpaar erzeugt (die Domain finnchristiansen.de ist entsprechend zu ersetzen) und der Besitzer angepasst:

cd /etc/opendkim/keys
# entweder Schlüsselpaar im Testmodus erstellen:
opendkim-genkey -t -s mail -d finnchristiansen.de
# oder im (normalen) Produktivmodus
opendkim-genkey -s mail -d finnchristiansen.de
chown opendkim: mail.private

Die Datei

mail.private
  enthält den privaten und die Datei
mail.txt
  den öffentlichen Teil des Schlüssels. Der Inhalt der
mail.txt
  wird später für den DNS Record benötigt. Im Testmodus enthält der DNS Eintrag das Flag
t=y
 , welches andere Mail-Server informiert, dass DKIM sich im Teststatus befinden. Nicht oder falsch signierte E-Mails dürfen im Testmodus nicht anders behandelt werden, als signierte E-Mails. Dies kann man nutzen, um DKIM testweise einzuführen und zu debuggen.

Die

/etc/opendkim.conf
  habe ich wie folgt angepasst (Standard-Kommentare habe ich zur besseren Übersicht entfernt):
PidFile    /var/run/opendkim/opendkim.pid
Mode    sv
Syslog    yes
SyslogSuccess    yes
LogWhy    yes
UserID    opendkim:opendkim
Socket    inet:8891@localhost
Umask    002
SendReports    yes
SoftwareHeader    yes
Canonicalization    relaxed/relaxed
Selector    mail
MinimumKeyBits    1024
KeyTable    /etc/opendkim/KeyTable
SigningTable    refile:/etc/opendkim/SigningTable
ExternalIgnoreList    refile:/etc/opendkim/TrustedHosts
InternalHosts    refile:/etc/opendkim/TrustedHosts
OversignHeaders    From

Wie man sieht, nutze ich nicht explizit einen Key und eine Domain, sondern die

KeyTable
  und die
SigningTable
 . Diese haben momentan folgenden Inhalt:

KeyTable:

mail._domainkey.finnchristiansen.de finnchristiansen.de:mail:/etc/opendkim/keys/mail.private

SigningTable:

*@finnchristiansen.de mail._domainkey.finnchristiansen.de

Das Wort “mail” ist der DKIM-Selector, er ist nicht Bestandteil des Hostnamens, denn hier geht es um die Domain finnchristiansen.de und nicht um meinen Mail-Server mail.finnchristiansen.de.

Die Datei 

TrustedHosts
  muss eventuell noch um weitere Hostnamen, IPv4 oder IPv6 Adressen ergänzt werden, falls andere eigene Hosts auch Mails von der entsprechenden Domain über diesen Mailserver versenden. Der eigene Host muss hier natürlich auch aufgeführt sein. Diese Datei wird sowohl vom Parameter
ExternalIgnoreList
  verwendet als auch beim Parameter
InternalHosts
 . Diese bewirken, dass Mails von diesen Hosts nicht verifiziert, sondern signiert werden. Meine Datei hat folgenden Inhalt:
127.0.0.1
::1
mail.finnchristiansen.de
109.230.236.169/32
2a02:d40:3:1:d45b:7eff:fe2d:6d44/128

Die Konfiguration von OpenDKIM ist abgeschlossen und der Dienst kann nun gestartet werden:

service opendkim start

DNS Record eintragen

Mit

cat /etc/opendkim/keys/mail.txt
  lässt man sich den öffentlichen Schlüssel anzeigen. Der Teil in den Anführungszeichen (v=DKIM1; … p=…;) ist der Inhalt des TXT Records
mail._domainkey.finnchristiansen.de
 . Einer kurzer Test mit dig verrät mir, dass ich alles richtig gemacht habe:
dig txt mail._domainkey.finnchristiansen.de +short
"v=DKIM1\; k=rsa\; t=y\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0HJ5kXqvJ5LpydQAZCS4lvkUTnrBUIAQMODgKrsR3GoGcVGntdtebto3L+EnvNe5/ytV9i6hpoBhoPQIIYbz2bZVINLQs+Gxdo+6NkV/FNzsV27BJi1AkRs0Bx8FDXLUNgZmXc2xqVDst1Y+Lmmzz4CcbOZXnMqWnYCfUig4SPwIDAQAB"

Alternativ kann auch die Webseite von Protodave zum testen verwendet werden.

Postfix konfigurieren

In die Postfix Konfigurationsdatei habe ich folgende Zeilen an das Ende eingefügt:

#DKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

Nach einem Neustart von Postfix mit

service postfix restart
  war alles soweit fertig.

Sollten E-Mails seltsamerweise mehrach signiert werden, liegt es daran, dass der eben konfigurierte Milter mehrach durchlaufen wird. Um dies zu unterbinden, muss die

/etc/postfix/master.cf
  angepasst werden. Dort verwende ich die Services smtp, smtps und submission, welche zeilenweise mit dem Parameter -o einige Optionen übergeben bekommen. Diese Dienste werden nun jeweils um die Zeile
-o smtpd_milters=
  ergänzt, so dass es in etwa so aussieht (übrige Optionen zur besseren Übersicht weggelassen):
smtp      inet  n       -       n       -       -       smtpd
 -o smtpd_milters=

Testen

Nun sollte man Testen bzw. Verifizieren, ob die Signierung und Verifizierung mit DKIM korrekt funktioniert. Wer nicht gerne selbst Mail-Header ansieht und Logdateien durchwühlt, kann einfach die Webseite mail-tester.com verwenden. Dort sendet man eine E-Mail an eine bestimmte Adresse und die Webseite zeigt dann unter anderem die Ergebnisse der DKIM Validierung.

Durch den OpenDKIM Konfigurationsparameter

Mode sv
  wird sowohl beim Verifigzieren als auch beim Signieren in der
/var/log/maillog
  geloggt. Dort sollten nun Zeilen wie diesen auftauchen (vereinfacht dargestellt):
# Validierung beim Empfang
0EF8D1608EF: mx.example.org [1:2:3:4:5:6:7:8] not internal
0EF8D1608EF: not authenticated
0EF8D1608EF: message has signatures from example.org
0EF8D1608EF: DKIM verification successful

# Signierung beim Versenden
2BEE71608F1: DKIM-Signature field added (s=mail, d=finnchristiansen.de)

owncloud 8.1: Dokumente in der Cloud bearbeiten

Permalink canox.net

Wenn ihr in eurer owncloud, welche z.B. auf eurem Raspberry Pi läuft, auch Dokumente bearbeiten möchtet benötigt ihr ein auf dem Server installiertes OpenOffice oder LibreOffice und die Dokumente App für owncloud. In diesem Beitrag zeige ich euch wie ihr beides installiert.

sudo apt-get install unoconv openoffice.org -y

cd /var/www/owncloud/apps

wget https://github.com/owncloud/documents/releases/download/v8.1.1/documents.zip

unzip documents.zip

rm documents.zip

Meldet euch nun als Administrator auf eurer owncloud an, geht zu den Apps, klickt auf den Reiter Nicht aktiviert und aktiviert Documents.

Geht anschließend in den Administrationsbereich > Dokumente

Ändert dort den Haken von Deaktiviert auf Lokal und klickt auf Übernehmen und Testen.

Von nun an könnt ihr eure Dokumente auch in eurer owncloud bearbeiten.

24. August 2015

Linux 4.2-rc8

Permalink menzer.net

Es gibt eine neue Entwicklerversion, aber es soll die letzte bleiben.

Zumindest ist das derzeit geplant – diesmal waren noch einige Änderungen hinzugekommen und im Zusammenhang damit, dass noch einige Entwickler im Urlaub sind, ließ sich ein -rc8 rechtfertigen.

Konkret wurden Neuerungen zurückgenommen, die IR-Geräte mit einer neuen Schnittstelle zum Versenden von Daten ausstatten sollte. Diese war scheinbar nicht ausgereift genug, sodass sie vorübergehend wieder entfernt wurde. Weiterhin wurde die Umsetzung für die automatische Erkennung von NCQ (Native Command Queing) zurückgenommen, wodurch bei bestimmten Massenspeichern automatisch NCQ genutzt werden sollte.

Sollten keine größeren Probleme auftreten, ist zu erwarten, dass Linux 4.2 tatsächlich Anfang kommender Woche freigegeben wird. Am ehesten könnten dem noch die Änderungen des x86-Entry-Codes im Wege stehen, der in diesem Entwicklungszyklus genügend Beschäftigung für die damit befassten Entwickler bereithielt.

Die kleine Statistik:

Commits geänderte Dateien eingefügte Zeilen gelöschte Zeilen Datum Tage *
4.2-rc1 12 808 10 344 1 062 782 272 311 05.07.2015 13
4.2-rc2 259 245 5771 1912 12.07.2015 7
4.2-rc3 427 525 4203 2956 19.07.2015 7
4.2-rc4 341 277 4013 3486 26.07.2015 7
4.2-rc5 336 296 4445 2073 03.08.2015 8
4.2-rc6 189 177 1669 648 09.08.2015 6
4.2-rc7 200 156 1356 1179 16.08.2015 7
4.2-rc8 136 112 708 1277 24.08.2015 8
Gesamt 14 702 10 916 1 081 067 281 962 63

* Tage seit dem letzten rc/Release

Quellen: Linux Kernel Mailing List

Call for Papers endet in einer Woche

Permalink Ubucon

Mit der Ankündigung der diesjährigen Ubucon 2015 starteten wir auch den „Call for Papers“. Bis zum 31. August kann noch jeder einen Vortrag einreichen. Bislang sind insgesamt 12 Programmpunkte enthalten, die genaueren Informationen zu den Programmpunkten lassen sich im vorläufigen Programm ansehen.

Um auch dieses Jahr ein breitgefächertes Angebot an Vorträgen und Workshops zu haben, folgt hier nochmal der Aufruf seinen eigenen Programmpunkt einzureichen. Als Inspiration kann euch auch die kleine aber feine Themenwunschliste dienen.

Für die Besucher ist auch weiterhin die Anmeldung eröffnet. Diese kostet in diesem Jahr 15€, darin enthalten sind Getränke und belegte Brötchen.

mailcow 0.11 ist jetzt stabil

Permalink debinux

Vielen Dank für die Geduld, Vorschläge, Hilfen und die vielen Sternchen im GitHub Repository. :-)

mailcow ist nun zuhause @ http://mailcow.email/.

Eine wichtige Änderung ist die Möglichkeit, mailcow auf entfernten Datenbanken zu installieren. Insgesamt wurde das SQL-Handling verbessert. Lokal kann nun ebenso zwischen MySQL und MariaDB ausgewählt werden.
Weiterhin wurde SabreDAV auf Version 3.0.3 aktualisiert und einige Fehler im Panel behoben, etwa die fehlerhafte Anmeldung und das Domainnamen-Handling (besonders Domänen mit „-“ im Namen).

Für ein Upgrade genügt auch weiterhin die Ausführung des Befehls ./install.sh -u.

Um auf einer entfernten SQL-Datenbank zu installieren, muss lediglich „my_dbhost“ dem Hostnamen/der IP- und „my_rootpw“ dem SQL-root-Passwort entsprechen.

Last but not least die wichtigsten Links:
mailcow.email
mailcow@GitHub
Changelogs@GitHub

owncloud 8.1: Anti-Virus App installieren

Permalink canox.net

owncloud lässt sich mithilfe von Apps erweitern. Wer seinen owncloud Server, der z.B. auf einem Raspberry Pi läuft, mit anderen Personen teilt, egal ob Familie oder Freunde, und nicht möchte das dort Viren oder Schadeware gehostet wird, der kann die App Antivirus App for files verwenden. In diesem Beitrag zeige ich euch wie ihr diese installiert.

cd /var/www/owncloud/apps

wget https://github.com/owncloud/files_antivirus/releases/download/v0.7.0.1/files_antivirus.tar.gz

sudo tar -vxzf files_antivirus.tar.gz

sudo rm files_antivirus.tar.gz

sudo apt-get install clamav -y

sudo freshclam

Meldet euch nun als Administrator auf eurer owncloud an, geht zu den Apps, klickt auf den Reiter Nicht aktiviert und aktiviert Antivirus App for files.

Geht anschließend in den Administrationsbereich  > Antivirus-Konfiguration:

Modus ausführbar
Aktion für infizierte Dateien die beim Scannen gefunden werden Datei löschen

Wenn ihr die Beiden Einstellungen geändert habt müsst ihr noch auf Speichern klicken.

Nun könnt ihr z.B. den eicar.com Testvirus auf eurer owncloud hochladen. Sobald diese hochgeladen ist wird diese euch aber nicht angezeigt sondern sie landet direkt bei den gelöschten Elementen. Mit ZIP-Dateien funktioniert das ganze derzeit (August 2015) nicht.

23. August 2015

GPG Error in der apt-get Schlüsselverwaltung

Permalink Andre's Webblog

Auf frisch installierten Server habe ich häufig das Problem, dass für eine Überprüfung nach sudo apt-get update die entsprechenden GPG-Schlüssel fehlen. Somit kann apt-get die zu installierenden Pakete nicht überprüfen. Natürlich kann auch auf die Überprüfung verzichtet werden. Jedoch ist dies nicht im Sinne des Entwicklers und es wird nicht mehr Sichergestellt, dass die Software-Paketdaten auch wirklich vertraulich sind.

Die Fehlermeldung sieh meisten wie folgt aus (hier Ubuntu 14.04):

...
Fetched 3732 B in 2s (1523 B/s)              
Reading package lists... Done
W: GPG error: http://archive.canonical.com trusty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG error: http://archive.ubuntu.com trusty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG error: http://archive.ubuntu.com trusty-updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG error: http://security.ubuntu.com trusty-security Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32

Wie der Meldung eindeutig zu entnehmen fehlen die hier GPG-Schlüssel 40976EAF437D05B5 und 3B4FE6ACC0B21F32.

Bei einem nachfolgenden sudo apt-get upgrade würde dann folgende Meldung erscheinen:

WARNING: The following packages cannot be authenticated!
  ...Auflistung von Paketen...
Install these packages without verification? [y/N]

Was tun ?

Ganz einfach die fehlenden GPG-Schlüssel dem System hinzufügen. Dies geht mit:

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys >SchlüsselID<

Danach sieht die Ausgabe etwa wie folgt aus und das Problem sollte nicht wieder auftauchen:

Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.ZfdYij3xyC --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 40976EAF437D05B5
gpg: requesting key 437D05B5 from hkp server keyserver.ubuntu.com
gpg: key 437D05B5: public key "Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Extra Info

Mit apt-key list kann man sich alle seine Schlüssel für die Paketverwaltung anzeigen lassen. Sollten Abgelaufene Schlüsse dabei sein (z.B. von fremden Paketquellen), könne diese z.B. mit

sudo apt-key del >Schlüssel ID<

entfernt werden. Aber ACHTUNG das Datum welches direkt nach der Schlüssel ID steht, ist das Erstellungsdatum. Schlüssel mit Ablaufdatum sehen aus, wie z.B.:

pub 2048g/133A59E3 2014-08-23 [verfällt: 2019-08-23]

Private Browsing 2.0: Mozilla erweitert Privaten Modus um Tracking-Schutz

Permalink Sören Hentzschel

Mozilla hat wie bereits vorab angekündigt den Privaten Modus von Firefox um einen Tracking-Schutz erweitert, den Nutzer der Nightly-Version und Developer Edition von Firefox nun testen können.

Firefox besitzt bereits seit einiger Zeit einen experimentellen Tracking-Schutz. Dieser kann in Vorabversionen von Firefox über eine versteckte Einstellung aktiviert werden. In die Nightly-Version von Firefox 39 wurde die experimentelle Funktion über eine weitere versteckte Einstellung zur Verfügung gestellt, den Tracking-Modus in den sogenannten privaten Fenstern zu aktivieren. Private Fenster sind Fenster, in denen Firefox keine Chronik, Sucheinträge, Cookies oder sonstige Surfspuren zurücklässt.

Wer eine Nightly-Version von Firefox oder die Developer Edition nutzt, wird feststellen können, dass diese Option in den Einstellungen sichtbar gemacht worden ist. Darüber hinaus ist der Tracking Schutz für private Fenster nun standardmäßig aktiviert.

Die Startseite der privaten Fenster wurde außerdem überarbeitet und macht nun deutlicher als bisher klar, was sich Firefox in diesem Modus merkt und was nicht. Der neue Tracking-Schutz findet in dem neuen Design eine besondere Hervorhebung. Der Status, ob dieser aktiviert ist oder nicht, wird auf dieser Seite ebenso angezeigt wie ein Link, um diesen zu deaktivieren respektive wieder zu aktivieren, ohne dafür extra in die Einstellungen gehen zu müssen.

Mit aktiviertem Tracking-Schutz erkennt der Nutzer am Schild-Symbol in der Adressleiste, dass Elemente blockiert worden sind. Hierüber gibt es auch die Möglichkeit, den Tracking-Schutz für die aktuelle Session auf dieser Webseite zu deaktivieren. In dem Fall befindet sich hinterher ein durchgestrichenes Schild-Symbol in der Adressleiste.

Wer wissen will, welche Elemente durch den Tracking-Schutz blockiert worden sind, kann dies über die Webkonsole ablesen.

Abgrenzung zu Werbeblockern

Der Tracking-Schutz blockiert Elemente von bekannten Trackern. Dies trifft häufig auf Anzeigen aus Werbenetzwerken zu, womit der Tracking-Schutz einen Großteil der Werbung im Web blockiert. Es handelt sich hierbei aber um keinen klassischen Werbeblocker, der jede Werbung blockiert: Werbung, die ohne Tracking auskommt, wird durch den Tracking-Schutz naheliegenderweise nicht blockiert.

Ubuntu: owncloud Client installieren

Permalink canox.net

In diesem Beitrage zeige ich euch wie ihr den owncloud Client unter Ubuntu 14.04 LTS, Ubuntu 14.10 & Ubuntu 15.04 installiert. Diesen könnt ihr verwenden um z.B. auf die owncloud, welchem auf eurem Raspberry Pi läuft, zuzugreifen.

Installation über die Paketquelle:

Ubuntu 14.04 LTS:

sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_14.04/ /' >> /etc/apt/sources.list.d/owncloud-client.list"

wget http://download.opensuse.org/repositories/isv:ownCloud:desktop/Ubuntu_14.04/Release.key

sudo apt-key add - < Release.key  

sudo apt-get update

sudo apt-get install owncloud-client

Ubuntu 14.10:

sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_14.10/ /' >> /etc/apt/sources.list.d/owncloud-client.list"

wget http://download.opensuse.org/repositories/isv:ownCloud:desktop/Ubuntu_14.10/Release.key

sudo apt-key add - < Release.key  

sudo apt-get update

sudo apt-get install owncloud-client

Ubuntu 15.04:

sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_15.04/ /' >> /etc/apt/sources.list.d/owncloud-client.list"

wget http://download.opensuse.org/repositories/isv:ownCloud:desktop/Ubuntu_15.04/Release.key

sudo apt-key add - < Release.key  

sudo apt-get update

sudo apt-get install owncloud-client

Quelle: software.opensuse.org

22. August 2015

Bananian 15.08 veröffentlicht

Permalink canox.net

Heute wurde die neue Bananian Version 15.08 veröffentlicht. Die Version basiert auf Debian 8 „Jessie“. Bananian 15.04, welches auf Debian 7 „Wheezy“ basiert, wird weiterhin zum Download angeboten.

Hier die Release Notes:
– 0000151: [Hardware] LCD support is broken with mainline U-Boot 2015.07
– 0000149: [Kernel] prepare for mainline Kernel 4.x
– 0000135: [Userland] add 15.08 release to bananian-update
– 0000146: [General] Keep SysVinit instead of systemd
– 0000127: [General] RFE: rebase Bananian to Debian 8
– 0000106: [Kernel] patch Realtek driver for 8192cu / 8188cu devices
– 0000118: [Userland] package swconfig as a .deb file
– 0000145: [Network] Improve SSH host key generation
– 0000138: [General] create repository for jessie
– 0000144: [Security] Adjust the SSH configuration for Debian Jessie
– 0000143: [General] expanding the filesystem does not work on Debian 8
– 0000133: [Kernel] enable CONFIG_BLK_DEV_THROTTLING in the kernel
– 0000141: [Userland] Lost colors and command prompt in zsh shell
– 0000142: [Kernel] Update Linux Kernel to 3.4.108
– 0000136: [Userland] error handling in “soctemp”

Folgende Einplatinencomputer werden unterstützt:

  • Banana Pi M1
  • Banana Pro
  • Banana Pi M1+
  • BPi-R1
  • A20-OLinuXIno-LIME2 (Beta)
  • Orange Pi (Beta)

Der Banana Pi M2 wird nicht unterstützt.

Download:

Bananian 15.08 (basiert auf Debian 8 „Jessie“)

Bananian 15.04 (basiert auf Debian 7 „Wheezy“)

Kaufen:

Banana Pi M1 bei Amazon kaufen

Banana Pro bei Amazon kaufen

BPi-R1 bei Amazon kaufen

Quelle: bananian.org/news, bananian.org/hardware,

LAN – statische IP für den Pi

Permalink Intux

raspberry

Will man dem über LAN angeschlossenen Raspberry Pi eine statische IP-Adresse zuweisen so geht man folgendermaßen vor.

sudo nano /etc/network/interfaces

auto lo

iface lo inet loopback
iface eth0 inet static
address 192.168.1.60
netmask 255.255.255.0
gateway 192.168.1.1

Dabei muss man natürlich die Adresse an das eigene Netzwerk anpassen.

Die Datei wird nun mit Ctrl + o und Enter gespeichert und mit Ctrl + x wird der Editor verlassen. Nun das Netzwerk neu starten und rebooten.

sudo /etc/init.d/networking restart

sudo reboot

Hinweis:

WLAN wird hierbei nicht berücksichtigt!

21. August 2015

Mozilla kündigt große Änderungen für Entwickler von Firefox Add-ons an

Permalink Sören Hentzschel

Mozilla hat heute eine Reihe von Ankündigungen gemacht, welche die Zukunft der Entwicklung von Add-ons für Firefox betreffen. Dabei geht es neben der Signierung von Add-ons und der kommenden Multiprozessarchitektur (Electrolysis, kurz: e10s) auch um die Einführung der sogenannten WebExtensions, welche größtenteils API-kompatibel mit Chrome, Opera und in der Zukunft ggfs. auch Edge ist, sowie um die Deprecation von XUL, XBL und XPCOM.

Auf die Entwickler von Add-ons für Firefox kommt eine Reihe von wichtigen Änderungen zu, die Mozilla frühzeitig kommuniziert, so dass Entwickler rechtzeitig über Mozillas Pläne informiert sind. Diese Änderungen seien notwendig, um Technologien wie die Multiprozessarchitektur Electrolysis (auch bekannt als e10s) oder Mozillas kommende Browserengine Servo zu unterstützen, die Nutzer besser vor Spyware und Aware zu schützen und außerdem die Zeit zu reduzieren, die es für die Reviews von Add-ons benötigt.

Neue Schnittstelle für browserübergreifend kompatible Add-ons

Die Entwicklung von Add-ons sollte nach Ansicht von Mozilla vergleichbar mit der Entwicklung von Webseiten sein: der selbe Code soll in verschiedenen Browsern funktionieren. Mit den sogenannten WebExtensions führt Mozilla eine neue Schnittstelle für Add-ons ein, welche größtenteils kompatibel mit Chrome und Opera ist – möglicherweise in der Zukunft sogar mit Microsoft Edge, wie Mozilla andeutet. Mozilla hat bereits Diskussionen mit anderen Browserherstellern gestartet, um zumindest einen Teil der Schnittstelle zu standardisieren und somit die browserübergreifende Kompatibilität auch langfristig zu gewährleisten. Dies bedeutet für Entwickler, die Add-ons für verschiedene Browser entwickeln, dass nur minimale Anpassungen notwendig sind und nicht für jeden Browser eine grundlegend unterschiedliche Erweiterung programmiert werden muss. Ein weiterer Vorteil der WebExtensions ist, dass diese die Multiprozessarchitektur der Browser direkt unterstützen. Eine erste Unterstützung für WebExtensions wird ab Firefox 42 verfügbar sein.

Multiprozessarchitektur („Electrolysis“ / „e10s“)

Die geplante Multiprozessarchitektur für Firefox macht große Fortschritte und wird bekanntermaßen große Auswirkungen auf die Kompatibilität von Add-ons haben, insbesondere von Add-ons, welche mit dem Inhalt von Webseiten interagieren.

Die neuen WebExtensions sind wie bereits erwähnt vollständig kompatibel mit e10s. Add-ons, die auf dem Add-on SDK basieren, auch bekannt als Jetpack, sind kompatibel, solange sie nicht require(‘chrome’) oder manche Low-Level-APIs nutzen, die Objekte im Content-Prozess berühren. Dann gibt es noch sogenannte Kompatibilitäts-Shims in Firefox, die dafür sorgen, dass Add-ons oder Teile von Add-ons auch in e10s funktionieren, obwohl sie noch nicht für e10s angepasst worden sind – dies allerdings zum Preis einer spürbar schlechteren Performance.

Einen verbindlichen Zeitplan für die Auslieferung von e10s in einer finalen Version von Firefox gibt es noch nicht. Fest steht, dass e10s in der Nightly Version sowie Developer Edition bereits standardmäßg aktiviert ist. Am 22. September wird Firefox 42 die Betaphase erreichen und e10s den Nutzern per Opt-In zur Aktivierung angeboten werden. Die am 3. November erscheinende Betaversion von Firefox 43 wird die früheste Betaversion sein, in welcher e10s standardmäßig aktiviert sein wird. Sobald dies der Fall ist, wird Mozilla damit beginnen, Add-ons zu blockieren, die nicht kompatibel mit e10s sind und Performance- und/oder Stabilitätsprobleme verursachen. Am 15. Dezember erscheint dann die finale Version von Firefox 43 und damit die frühestmögliche Version, in welcher e10s aktiviert sein wird. Im Zeitraum von zwischen sechs und zwölf Monaten nach der standardmäßigen Aktivierung von e10s in der finalen Version von Firefox wird Mozilla die Kompatibilitäts-Shims entfernen, womit Add-ons inkompatibel werden, die hiervon Gebrauch machen.

Entwickler von Add-ons sollten sich also so langsam mit der möglicherweise notwendigen Anpassung ihrer Add-ons befassen, falls nicht schon geschehen, und ggfs. das Kompatibilitäts-Flag setzen. Eine Alternative dazu ist natürlich die Portierung zu einer WebExtension. Add-ons können bereits in der Nightly Version sowie Developer Edition mit aktivierter Multiprozessarchitektur getestet werden. Außerdem ist jeder eingeladen, auf der Webseite arewee10syet.com die Liste der Add-ons durchzugehen und die Kompatibilität der Add-os zu testen.

Signierung von Add-ons

An den Plänen zur Signierung von Add-ons hat sich nichts geändert. Add-ons müssen in Zukunft von Mozilla signiert sein, damit sie in Firefox installiert werden können. Damit sollen Nutzer besser vor schädlichen Add-ons und Add-ons, die Dinge gegen den ausdrücklichen Willen des Nutzers machen, geschützt werden. Bislang konnte Mozilla immer nur im Nachhinein reagieren und Add-ons blockieren, nachdem sie bereits Schaden angerichtet haben.

Seit Version 40 warnt Firefox bei nicht signierten Add-ons, ab Version 41 werden diese standardmäßig deaktiviert werden, können aber per Änderung in about:config wieder zum Laufen gebracht werden, ab Firefox 42 ist die Signaturpflicht in der finalen Version und in der Beta unumgänglich. In der Nightly-Version sowie Developer Edition wird die Signaturpflicht auch weiterhin deaktivierbar bleiben. Außerdem wird Mozilla spezielle Beta- und Finalbuilds ohne offizielles Firefox-Branding bereitstellen, welche ebenfalls eine Deaktivierung der Signaturpflicht erlauben.

Schnellere Reviews von Add-ons

Bis Add-ons ein Review von Mozilla erhalten, können schon mal Wochen vergehen – was ohne Frage zu lange ist. Auch hier spielen die neuen WebExtensions einen Vorteil aus, denn diese können wesentlich schneller von Mozilla kontrolliert werden. Ziel sind maximal fünf Tage für ein neues Add-on und maximal zwei Tage für ein Update.

Mozilla wird außerdem das Team der freiwilligen und bezahlten Reviewer aufstocken und weitere Verbesserungen am automatischen Validator vornehmen, um die Wartezeiten zu verkürzen.

Deprecation von XUL, XBL und XPCOM

Eine weitere sehr große Veränderung betrifft die XUL- und XPCOM-basierten Erweiterungen. Dass Mozilla von XUL und XBL abweichen möchte, ist nicht neu. Auch kann Firefox nicht Mozillas kommende Engine Servo nutzen, solange XUL unterstützt wird. Die enge Verzahnung von Browser und XUL-Erweiterungen bereitet außerdem Probleme für die Entwicklung, die in der Ankündigung näher benannt werden.

Für die Deprecation von XUL, XBL und XPCOM gibt es noch keinen genauen Zeitplan, vermutlich wird dies aber innerhalb der nächsten zwölf bis 18 Monate passieren. Ab dann muss man sich darauf einstellen, dass Add-ons, welche Gebrauch von diesen Technologien machen, irgendwann nicht länger funktionieren werden.

Mozilla ist sich dessen bewusst, dass die SDK basierten Add-ons und auch die WebExtensions Stand heute nicht alles leisten können, was XUL-basierte Add-ons leisten können. Basierend auf dem Feedback der Entwickler möchte Mozilla die WebExtensions-API im Laufe des kommenden Jahres aber entsprechend erweitern, um so viel wie möglich zu unterstützen, was von den populären Erweiterungen benötigt wird.