Geschrieben am

ISPConfig Multi-Server Anleitung auf Debian 9 mit dediziertem Web-, Mail-, NS1-, NS2-, Datenbank-Server

Damit ISPConfig ordentlich arbeiten kann, muss die dash einmal nach bash umgestellt werden. Das machen wir mit:

dpkg-reconfigure dash
Use dash as the default system shell (/bin/sh)? <== No

Anschließend werde ich die Locales mithilfe von:

dpkg-reconfigure locales

rekonfigurieren, diese Fehlermeldung zu beseitigen.

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_PAPER = "de_DE.UTF-8",
	LC_ADDRESS = "de_DE.UTF-8",
	LC_MONETARY = "de_DE.UTF-8",
	LC_NUMERIC = "de_DE.UTF-8",
	LC_TELEPHONE = "de_DE.UTF-8",
	LC_IDENTIFICATION = "de_DE.UTF-8",
	LC_MEASUREMENT = "de_DE.UTF-8",
	LC_TIME = "de_DE.UTF-8",
	LC_NAME = "de_DE.UTF-8",
	LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory

Die Abfragen beantworte ich folgendermaßen:

Locales to be generated: <== All locales
Default locale for the system enviroment: <== en_US.UTF-8

Das dauert einen Moment. Zeit für Kaffee.

Anschließend installiere ich die letzten Updates mit:

apt update && apt upgrade -y

Damit der Server selber weiß in welcher Zeitzone er sich befindet, konfiguriere ich diese einmal neu mit:

dpkg-reconfigure tzdata
Geographic area: <== Europe
Time zone: <== Berlin

Damit die Uhrzeit immer synchron gehalten, und weil auf allen Servern Fail2Ban und die Ubuntu Firewall UFW gebraucht wird, installieren wir auf allen Servern einmal:

apt install ntp ntpdate fail2ban ufw -y

ISPConfig kann nicht so sehr gut mit AppArmor und deshalb stelle ich es wie folgt ab:

service apparmor stop
update-rc.d -f apparmor remove
apt remove apparmor apparmor-utils

Dann starte ich alle Maschinen einmal neu um ggf. die letzten Kernel Updates zu aktivieren.

reboot

Nach dem die Server wieder erreichbar sind, entferne ich unnötige Pakete mit:

apt autoremove -y

Auf allen Servern werde ich MariaDB als client und als Server benötigen. Deswegen installiere ich MariaDB schonmal auf allen Maschinen mit:

apt install mariadb-client mariadb-server

Um sicher zu stellen, dass ein Zugriff von Außen möglich ist, kommentiere ich „bind-address = 127.0.0.1“ in der MariaDB Konfiguration auf allen Maschinen aus.

nano /etc/mysql/mariadb.conf.d/50-server.cnf
[…]
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
# bind-address           = 127.0.0.1
[…]

Um MariaDB zu konfigurieren, führe ich ein:

mysql_secure_installation

aus, und mache folgende Angaben:

Enter current password for root (enter for none): <== Enter
Set root password? [Y/n] <== Enter
New password: <== Passwort für den DB Root des jeweiligen Servers eintragen
Re-enter new password: <== Passwort für den DB Root des jeweiligen Servers wiederholen
Remove anonymous users? [Y/n] <== Enter
Disallow root login remotely? [Y/n] <== Enter
Remove test database and access to it? <== Enter
Reload privilege tables now? [Y/n] <== Enter

Und starte MySQL einmal neu mit:

service mysql stop && service mysql start

Damit ist die Vorbereitung der Server abgeschlossen.

 

 

Geschrieben am

Piwik Datenbank verkleinern

In der derzeitigen Version 1.2 von Piwik ist noch kein automatisches Bereinigen der durchaus richtig groß werdenden Datenbanktabellen log_link_visit_action und log_visit integriert. Laut Entwickler-Bereich ist dies aber in Planung. Je nach Besucherzustrom auf den zu trackenden Webseiten können diese – wie in diesem Beispiel – mehrere Millionen Einträge erzeugen und somit die MySQL-Datenbank mehrere Gigabyte groß werden lassen. Das ist natürlich auch dann problematisch, wenn die Festplattenkapazität zwar an den Terrabyte-Bereich kratzt und ein paar Gigabyte Datenbank-Speicher nichts ausmachen, aber spätestens ein endlos dauernder Datenbank-Dump bei der Datensicherung oder der Traffic zum Backup-System bringen auch größere Server-Umgebungen an ihre Leistungsgrenzen.

Dieser Artikel soll als Anleitung dienen, um die Datenbankgröße in einem vernünftigen Rahmen zu halten. Im Piwik-Forum sowie in den Piwik-FAQ ist diese Vorgehensweise ebenso beschrieben. Die erste Anregung mich mit diesem Thema intensiver auseinander zu setzen, bekam ich auf dem Blog vom pcdoc. Das Vor-sich-herschieben hatte somit ein Ende!

  1. Datenbankgröße
  2. Automatische Archivierung einrichten
  3. SQL zum Bereinigen der Logeinträge
  4. Löschen alter Archiv-Tabellen
  5. Speicherfresser access_logs

Datenbankgröße auf 6 Gigabyte angewachsen

Die Gesamtgröße der Datenbank ist bei meiner Installation auf über 6 Gigabyte angewachsen. Allein die Tabelle log_link_visit_action hat über 22 Millionen Einträge und das Backup der Piwik-Datenbank nimmt somit jede Nacht eine ganze Menge Ressourcen in Anspruch. Probleme bei den Piwik-Laufzeiten konnte ich auf einem Hetzner EQ6 Server allerdings noch nicht feststellen. Seit über 2 Jahren werden rund 20.000 Besucher am Tag erfasst und nun ist es an der Zeit ein wenig aufzuräumen.

Die Piwik Datenbank

Cronjob zum Archivieren der Berichte einrichten

In den allgemeinen Piwik-Einstellungen wird darauf hingewiesen, dass größere Installationen die Berichterstellung nicht im Browser sondern per Cronjob ablaufen lassen sollten. Ab wann die Bezeichnung „groß“ zutrifft wird an dieser Stelle nicht verraten. Allerdings macht die Einrichtung eines Cronjobs keine Arbeit und somit spricht aus meiner Sicht nichts gegen dessen standardmäßige Nutzung.

Piwik Berichterstellung per Cronjob
Die Piwik-Installation bringt ein unter misc/cron liegendes Shell-Script namens archive.sh mit. Dieses lässt sich automatisch per Cronjob ausführen (z.B. jede Stunde oder einmal am Tag). Wer bereits mein Rechte-Script für Piwik nutzt, hat in diesem Script bereits das benötigte Ausführungsrecht für den Webserver-User (bei mir www-data) für diese Datei gegeben. Ansonsten könnt ihr dies natürlich auch per Hand setzen, sicherlich bei den meisten 755.

Ein Cronjob lässt sich auf einem root-Server unkompliziert auf der Kommandozeile einrichten. Der hier aufgeführte wird alle 6 Stunden gestartet.

~# crontab -e -u www-data

* */6 * * * /euer/pfad/zu/piwik/misc/cron/archive.sh &gt; /dev/null

Sicherlich lässt sich dies auch über die Oberflächen der verschiedenen ISP regeln, da hilft fast immer ein Blick in die Anleitung, in die FAQ oder ein Anruf beim Support. Ein manuelles Ausführen der Archivierung bzw. der Test, ob alles reibungslos funktioniert, lässt sich auf der Linux-Shell mit dem folgenden Aufruf realisieren.

~# su www-data -c &quot;sh /euer/pfad/zu/piwik/misc/cron/archive.sh&quot;

Wenn alles funktioniert, dann erfolgen einige XML-Ausgaben und die abschließende Meldung: Finished Scheduled tasks.

SQL-Aufruf zum Säubern der Log-Einträge

In den Piwk-FAQ #42 wird auf das Thema Piwik-Logs bereinigen eingegangen. Von dieser Seite stammt auch der hier aufgeführte MySQL-Aufruf, der z.B. im phpMyAdmin ausgeführt werden kann und alle Logs, die älter als 30 Tage sind, löscht.

DELETE piwik_log_visit, piwik_log_link_visit_action

FROM piwik_log_visit INNER JOIN piwik_log_link_visit_action

WHERE piwik_log_visit.idvisit = piwik_log_link_visit_action.idvisit

AND visit_first_action_time &lt;= DATE_SUB(CURDATE(), INTERVAL 30 DAY);

OPTIMIZE TABLE piwik_log_visit, piwik_log_link_visit_action;

Oder direkt auf der Linux-Shell, was ich aufgrund der Datenmenge bei meiner Installation angewandt habe:

1 ~# mysql -udatenbankuser -p
2 Enter password:*****
3 mysql&gt; use piwik;
4 mysql&gt; DELETE piwik_log_visit, piwik_log_link_visit_action
5     -&gt; FROM piwik_log_visit INNER JOIN piwik_log_link_visit_action
6     -&gt; WHERE piwik_log_visit.idvisit = piwik_log_link_visit_action.idvisit
7     -&gt; AND visit_first_action_time &lt;= DATE_SUB(CURDATE(), INTERVAL 30 DAY);
8 mysql&gt; OPTIMIZE TABLE piwik_log_visit, piwik_log_link_visit_action;

Das Ergebnis sind zwei immens verkleinerte Tabellen.

Datenbank-Speicherplatz veringert
Die bereits verarbeiteten und archivierten Berichte werden hierbei nicht gelöscht. Es ist aber darauf zu achten, dass die Archivierung auch wirklich durchgeführt wurde.

Löschen alter Archiv-Tabellen

Wer die Piwik-Datenbank noch mehr verkleinern möchte, kann alte Archiv-Tabellen löschen. Die Tabellen heißen archive_blob_YYYY_MM und archive_numeric_YYYY_MM. Hier sind die Berichte aller Webseiten, in denen Piwik eingebunden ist, gespeichert. Wenn man die Daten nur für die vergangenen 12 Monate benötigt, spricht nichts dagegen ältere Tabellen einfach zu löschen. Ein vorheriges Wegsichern bietet natürlich die Möglichkeit, irgendwann einmal diese zurück zu spielen. Ebenso könnte man diese in eine lokale Piwik-Installation kopieren und hätte so aus seiner Entwicklungsumgebung o.ä. heraus immer Zugriff auch auf ältere Datenbestände.

Speicherfresser access_logs

Schnell übersehen könnte man bei einem eigenen Hosting von Piwik, dass der Apache eine access- und error-Logdatei anlegt und diese mit jedem Zugriff auf den Piwik-JavaScript-Code fleißig befüllt. Dieses Logging habe ich nur die ersten Tage nach der Inbetriebnahme von Piwik genutzt oder wenn nach einem Update Probleme auftraten. Ansonsten macht das keinen Sinn. Ebenso würde man hiermit natürlich nicht mehr den hier beschriebenen Vorgehen beim Thema Datenschutz entsprechen, da standardmäßig die IP-Adressen in diesen Dateien gespeichert werden.

Geschrieben am

Täglicher Update-Check für Linux

Kaum eine Aufgabe ist für uns Administratoren so wichtig, wie die stetige Aktualisierung unserer Linux-Server. Ohne regelmässige Updates drohen Schwachstellen installierter Software zum Einfallstor für Angreifer zu werden. Das manuelle Aktualisieren der Software wird in der Praxis jedoch schnell vergessen. Deshalb benötigen Sie ein Werkzeug, das diese Aufgabe automatisch für Sie übernimmt. Mit dem Tool cron-apt steht Ihnen ein solches Werkzeug für Debian-Linux zur Verfügung.

Funktionen: cron-apt benachrichtigt Sie bei Updates automatisch

cron-apt basiert auf dem „Advanced Packaging Tool“ (APT) von Debian. APT ist ein Paketverwaltungssystem, das für Sie neue Software (Pakete genannt) installiert und bestehende aktualisiert. Typische Befehle des APT sind z.B. „apt-get update“, um die Paketlisten neu zu laden.

cron-apt automatisiert die für ein Software-Update nötigen Schritte. Dafür prüft das Tool jede Nacht um 4.00 Uhr die vorhandenen Paketinformationen und aktualisiert die Paketlisten. Je nach Konfiguration lädt das Tool automatisch neue Pakete herunter, benachrichtigt Sie darüber per E-Mail und installiert sie automatisch.

Installation: Wie Sie cron-Apt einrichten

Um die praktische Update-Hilfe zu nutzen, richten Sie cron-apt wie folgt ein:

  1. 1. Installieren Sie das Debian-Paket mit dem Kommando: apt-get install cron-apt.
  2. 2. Öffnen Sie die Konfigurationsdatei „/etc/cron-apt/config“ mit vi /etc/cron-apt/config.
  3. 3. Entfernen Sie das Kommentarzeichen („#“) vor „MAILTO“. Tragen Sie Ihre E-Mail-Adresse hinter „MAILTO“ ein.
  4. 4. Entfernen Sie vor „MAILON“ ebenfalls das Kommentarzeichen und tragen Sie hier „upgrade“ ein. Falls auch ohne vorliegende Updates täglich informiert werden möchten, tragen Sie hier „always“ statt „upgrade“ ein.

Mit diesen vier Schritten haben Sie das Werkzeug so eingerichtet, dass es automatisch neue Pakete herunterlädt und sie per E-Mail informiert. Die Pakete werden jedoch nicht automatisch installiert; dies müssen Sie mit dem Kommando „apt-get upgrade“ selbst vornehmen.

Um sich von der sachgemässen Funktionalität von cron-apt zu überzeugen, geben Sie den Befehl cron-apt –s in Ihre Kommandozeile ein. Ihnen werden nun die zur Verfügung stehenden Updates für Ihre Pakete angezeigt. Gleichzeitig erhalten Sie Ihre erste E-Mail-Benachrichtigung.

Vorsicht bei automatischer Aktualisierung von cron-apt

cron-apt kann die vorhandenen Updates auch selbstständig einspielen, ohne auf Ihren Befehl zu warten. Dazu müssen Sie lediglich eine Änderung in der Datei „/etc/cron-apt/action.d/3-download“ vornehmen. Hier entfernen Sie den Parameter „-d“ im „dist-upgrade“-Befehl. cron-apt wird dann zukünftig Updates ohne vorherige Kontrolle installieren. Davon raten wir Ihnen jedoch ab, denn jedes Update birgt die Gefahr eines unerwünschten Verhaltens der Software oder gar eines Fehlers. Führen Sie eine Aktualisierung daher immer bewusst und kontrolliert selbst aus. Nach einer Benachrichtigung durch cron-apt wissen Sie, dass Sie aktiv werden müssen.