WordPress – Avatar in Beitragsüberschrift anzeigen

Leider bietet WordPress in der Basisversion keine Option, einen Avatar des Autors in den Metainformationen unterhalb des Beitragstitels anzuzeigen. Diese Möglichkeit kann man durch die Erweiterung eines Child Themes mit dem nachfolgend beschriebenen Verfahren nachrüsten. Die Methode funktioniert auch direkt im Standard-Theme, bei einem Update des Themes gehen allerdings unsere Änderungen verloren.

Für die folgenden Ausführungen verwenden wir das Theme Twenty Fourteen unter WordPress Version 4.2.4.

Child Theme erstellen

Als Vorbereitung legen wir – falls noch nicht vorhanden – ein Child Theme Twenty Fourteen Child für das Standard-Theme / Parent Theme Twenty Fourteen an. Der Child Theme-Ordner heißt twentyfourteen-child und beinhaltet die beiden Dateien functions.php und style.css. Wir können hierbei z. B. nach der Anleitung WordPress – Child Theme erstellen vorgehen.

Avatar integrieren

Für die Darstellung der Metainformationen über Datum und Autor eines Beitrages im Standard-Theme Twenty Fourteen ist die Funktion twentyfourteen_posted_on in der Datei inc/template-tags.php verantwortlich. Die Abfrage if ( ! function_exists( ‚twentyfourteen_posted_on‘ ) ) : macht die Funktion „pluggable“, d. h. wir können sie mit einer eigenen gleichnamigen Funktion überschreiben. Hierbei machen wir uns zunutze, dass WordPress die Funktionen des Child Themes vor denen des Parent Themes lädt.

Wir kopieren zunächst die Funktionsdefinition von twentyfourteen_posted_on inkl. der if-Abfrage aus der Datei inc/template-tags.php im Parent Theme Twenty Fourteen an das Ende der Datei functions.php im Child Theme Twenty Fourteen Child. inc/template-tags.php finden wir im Administrationsbereich unter DesignEditor nach Auswahl von Twenty Fourteen als zu bearbeitendem Theme. Danach fügen wir vor der Ausgabeanweisung printf … die Zeile echo get_avatar(get_the_author_meta(‚ID‘), 32); ein. Der Aufruf von get_avatar liefert ein Bild des Autoren-Avatars mit einer Höhe und Breite von 32 Pixeln.

Unsere modifizierte Version von functions.php sollte schließlich wie folgt aussehen:

...
if (!function_exists('twentyfourteen_posted_on')):
function twentyfourteen_posted_on()
{
  if (is_sticky() && is_home() && !is_paged())
  {
    echo '<span class="featured-post">' . __('Sticky', 'twentyfourteen') . '</span>';
  }
  echo get_avatar(get_the_author_meta('ID'), 32);
  printf('<span class="entry-date"><a href="%1$s" rel="bookmark"><time class="entry-date" datetime="%2$s">%3$s</time></a></span><span class="byline"><span class="author vcard"><a class="url fn n" href="%4$s" rel="author">%5$s</a></span></span>',
    esc_url(get_permalink()),
    esc_attr(get_the_date('c')),
    esc_html(get_the_date()),
    esc_url(get_author_posts_url(get_the_author_meta('ID'))),
    get_the_author());
}
endif;

Avataranzeige anpassen

Die Anzeige des Avatars können wir noch mit zusätzlichen Einträgen in der Datei style.css im Child Theme individuell anpassen. Mit den nachfolgenden Formatanweisungen stellen wir beispielsweise den Autoren-Avatar rund dar und legen einen Abstand von 80% der Schriftgröße zu den übrigen Metainformationen fest:

...
div.entry-meta img.avatar {
        border-radius: 50%;
        margin-right: 0.8em;
}

Sollen die Kommentar-Avatare ebenfalls rund sein, ergänzen wir noch:

...
div.comment-author img.avatar {
        border-radius: 50%;
}

Falls wir die Avatar-Anzeige ausschalten möchten, fügen wir eine Zeile ein, in der wir der Eigenschaft display den Wert none zuweisen:

...
div.entry-meta img.avatar {
        border-radius: 50%;
        margin-right: 0.8em;
        display: none;
}

WordPress – Child Theme erstellen

Aufgrund der offenen und gut dokumentierten Architektur von WordPress sind die Designvorlagen („Themes“) weitestgehend an die eigenen Vorstellungen anpassbar. Um das Layout eines Blogs zu ändern oder neue Funktionen hinzuzufügen, kann man z. B. ein Theme direkt modifizieren oder geeignete Plugins installieren. In vielen Fällen ist jedoch die Nutzung eines sogenannten „Child Themes“ sinnvoller, die auch von den WordPress-Entwicklern im WordPress Codex über Child Themes empfohlen wird.

Ein Child Theme „erbt“ die Funktionen und Eigenschaften eines sogenannten „Parent Themes“, so dass wir keine komplett neue Designvorlage erstellen müssen. Darüber hinaus bleiben unsere Modifikationen und Erweiterungen auch bei einem Update des Parent Themes erhalten. Diesen Vorteilen steht ein im Vergleich zur direkten Änderung eines Themes höherer Aufwand gegenüber.

Wir werden im Folgenden exemplarisch ein Child Theme für das Theme Twenty Fourteen in WordPress 4.2.4 erstellen.

Verzeichnis und Dateien anlegen

Die einfachste Child Theme-Struktur besteht aus einem Child Theme-Verzeichnis mit den beiden Dateien style.css und functions.php. In der Stylesheet-Datei style.css werden die (CSS)-Layout-Vorgaben hinterlegt. Die Datei functions.php beinhaltet die (PHP)-Funktionen. Entsprechende Dateien existieren – neben weiteren – auch in den (Parent) Theme-Verzeichnissen, die bei der WordPress-Installation angelegt werden.

Das Child Theme-Verzeichnis wird wie die anderen Theme-Verzeichnisse in einem Unterordner des WordPress-Themes-Verzeichnisses /wp-content/themes gespeichert. In unserem Fall werden wir mit dem Theme Twenty Fourteen als Ausgangsbasis schließlich folgende Verzeichnisstruktur erhalten:

/wp-content
  ...
  /themes
    ...
    /twentyfourteen
    /twentyfourteen-child
      functions.php
      style.css
    ...
  ...

Direkter Serverzugang / Fernzugriff

Haben wir direkten Zugriff auf den WordPress-Server oder die Möglichkeit, uns per Telnet bzw. SSH einzuwählen, können wir die Child Theme-Installation mit Root-Rechten in einem Terminal-Fenster durchführen. Hierzu legen wir zuerst im WordPress-Themes-Verzeichnis einen neuen Ordner twentyfourteen-child mit den beiden leeren Dateien style.css und functions.php an. Bei einer typischen WordPress-Installation unter Ubuntu mit dem Themes-Verzeichnis /usr/share/wordpress/wp-content/themes verwenden wir die Anweisungen:

root@server:~# mkdir /usr/share/wordpress/wp-content/themes/twentyfourteen-child
root@server:~# touch /usr/share/wordpress/wp-content/themes/twentyfourteen-child/style.css
root@server:~# touch /usr/share/wordpress/wp-content/themes/twentyfourteen-child/functions.php

In die Datei style.css fügen wir folgende Zeilen ein, wobei die Einträge durch eigene Angaben zu ersetzen sind:

/*
 Theme Name:   Twenty Fourteen Child
 Theme URI:    ...
 Description:  ...
 Author:       ...
 Author URI:   ...
 Template:     twentyfourteen
 Version:      ...
 License:      ...
 License URI:  ...
 Tags:         ...
 Text Domain:  ...
*/

Am wichtigsten ist hierbei der Eintrag hinter Template:, der den Verzeichnisnamen des Parent Themes, in unserem Fall twentyfourteen, enthalten muss.

In die Datei functions.php schreiben wir folgenden PHP-Code:

<?php
add_action('wp_enqueue_scripts', 'theme_enqueue_styles');
function theme_enqueue_styles()
{
  wp_enqueue_style('parent-style', get_template_directory_uri() . '/style.css' );
}
?>

Hiermit wird die Stylesheet-Datei style.css des Parent Themes geladen. Das Laden der Stylesheet-Datei des Child Themes geschieht normalerweise automatisch. Ein zusätzlicher Aufruf von wp_enqueue_style ist daher in der Regel nicht erforderlich.

FTP-Zugang

Ist nur ein eingeschränkter Server-Zugang per FTP möglich, legen wir zunächst lokal auf unserem Rechner mit einem (Text-)Editor die Dateien style.css und functions.php mit den oben beschriebenen Inhalten an. Danach verbinden wir uns mit einem FTP-Client wie FileZilla mit dem Server, erzeugen dort das Verzeichnis twentyfourteen-child und laden die beiden Dateien hoch.

Child Theme aktivieren

Zur Umstellung auf unser Child Theme klicken wir im Administrations-Bereich von WordPress unter Design – Themes auf den Aktivieren-Button des Themes Twenty Fourteen Child. Nach dieser Änderung kann es vorkommen, dass unser Menü nicht mehr (vollständig) angezeigt wird. Zur Behebung des Problems müssen wir in Design – Menüs bei Anordnung im Theme (bei neueren WordPress-Versionen Position im Theme) die Häkchen gemäß den Einstellungen im Parent Theme Twenty Fourteen erneut setzen und das Menü speichern.

Nun können wir unter Design – Editor das Layout unseres Child Themes ändern. Mit folgender Ergänzung in der Datei style.css vergrößern wir beispielsweise die Breite der Hauptbereichs mit dem Inhaltsbereich, der Navigation, usw. von 474 auf 640 Pixel:

...
.site-content .entry-header,
.site-content .entry-content,
.site-content .entry-summary,
.site-content .entry-meta,
.page-content {
        margin: 0 auto;
        /* max-width: 474px; */
        max-width: 640px;
}
.post-navigation,
.image-navigation {
        margin: 24px auto 48px;
        /* max-width: 474px; */
        max-width: 640px;
        padding: 0 10px;
}
.archive-header,
.page-header {
        margin: 24px auto;
        /* max-width: 474px; */
        max-width: 640px;
}
.contributor-info {
        margin: 0 auto;
        /* max-width: 474px; */
        max-width: 640px;
}
.comments-area {
        margin: 48px auto;
        /* max-width: 474px; */
        max-width: 640px;
        padding: 0 10px;
}
.site-main .mu_register,
.widecolumn > h2,
.widecolumn > form {
        margin: 0 auto 48px;
        /* max-width: 474px; */
        max-width: 640px;
        padding: 0 30px;
}

WordPress – Menüeinträge ohne Inhalt

Ist ein WordPress-Blog mit einer mehrstufigen Menüstruktur aufgebaut, so sind oft Menüeinträge ohne speziellen Inhalt wünschenswert, die ausschließlich zu Gliederungszwecken eingesetzt werden. Leider ist ein solcher Eintragstyp in WordPress standardmäßig nicht vorhanden.

Eine einfache und elegante Lösung, um Menüpunkte zu erstellen, die keine Seiten, Links, Kategorien o. ä. enthalten, wird in dem Beitrag How to Add Titles in WordPress Menu Without Linking to a Page vorgestellt. Die dort beschriebene Vorgehensweise wird nachfolgend kurz zusammengefasst.

Wir legen zunächst im Administrations-Bereich unter Design – Menüs – Links einen Link mit einem beliebigen nichtleeren Text im Feld URL wie beispielsweise # und dem gewünschten Menüeintrag im Feld Linktext an und fügen ihn zum Menü hinzu. Danach löschen wir in der Menüstruktur in den Eigenschaften des individuellen Links den Eintrag im Feld URL. Weitere Änderungen sind nicht erforderlich.

Wie ein Blick in den HTML-Quelltext einer Seite mit einem derart erzeugten Menü zeigt, generiert WordPress bei einem leeren URL-Feld in einem Link-Eintrag einen sogenannten „Platzhalter“-Hyperlink ohne href-Attribut in der Form <a>Menüeintrag</a>. Dieser stellt gemäß der HTML-Sprachreferenz des W3C („World Wide Web Consortium“) zulässigen HTML-Code dar.

Die beschriebene Vorgehensweise funktioniert ab WordPress Version 4.2.4. Ältere Versionen habe ich (noch) nicht getestet.

Ubuntu Server 14.04 – DNS-Server Bind im lokalen Netzwerk

Um Rechner in einem Netzwerk mit Domainnamen wie client.test.local statt IP-Adressen wie 192.168.0.101 ansprechen zu können, ist eine Zuordnung von Namen und Adressen erforderlich. Diese Zuordnung kann im einfachsten Fall durch Einträge in einer Datei, unter Linux z. B. /etc/hosts, erfolgen. Nachteilig ist bei diesem Verfahren, dass die Datei auf jedem Client-Rechner vorhanden sein muss und bei Änderungen alle Dateien zu aktualisieren sind.

Sinnvoll ist in Netzwerken mit mehr als einer Handvoll Rechnern der Einsatz eines DNS(„Domain Name System“)-Servers zur Namensauflösung. Dieser wird zentral eingerichtet und administriert.

Nachfolgend werden wir den DNS-Server / Nameserver Bind installieren und konfigurieren. Wir setzen Bind dabei nur für die Auflösung von Domainnamen aus unserem lokalen Netzwerk ein. Ein externer Zugriff aus dem Internet wird nicht eingerichtet. Eine ausführliche Dokumentation zu Bind ist das BIND 9 Administrator Reference Manual.

Voraussetzungen

Wir haben unseren Server z. B. gemäß der Anleitung zur Basisinstallation für Ubuntu Server 14.04 im lokalen Netzwerk 192.168.0.0/24 installiert und durch Updates / Upgrades auf den neuesten Stand gebracht. Der Server hat die IPv4-Adresse 192.168.0.1, der Router für die Internetverbindung die Adresse 192.168.0.254. Unsere Rechner haben feste IP-Adressen, das DHCP („Dynamic Host Configuration Protocol“) ist nicht aktiviert. Die Befehle führen wir mit Root-Rechten aus, z. B. nach Öffnen einer Rootshell mit sudo -i.

DNS-Server Bind installieren

Wir installieren den DNS-Server Bind mit folgender Anweisung auf unserem Server:

root@server:~# apt install bind9

Erreichbarkeit auf IPv4 beschränken

In der Standardkonfiguration löst Bind Domainnamen für die beiden Protokolle IPv4 und IPv6 auf. Falls wir ins unserem lokalen Netzwerk nur IPv4 verwenden und kein IPv6 benötigen, sollten wir in der Datei /etc/default/bind9 die Startoptionen ändern:

...
#OPTIONS="-u bind"
OPTIONS="-4 -u bind"
...

Dies kann die Arbeit von Bind deutlich beschleunigen.

Zusätzlich passen wir den Eintrag listen-on-v6 in der Optionsdatei /etc/bind/named.conf.options wie folgt an:

options {
        ...
        //listen-on-v6 { any; };
        listen-on-v6 { none; };
        ...
};

Optionsdatei anpassen

In der Optionsdatei /etc/bind/named.conf.options fügen wir im options-Block folgende Optionen hinzu:

options {
        ...
        listen-on { 192.168.0.1; };
        forwarders { 8.8.8.8; 8.8.4.4; };
        forward only;
};

Die erste Option beschränkt die Namensauflösung auf Anfragen an die Adresse 192.168.0.1 und somit auf Clients unseres lokalen Netzwerks 192.168.0.0/24. Das ist sinnvoll, falls der Server beispielsweise gleichzeitig als Gateway arbeitet und über mehrere Netzwerkkarten/-interfaces verfügt.

Mit der zweiten und dritten Option werden Namen, die nicht von Bind aufgelöst werden können, d. h. in der Regel Anfragen, die nicht in das lokale Netz gehen, direkt an die DNS-Server 8.8.8.8 und 8.8.4.4 von Google weitergeleitet.

Da unser Server nicht aus dem Internet erreichbar ist, ist eine Einschränkung des Client-Zugriffs z. B. mit allow-query { 192.168.0.0/24; }; nicht notwendig. Die Weitergabe von Zoneninformationen an andere DNS-Server müssen wir ebenfalls nicht beschränken oder mit der Option allow-transfer { none; }; unterbinden.

Zonendateien anlegen

Der Hauptteil der Konfiguration von Bind wird in den Zonendateien vorgenommen. Für unser lokales Netzwerk benötigen wir zwei Zonendateien, die wir im Verzeichnis /etc/bind anlegen. In der Datei db.test.local konfigurieren wir die „Forward Lookup“-Zone zur Auflösung von Rechnernamen in IP-Adressen, in der Datei db.0.168.192 die entsprechende „Reverse Lookup“-Zone für die Auflösung von IP-Adressen in Rechnernamen.

„Forward Lookup“-Zonendatei

Zunächst erzeugen wir die „Forward Lookup“-Zonendatei db.test.local mit den passenden Zugriffsrechten:

root@server:~# touch /etc/bind/db.test.local
root@server:~# chown root:bind /etc/bind/db.test.local

Für den vereinfachten Fall eines Netzwerks mit einem Server server und nur einem Client client reichen folgende Einträge in db.test.local aus:

$TTL   604800
@      SOA server.test.local. root.test.local. (
           2015082401 ; Serial
           604800     ; Refresh
           86400      ; Retry
           2419200    ; Expire
           604800 )   ; Minimum
@      NS  server.test.local.
@      A   192.168.0.1
server A   192.168.0.1
client A   192.168.0.101

Die Zonendatei besteht im wesentlichen aus sogenannten „Resource Records“, die zusammen die DNS-Zone, in unsererem Fall die Domain test.local, komplett definieren. Die Reihenfolge der Resource Record-Angaben spielt dabei keine Rolle. Eine detaillierte Referenz findet sich in RFC 1035: Domain Names – Implementation and Specification der Internet Engineering Task Force IETF.

Mit der $TTL(„Time to Live“)-Anweisung am Anfang legen wir global fest, wie lange die Resource Records gültig sind. In unserem Beispiel verbleiben die Informationen 604800 Sekunden = 1 Woche im Cache des anfragenden Clients oder eines anderen anfragenden DNS-Servers. Dieser Wert kann innerhalb eines Resource Records individuell überschrieben werden.

Die Resource Records haben allgemein das Format Name TTL Klasse Typ Daten. Den optionalen Eintrag TTL haben wir weggelassen, so dass für jeden Resource Record die globale Einstellung 604800 Sekunden gilt. Die optionale Klasse ist bei allen Resource Records der Default-Wert IN und muss daher ebenfalls nicht angegeben werden.

Der erste Resource Record vom Typ SOA („Start of a Zone of Authority“) muss genau einmal in der Zonendatei vorkommen und enthält die wesentlichen Informationen über die Zone. Das @-Zeichen am Anfang dient als Platzhalter für den Zonennamen, bei uns also test.local. Die Daten bestehen aus dem Nameserver server.test.local, der E-Mail-Adresse des Administrators root@test.ibf.local, bei der das @-Zeichen durch einen Punkt ersetzt ist, der Seriennummer und verschiedenen eingeklammerten Zeitangaben. Die zusätzlichen Punkte am Ende des Nameservers und der E-Mail-Adresse kennzeichnen die Angabe eines vollqualifizierten Domainnamens FQDN („Fully Qualified Domain Name“). Eine Besonderheit ist, dass der SOA-Record auf mehrere Zeilen verteilt ist und wir daher Klammern verwenden müssen. Kommentare wie z. B. Serial werden mit einem Semikolon abgetrennt.

Falls wir neben unserem (primären) DNS-Server einen oder mehrere sekundäre DNS-Server einsetzen, müssen wir die Seriennummer Serial bei jeder Änderung der Zonendatei erhöhen. Hiermit signalisieren wir sekundären DNS-Servern, dass sie einen Zonentransfer durchführen sollen, bei dem die aktuellen Zonendaten mit dem primären DNS-Server abgeglichen werden. Ein gebräuchliches Schema für die Seriennummer ist yyyymmddvv, wobei yyyymmdd für das Datum im Format Jahr yyyy, Monat mm und Tag dd und vv für die unterschiedlichen Dateiversionen eines Tages stehen.

Die Werte für Refresh, Retry, Expire und Minimum entsprechen wie der Eintrag $TTL den Vorgaben aus der Beispieldatei /etc/bind/db.local und werden in RFC 1035 genauer beschrieben.

Der zweite Resource Record vom Typ NS („Authoritative Name Server“) muss mindestens einmal in der Zonendatei enthalten sein. Hier hinterlegen wir den FQDN des Nameservers server.test.local unserer Zone test.local, wie beim SOA-Record mit einem zusätzlichen Punkt am Ende.

Die weiteren Resource Records sind jeweils vom Typ A („Host Address“) und können in beliebiger Anzahl vorkommen. Mit ihnen ordnen wir dem Zonennamen test.local (Platzhalter @) und den Rechnern server und client in unserem lokalen Netzwerk die IP-Adressen 192.168.0.1, 192.168.0.1 und 192.168.0.101 zu. Für die Einträge server und client müssen wir nicht die FQDN benutzen, da Namen ohne Punkt am Ende automatisch durch den Zonennamen ergänzt werden.

Falls es in unserem lokalen Netz einen Mail-Server mail.test.local mit der IP-Adresse 192.168.0.2 gibt, ergänzen wir die „Forward Lookup“-Datei noch um 2 Einträge:

...
@      MX  10 mail.test.local.
mail   A   192.168.0.2
...

Der Resource Record vom Typ MX („Mail Exchange“) enthält einen ganzzahligen Wert für die Priorität des Mail-Servers, hier 10, und seinen Domainnamen mail.test.local. Beim Einsatz mehrerer Mail-Server werden diese in der Reihenfolge steigender Prioritätswerte genutzt. Da der Domainname des MX-Records auf einen A-Record verweisen muss, definieren wir diesen ensprechend in der nächsten Zeile. Der Mail-Server kann natürlich auch identisch mit unserem Server sein. In diesem Fall ersetzen wir den Eintrag 192.168.0.2 durch 192.168.0.1. Unser Server wäre dann unter server.test.local und mail.test.local ansprechbar.

„Reverse Lookup“-Zonendatei

Als zweite Datei legen wir die „Reverse Lookup“-Zonendatei db.0.168.192 mit den entsprechenden Berechtigungen an:

root@server:~# touch /etc/bind/db.0.168.192
root@server:~# chown root:bind /etc/bind/db.0.168.192

Die „Reverse Lookup“-Zonendatei ist ähnlich aufgebaut wie die „Forward Lookup“-Zonendatei db.test.local. Für unser Beispiel mit Mail-Server sieht sie folgendermaßen aus:

$TTL 604800
@   SOA server.test.local. root.test.local. (
        2015082401 ; Serial
        604800     ; Refresh
        86400      ; Retry
        2419200    ; Expire
        604800 )   ; Minimum
@   NS  server.test.local.
1   PTR server.test.local.
2   PTR mail.test.local.
101 PTR client.test.local.

Statt der A-Records für die Auflösung von Namen in IP-Adressen werden Resource Records vom Typ PTR („Pointer“) für die umgekehrte Zuordnung von IP-Adressen zu vollqualifizierten Domainnamen verwendet. Die IP-Adressen notieren wir hierbei nicht vollständig, sondern nur ihren Hostanteil (d. h. den letzten Block) ohne den Netzanteil (die ersten 3 Blöcke) 192.168.0.. MX-Records werden in der „Reverse Lookup“-Zonendatei nicht angegeben.

Konfigurationsdatei ergänzen

Die Zuordnung der Informationen aus den beiden Zonendateien erfolgt in der Konfigurationsdatei /etc/bind/named.conf.local, die bereits während der Installation von Bind angelegt wird. Jede Zonendatei wird dabei mit Hilfe einer zone-Definition eingebunden, die unterschiedliche Optionen beinhalten kann:

...
zone "test.local" {
  type master;
  file "/etc/bind/db.test.local";
};
zone "0.168.192.in-addr.arpa" {
  type master;
  file "/etc/bind/db.0.168.192";
};

Mit der Option type legen wir unseren Server als primären DNS-Server (master) fest. Mit file ordnen wir der Zone eine Zonendatei zu. Die in der zweiten Zonenendefinition verwendete in-addr.arpa-Domäne ist eine spezielle Domäne für „Reverse Lookups“ von IP-Adressen. Für den Netzanteil einer Adresse gibt es hierbei pro Block eine Subdomain-Ebene, die in umgekehrter Reihenfolge notiert werden. Für den Adressbereich 192.168.0.0192.168.0.255 unseres IPv4-Netzwerks ist die Subdomain somit 0.168.192.in-addr.arpa. Ausführlichere Informationen enthält z. B. RFC 1035.

Bind testen

Vor dem Neustart von Bind überprüfen wir die Zonendateien mit dem Programm named-checkzone, das zusammen mit Bind installiert wird, auf Syntax- und Integritätsfehler:

root@server:~# named-checkzone test.local /etc/bind/db.test.local
root@server:~# named-checkzone 0.168.192.in-addr.arpa. /etc/bind/db.0.168.192

Nachdem eventuelle Fehler behoben sind, starten wir Bind neu:

root@server:~# service bind9 restart

Wie den Clients müssen wir auch unserem Server noch den neuen DNS-Server mitteilen. Hierzu ändern wir den dns-nameservers-Eintrag in der Datei /etc/network/interfaces:

...
#dns-nameservers 8.8.8.8 8.8.4.4
dns-nameservers 192.168.0.1 8.8.8.8 8.8.4.4
...

Damit die geänderten Einstellungen wirksam werden, starten wir den Netzwerk-Service neu:

root@server:~# /etc/init.d/networking restart

Nun sollten wir unsere Domain mit ping erreichen können:

root@server:~# ping -c 4 test.local

Falls dies nicht funktioniert, müssen wir die Netzwerkschnittstelle, hier eth0, zunächst stoppen und danach neu starten:

root@server:~# ifdown eth0 && ifup eth0

eth0 ist bei Bedarf durch den entsprechenden Eintrag für die Netzwerkschnittstelle in /etc/network/interfaces zu ersetzen.

Abschließend testen wir unsere Konfiguration mit dem Programm dig („Domain Information Groper“), das diverse Informationen von DNS-Servern abfragt:

root@server:~# dig test.local ANY
root@server:~# dig -x 192.168.0.1

Mit dem ersten Aufruf werden alle (Abfrageoption ANY) Resource Records der „Forward Lookup“-Zone ausgegeben. Der zweite Aufruf mit der Option -x liefert die Resource Records der „Reverse Lookup“-Zone.

Clients konfigurieren

Für die betriebssystemabhängige Client-Konfiguration werden in der Regel folgende Daten benötigt:

  • DHPC: deaktiviert
  • IPv4-Adresse: 192.168.0.xxx
  • Subnetzmaske 255.255.255.0
  • Gateway: 192.168.0.254
  • Nameserver: 192.168.0.1
  • Weitere Nameserver: 8.8.8.8, 8.8.4.4

Details finden sich in der Dokumentation des jeweiligen Betriebssystems.

Zum Testen nutzen wir ping, unter Linux beispielsweise mit dem Aufruf:

hans@client:~ ping -c 4 test.local

Unter Windows geben wir in der Eingabeaufforderung entsprechend ein:

C:\Windows\System32>ping test.local

Ubuntu Server 14.04 – Fernzugriff einrichten

Die Administration eines räumlich entfernten Servers, der z. B. in einem Serverraum oder bei einem Webhoster steht, erfolgt am effizientesten per Fernzugriff. Aus Sicherheitsgründen sollte man dabei nicht das ursprünglich hierfür vorgesehene Protokoll Telnet („Teletype Network“), sondern SSH („Secure Shell“) verwenden. SSH ermöglicht die Verschlüsselung der Kommunikation und eine Authentifizierung von Rechnern und Benutzern.

Unter Ubuntu ist das Programmpaket OpenSSH der Standard für SSH. Dessen Serverkomponente werden wir nachfolgend installieren und konfigurieren. Für höchstmögliche Sicherheit richten wir hierbei OpenSSH für ausschließliche Public Key-Authentifizierung ein.

Denjenigen, die mehr in die Tiefe gehen möchten, sei die Seite Specifications implemented by OpenSSH mit einer Zusammenstellung der umgesetzten Spezifikationen empfohlen. Die Erläuterung der einzelnen OpenSSH-Befehle mit den zugehörigen Parametern findet man auf der Seite Manual pages.

Voraussetzungen

Wir haben unseren Server z. B. gemäß der Anleitung zur Basisinstallation für Ubuntu Server 14.04 im lokalen Netzwerk 192.168.0.0/24 installiert und durch Updates / Upgrades auf den neuesten Stand gebracht. Der Server hat die IPv4-Adresse 192.168.0.1, den Rechnernamen server und gehört zur Domain test.local. Es existiert ein Benutzer theo, der Mitglied der Gruppe sudo ist und somit über Administratorrechte verfügt. Die Befehle führen wir mit Root-Rechten aus, z. B. nach Öffnen einer Rootshell mit sudo -i.

SSH-Server OpenSSH installieren

Die Installation des SSH-Servers OpenSSH auf unserem Server erfordert nur eine Anweisung:

root@server:~# apt install openssh-server

OpenSSH absichern

Mit den folgenden Änderungen / Ergänzungen in der Konfigurationsdatei /etc/ssh/sshd_config sichern wir OpenSSH zusätzlich ab:

...
#Port 22
Port 42022
...
#ListenAddress 0.0.0.0
ListenAddress 192.168.0.1
...
#PermitRootLogin without-password
PermitRootLogin no
...
AllowUsers theo

Die Änderung des Standard-Ports von 22 in 42022 bringt streng genommen keine zusätzliche Sicherheit („Security by Obscurity“), verringert aber die Anzahl der Login-Angriffe. Hier sollte ein Port stehen, der nicht für andere Dienste vorgesehen ist. Eine Liste mit Diensten und zugehörigen Standard-Ports ist z. B. in der Datei /etc/services hinterlegt.

Durch die zweite Änderung wird der Zugriff auf den Server auf das Netzwerkinterface / die IP-Adresse 192.168.0.1 eingeschränkt.

Mit der dritten Änderung verhindern wir das Einloggen als Benutzer root. Die Einwahl mit diesem Benutzerkonto ist nicht notwendig, da wir bei Bedarf mit sudo als root arbeiten können.

Mit dem zusätzlichen letzten Eintrag erlauben wir den Fernzugriff exklusiv nur dem Benutzer theo.

Wir belassen es zunächst bei einer Authentifizierung mit Benutzername und Passwort, da wir erst im folgenden Schritt auf das Authentifizierungsverfahren mit Public Key umstellen.

Damit die Änderungen wirksam werden, starten wir abschließend den OpenSSH-Dienst neu:

root@server:~# service ssh restart

SSH auf Public Key-Authentifizierung umstellen

Um die Einwahl über SSH weiter abzusichern, stellen wir das Authentifizierungsverfahren auf Public Key-Authentifizierung um. Zum Einloggen ist dann eine Datei mit einem privaten Schlüssel auf dem sich einwählenden Client-Rechner und eine Datei mit dem dazu passenden öffentlichen Schlüssel auf unserem Server erforderlich. Die entsprechenden Schlüssel können wir sowohl unter Linux als auch unter Windows erzeugen.

Den öffentlichen Schlüssel erwartet OpenSSH in der Datei authorized_keys im Unterordner .ssh des Heimat-Verzeichnisses. Diese Datei kann mehrere öffentliche Schlüssel für unterschiedliche Fernzugriffsnutzer enthalten.

Schlüssel unter Linux generieren

Auf einem Linux-Client erstellen wir mit Hilfe von ssh-keygen ein RSA(„Rivest, Shamir, Adleman“)-Schlüsselpaar mit einer Verschlüsselungstiefe von 4096 bit:

hans@client:~ ssh-keygen -b 4096 -t rsa

Wir übernehmen die Voreinstellung /home/hans/.ssh/id_rsa für den Dateinamen des privaten Schlüssels und sichern ihn nachfolgend mit einer Passphrase ab.

ssh-keygen erzeugt zusätzlich noch eine Datei /home/hans/.ssh/id_rsa.pub mit dem öffentlichen Schlüssel. Diese übertragen wir mit ssh-copy-id auf den Server:

hans@client:~ ssh-copy-id -p 42022 theo@server.test.local

Das Verzeichnis /home/theo/.ssh mit der Datei authorized_keys wird hierbei bei Bedarf neu angelegt.

Um die Korrektheit unserer Konfiguration zu überprüfen, wählen wir uns schließlich noch mit ssh ein:

hans@client:~ ssh -p 42022 theo@server.test.local

Nach Eingabe der Passphrase sollten wir Zugriff auf unseren Server haben.

Schlüssel unter Windows generieren

Als Vorbereitung erstellen wir – falls noch nicht vorhanden – auf dem Server im Heimat-Verzeichnis des Benutzers theo einen Ordner .ssh mit einer leeren Schlüsseldatei authorized_keys mit entsprechenden Zugriffsrechten:

root@server:~# mkdir /home/theo/.ssh
root@server:~# touch /home/theo/.ssh/authorized_keys
root@server:~# chown -R theo:theo /home/theo/.ssh
root@server:~# chmod 0700 /home/theo/.ssh
root@server:~# chmod 0600 /home/theo/.ssh/authorized_keys

Zur Generierung des Schlüsselpaares unter Windows eignet sich z. B. das Programm PuTTYgen. Nach dem Start von PuTTYgen erzeugen wir mit zufälligen Mausbewegungen SSH-2 RSA-Schlüssel (voreingestellt) mit einer Schlüssellänge von 4096 bit. Im darauffolgenden Fenster können wir den Kommentar rsa-key-„Datum“ in eine aussagekräftigere Beschreibung wie hans@client ändern. Zum Schutz unseres privaten Schlüssels vergeben wir noch eine Passphrase und speichern ihn z. B. in c:\users\hans\id_rsa.ppk ab. Da die von PuTTYgen erzeugte öffentlichen Schlüsseldatei nicht kompatibel zum OpenSSH-Format ist, kopieren wir den Text aus dem Feld unter Public key for pasting into OpenSSH authorized_keys file: in die Zwischenablage und fügen ihn in eine neue Datei, beispielsweise c:\users\hans\id_rsa.pub, ein.

Den öffentlichen Schlüssel können wir dann mit einem SCP(„Secure Copy“)-Client wie PSCP auf unseren Server übertragen. Befindet sich pscp.exe im Verzeichnis c:\users\hans, geben wir hierzu in der Windows-Eingabeaufforderung ein:

C:\Windows\System32>c:\users\hans\pscp -P 42022 c:\users\hans\id_rsa.pub theo@server.test.local:id_rsa.pub

Hierdurch wird die Schlüsseldatei im Heimat-Verzeichnis /home/theo/ auf dem Server gespeichert.

Abschließend fügen wir den Schlüssel noch an die Datei authorized_keys an und löschen ihn:

root@server:~# cat /home/theo/id_rsa.pub >> /home/theo/.ssh/authorized_keys
root@server:~# rm /home/theo/id_rsa.pub

Zum Test nutzen wir das Programm PuTTY, das wir ebenfalls in c:\users\hans installieren, in der Kommandozeilenversion:

C:\Windows\System32>c:\users\hans\putty -ssh -i c:\users\hans\id_rsa.ppk -P 42022 theo@server.test.local

Hierbei sollte bei korrekter Konfiguration nur noch die Abfrage der Passphrase erscheinen.

Ausschließliche Public Key-Authentifizierung aktivieren

Nach erfolgreichem Test schalten wir die Passwort-Authentifizierung in der Datei /etc/ssh/sshd_config ab:

...
#PasswordAuthentication yes
PasswordAuthentication no
...

Die Änderungen übernehmen wir mit einem Neustart des OpenSSH-Dienstes:

root@server:~# service ssh restart

Ab jetzt können sich nur noch Benutzer mit einem passenden Schlüssel einloggen.

Ubuntu Server 14.04 – Basisinstallation

Möchte man einen eigenen Web-, Mail- oder Datenbankserver betreiben, so eignet sich als Unterbau am besten Linux mit den passenden Softwarepaketen. Die Quellcodes der Programme sind in der Regel frei zugänglich und können, falls z. B. die Konfigurationsmöglichkeiten nicht ausreichen sollten, entsprechend angepasst werden.

Wir werden im Folgenden ein Basissystem der Servervariante der Linux-Distribution Ubuntu 14.04 LTS („Long Term Support“) installieren. Die LTS-Versionen von Ubuntu haben den Vorteil, dass die Versorgung mit Sicherheits-Updates über einen längeren Zeitraum von derzeit 5 Jahren sichergestellt ist. So können wir aufwendige Neuinstallationen unseres Servers beim Erscheinen aktuellerer Ubuntu-Versionen vermeiden.

Die Installationsanleitung ist knapp gehalten und beschränkt sich auf die wesentlichen Schritte. Eine detaillierte Beschreibung findet sich beispielsweise im Ubuntu Installation Guide.

Voraussetzungen

Wir haben ein IPv4-Netzwerk 192.168.0.0/24 mit dem IP-Adressbereich von 192.168.0.0 bis 192.168.0.255 und der Subnetzmaske 255.255.255.0 eingerichtet. Unsere Rechner haben feste IP-Adressen, das DHCP („Dynamic Host Configuration Protocol“) ist nicht aktiviert.

Der Router für die Internetverbindung hat die IP-Adresse 192.168.0.254. Wir verwenden keinen Proxy-Server.

Installationsmedium erstellen

Wir laden die ISO-Datei ubuntu-14.04.3-server-amd64.iso der 64-bit-Version von Ubuntu Server 14.04.3 LTS von der Ubuntu-Server-Download-Seite und brennen sie – unter Windows z. B. mit ImgBurn – auf eine Installations-CD/-DVD. Alternativ können wir einen USB-Stick als Installationsmedium nutzen. Hierzu eignet sich z. B. das Programm LinuxLive USB Creator.

Basissystem installieren

Wir booten unsere Server-Hardware vom Installationsmedium und wählen als Sprache Deutsch. Im folgenden Menü starten wir die Installation mit dem voreingestellten Ubuntu Server installieren. Während des Installationsvorgangs stellen wir zunächst die Sprachoptionen ein. Dann konfigurieren wir das Netzwerk und legen den ersten Benutzer an. Nachdem wir die Zeitzone festgelegt und die Festplatte partitioniert haben, beginnen wir mit der eigentlichen Softwareinstallation. Die einzelnen Schritte werden nachfolgend beschrieben.

Sprache einstellen

Bei der Sprachauswahl für die Installation und das Ubuntu-System wählen wir German – Deutsch. Die Warnung, dass die Übersetzung unvollständig ist, quittieren wir mit Ja. Beim Standort belassen wir es bei der Voreinstellung Deutschland. Die Frage nach der Erkennung des Tastaturmodells beantworten wir mit Nein. Als Herkunftsland für die Tastatur wählen wir den voreingestellten Wert Deutsch, als Tastaturbelegung ebenfalls Deutsch.

Netzwerk einrichten

Falls unser Server über mehrere Netzwerkkarten verfügt, wählen wir im Menü für die primäre Netzwerk-Schnittstelle die passende aus. Da unser Netzwerk keinen DHCP-Server hat, können wir die Meldung Die automatische Netzwerkonfiguration ist fehlgeschlagen mit Weiter ignorieren. Im nächsten Menü übernehmen wir das voreingestellte Netzwerk manuell einrichten. Als IP-Adresse geben wir 192.168.0.1 an, als Netzmaske 255.255.255.0. Für den Internetzugriff verwenden wir unser Gateway 192.168.0.254 mit den DNS-Servern von Google 8.8.8.8 und 8.8.8.4. Unser Server bekommt den Rechnernamen server und den Domain-Namen test.local.

Benutzer anlegen

Bei der Abfrage der Benutzerinformationen wählen wie als vollständigen Namen Theo Test, als Benutzernamen für unser Konto das vorgeschlagene theo. Schließlich vergeben wir noch ein möglichst sicheres Passwort. Unseren persönlichen Ordner verschlüsseln wir nicht, daher beantworten wir den nachfolgenden Dialog mit Nein.

Zeitzone einstellen

Als Zeitzone übernehmen wir die Voreinstellung Europe/Berlin.

Festplatte(n) partitionieren

Bei der Festplattenpartitionierung folgen wir den Vorschlägen Geführt – gesamte Platte und LVM einrichten bis Partitionierung beenden und Änderungen übernehmen und bestätigen den abschließenden Dialog mit Ja.

Software installieren

Da wir keinen Proxy-Server für den Download verwenden, lassen wir die Zeile mit der HTTP-Proxy-Information frei. Um unser System möglichst sicher zu halten, wählen wir Sicherheitsaktualisierungen automatisch installieren. Bei der Software-Auswahl haken wir keine der angebotenen Optionen an bzw. entfernen bereits gesetzte Häkchen, da wir zusätzliche Pakete bei Bedarf einzeln installieren und anpassen möchten.

Installation abschließen

Nachdem alle erforderlichen Dateien installiert und das System konfiguriert ist, übernehmen wir abschließend die Option, den GRUB Boot Loader in den Master Boot Record zu installieren. Zum Abschluss der Installation starten wir – nach dem Entfernen des Installationsmediums – den Server neu.

Nacharbeiten

Für die nachfolgenden Konfigurationsarbeiten führen wir alle Befehle als Benutzer root aus, z. B. durch Wechsel in eine Rootshell mit sudo -i oder durch Voranstellen von sudo vor den jeweiligen Befehl.

System aktualisieren

Zunächst bringen wir den Server durch Upgrades aller installierten Pakete auf den neuesten Stand:

root@server:~# apt update && apt upgrade

Systemzeit synchronisieren

Die Systemzeit unseres Servers wollen wir mit einem NTP(„Network Time Protocol“)-Server über das Internet abgleichen. Hierzu installieren wir das Paket ntp:

root@server:~# apt install ntp

Fernzugriff einrichten

Für den sichereren Fernzugiff auf den Server mit ssh eignet sich der SSH-Server OpenSSH. Ihn richten wir wie z. B. in der Anleitung für den Fernzugriff auf Ubuntu Server 14.04 beschrieben ein.