Schlagwort-Archive: ubuntu

Desktop-Linux – Wer die Wahl hat, hat die Qual

Vorwarnung: Dieser Artikel wird euch vermutlich nicht interessieren, wenn ihr nicht zufällig die gleichen Anforderungen an eine Linux-Distribution für den Desktop stellt wie ich. Mir selbst dient dieser Beitrag als Sammlung von Informationen und zum Vergleich von Distributionen, um schlussendlich eine neue Distribution für meinen Desktop-PC und meine beiden Notebooks auszuwählen. Falls euch langweilig ist oder ihr neugierig seid, dürft ihr natürlich gerne weiter lesen. ;-)

Update vom 10.02.2020 TL;DR: Ich habe mich nach dem LinuxDay AT 2019 für Debian 10 (Buster) entschieden.

Umfeld

Auf meinen privaten Geräten läuft seit 2006 Ubuntu. Die Geräte haben dabei selten eine Neuinstallation erlebt, sondern wurden meist per Distribution-Upgrade auf eine neue Release aktualisiert. Leider klappt letzteres in jüngerer Vergangenheit zunehmend schlechter und unzuverlässiger. Eine Neuinstallation ist inzwischen einem Upgrade vorzuziehen, da sie meist schneller durchgeführt ist und weniger Nacharbeiten nach sich zieht.

Neben den zunehmenden Problemen mit dem Distribution-Upgrade hat mir Canonical in der jüngeren Vergangenheit ein wenig zu viel an meiner Lieblingsdistribution herumgepfuscht bzw. sie ver(schlimm)bessert. Dies ist der Auslöser, mir mal eine Alternative für den Desktop-Einsatz zu suchen.

Bei meinen Geräten handelt es sich um einen älteren Desktop-PC und zwei ThinkPads (T410 und X201). Dazu gesellt sich in der Peripherie noch ein Brother DCP-540CN, ein Synology DS213air. Alle Komponenten sind in das WLAN-Heimnetzwerk eingebunden. Die Hardware ist alt, doch funktioniert sie noch tadellos und erfüllt ihren Zweck. Daher möchte ich sie gerne noch einige Jahre weiter nutzen.

Anforderungen

Beruflich bin ich im BITS, dem Hochschulrechenzentrum der Uni Bielefeld, tätig und betreue dort diverse IT-Dienste und Themen. Da ich also bereits einen sehr großen Teil des Tages mit der Wartung, Pflege, Entstörung und (sofern noch Zeit ist) der Weiterentwicklung dieser Dienste verbringe, möchte ich mich daheim so wenig wie möglich mit diesen Tätigkeiten aufhalten. Die regelmäßige Installation von Sicherheits-Aktualisierungen ist obligatorisch, doch auf lange Fehlersuche und Behebung möchte ich daheim gerne verzichten.

Bei mir gilt Stabilität vor Bleeding Edge. Ich benötige nicht ständig neue Funktionen und die aktuellste Upstream-Version. Wenn eine Anwendung meine Anforderungen erfüllt und mit Sicherheits-Aktualisierungen versorgt wird, reicht mir das völlig aus.

Aktuell bieten mir die unter Ubuntu 16.04 LTS verfügbaren Anwendungen die Funktionalität, die ich benötige. Die auszuwählende Distribution sollte die entsprechenden Versionen in gleicher oder aktuellerer Version bereitstellen können. Sollte nur eine ältere Version einer Anwendung verfügbar sein, ist dies nicht automatisch ein Ausschlusskriterium. In diesem Fall ist die Anwendung zu testen, ob sie meinen Anforderungen genügt.

Ich wünsche mir einen möglichst großen Unterstützungszeitraum. Ubuntu bietet in den Versionen mit Long Term Support eine Unterstützung für 5 Jahre an. Damit bin ich bisher ganz gut gefahren und möchte mich deshalb in diesem Punkt nur ungern verschlechtern.

Bewertungskriterien

Wie ihr oben gelesen habt, habe ich keine knallharten und messbaren Anforderungen definiert, sondern lediglich Punkte genannt, die mir wichtig sind. In den folgenden Abschnitten werde ich mir eine Auswahl von Linux-Distributionen etwas näher ansehen und diese zuerst auf dem Papier und anhand meiner Erfahrungen miteinander vergleichen. Dabei bewerte ich folgende Kriterien:

  • Release-Zyklus
  • Support-/Life-Cycle
  • Paketverfügbarkeit und Versionsstand
  • Community

Für vorstehend genannte Kriterien vergebe ich Punkte nach folgender Tabelle. Dabei gehen alle Kriterien mit gleicher Gewichtung in das Endergebnis ein, sodass die Distribution mit den meisten Punkten am besten zu mir passen sollte.

Punkte
Beschreibung

0gefällt mir/funktioniert sehr schlecht
1gefällt mir/funktioniert schlecht
2Ist in Ordnung
3gefällt mir/funktioniert gut
4gefällt mir/funktioniert sehr gut

Als Referenz dient mir Xenial, für welches meine Bewertungstabelle wie folgt aussieht:

Ubuntu 16.04 LTS
NameWertBewertung
Unterstützungszeitraum5 Jahre bis April 20213
Release-ZyklusAlle 2 Jahre3
Communityubuntuusers.de4
Kernel4.42
systemd2292
gnome-shell3.18.42
Vim7.42
Firefox66.0.33
Thunderbird60.6.13
Evolution3.18.5.22
gThumb3.4.32
Evince3.18.22
Kile2.1.33
TeXlive20151
XSane0.9994
Summe38

Anmerkung: Bitte beachtet, dass dies hier eine sehr vereinfachte Form einer Bewertungstabelle für meinen privaten Zeitvertreib ist. Als Entscheidungstabelle für die Arbeit ist dieses Format ganz sicher nicht geeignet.

Ausgewählte Distributionen im Vergleich

Für den hier stattfindenden Vergleich habe ich mir folgende Distributionen angesehen (alphabetisch sortiert). Warum genau diese? Nun, entweder kenne ich sie schon oder sie wurden mir von Arbeitskollegen empfohlen.

  • Antergos
  • Arch Linux
  • CentOS
  • Debian
  • Fedora
  • Ubuntu

Antergos

Antergos basiert auf Arch Linux und folgt dem Rolling-Release-Prinzip. Ich möchte kein Rolling Release nutzen. Daher hört die Bewertung hier schon auf, da Antergos für mich nicht in Frage kommt.

Arch Linux

Arch Linux folgt ebenfalls dem Rolling-Release-Prinzip und scheidet daher ebenfalls von vornherein aus.

CentOS 7

CentOS wird aus den Quellen von Red Hat Enterprise Linux gebaut, zu welchem es binärkompatibel ist. CentOS ist nach eigenen Angaben ein Enterprise-Betriebssystem, welches mit langen Wartungszyklen aufwartet. So kann ein Release bis zu zehn Jahre genutzt werden, ohne dass Softwareversionen migriert werden müssen.

Zehn Jahre lang Ruhe. Das klingt verlockend. Grund genug, sich das aktuelle CentOS 7 auf dem Papier anzuschauen.

CentOS 7
NameWertBewertung
Unterstützungszeitraum10 Jahre bis Juni 20244
Release-ZyklusAlle 3-4 Jahre3
CommunityForum und Mailingliste2
Kernel3.10.02
systemd2192
gnome-shell3.28.33
Vim7.42
Firefox60.6.13
Thunderbird60.6.13
Evolution3.28.52
gThumb3.3.42
Evince3.28.22
Kile2.1.33
TeXlive20121
XSane0.9994
Summe38

Debian

Debian ist ein von der Gemeinschaft entwickeltes freies Betriebssystem und mein heimlicher Favorit. Mir gefällt die Idee, mich neben einer RPM-basierten Distribution auf der Arbeit,Ubuntu importiert den Großteil seiner Pakete aus Debian Unstable. Für einen Teil dieser Pakete übernimmt nach dem Debian Import Freeze die Firma Canonical die Pflege. Der größte Teil landet hingegen in der Komponente universe, wo er von den MOTU betreut wird (oder gar nicht). Die Folge dieses Vorgehens: Wenn Pakete in Debian Unstable während des Debian Import Freeze kaputt und unbenutzbar sind, werden sie in die Ubuntu-Paketquellen importiert und bleiben mit großer Wahrscheinlichkeit für die Lebensdauer des jeweiligen Releases daheim mit einer DEB-basierten Distribution zu beschäftigen, um in beiden Paketformatwelten auf dem Laufenden zu bleiben.

Debian Stable steht in dem Ruf rock solid zu sein, was meinem Wunsch nach einer sehr stabilen Distribution entgegen kommt. Die Softwarepakete in Debian Stable gelten gemeinhin als sehr gut abgehangen. Kritiker bezeichnen sie auch als hoffnungslos veraltet. So lange sie die von mir gewünschte Funktionalität bieten, ist mir das Alter egal. Falls ich mich für Debian entscheide, werde ich auf die Veröffentlichung von Buster warten, welche mit folgenden Werten aufwartet.

Debian 10 (Buster)
NameWertBewertung
Unterstützungszeitraum3 Jahre (+2 Jahre LTS)2
Release-ZyklusCa. alle 2 Jahre3
CommunitySee Support Page2
Kernel4.19.163
systemd2412
gnome-shell3.30.24
Vim8.13
Firefox60.6.13
Thunderbird60.6.13
Evolution3.30.52
gThumb3.6.22
Evince3.30.22
Kile2.9.922
TeXlive20183
XSane0.9994
Summe40

Fedora

Bei Fedora handelt es sich wiederum um eine RPM-basierte Distribution. Diese wartet mit recht aktuellen Softwarepaketen auf und gibt sich selbst als für Desktops, Workstations, Laptops und Server geeignet. Fedora wird auch gern als Testlabor für RHEL bezeichnet, da viele Entwicklungen, die sich hier etablieren konnten, später in RHEL übernommen werden.

Die Aktualität hat ihren Preis. So kommt Fedora mit recht kurzen Releasezyklen daher, was für mich ganz klar Punktabzug bedeutet.

Fedora Rawhide
NameWertBewertung
Unterstützungszeitraum13 Monate0
Release-ZyklusAlle 6 Monate0
Communityfedoraforum.de2
Kernel5.13
systemd2422
gnome-shell3.32.14
Vim8.13
Firefox66.0.33
Thunderbird60.6.13
Evolution3.33.12
gThumb3.7.13
Evince3.32.02
Kile2.9.922
TeXlive20183
XSane0.9994
Summe36

Ubuntu LTS

Basierend auf Debian laufen die Ubuntu LTS Releases seit Jahren auf meinen Rechnern. Da ich mit dieser Distribution die meiste Erfahrung habe und dadurch auch einige ihrer Macken kenne, fällt es mir schwer, bei einer Bewertung neutral zu bleiben. Doch werde ich mir Mühe geben.

Ubuntu importiert den Großteil seiner Pakete aus Debian Unstable. Für einen Teil dieser Pakete übernimmt nach dem Debian Import Freeze die Firma Canonical die Pflege. Der größte Teil landet hingegen in der Komponente universe, wo er von den MOTU betreut wird (oder gar nicht). Die Folge dieses Vorgehens: Wenn Pakete in Debian Unstable während des Debian Import Freeze kaputt und unbenutzbar sind, werden sie in die Ubuntu-Paketquellen importiert und bleiben mit großer Wahrscheinlichkeit für die Lebensdauer des jeweiligen Release kaputt und unbenutzbar. Dieses Vorgehen halte ich persönlich für ganz großen Schwachsinn.

Als einzigartig hingegen empfinde ich die deutschsprachige Community ubuntuusers.de. Auch wenn hier in einigen Themen auch mal die Fetzen fliegen, ist der Umgangston doch überwiegend freundlich. Hier fand ich in der Vergangenheit stets wertvolle Hilfe bei kleinen und auch großen Problemen

Ubuntu 18.04 LTS
NameWertBewertung
Unterstützungszeitraum5 Jahre bis April 20233
Release-ZyklusAlle 2 Jahre3
Communityubuntuusers.de4
Kernel4.153
systemd2372
gnome-shell3.28.32
Vim8.02
Firefox66.0.33
Thunderbird60.6.13
Evolution3.28.52
gThumb3.6.12
Evince3.18.42
Kile2.9.911
TeXlive20171
XSane0.9994
Summe37

Schlussfolgerung und selbstkritische Reflexion des Distributions-Vergleichs

Ubuntu 16.04 LTSCentOS 7Debian BusterFedora RawhideUbuntu 18.04 LTS
3838403637

Sieg nach Punkten für das hoffentlich bald erscheinende Debian Buster!

Dass mein heimlicher Favorit das Rennen gemacht hat, verwundert nicht. Nüchtern und bei Licht betrachtet muss ich gestehen, dass der oben stehende Vergleich Makulatur und nicht objektiv ist. So ist der Vergleich und die Bewertung von Software-/Paket-Versionen nicht geeignet, um zu bestimmen, wie gut meine funktionalen Anforderungen erfüllt werden. Dazu hätte es eines praktischen Tests der einzelnen Versionen bedurft.

So offenbarte ein praktischer Vergleich von kile in Version 2.9.91, dass mir dieses in der Benutzung deutlich schlechter gefällt, als die ältere Version 2.1.3. Und was für kile gilt, mag selbstverständlich auch für andere Anwendungen gelten.

Ein weiterer großer Schwachpunkt des Vergleichs ist der Punkt ‚Community‘. Aus persönlicher Erfahrung kenne ich nur die ubuntuusers.de wirklich gut, weil ich nur hier seit vielen Jahren selbst aktiv bin. Die Bewertung aller anderen Communities und Unterstützungsmöglichkeiten basiert auf deutlich weniger Erfahrungen und Teils sogar nur auf Hörensagen. Eine objektive Bewertung ist so natürlich nicht möglich.

Streng genommen handelt es sich bei dem angestellten Vergleich um Humbug und Mumpitz. Bitte nicht nachmachen!

Mir selbst reicht er jedoch als Indikator, dass das kommende Debian Buster meine Anforderungen daheim gut erfüllen könnte. Es wird daher nach der Veröffentlichung auf einem meiner Geräte installiert und in der Praxis erprobt.

Tja, wenn ich ehrlich bin, ist dieser Artikel wenig hilfreich. Zum Trost sei gesagt, dass er mir half, ein wenig die Zeit bis zum Release von Buster zu überbrücken.

Benutzer die Ausführung eines Skripts mit sudo gestatten

In diesem kurzen Tutorial wird beschrieben, wie man einem normalen Benutzer das Recht einräumt, ein einzelnes Skript mit sudo auszuführen. Das Tutorial ist auf alle Linux-Distributionen anwendbar, welche sudo[1. sudo – Wikipedia] unterstützen.

Schritt 1: Skript und Benutzerkonto erstellen

Zuerst wird natürlich das Skript benötigt, welches der neue Benutzer später ausführen soll. Als Beispiel mag hier folgendes einfaches Beispiel dienen:

#!/bin/bash
echo "Hallo Welt."

Wichtig! Der Benutzer, welcher das Skript später ausführen soll, darf selbst keine Schreibrechte darauf besitzen. Andernfalls könnte er das Skript bearbeiten und durch eintragen von bash eine root-shell öffnen. Danke an Gerald für diesen wichtigen Hinweis.

Der Benutzer kann, sofern er nicht schon existiert, mit folgendem Kommando angelegt werden:

sudo adduser USERNAME

Schritt 2: /etc/sudoers konfigurieren

Um einem Benutzer das Recht zu verleihen, gibt es grundsätzlich mehrere Möglichkeiten.

Benutzer einer Gruppe hinzufügen

Auf vielen Linux-Distributionen existiert bereits eine Gruppe, deren Mitglieder die Berechtigung zur Verwendung von sudo besitzen. Unter Ubuntu ist dies z.B. die Gruppe ’sudo‘. Unter RHEL, CentOS und Fedora ist dies bspw. die Gruppe ‚wheel‘. Um welche Gruppe es sich konkret handelt, kann in der Datei /etc/sudoers nachgeschlagen werden. Dort findet sich auf einem Ubuntu 16.04 LTS z.B. folgender Eintrag:

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

Da dem Benutzer im hier beschriebenen Fall jedoch nur erlaubt werden soll, ein einziges Skript mittels sudo auszuführen, ist diese Methode ungeeignet.

Benutzer in /etc/sudoers

Um einem Benutzer das Recht zu gewähren, ein bestimmtes Skript oder Programm mit sudo auszuführen, kann der Benutzer wie folgt in die Datei /etc/sudoers eingetragen werden.

Wichtig! Die Datei /etc/sudoers sollte nur als root mit dem Kommando visudo editiert werden, da hiermit eine Syntaxprüfung erfolgt. Eine Beschädigung der Datei /etc/sudoers, z.B. durch Syntaxfehler, kann dazu führen, dass das gesamte System unbrauchbar wird.

# User privilege specification
USERNAME    ALL=/path/to/script.sh

Mit obiger Zeile wird dem Benutzer ‚USERNAME‘ erlaubt, das Skript unter /path/to/script.sh mit sudo auszuführen.

Diese Methode ist bereits geeignet, um die gestellte Aufgabe zu lösen.

Datei unter /etc/sudoers.d/ erstellen

Unter aktuellen Versionen von Debian, Ubuntu, RHEL, CentOS und Fedora besteht die Möglichkeit, eine Datei im Verzeichnis /etc/sudoers.d/ zu erstellen, welche den Eintrag aus dem vorangegangenen Abschnitt enthält. Voraussetzung dafür ist, dass die Datei /etc/sudoers folgende Direktive enthält:

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Beachte: Das Zeichen ‚#‘ vor ‚includedir‘ stellt in diesem Fall kein Kommentarzeichen dar.

Diese Methode hat den Vorteil, dass die Datei /etc/sudoers unverändert bleibt und es bei Updates nicht zu einem Versionskonflikt kommen kann.

Fazit

Mittels /etc/sudoers ist es möglich, sudo-Berechtigungen granular an Benutzer zu delegieren. Neben dem in diesem Tutorial beschriebenen Beispiel existieren noch weitere Möglichkeiten. Beispiele dazu finden sich in der Manpage von sudoers.

Installation von Seafile auf einem Ubuntu/Debian Server

Diese Anleitung beschreibt, wie die Software Seafile[1. Wikipedia Artikel zu Seafile}] auf einem Ubuntu Server installiert werden kann. Sie gilt prinzipiell auch für Debian. Jedoch müssen einzelne Schritte ggf. angepasst werden.

Hinweis zu Seafile Version 6.2: Bitte beachten Sie bei der Installation von Seafile in Version 6.2 den Kommentar von Christoph weiter unten. Ich Danke Christoph für diesen Hinweis.

Getestete Versionen

BetriebssystemUbuntu 14.04 LTS Server
WebserverNGINX 1.4.6
DatenbankserverMySQL 5.6
Seafile5.1.4 64bit

Einleitung

Seafile ist eine freie Software, um Dateien zentral auf einem eigenen Server zu speichern (Filehosting). Benutzer können auf ihre Daten über eine Webschnittstelle zugreifen oder über Desktop-Clients synchronisieren. Quelle: Wikipedia {de}

Seafile[2. Seafile Homepage {en}] bildet damit einen Teil des Funktionsumfangs bekannter Open Source Projekte wie ownCloud und Nextcloud ab, konzentriert sich dabei jedoch auf die „Sync+Share“-Funktion für Dateien. Jan Karres hat in seinem Blog einen schönen Artikel über den Vergleich ownCloud vs Seafile geschrieben, welcher die Eigenschaften sowie die Vor- und Nachteile beider Projekte erläutert.

Bei dem hier vorliegenden Anwendungsfall habe ich mich für Seafile entschieden, da die einzige Anforderung im Sync+Share von Dateien besteht. Seafile bietet im Gegensatz zu ownCloud auf diesem Gebiet auch clientseitige Verschlüsselung[3. How to Use Encrypted Libraries] an. Die zukünftigen Anwender sind im Umgang bereits geübt und die Sync-Clients bereits auf den meisten ihrer Endgeräte installiert.

Um dieser Anleitung folgen zu können, werden grundlegende Kenntnisse in der Administration eines Linuxservers vorausgesetzt.

Anleitung

Die folgende Anleitung wurde auf Basis der Artikel von Jan Karres[4. Raspberry Pi: Owncloud-Alternative Seafile Server installieren] und André P.[5. Seafile 4.0.x mit Nginx und MySQL-Backend auf Debian/Ubuntu] erstellt.

Voraussetzungen

Folgende Dienste müssen auf dem Server installiert und funktionsfähig sein, um Seafile installieren zu können:

Als Servername wird im Folgenden stets seafile verwendet. Dieser ist an den gewünschten Servernamen der eigenen Installation anzupassen.

Installation und Konfiguration

Zuerst werden die von Seafile benötigten Abhängigkeiten installiert:

sudo apt-get install python2.7 python-setuptools python-simplejson python-imaging python-mysqldb

Im zweiten Schritt wird ein Systembenutzer[9. Der Unterschied zwischen einem Systembenutzer und einem normalen Benutzer] erstellt, dessen Home-Verzeichnis die gesamte Seafile-Installation aufnehmen wird. Der Benutzername kann dabei frei gewählt werden.

sudo adduser --system --group BENUTZERNAME

Mit den folgenden Befehlen wird der Benutzer gewechselt, die benötigte Verzeichnisstruktur erstellt, die Software heruntergeladen und entpackt.

# Wechselt zum erstellten Systembenutzer für die Seafile-Installation
sudo su - BENUTZERNAME -s /bin/bash

# Erstellen der Verzeichnisstruktur
mkdir -p seafile/installed && cd seafile/installed
wget wget https://download.seafile.de/seafile-server_latest_x86-64.tar.gz

# Archiv in das Zielverzeichnis entpacken und zurück ins Home-Verzeichnis wechseln
tar -xzvf *tar.gz -C ../ && cd ..

Im Home-Verzeichnis sollte die Verzeichnisstruktur nun wie folgt aussehen:

seafile@rs212997:/home/seafile/seafilesrv$ tree -L 2
.
├── installed
│   └── seafile-server_latest_x86-64.tar.gz
└── seafile-server-5.1.3
    ├── check_init_admin.py
    ├── reset-admin.sh
    ├── runtime
    ├── seaf-fsck.sh
    ├── seaf-fuse.sh
    ├── seaf-gc.sh
    ├── seafile
    ├── seafile.sh
    ├── seahub
    ├── seahub.sh
    ├── setup-seafile-mysql.py
    ├── setup-seafile-mysql.sh
    ├── setup-seafile.sh
    └── upgrade

6 directories, 11 files

Nun wechselt man in das Verzeichnis mit der Software (in diesem Fall seafile-server-5.1.3) und führt das Skript setup-seafile-mysql.sh aus. Die Antworten auf die Fragen sind selbstverständlich an die eigene Umgebung anzupassen.

./setup-seafile-mysql.sh 
Checking python on this machine ...
  Checking python module: setuptools ... Done.
  Checking python module: python-imaging ... Done.
  Checking python module: python-mysqldb ... Done.

-----------------------------------------------------------------
This script will guide you to setup your seafile server using MySQL.
Make sure you have read seafile server manual at

        https://github.com/haiwen/seafile/wiki

Press ENTER to continue
-----------------------------------------------------------------


What is the name of the server? It will be displayed on the client.
3 - 15 letters or digits
[ server name ] seafile

What is the ip or domain of the server?
For example: www.mycompany.com, 192.168.1.101
[ This server's ip or domain ] seafile.domain.tld

Where do you want to put your seafile data?
Please use a volume with enough free space
[ default "/home/BENUTZERNAME/seafilesrv/seafile-data" ] 

Which port do you want to use for the seafile fileserver?
[ default "8082" ] 

-------------------------------------------------------
Please choose a way to initialize seafile databases:
-------------------------------------------------------

[1] Create new ccnet/seafile/seahub databases
[2] Use existing ccnet/seafile/seahub databases

[ 1 or 2 ] 1

What is the host of mysql server?
[ default "localhost" ] 

What is the port of mysql server?
[ default "3306" ] 

What is the password of the mysql root user?
[ root password ] 

verifying password of user root ...  done

Enter the name for mysql user of seafile. It would be created if not exists.
[ default "root" ] seafile_user

Enter the password for mysql user "seafile_user":
[ password for seafile_user ] 

Enter the database name for ccnet-server:
[ default "ccnet-db" ] my-ccnet-db

Enter the database name for seafile-server:
[ default "seafile-db" ] my-seafile-db

Enter the database name for seahub:
[ default "seahub-db" ] my-seahub-db

---------------------------------
This is your configuration
---------------------------------

    server name:            seafile
    server ip/domain:       seafile.domain.tld

    seafile data dir:       /home/BENUTZERNAME/seafilesrv/seafile-data
    fileserver port:        8082

    database:               create new
    ccnet database:         my-ccnet-db
    seafile database:       my-seafile-db
    seahub database:        my-seahub-db
    database user:          seafile_user



---------------------------------
Press ENTER to continue, or Ctrl-C to abort
---------------------------------

Generating ccnet configuration ...

done
Successly create configuration dir /home/BENUTZERNAME/seafilesrv/ccnet.
Generating seafile configuration ...

Done.
done
Generating seahub configuration ...

----------------------------------------
Now creating seahub database tables ...

----------------------------------------

creating seafile-server-latest symbolic link ...  done




-----------------------------------------------------------------
Your seafile server configuration has been finished successfully.
-----------------------------------------------------------------

run seafile server:     ./seafile.sh { start | stop | restart }
run seahub  server:     ./seahub.sh  { start  | stop | restart  }

-----------------------------------------------------------------
If you are behind a firewall, remember to allow input/output of these tcp ports:
-----------------------------------------------------------------

port of seafile fileserver:   8082
port of seahub:               8000

When problems occur, Refer to

        https://github.com/haiwen/seafile/wiki

for information.

Möchte man Seafile via HTTPS nutzen, sind noch zwei Dateien anzupassen. Zuerst wird in die Datei ~/seafilesrv/conf/ccnet.conf der Parameter SERVICE_URL wie folgt angepasst:

SERVICE_URL = https://seafile.domain.tld:8000

Die zweite zu bearbeitende Datei ist seahub_settings.py. Hier wird am Ende der Datei die folgende Zeile eingefügt:

FILE_SERVER_ROOT = 'https://seafile.domain.tld/seafhttp'

Durch manuelles Starten der Dienste wird der Administrator-Account erstellt. Das folgende Listing zeigt die auszuführenden Befehle und Abfragen:

:~$ ~/seafilesrv/seafile-server-latest/seafile.sh start

[09/02/16 21:56:00] ../common/session.c(132): using config file /home/BENUTZERNAME/seafilesrv/conf/ccnet.conf
Starting seafile server, please wait ...
Seafile server started

Done.
:~$ ~/seafilesrv/seafile-server-latest/seahub.sh start-fastcgi

LC_ALL is not set in ENV, set to en_US.UTF-8
Starting seahub (fastcgi) at 127.0.0.1:8000 ...

----------------------------------------
It's the first time you start the seafile server. Now let's create the admin account
----------------------------------------

What is the email for the admin account?
[ admin email ] EURE E-MAIL-ADRESSE

What is the password for the admin account?
[ admin password ] SICHERESPASSWORThttp://start.ubuntu.com/16.04/Google/?sourceid=hphttp://start.ubuntu.com/16.04/Google/?sourceid=hp

Enter the password again:
[ admin password again ] SICHERESPASSWORT



----------------------------------------
Successfully created seafile admin
----------------------------------------




Seahub is started

Done.

Zum Abschluss werden die manuell gestarteten Dienste wieder beendet:

:~$ ~/seafilesrv/seafile-server-latest/seafile.sh stop
:~$ ~/seafilesrv/seafile-server-latest/seahub.sh stop

Um sicherzustellen, dass der lokale Seafile-Webdienst nicht aus dem Internet erreichbar ist, sollte folgender Block in der Datei ~/seafilesrv/conf/seafile.conf vorhanden sein:

[fileserver]
host=127.0.0.1
port=8082

An dieser Stelle wird die aktuelle Shell mit exit verlassen. Von nun an kann mit sudo oder als root weitergearbeitet werden.

Konfiguration von NGINX

Für NGINX wird ein neuer VirtualHost für die Domain seafile.domain.tld erstellt. Wird die Konfiguration aus folgendem Listing übernommen, so sind mindestens die Werte für den root-Pfad, server_name, ssl_certificate und ssl_certificate_key an die eigene Konfiguration anzupassen.

server {
        listen       80;
        server_name  seafile.domain.tld;
        rewrite ^/(.*) https://$server_name/$1 permanent;
}
server {
        listen 443; #IPv4
        #listen [::]:443; # IPv6
        ssl on;
        ssl_certificate /etc/nginx/certs/ssl-unified.crt;
        ssl_certificate_key /etc/nginx/certs/ssl.key;
        server_name seafile.domain.tld;

        location / {
                fastcgi_pass    127.0.0.1:8000;
                fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param   PATH_INFO           $fastcgi_script_name;

                fastcgi_param   SERVER_PROTOCOL     $server_protocol;
                fastcgi_param   QUERY_STRING        $query_string;
                fastcgi_param   REQUEST_METHOD      $request_method;
                fastcgi_param   CONTENT_TYPE        $content_type;
                fastcgi_param   CONTENT_LENGTH      $content_length;
                fastcgi_param   SERVER_ADDR         $server_addr;
                fastcgi_param   SERVER_PORT         $server_port;
                fastcgi_param   SERVER_NAME         $server_name;

                fastcgi_param   HTTPS on;
                fastcgi_param   HTTP_SCHEME https;
        }

        location /seafhttp {
                rewrite ^/seafhttp(.*)$ $1 break;
                proxy_pass http://127.0.0.1:8082;
                client_max_body_size 0;
        }

        location /media {
                root /home/BENUTZERNAME/seafilesrv/seafile-server-latest/seahub;
        }
}

Mit der oben stehenden Konfiguration erfolgt automatisch eine Weiterleitung von HTTP auf HTTPS. Wer für die Beantragung und Implementierung des Zertifikats Anleitung benötigt oder die Installation zusätzlich noch mit HSTS und HPKP schützen möchte, sei auf mein TLS-Kochbuch[10. Kapitel 4, TLS-Kochbuch mit Rezepten zur Verwendung von OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP)] verwiesen.

Konfiguration des Seafile-Dienstes

Zur Konfiguration des Dienstes bediene ich mich der Arbeit aus dem Artikel von André P. Dazu wird die Datei /etc/init.d/seafile mit folgendem Inhalt erstellt. Die Parameter user und seafile_dir sind dabei an die eigene Installation anzupassen.

#!/bin/bash

### BEGIN INIT INFO
# Provides:          seafile
# Required-Start:    $local_fs $remote_fs $network
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Starts Seafile and Seahub
# Description:       starts Seafile and Seahub
### END INIT INFO

#### CONFIG START ####
user=seafile
seafile_dir=/srv/seafile/servername
##### CONFIG END #####

script_path=${seafile_dir}/seafile-server-latest
seafile_init_log=${seafile_dir}/logs/seafile.init.log
seahub_init_log=${seafile_dir}/logs/seahub.init.log
[ -d ${seafile_dir}/logs ] || mkdir ${seafile_dir}/logs && chown $user:$user ${seafile_dir}/logs

# Change the value of fastcgi to true if fastcgi is to be used
fastcgi=true
# Set the port of fastcgi, default is 8000. Change it if you need different.
fastcgi_port=8000

case "$1" in
        start)
                sudo -u ${user} ${script_path}/seafile.sh start >> ${seafile_init_log}
                if [  $fastcgi = true ];
                then
                        sudo -u ${user} ${script_path}/seahub.sh start-fastcgi ${fastcgi_port} >> ${seahub_init_log}
                else
                        sudo -u ${user} ${script_path}/seahub.sh start >> ${seahub_init_log}
                fi
        ;;
        restart)
                sudo -u ${user} ${script_path}/seafile.sh restart >> ${seafile_init_log}
                if [  $fastcgi = true ];
                then
                        sudo -u ${user} ${script_path}/seahub.sh restart-fastcgi ${fastcgi_port} >> ${seahub_init_log}
                else
                        sudo -u ${user} ${script_path}/seahub.sh restart >> ${seahub_init_log}
                fi
        ;;
        stop)
                ${script_path}/seafile.sh $1 >> ${seafile_init_log}
                ${script_path}/seahub.sh $1 >> ${seahub_init_log}
        ;;
        *)
                echo "Usage: /etc/init.d/seafile {start|stop|restart}"
                exit 1
        ;;
esac

Mit den folgenden Kommandos wird das Skript ausführbar gemacht, installiert und der Dienst gestartet:

chmod +x /etc/init.d/seafile
update-rc.d seafile defaults
service seafile start

Ende

Die Installation ist damit abgeschlossen. Die Seafile-Installation kann nun über https://seafile.domain.tld aufgerufen und genutzt werden.

An dieser Stelle möchte ich mich noch einmal bei André P. für seinen Artikel „Seafile 4.0.x mit Nginx und MySQL-Backend auf Debian/Ubuntu bedanken. Er stellt die Basis für diese Anleitung mit der aktuellen Version von Seafile dar.

Solltet ihr Seafile mit dieser Anleitung auch unter anderen Versionen von Ubuntu/Debian, etc. installieren können, freue ich mich über eure Kommentare, um die Tabelle mit den getesteten Versionen ergänzen zu können.

Ubuntu/Debian: PPA für PHP wechseln

In diesem Artikel dokumentiere ich den Wechsel eines PPA[1. „Personal Package Archive“] unter Ubuntu 14.04 LTS „Trusty Tahr“.

Achtung: Dies ist keine Schritt-für-Schritt-Anleitung. Die im Folgenden beschriebenen Schritte müssen auf einem anderen System nicht zwingend funktionieren. Fehler können euer System unbrauchbar machen. Also sagt nicht, ihr wurdet nicht gewarnt.

Warnung vor Fremdquellen: Die Benutzung fremder Quellen für Software sollte nach Möglichkeit auf das Notwendigste beschränkt werden, da sie einige gravierende Nachteile mit sich bringt.[2. ubuntuusers Wiki – Risiken von Fremdquellen]

Ich betreibe einen Server mit Ubuntu 14.04 LTS. In Trusty steht in den Originalquellen lediglich die PHP-Version 5.5.x zur Verfügung. Ich benötige jedoch PHP in Version 5.6.x und habe dazu das PPA ppa:ondrej/php5 in mein System eingebunden. Dieses PPA wurde nun von seinem Maintainer als deprecated markiert.

ppa:ondrej/php5 deprecated

ppa:ondrej/php5 deprecated

Der Maintainer stellt als Ersatz das PPA ppa:ondrej/php bereit. Dieses beinhaltet die PHP-Versionen 5.5, 5.6 und 7.0, welche auch nebeneinander installiert werden können.

Um dieses PPA meinem System hinzuzufügen, folge ich der PPA-Beschreibung[3. The main PPA for PHP (5.5, 5.6, 7.0) with many PECL[…]] und führe folgenden Befehl aus:

:~$ sudo LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/php
 Co-installable PHP versions: PHP 5.5, 5.6, PHP 7.0 and batteries included.

You can get more information about the packages at https://deb.sury.org

For PHP 5.4 on Ubuntu 12.04 use: ppa:ondrej/php5-oldstable

BUGS&FEATURES: This PPA now has a issue tracker: https://deb.sury.org/#bug-reporting

PLEASE READ: If you like my work and want to give me a little motivation, please consider donating regularly: https://donate.sury.org/

WARNING: add-apt-repository is broken with non-UTF-8 locales, see https://github.com/oerdnj/deb.sury.org/issues/56 for workaround:

# LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/php
 More info: https://launchpad.net/~ondrej/+archive/ubuntu/php
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmptgkt4t8k/secring.gpg' created
gpg: keyring `/tmp/tmptgkt4t8k/pubring.gpg' created
gpg: requesting key E5267A6C from hkp server keyserver.ubuntu.com
gpg: /tmp/tmptgkt4t8k/trustdb.gpg: trustdb created
gpg: key E5267A6C: public key "Launchpad PPA for Ondřej Surý" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK
:~$

Analog zu dem oben ausgeführten Befehl wird das alte PPA aus dem System entfernt:

:~$ sudo add-apt-repository -r ppa:ondrej/php5
 This PPA is going to be DEPRECATED, please use ppa:ondrej/php

If you need other PHP versions use:
  PHP 5.4: ppa:ondrej/php5-oldstable (Ubuntu 12.04 LTS)
  PHP 5.5, PHP 5.6 and PHP 7.0: ppa:ondrej/php (Ubuntu 14.04 LTS - Ubuntu 16.04 LTS)

WARNING: add-apt-repository is broken with non-UTF-8 locales, see https://github.com/oerdnj/deb.sury.org/issues/56 for workaround:

# apt-get install -y language-pack-en-base
# LC_ALL=en_US.UTF-8 add-apt-repository ppa:ondrej/php5
 More info: https://launchpad.net/~ondrej/+archive/ubuntu/php5
Press [ENTER] to continue or ctrl-c to cancel removing it
:~$

Hinweis: Durch das Entfernen des PPA wird die aus diesem PPA installierte Software nicht vom System entfernt.

Um zukünftig die Software aus dem neuen PPA zu nutzen, werden die folgenden Befehle ausgeführt. Bei dieser Gelegenheit habe ich gleich meine PHP-Version auf 7.0 aktualisiert:

:~$ sudo apt-get update
:~$ sudo apt-get --reinstall install php-pear
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  php-cli php-common php-xml php7.0-cli php7.0-common php7.0-json
  php7.0-opcache php7.0-readline php7.0-xml
Die folgenden NEUEN Pakete werden installiert:
  php-cli php-common php-xml php7.0-cli php7.0-common php7.0-json
  php7.0-opcache php7.0-readline php7.0-xml
Die folgenden Pakete werden aktualisiert (Upgrade):
  php-pear
1 aktualisiert, 9 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.
Es müssen 2.284 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 9.839 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] J

Operation beendet, Webanwendung funktioniert noch, Happy End.

Logging und logrotate mit NGINX

In diesem Artikel wird beschrieben, wie ich das Logging und logrotate meines NGINX-Servers konfiguriert habe. Dabei gehe ich kurz auf die beiden verwendeten Direktiven error_log und ngx_http_log_module ein.

Damit dient dieser Artikel meiner Dokumentation und evtl. euch als Anregung, ein eigenes Logging zu konfigurieren.

Logging

Informationen zum Logging findet man in der offiziellen NGINX-Dokumentation.[1. NGINX-Dokumentation] Im folgenden werden die Direktiven error_log[2. NGINX core module error_log] und ngx_http_log_module[3. NGINX – ngx_http_log_module] verwendet.

Mein Server liefert mehrere Webseiten aus. Ich möchte gern für jede Webanwendung ein separates Error-Log und Access-Log schreiben. Dabei wird folgendes Muster verwendet:

  • Log-Verzeichnis: /var/www//logs
  • Name für error_log: _error.log
  • Name für access_log: _access.log

Konfiguration des Error-Log

Die Error_log-Syntax ist denkbar einfach:

error_log log_file [ log_level ]

log_file gibt den Pfad zur Log-Datei an. Mit log_level wird bestimmt, wie viele Informationen protokolliert werden sollen.

Log-Level[4. How To Configure Logging and Log Rotation in Nginx on an Ubuntu VPS]

  • emerg: Notfall, in dem sich das System in einem nicht nutzbaren Zustand befindet
  • alert: Ernste Störung. Sofortiger Eingriff ist erforderlich
  • crit: Kritische Probleme, um die man sich kümmern sollte
  • error: Ein Fehler ist aufgetreten. Hier funktioniert etwas nicht
  • warn: Ein ungewöhnliches Ereignis ist aufgetreten. Dies ist jedoch kein Grund zur Sorge
  • notice: Normale Vorgänge werden ebenfalls protokolliert
  • info: Unnützes Wissen – Nice to know
  • debug: Debugging-Informationen, welche helfen, ein Problem näher zu analysieren

Die Log-Level sind nach Priorität angeordnet. Wird das Level auf „error“ gesetzt, so werden alle Events der Level error, crit, alert und emerg protokolliert.

Möchte man rein gar nichts protokollieren, muss das Log nach /dev/null umgeleitet werden.

error_log /dev/null crit;

Konfiguration des Access-Log

Das Modul ngx_http_log_module besteht aus den Direktiven access_log, log_format und open_log_file_cache, von denen ich hier nur die ersten beiden verwenden werde.

Mit der Direktive log_format kann das Format der Log-Dateien konfiguriert werden. Die einzelnen Formate werden über einen Bezeichner ausgewählt. Dies kann z.B. wie folgt aussehen:

log_format compression '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $bytes_sent '
                       '"$http_referer" "$http_user_agent" "$gzip_ratio"';

access_log /spool/logs/nginx-access.log compression buffer=32k;

Eine detaillierte Beschreibung aller verfügbaren Parameter kann der offiziellen Dokumentation entnommen werden.[5. NGINX -log_format]

Ich selbst verwende aktuell ausschließlich das Format combined. Dieses ist bereits in der Standardinstallation enthalten. Es sieht wie folgt aus:

log_format combined '$remote_addr - $remote_user [$time_local]  '
		    '"$request" $status $body_bytes_sent '
		    '"$http_referer" "$http_user_agent"';

Für die Protokollierung meiner Webanwendungen wird daher folgendes in die jeweiligen Server-Direktiven eingetragen:

server {
...
access_log /var/www//logs/_access.log combined;
...
}

Falls man das Access-Log deaktivieren möchte, kann man dies durch den folgenden Eintrag erreichen:

access_log off;

Nun werden schon mal alle Log-Dateien nach Webanwendungen getrennt in das Verzeichnis /var/www//logs geschrieben.

Im nächsten Abschnitt gehe ich darauf ein, wie man verhindert, dass die Festplatte mit Log-Dateien vollgeschrieben wird.

Rotation der NGINX Log-Dateien

Zum Rotieren der Logs verwende ich die Anwendung logrotate. Diese ist bei Ubuntu bereits in der Standardinstallation enthalten.

Es wird ein Skript im Verzeichnis /etc/logrotate.d erstellt und folgender Inhalt eingefügt.

/var/www//logs/*.log {
        daily
        missingok
        rotate 31
        compress
        delaycompress
        notifempty
        sharedscripts
        postrotate
                [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
        endscript
}

Mit diesem Skript wird logrotate angewiesen, die Log-Dateien im Verzeichnis /var/www//logs/ täglich zu rotieren und die letzten 31 Log-Dateien zu behalten. Die Log-Datei wird nicht rotiert, falls sie leer ist, also keine Einträge enthält. Die älteren Dateien werden dabei komprimiert, um Speicherplatz zu sparen.

Die generelle Beschreibung von logrotate würde den Rahmen dieses Artikels sprengen. Weitere Informationen sind in der Manpage zu finden.[6. logrotate(8) – Linux man page]

Damit ist der verspätete Frühjahrsputz auf diesem Server beendet.

SSL-Schwachstelle bedroht Web- und Mail-Server

Diverse Seiten im Internet berichten über eine neue SSL-Schwachstelle, die durch eine sogenannte Logjam-Attacke ausgenutzt werden kann.[1. Logjam-Attacke: Verschlüsselung von zehntausenden Servern gefährdet] [2. Tausende Web-Server betroffen: Neue HTTPS-Sicherheitslücke aufgetaucht] [3. Guide to Deploying Diffie-Hellman for TLS]

Dieser Artikel beschreibt, wie sich NGINX, Postfix und Dovecot härten lassen. Damit sind diese Dienste nicht mehr verwundbar für die aktuelle SSL-Schwachstelle.

Ich beschreibe die drei genannten Dienste, da ich diese selbst auf mehreren Ubuntu-Servern betreibe. Für weitere Dienste schaut bitte in der Quelle unter Punkt „3.“ nach.

Zu Beginn wird eine Diffie-Hellman-Group für den Server generiert:

openssl dhparam -out dh_params.pem 2048

Anschließend folgt die Härtung der einzelnen Dienste.

NGINX

Im server Block der jeweiligen Webpräsenz werden die zu verwendenden „Cipher Suites“ und Diffie-Hellman-Parameters angegeben:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

ssl_prefer_server_ciphers on;

ssl_dhparam /pfad/zur/dh_params.pem;

Anschließend wird der Dienst zur Übernahme der Einstellungen neu geladen:

sudo service nginx reload

Postfix

Beim MTA Postfix werden beide Parameter in der Datei /etc/postfix/main.conf eingetragen:

smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
smtpd_tls_dh1024_param_file = /pfad/zur/dh_params.pem

Auch hier werden die Einstellungen anschließend neu eingelesen:

sudo service postfix reload

Dovecot

Die beiden Parameter werden in die Datei /etc/dovecot/conf.d/10-ssl.conf eingetragen:

ssl_cipher_list=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
ssl_prefer_server_ciphers = yes

#regenerates every week
ssl_dh_parameters_length = 2048

Und auch hier werden die Änderungen anschließend eingelesen:

sudo doveadm reload

Damit sollte man vor dieser Schwachstelle vorerst geschützt sein.

Cisco AnyConnect VPN Client unter Ubuntu installieren

Dieser Artikel beschreibt die Installation des Cisco AnyConnect VPN Client unter Ubuntu Trusty Tahr.

Laut einem Dokument[1. AnyConnect – Unterstützte Betriebssysteme und Systemvoraussetzungen], dass ich bei der Universität Bielefeld gefunden habe, werden Ubuntu 9.x und 10.x unterstützt. Ich konnte den Client jedoch auch problemlos unter Ubuntu 14.01.1 LTS installieren.

Dazu habe ich einfach das Installationsskript vpnsetup.sh heruntergeladen, ausführbar gemacht und ausgeführt.

:~$ wget https://github.com/Tronde/Schriftrolle/blob/master/vpnsetup.sh
:~$ sudo chmod u+x vpnsetup.sh
:~$ sudo ./vpnsetup.sh

Ist das Setup durchgelaufen, kann der Client aus dem Anwendungsmenü heraus gestartet werden.

cisco anyconnect secure mobility client

Cisco AnyConnect Secure Mobility Client

In das Feld „Connect to“ müsst ihr nun nur noch eureb Verbindungsserver eintragen und schon kann es losgehen.

Die Installation ist damit abgeschlossen. Das war es schon. :-)

Das lokale Paketarchiv aufräumen

Während ich im Artikel „Automatische Installation von Sicherheitsupdates“ beschrieben habe, wie man Sicherheitsupdates unter Ubuntu automatisch installieren lassen kann, werde ich hier kurz beschreiben, wie das lokale Paketarchiv automatisch bereinigt werden kann.

In der Datei /etc/apt/apt.conf.d/10periodic gibt es unter anderem den folgenden Eintrag:

APT::Periodic::AutocleanInterval "0";

Dieser Wert gibt an, in welchem Intervall (in Tagen) das lokale Archiv der Paketquellen bereinigt werden soll. Dieser Wert steht standardmäßig auf „0“. Damit wird das Paketarchiv gar nicht automatisch bereinigt. Um dies zu ändern trägt man hier einfach einen Wert seiner Wahl ein. So lasse ich das Paketarchiv bspw. alle 28 Tage bereinigen:

APT::Periodic::AutocleanInterval "28";

Viele Grüße
Tronde

Installation von VMware Tools in einer Ubuntu VM

Update 2021-06-09

Um den Netzwerkadapter VMXNET3[1. Choosing a network adapter for your virtual machine (1001805)] in einem virtuellen Ubuntu verwenden zu können, müssen die VMware Tools installiert sein. In den aktuellen Versionen von Ubuntu und weiteren Distributionen wie z.B. RHEL, SLES, etc. sind inzwischen Treiber für die VMXNET3-Netzwerkkarte enthalten. Dennoch ist die Installation der VMware Tools empfohlen.
Dieser Artikel beschreibt zwei Methoden, wie dies getan werden kann. Ich gehe dabei ausschließlich auf die Installation unter Verwendung der Kommandozeile (CLI) ein.

Methode 1 – Open-VM-Tools

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB2073803[2. VMware support of open-vm-tools (2073803)].

Bei den open-vm-tools handelt es sich um die Open Source Implementierung der VMware Tools. Die Vorteile dieser Implementierung sind:

  • Die Open-VM-Tools sind in den offiziellen Paketquellen von Ubuntu enthalten. Dadurch wird das Deployment von virtuellen Ubuntu VMs entschieden vereinfacht. Die Installation kann direkt aus den Quellen durchgeführt werden. Es muss nicht auf separate Quellen zurückgegriffen werden.
  • Keine Downtime für das Update der VMware Tools. Das Paket open-vm-tools wird automatisch über die Paketverwaltung aktualisiert.
  • Keine Kompatibilitätsprüfung erforderlich. Aus den Paketquellen wird automatisch das zum Betriebssystem passende Paket installiert.

Die Installation der Tools ist denkbar einfach und geschieht z.B. mittels:

sudo apt-get install open-vm-tools

VMware empfiehlt ausdrücklich die Verwendung der Open-VM-Tools.[3. VMware Tools in an Ubuntu 14.04 Guest] Wer sich über den aktuellen Entwicklungsstand der Open-VM-Tools informieren möchte, kann dies auch direkt auf GitHub tun. [4. https://github.com/vmware/open-vm-tools]

Methode 2

Diese Methode verbleibt der Vollständigkeit halber im Artikel. Es wird ausdrücklich Methode 1, wegen der dort genannten Vorteile, empfohlen.

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB1022525[5. Installing VMware Tools in an Ubuntu virtual machine (1022525)] und führt die einzelnen Schritte auf, die benötigt werden, um die VMware-Tools in einer VM mit Ubuntu zu installieren.

Abhängigkeiten der VMware-Tools

Um die VMware Tools installieren zu können, müssen folgende Pakete auf dem System installiert sein:

  • gcc
  • binutils
  • make
  • kernel sources

Installation auf der Kommandozeile

Als Erstes wird ein Rechtsklick auf die VM in der Bestandsliste des vSphere-Clients ausgeführt. Aus dem Kontextmenü wählt man „Gast -> VMware Tools installieren/aktualisieren“.

In der laufenden Ubuntu-VM werden nun die folgenden Kommandos ausgeführt:

sudo mkdir /mnt/cdrom
sudo mount /dev/cdrom /mnt/cdrom
tar xzvf /mnt/cdrom/VMwareTools-.tar.gz -C /tmp/
cd /tmp/vmware-tools/distrib/
sudo ./vmware-install.pl -d

Nach Abschluss der Installation ist ein Neustart auszuführen. Nun kann anstatt des veralteten E1000 auch der aktuelle Netzwerkadapter VMXNET3 zur VM hinzugefügt und verwendet werden.

Testinstanz für einen WordPress Blog erstellen

Um Änderungen an der Konfiguration und den Dateien meines Blogs gefahrlos testen zu können, möchte ich eine Testinstanz meines Blogs einrichten. Die dazu erforderlichen Schritte werde ich in diesem Artikel dokumentieren.

Dieser Artikel ist keine Schritt-für-Schritt-Anleitung und kein Tutorial, welches man blind befolgen kann. So gehe ich hier z.B. nicht auf die allgemeine Webserverkonfiguration ein. Falls ihr hierzu Hilfe benötigt, schaut bitte in der offiziellen Dokumentation zu eurem Webserver nach.

Voraussetzungen

Ich betreibe meinen Blog bei einem deutschen Webhosting-Provider. Bei diesem habe ich über ein Kundencenter via FTP-Zugang Zugriff auf die Konfiguration und die Dateien meines Blogs.

Bei einem anderen deutschen Unternehmen betreibe ich noch einen Linux-Root-Server, welcher sich hervorragend eignet, um darauf eine Testinstanz einzurichten.

Daten sichern

Um die spätere Testinstanz mit den Daten des Live-Blogs füttern zu können, werden die Daten aus dem aktuellen Blog zuerst einmal gesichert.

Die Sicherung umfasst die Datenbank und das DocumentRoot des Blogs.

Zur Sicherung der Datenbank verwende ich das Tool MySQLDumper.[1. http://www.mysqldumper.de/] Mit diesem Werkzeug kann man über eine einfach zu bedienende Weboberfläche ein Backup seiner Datenbank erstellen. Dieses Backup wird anschließend zur weiteren Verwendung auf den lokalen Rechner heruntergeladen.

Im zweiten Schritt wird das DocumentRoot-Verzeichnis des Blogs gesichert. Hierzu nutze ich den FTP-Client FileZilla.[2. http://www.filezilla.de/]

Serverkonfiguration

Auf dem Linux-Root-Server laufen Ubuntu Server 14.04 LTS und der Webserver NGINX.[3. http://nginx.org/]

Für meine Webseiten verwende ich eine einheitliche Verzeichnisstruktur:

example.org/
├── logs
│   ├── access.log
│   └── error.log
└── public
    └── index.html

2 directories, 3 files

So wird für jede Webseite in separate Log-Dateien geschrieben, was eine Fehleranalyse deutlich erleichtern kann. Die Dateien der Webseite liegen im Verzeichnis public. Die Datei index.html stellt dabei aktuell nur einen Platzhalter dar, bis die gesicherten Daten des Live-Blogs eingespielt werden.

Den Platzhalter kann man nutzen, um zu testen, ob der Webserver korrekt konfiguriert ist und die im Verzeichnis public abgelegte Seite auch ausliefert.

Um die spätere Testinstanz über die gleiche URL aufrufen zu können, wie den Live-Blog, wird ein Eintrag in die /etc/hosts eingefügt. So erreicht man, dass die URL des Live-Blogs nun auf die IP-Adresse des Servers mit der Testinstanz zeigt.

Hat man alles richtig konfiguriert, wird man vom Webserver mit einem „Hallo Welt!“ begrüßt.

Zugriff beschränken

Während man eine neue Konfiguration testet, können Fehler passieren. Diese können zu Folge haben, dass der Blog nicht korrekt ausgeliefert wird. Für gewöhnlich ist nicht gewünscht, dass ein Benutzer dies sieht. Evtl. möchte man auch einfach nicht, dass Neuerungen zufällig schon von Besuchern entdeckt werden, bevor sie in den Live-Blog überführt wurden.

Daher scheint es sinnvoll den Zugriff auf die Testinstanz einzuschränken und einen Aufruf der Testinstanz erst nach erfolgreicher Authentifizierung mit Benutzername und Passwort zu erlauben.

Dazu eignet sich für NGINX-Benutzer das Modul ngx_http_auth_basic_module.[4. http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html] Nutzer von Apache können .htaccess-Dateien[5. .htaccess – Wikipedia] verwenden. Da ich selbst einen NGINX betreibe, gehe ich im Folgenden auf das zuerst genannte Modul ein.

Zuerst wird die .htpasswd-Datei erstellt, welche Benutzernamen und Passwort für die Authentifizierung enthält.

sudo touch /etc/nginx/conf.d/.htpasswd

Um das Passwort in verschlüsselter Form speichern zu können wird das Paket apache2-utils benötigt. Dieses enthält das Programm htpasswd, mit welchem Benutzername und Passwort erzeugt werden.

:~$ sudo htpasswd -c /etc/nginx/conf.d/.htpasswd BENUTZERNAME
New password: 
Re-type new password: 
Adding password for user BENUTZERNAME

Der Benutzer, unter dessen Kontext der Webserver (NGINX) läuft, muss Zugriff auf die .htpasswd erhalten.

:~$ sudo chown www-data:www-data /etc/nginx/conf.d/.htpasswd

Nun öffnet man die Konfigurationsdatei für die Testseite, welche für gewöhnlich unterhalb von /etc/nginx/sites-available/ liegt. Hier ist folgende Konfiguration zu integrieren:

location / {
    auth_basic           "Authentifizierung erforderlich!";
    auth_basic_user_file conf.d/.htpasswd;
}

auth_basic aktiviert die Überprüfung von Benutzername und Passwort. auth_basic_user_file gibt den Pfad an, wo die .htpasswd-Datei liegt, gegen die geprüft wird.

Mit einem „configtest“ kann man seine Konfiguration auf syntaktische Fehler überprüfen und bei Bestehen der Prüfung die Konfiguration neu laden.

:~$ sudo service nginx configtest 
 * Testing nginx configuration                    [ OK ] 
jkastning@rs212997:~$ sudo service nginx reload
 * Reloading nginx configuration nginx            [ OK ]

Ab jetzt fragt NGINX nach einem Benutzernamen und Passwort, bevor er die Webseite mit dem „Hallo Welt.“-Slogan ausliefert.

Daten einspielen

Wenn der Webserver prinzipiell mit dem weiter oben erstellten vHost funktioniert und die „Hallo Welt.“-Seite ausliefert, werden als nächstes die Daten aus dem Live-Blog eingespielt.

Dazu werden der Datenbank-Dump und das im ersten Schritt gesicherte Verzeichnis auf den Linux-Root-Server hochgeladen. Ich habe dazu wieder FileZilla und das SFTP-Protokoll genutzt.

DocumentRoot

Die gesicherten Dateien und Verzeichnisse, müssen in das DocumentRoot-Verzeichnis der Testinstanz kopiert werden. In meinem Beispiel ist das das Verzeichnis /var/www/example.org/public/. Mit folgendem Befehl wird sichergestellt, dass der Webserver auch alle Dateien lesen kann.

sudo chgrp -R www-data /var/www/example.org/public

Die Datenbank

Bevor die Datenbanksicherung eingespielt werden kann, muss eine Datenbank und ein Datenbankbenutzer angelegt werden.

Wer hierbei Hilfe zur Syntax benötigt, kann im Artikel „Häufig verwendete MySQL-Befele“ nachlesen.

Ist dies erledigt, kann die Datenbanksicherung mit folgendem Befehl eingespielt werden.

mysql -u root -p db_name < db_sicherung.sql

Ober der angelegte Benutzer auch wirklich Zugriff auf die Datenbank hat, kann man mit dem folgenden Befehl überprüfen. Wenn alles stimmt, kann man sich so an der Datenbank anmelden.

mysql -u db_benutzer -p db_name

Fertig. Mein Testblog läuft und ich kann mich jetzt daran machen, mit der WordPress-Konfiguration zu experimentieren. :-)

Update vom 24.12.2016

Bei der gestrigen Aktualisierung der Testinstanz musste ich feststellen, dass zwar die Startseite des Blogs geladen wird, jedoch alle Artikelaufrufe in einen 404-Fehler laufen.

Die Ursache für diese Fehler liegt darin begründet, dass ich mit Nginx einen anderen Webserver verwendet, als mein Webhoster. Dieser behandelt die Permalinks von WordPress anders, als z.B. ein Apache-Webserver mit dem Modul mod_rewrite.

Eine Lösung für dieses Problem habe ich ziemlich schnell in der Nginx Library[6. Nginx Library - WordPress Permalinks {en}] gefunden. Es wird die try_files-Direktive[7. Nginx try_files directive {en}] verwendet, um aufgerufene URLs zur weiteren Behandlung an die index.php von WordPress weiterzuleiten.

Die Einrichtung ist relativ einfach. Das Vorgehen unterscheidet sich, je nach dem ob WordPress direkt im Wurzelverzeichnis einer Domain oder in einem Unterverzeichnis installiert ist. Im Folgenden werden beide Fälle betrachtet.

WordPress im Wurzelverzeichnis

Liegt die WordPress-Installation im Wurzelverzeichnis der Domain z.B. unter http://www.example.com, sucht man in der Konfigurationsdatei der Seite nach dem Block location /. Diesem Block wird folgende Zeile hinzugefügt:

try_files $uri $uri/ /index.php?$args;

Der vollständige Block sollte anschließend wie folgt aussehen:

location / {
    index index.php index.html index.htm;
    try_files $uri $uri/ /index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.

WordPress in einem Unterverzeichnis

Liegt die WordPress-Installation in einem Unterverzeichnis der Domain z.B. unter http://www.example.com/wordpress, muss der Konfigurationsdatei ein Block nach dem Muster location /wordpress/ hinzugefügt werden, welcher wie folgt aussieht:

location /wordpress/ {
  try_files $uri $uri/ /wordpress/index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.