Schlagwort-Archiv: Planet

Tag für den Ubuntuusers.de Planeten.

Erstellung eines Yum-Repositories

Nachdem ich im Artikel „Lokaler Spiegelserver für CentOS, Fedora und RHEL“ beschrieben habe, wie man Paketquellen auf den eigenen Server spiegeln kann, möchte ich in diesem Artikel dokumentieren, wie man ein Yum-Repository erstellt, um darüber z.B. eigene RPM-Pakete zur Verfügung zu stellen.

Auch für diesen Artikel gilt, dass es keine Schritt-für-Schritt-Anleitung ist. Weiterführende Informationen findet man unter den Links am Ende des Artikels oder in der manpage des jeweiligen Programms.

Voraussetzung dafür ist, dass wie beim lokalen Spiegelserver ein Webserver läuft, über welchen das Repository ausgeliefert werden kann. Darüber hinaus muss das Programm createrepo installiert sein, welches über das gleichnamige Paket bereitgestellt wird.

Für das eigene Yum-Repository wird ein Verzeichnis erstellt, welches vom Webserver ausgeliefert werden kann. Unter CentOS, RHEL und Fedora kann dies z.B. wie folgt erfolgen:

:~# mkdir /var/www/html/custom-rpms

In dieses Verzeichnis werden die RPM-Pakete kopiert, welche man über dieses Repository bereitstellen möchte. Anschließend wechselt man in das Verzeichnis und erstellt durch den Aufruf von createrepo die erforderlichen Meta-Daten.

:~# cd /var/www/html/custom-rpms
:~# createrepo --database /var/www/html/custom-rpms

Damit ist die Erstellung des Yum-Repositories bereits abgeschlossen.

Ergänzend kann man noch eine *.repo-Datei erstellen, um die Verwendung des Repository zu vereinfachen.

Quellen und weiterführende Links

Konfiguration eines einfachen Git-Servers

Git ist ein freies Versionsverwaltungssystem für Dateien. In diesem Artikel wird die Konfiguration eines einfachen Git-Servers dokumentiert, der von Entwicklern genutzt werden kann, um ihren Code ein- bzw. auszuchecken.

Der Zugriff auf den hier beschriebenen Git-Server erfolgt ausschließlich über SSH. Die öffentlichen SSH-Schlüssel der Entwickler müssen in der Datei authorized_keys hinterlegt werden, bevor diese auf den Server zugreifen können. Doch ein Schritt nach dem anderen.

Installation von Git

Zuerst wird Git selbst auf dem Server installiert. Dies kann je nach verwendeter Distribution mit einem der folgenden Kommandos erledigt werden.

Für CentOS, Fedora, RHEL, etc.:

sudo yum install git

Für Debian, Ubuntu und Derivate:

sudo apt-get install git

Die benötigten Abhängigkeiten werden dabei von der Paketverwaltung selbstständig aufgelöst.

Git-Benutzer erstellen und SSH-Zugriff einrichten

Für die Verwendung des Git-Servers wird ein eigener Benutzeraccount erstellt. In diesem Beispiel wird dafür der Benutzer „git“ angelegt. Der Name ist jedoch frei wählbar.

Anschließend wird im HOME-Verzeichnis dieses Benutzers die Datei ~/.ssh/authorized_keys angelegt, in welche die öffentlichen SSH-Schlüssel der Benutzer eingefügt werden, welche den Server später verwenden sollen.


:~# useradd git -m
:~# su git
:~$ cd
:~$ mkdir .ssh && chmod 700 .ssh
:~$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys

Ein leeres Git-Repository erstellen

Um ein neues/leeres Git-Repository zu erstellen, meldet man sich als „git“-Benutzer an und führt die folgenden Befehle aus:

mkdir verzeichnis.git
cd verzeichnis.git
git init --bare
Initialisierte leeres Git-Projektarchiv in /home/git/verzeichnis.git/

Fertig. Damit wurde ein Git-Repository erzeugt, welches von anderen Rechnern für Push- und Pull-Operationen genutzt werden kann.

Hinweis: Für die Erstellung weiterer Repositories muss die obige Prozedur wiederholt werden.

Zusätzliche Absicherung des Git-Servers

Bisher können Anwender, deren öffentlicher SSH-Schlüssel in der Datei authorized_keys des Git-Servers hinterlegt ist, sich via SSH am Server anmelden und bekommen eine Login-Shell. Dies ist evtl. nicht in jedem Fall gewünscht. Daher wird im Folgenden beschrieben, wie man den Git-Server härten kann.

Um ein Login via SSH zu verhindern, gleichzeitig aber die Ausführung von Git-Operationen zu erlauben, kann eine andere Shell für den Git-Benutzer gesetzt werden. Ob die dafür erforderliche Shell bei der Installation von Git bereits mit installiert wurde, kann mit folgendem Kommando überprüft werden:

which git-shell

Ist die git-shell installiert, liefert das Kommando den Installationspfad zurück. Dieser Pfad wird der Datei /etc/shells hinzugefügt.

Um nun die Login-Shell für den Benutzer „git“ zu ändern, wird folgendes Kommando mit root-Rechten ausgeführt.

sudo chsh -s git-shell git

Repository auf einem Client nutzen

In diesem Abschnitt beschreibe ich, wie ein Repository von einem einfachen Git-Server auf einem Client genutzt werden kann. Dabei verwende ich folgende Werte für die Umgebung.

  • FQDN des einfachen Git-Servers: git.example.com
  • Repository-Name: verzeichnis.git

git-clone via SSH-Protokoll

$ git clone ssh://git@git.example.com/home/git/verzeichnis.git

Repository als remote hinzufügen

Ich habe häufig den Fall, dass ich lokal auf meinem Client bereits ein Git-Repository habe, welches ich in das Repository auf meinem einfachen Git-Server pushen möchte. Dazu füge ich dies als remote wie folgt hinzu:

git remote add git-example ssh://git@git.example.com/home/git/verzeichnis.git

Dabei ist git-example ein Name, der mich daran erinnert, auf welchem Server das Remote-Repository liegt.

Quellen und weiterführende Informationen

Lokaler Spiegelserver für CentOS, Fedora und RHEL

Durch die Nutzung eines lokalen Spiegelservers lassen sich Softwarepakete im lokalen Netzwerk bereitstellen. Dies schont die Internetverbindung und spart damit Bandbreite und evtl. Kosten.

Dieser Artikel beschreibt und dokumentiert die Einrichtung eines lokalen Spiegelservers für CentOS, Fedora und RHEL. Er bietet jedoch keine Schritt-für-Schritt-Anleitung. Für detaillierte Informationen wird auf die Quellen am Ende des Artikels sowie auf die manpages der einzelnen Kommandos verwiesen.

Konfiguration des Spiegelservers

Für den Betrieb eines lokalen Spiegelservers müssen ein Webserver sowie die CLI-Programme reposync und createrepo auf dem Host installiert werden, welcher als Spiegelserver dienen soll.

Hinweis für RHEL: Bei Verwendung von RHEL könnten nur jene Paketquellen gespiegelt werden, für welche der Spiegelserver eine gültige Subskription besitzt. Sollen auch solche Paketquellen gespiegelt werden, für die der Host keine Subskription besitzt, ist der Einsatz des kostenpflichtigen Satellite Servers erforderlich.

Diese Pakete befinden sich in der Regel in den Paketquellen, welche standardmäßig zur jeweiligen Distribution gehören. Für CentOS/RHEL können die Pakete zum Beispiel mit den folgenden Befehlen installiert werden:

$ sudo yum groupinstall "Einfacher Webserver"
$ sudo yum install yum-utils createrepo

Verwendet man bereits eine Fedora-Version mit dem YUM-Nachfolger DNF, so können die Pakete wie folgt installiert werden:

$ sudo dnf groupinstall "Web Server"
$ sudo dnf install yum-utils createrepo

Für eine Minimalkonfiguration des Webservers ist es erforderlich, den FQDN des Hosts als ServerName in der Datei /etc/httpd/conf/httpd.conf zu setzen.

Verwendet man die Hostfirewall, so ist der Zugriff auf den Webserver in dieser noch freizugeben.

$ sudo firewall-cmd --add-service http

Im nächsten Schritt wird unterhalb des Webserver-Wurzelverzeichnisses ein Verzeichnis erstellt, in dem zukünftig die gespiegelten Repositories abgelegt werden.

sudo mkdir /var/www/html/repomirror

Nun können mit reposync Pakete aus Online-Quellen auf den Spiegelserver heruntergeladen werden:

$ sudo reposync --gpgcheck -l --repoid= --download_path=/var/www/html/repomirror --downloadcomps --download-metadata -n

Die benötigte Repo-ID kann der ersten Spalte der Ausgabe von sudo yum repolist entnommen werden. Mit dem Parameter -n wird nur die aktuellste verfügbare Paketversion heruntergeladen.

Möchte man bspw. das base-Repository von CentOS spiegeln, so geschieht dies mit dem Kommando:

$ sudo reposync --gpgcheck -l --repoid=base --download_path=/var/www/html/repomirror --downloadcomps --download-metadata -n

Dadurch wird im Verzeichnis /var/www/html/repomirror das Unterverzeichnis base erstellt.

Damit die lokale Paketquelle nun von anderen Servern im lokalen Netzwerk genutzt werden kann, müssen noch die Metadaten mit Hilfe des folgenden Befehls erstellt werden. Beispiel für das base-Repository aus CentOS:

# cd /var/www/html/repomirror/base
# createrepo -v /var/www/html/repomirror/base/ -g comps.xml

Um den Abgleich der Paketquellen und die Erstellung der Metadaten zu automatisieren, kann folgendes Skript über den Cron-Dienst ausgeführt werden. Hier sind lediglich noch die REPO-ID und der Download-Pfad für die entsprechenden Variablen zu definieren.
#!/bin/bash
#
# Beschreibung: Skript zur Synchronisierung des RHEL-Repositories
# auf dem Spiegelserver
# Autor: Joerg Kastning <joerg(Punkt)kastning(aet)uni-bielefeld.de>

LOG="/var/log/do_reposync.log"
REPOID=" "
DOWNLOADPATH=" "

echo \# `date +%Y-%m-%d` - START REPOSYNC \# > $LOG

reposync --gpgcheck -l --repoid=$REPOID --download_path=/var/www/html/$DOWNLOADPATH --downloadcomps --download-metadata -n >> $LOG

echo \# `date +%Y-%m-%d` - END REPOSYNC \# >> $LOG
echo \# `date +%Y-%m-%d` - START CREATEREPO \# >> $LOG

cd /var/www/html/$DOWNLOADPATH/$REPOID
createrepo -v /var/www/html/$DOWNLOADPATH/$REPOID -g comps.xml >> $LOG

echo \# `date +%Y-%m-%d` - END CREATEREPO \# >> $LOG

exit 0

Erzeugung einer *.repo-Datei

Um die Paketquellen auf dem Spiegelserver zu verwenden, müssen diese auf dem Client bekannt gemacht werden. Dies geschieht zum Beispiel, indem auf dem Client eine *.repo-Datei im Verzeichnis /etc/yum.repos.d/ angelegt wird. Der Aufbau dieser Datei wird am Beispiel des CentOS-Repositories base demonstriert:

[base]
name= CentOS-$releasever - Base (local)
baseurl=http://FQDN/repomirror/base/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Legt man diese Datei auf dem lokalen Spiegelserver in einem Verzeichnis ab, welches über den Webserver erreichbar ist, kann sie von einem Client mit dem folgenden Kommando importiert werden:

# yum-config-manager --add-repo http://FQDN/repomirror/DATEINAME.repo

Besonderheit bei Verwendung von SELinux

Bei Verwendung von SELinux, müssen die Dateien noch mit dem Attribut httpd_sys_content_t ausgestattet werden. Für Dateien in /var/www/html geschieht dies mit:

restorecon -R -v /var/www/html/*

Quellen und weiterführende Links

Bash-Skript zur Aktualisierung einer Roundcube-Installation

In diesem Artikel möchte ich euch ein kleines Bash-Skript vorstellen, mit dem die Aktualisierung von Roundcube gesteuert werden kann.

Es führt ein Backup der Roundcube-Installation inkl. der dazugehörigen MySQL-Datenbank durch, lädt das TAR-Archiv der neuen Version herunter und aktualisiert die existierende Version.

Das Skript habe ich auf GitHub Gist unter der GPLv3 veröffentlicht. Ihr dürft es also gern unter den Bedingungen der GPLv3 verwenden, ändern und in eigene Projekte einbauen. Es kann auch am Ende dieses Artikels als ZIP-Archiv heruntergeladen werden.

Um das Skript nutzen zu können, müssen die vier Variablen am Anfang des Skripts definiert werden:

# Variablen
INSTALL_PATH=" " # Pfad zur Roundcube-Installation
RC_DB_NAME=" " # Name der zur Roundcube-Installation gehörenden MySQL-Datenbank
PACKAGE_URL=" " # Download-URL der akutellen Roundcube-Version
MYSQL_ROOT_USER=" " # MySQL-Benutzer mit Root-Rechten auf der Roundcube-Datenbank

Anschließend muss das Skript noch mit dem Befehl chmod a+x updating_roundcube.sh ausführbar gemacht werden.

Nun kann das Skript zur Aktualisierung der Roundcube-Installation ausgeführt werden. Getestet habe ich das Skript heute, um meine Roundcube-Installation von Version 1.0.8 auf Version 1.0.9 zu aktualisieren.

Downloads:

2017-03-25_updating_roundcube.zip

Support-Subskriptionen von SUSE und RedHat

Nachdem ich an dieser Stelle bereits ausführlich über das kommerzielle Angebot Ubuntu Advantage berichtet habe, möchte ich in diesem Artikel kurz die Support-Subskriptionen von SUSE und RedHat vorstellen.

Die Subskriptionen

Beim SUSE Linux Enterprise Server (SLES) sowie dem RedHat Enterprise Linux (RHEL) handelt es sich um kommerzielle Produkte, welche nur mit einer gültigen Subskription verwendet werden dürfen.

Mit einer Subskription erhält man neben dem Recht, das erworbene Enterprise Linux verwenden zu dürfen, auch Zugriff auf Software-Paketquellen und darin enthaltene Updates für das Betriebssystem und enthaltene Software. Darüber hinaus umfassen die Subskriptionen Zugang zu Wissensdatenbanken und zu technischem Support. Für letzteren legen die einzelnen Subskriptionen auch das jeweilige Service-Level-Agreement fest.

Im Unterschied zu Ubuntu Advantage umfassen die in der folgenden Tabelle dargestellten Subskriptionen keine Verwaltungs-Werkzeuge, wie z.B. das von Canonical angebotene Landscape. Diese können sowohl bei SUSE, als auch bei RedHat zusätzlich erworben werden.

Die folgende Tabelle bietet eine Übersicht über die gängigen Support-Subskriptionen für SLES und RHEL:

SLES StandardSLES PriorityRHEL StandardRHEL Premium
Subskription für1-2 Sockets oder 1-2 VMs1-2 Sockets oder 1-2 VMs2 Sockets, 1 physischer Server oder 2 VMs2 Sockets, 1 physischer Server oder 2 VMs
Software Upgrades & UpdatesJaJaJaJa
Anzahl Supportanfragenunbegrenztunbegrenztunbegrenztunbegrenzt
ZugangChat, Telefon und E-MailChat, Telefon und E-MailWeb und TelefonWeb und Telefon
Verfügbarkeit12x524x78x524x7
Reaktionszeiten
Stufe 12 Std.1 Std.1 Geschäfts-Std.1 Std.
Stufe 24 Std.2 Std.4 Geschäfts-Std.2 Std.
Stufe 31 Werktag4 Std.1 Werktag4 Std.
Stufe 41 Werktag1 Werktag2 Werktage8 Std. initial / 2 Werktage ongoing
Listenpreis pro Jahr670 EUR1.250 EUR700 EUR1.139 EUR

Die in der Tabelle enthaltenen Informationen beziehen sich auf die bei Veröffentlichung dieses Artikels aktuellen Angaben der Distributionen.

Die dargestellten Subskriptionen gelten für je einen physischen Server mit 1-2 CPU Sockets oder 2 VMs. Besitzt man einen physischen Server mit mehr als 2 CPU-Sockets muss eine Subskription mehrfach erworben werden, um diesen Server abzudecken. Besitzt ein Server bspw. 4 CPU-Sockets, muss die Subskription für diesen Server zweimal erworben werden. Möchte man die benötigte Anzahl der Subskriptionen für virtuelle Maschinen bestimmen, so lautet die Formel Anzahl VMs / 2 = Anzahl benötigter Subskriptionen.

Bei den Subskriptionen für virtuelle Maschinen spielt es dabei keine Rolle, ob diese mit Hilfe von VMware, Microsoft Hyper-V, XEN oder KVM betrieben werden.

Ab einer bestimmten Menge VMs ist es kostengünstiger statt Subskriptionen für einzelne VMs solche einzusetzen, welche das gesamte virtuelle Datacenter abdecken:

SUSE für hochdichte VirtualisierungsumgebungenRed Hat Enterprise Linux for Virtual Datacenters
StandardPriorityStandardPremium
Gültig für1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen1-2 Sockets mit unbegrenzter Anzahl virtueller Maschinen
Listenpreis für 1 Jahr1.330 EUR2.490 EUR2.192 EUR3.507 EUR

Die in der obigen Tabelle dargestellten Subskriptionen gelten jeweils für einen physischen Host, auf welchem virtuelle Maschinen ausgeführt werden. Zum Beispiel müssen für einen VMware vSphere-Cluster bestehend aus drei physischen Hosts mit je 1-2 CPU Sockets dann drei der entsprechenden Subskriptionen erworben werden. Auch hier gilt wieder, besitzt ein Host mehr als 2 CPU-Sockets, muss die jeweilige Subskription entsprechend mehrmals für diesen Host gekauft werden, bis die Gesamtzahl der CPU-Sockets pro Host abgedeckt ist.

Der Vorteil dieses Subskriptions-Modells liegt darin, dass hiermit beliebig viele VMs in einem virtuellen Datacenter betrieben werden können. Wird das virtuelle Datacenter jedoch um einen physischen Host erweitert, muss für diesen ebenfalls eine Subskription erworben werden, obwohl weiterhin die gleiche Anzahl VMs darauf ausgeführt wird. Je nach Kostenbetrachtung kann dies einen Nachteil darstellen.

Die folgenden Diagramme stellen den Break Even der jeweiligen Subskriptionen dar. Sie wurden für die Verwendung eines virtuellen Datacenters bestehend aus 3 Hosts mit jeweils 1-2 CPU Sockets berechnet.

Bei den in diesem Artikel verwendeten Preisen handelt es sich um Listenpreise. Beim Kauf von Subskriptionen über einen Fachhändler können je nach Umfang der Bestellung meist noch Rabatte gewährt werden.

Neben den hier betrachteten Subskriptionen existieren noch weitere für die Bereiche Forschung und Lehre sowie zur Erweiterung des Leistungsumfangs. Weitere Informationen dazu finden sich über die Links am Ende dieses Artikels.

Die in diesem Artikel enthaltenen Informationen wurden im Rahmen einer Linux-Evaluierung im Hochschulrechenzentrum der Uni Bielefeld erhoben.

Links

Überwachung eines Bienenbrutschranks mit Raspi-SHT21 v1.5.0

Vor ein paar Wochen erreichte mich eine Nachricht aus der Schweiz mit einer Frage zum Raspi-SHT21. Mario interessierte sich für das Projekt, um damit die Temperatur und Luftfeuchtigkeit in einem Bienenbrutschrank zu überwachen und die Messwerte für die Heizungssteuerung zu verwenden.

Neben den bereits bestehenden Funktionen wünschte sich Mario zusätzlich zur Anzeige der aktuellen Temperatur und Luftfeuchtigkeit noch die Anzeige der Minimal- und Maximal-Werte mit Zeitstempel der Messung. Da mir die Idee gefallen hat, war ich gerne bereit, ihm diese Funktionen zur Verfügung zu stellen. Die neuen Funktionen sind in die Version 1.5.0 eingeflossen, welche auf GitHub zum Download bereit steht.

Mario hat inzwischen einen ersten Prototyp fertiggestellt. Eine Beschreibung seines Projekts findet ihr auf seiner Webseite im Artikel „Brutschrank InkuPI“.

Viel Spaß beim Lesen.

Die Verwendung von „date“ in der crontab

Bei der Verwendung des Kommandos date +%Y%m%dT%H%M%S in der crontab meines Benutzers erlebte ich heute eine Überraschung. Das Kommando wurde nicht wie erwartet abgearbeitet.

Das Problem ließ sich jedoch schnell und einfach lösen. Die %-Zeichen der date-Formatierungsangaben müssen mit einem Backslash escaped werden. Ein korrekter Aufruf sieht bspw. wie folgt aus:


# m h dom mon dow command
*/10 * * * * /bin/echo `/bin/date +\%Y-\%m-\%dT\%H:\%M:\%S` >> /home/bob/check.log

Erster bekannter Missbrauch eines Let’s Encrypt Zertifikats

Dennis Schirrmacher berichtet in seinem heise-Artikel „Erste Malvertising-Kampagne mit Let’s-Encrypt-Zertifikat“ über die missbräuchliche Verwendung eines Let’s Encrypt Zertifikats.

Laut dem Artikel ist es Online-Gaunern gelungen, eine Subdomain für eine legitime Domain einzurichten und für diese ein Let’s Encrypt Zertifikat zu beantragen. Mit Hilfe der legitimen Domain und des vertrauenswürdigen Zertifikats wird Besuchern der Webseite Schadcode untergeschoben. Im konkreten Fall wird ein Online-Banking-Trojaner auf den Computern der Opfer installiert.

Die missbräuchliche Nutzung ist kein spezielles Problem von Let’s Encrypt. Es handelt sich vielmehr um ein generelles Designproblem der öffentlichen TLS/SSL-Infrastruktur, welches ich bereits in der Einleitung von „Certificate Pinning mit NGINX“ beschrieben habe.

Let’s Encrypt versucht den Missbrauch durch den Einsatz kurzlebiger Zertifikate einzuschränken. Dieser Versuch läuft meiner Ansicht nach jedoch weitgehend ins Leere. Denn auch Online-Gauner können die Erneuerung der ergaunerten Zertifikate mit dem Let’s Encrypt Client automatisieren.

Einen deutlich effektiveren Schutz gegen die genannte Art von Missbrauch bieten Verfahren wie „Public Key Pinning Extension for HTTP“[1. RFC 7469 – Public Key Pinning Extension for HTTP] [2. HTTP Public Key Pinning – Wikipedia (de)] und „HTTP Strict Transport Security (HSTS)“[3. RFC 6796 – HTTP Strict Transport Security (HSTS)] [4. HTTP Strict Transport Security – Wikipedia (de)]. Speziell mit Hilfe des Certificate Pinning kann ein Browser erkennen, ob ein TLS/SSL-Zertifikat zur besuchten Domain gehört oder nicht. Nähere Informationen dazu und wie das Certificate Pinning für den Webserver NGINX konfiguriert werden kann, finden sich im Artikel „Certificate Pinning mit NGINX“. Viel Spaß beim Lesen.

Pinning-Test im Firefox bei lokaler Root-CA erzwingen

In Certificate Pinning mit NGINX habe ich das „Public Key Pinning for HTTP“[1. RFC 7469] und dessen Einrichtung mit dem Webserver NGINX[2. Ubuntuusers.de-Wiki-Artikel zu NGINX] beschrieben. Im vorliegenden Artikel beschreibe ich, wie man den Pinning-Test im Firefox auch bei Installation einer lokalen Root-CA aktiviert.

Schmidt schreibt in seinem Artikel[3. Schmidt, Jürgen: Festgenagelte Zertifikate: TLS wird sicherer durch Certificate Pinning, in: c’t magazin für computer technik, Nr. 23, 17.10.2015, Seite 120-121], dass Firefox in der Standardeinstellung sämtliche Pinning-Tests deaktiviert, wenn nachträglich ein Root-CA-Zertifikat auf dem System installiert wurde. Um die Pinning-Tests auch in diesem Fall zu erzwingen ist der unten genannte Parameter auf der Seite „about:config“ auf den Wert „2“ zu setzen.

security.cert_pinning.enforcement_level

Dieser Parameter kann die folgenden Werte annehmen:

  • 0 -> Schaltet die Pin-Prüfung komplett ab.
  • 1 -> Standardwert; Führt Pin-Prüfung durch, solange keine lokale Root-CA im Spiel ist.
  • 2 -> Strict; Erzwingt die Pin-Prüfung in jedem Fall.

Update vom 08.12.2015
Wie ich bei meinen Tests am vergangenen Wochenende herausgefunden habe, muss noch ein weiterer Parameter in der Firefox-Konfiguration angepasst werden, um das Public-Key-Pinning im Firefox bei Existenz eines Root CA Zertifikats zu aktivieren.

security.cert_pinning.process_headers_from_non_builtin_roots;true

Wir oben genannter Parameter auf „true“ gesetzt, führt der Firefox den Pinning Test auch durch, wenn zusätzliche Root-Zertifikate auf dem System installiert wurden.

Einen ausführlichen Bericht zum Thema findet ihr auch in „Certificate_Pinning_mit_NGINX (PDF)„.

Biblatex mit Tex Live und Kile unter Ubuntu nutzen

BibLaTex[1. CTAN: biblatex – Bibliographies in LaTeX using BibTeX for sorting only (en)] ist eine Neuimplementierung des bekannten BibTeX[2. Wikipedia – BibTeX (de)]. Da die Nutzung mit Kile[3. Kile im Ubuntuusers Wiki (de)] unter Ubuntu mich heute fast wahnsinnig gemacht hat, möchte ich hier kurz dokumentieren, mit welchen Einstellungen ich meine LaTeX-Umgebung einsatzbereit gemacht habe.

Systemumgebung

Ich setze aktuell folgende Ubuntuversion mit den angegebenen Paketen ein:

:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:        14.04
Codename:       trusty
:~$ dpkg -l texlive-full biber
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                Version        Architektur    Beschreibung
+++-===================-==============-==============-===========================================
ii  biber               1.8-1          all            Much-augmented BibTeX replacement for BibLa
ii  texlive-full        2013.20140215- all            TeX Live: metapackage pulling in all compon
ii  kile                4:2.1.3-2ubunt amd64          KDE Integrated LaTeX Environment
:~$

Kile Einstellungen

Bei der Erstellung eines Dokuments hagelte es jedoch unzählige Fehlermeldungen. Nach langer Recherche im Internet bin ich auf die folgenden Einstellungen in Kile gestoßen:

Kile Einstellungen BibTeX (falsch)

Kile Einstellungen BibTeX (falsch)

Diese Einstellungen mussten auf die Verwendung von biber konfiguriert werden:

Kile Einstellungen BibTeX (richtig)

Kile Einstellungen BibTeX (richtig)

Zum Test habe ich folgendes Minimalbeispiel verwendet:

\documentclass[a4paper,12pt]{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[english,ngerman]{babel}
\usepackage[babel]{csquotes}
% Bibliographie
\usepackage[style=numeric,backend=biber]{biblatex}
\addbibresource{Quellen.bib}
%\usepackage[german]{varioref}
\usepackage{url}
\usepackage{hyperref}

\begin{document}
Lorem ipsum \dots
\cite[][]{key}
\printbibliography[title={Quellen:},heading=bibintoc]
\end{document}

Um das fertige Dokument zu erzeugen, wurden folgende Arbeitsschritte ausgeführt:

latex document_name.tex
biber document_name
latex document_name.tex
latex document_name.tex

Was lange währt, wird endlich gut. Nun kann ich wieder Dokumente mit ordentlichen Quellenangaben erstellen.