====== Ubuntu ======
Um einen Entwicklungsserver einzurichten habe ich bei Hetzner den kleinsten Cloud-Server angemietet und wie folgt eingerichtet.
Ubuntu 24.04 Minimalimage installieren

====== Bash als Default-Shell ======
<code bash>
dpkg-reconfigure dash
</code>
Select->No

====== Remove Snap ======
<code bash>
apt remove snapd -y --purge
</code>

====== MariaDB installieren ======
<code bash>
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash
apt install mariadb-client mariadb-server
</code>

====== Update und Autoremove ======
<code bash>
apt update
apt autoremove
</code>

====== Pakete installieren ======
<code bash>
apt install mc htop p7zip-full zip apache2 php8.3 libapache2-mod-php php-mysql letsencrypt ufw fail2ban
</code>

====== Apache konfigurieren ======
<code bash>
a2enmod rewrite
a2enmod headers
a2enmod ssl
</code>

<code bash>
cd /var/www/html
mkdir gp-admin
cd gp-admin
wget https://www.adminer.org/latest-mysql-de.php
mv latest-mysql-de.php gp-adminer.php
</code>

<code | /etc/apache2/conf-available/security.conf>
ServerTokens Prod
ServerSignature Off
RedirectMatch 404 /\.git
RedirectMatch 404 /\.svn
Header set X-Content-Type-Options: "nosniff"
Header set Content-Security-Policy "frame-ancestors 'self';"
</code>

<code>
systemctl restart apache2
</code>

====== Letsencrypt für eine Subdomain einrichten ======
<code bash>
a2enmod ssl
service apache2 restart
service apache2 stop
letsencrypt certonly -a standalone -d subdomain.domain.de
</code>

In der VHost-Config-Datei vom Webserver dann das Zertifikat hinterlegen: 

<code | /etc/apache2/sites-available/default-ssl.conf>
SSLEngine on
SSLCertificateFile    /etc/letsencrypt/live/subdomain.domain.de/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/subdomain.domain.de/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/subdomain.domain.de/fullchain.pem
</code>

<code bash>
service apache2 restart
</code>

===== Let's Encrypt Zertifikate erneuern =====

<code cron>
letsencrypt renew
</code>

====== Uncomplicated Firewall konfigurieren ======
Auf dem Server möchte ich nur SSH und den Webserver von außen erreichbar haben.
<code bash>
ufw allow ssh
ufw allow http
ufw allow https
ufw enable
ufw status
</code>

====== MariaDB von externer IP Zugriff erlauben und mit UFW absichern ======
Falls man einen Cloud-Server nur als Datenbankserver aufsetzen möchte, kann man den Zugriff von einer externen IP einrichten.

Bei Ubuntu 18.04 liegt die Konfigurationsdatei für MariaDB unter /etc/mysql/my.cnf \\
Dort einfach folgende Zeile auskommentieren: \\
<code | /etc/mysql/my.cnf>
bind-adress = 127.0.0.1
</code>
<code | /etc/mysql/my.cnf>
#bind-adress = 127.0.0.1
</code>
Danach MariaDB neu starten damit die Konfiguration aktiv wird.
<code bash>
service mariadb restart
</code>
Man könnte auch direkt eine IP angeben damit MariaDB nur an diese IP gebunden ist. Dies lösen wir aber durch die Firewall. \\
Warum? Um auf die DB von einer dynamischen IP zuzugreifen nutze ich ein Shellskript welches die Firewall um die dementsprechenden Regeln erweitert.

===== Benutzer für den externen Zugriff für eine DB einrichten =====
==== Benutzer und Datenbank anlegen ====

<code mysql>
mysql -u root -p
USE mysql;
SELECT User,Host FROM user;
CREATE user 'db-benutzername'@'%';
CREATE DATABASE 'datenbankname' COLLATE 'utf8_general_ci';
</code>

==== Zugriffsrechte des Benutzers für die Datenbank festlegen ====
<code mysql>
GRANT ALL PRIVILEGES ON datenbankname.* TO 'db-benutzername'@'192.168.100.%' IDENTIFIED BY 'mein-neues-passwort' WITH GRANT OPTION;
FLUSH PRIVILEGES;
SELECT User,Host FROM mysql.user;
</code>

Das %-Zeichen dient hier als Platzhalter für den jeweiligen Adressbereich. Also kann jede IP von 192.168.100.1-192.168.100.255 darauf zugreifen. \\
Der Benutzer kann hier von jeder beliebigen IP auf den MariaDB-Server zugreifen.
Möchte man das verhindern und diesen nur an eine IP binden muss man beim anlegen des Benutzers noch die IP festlegen.

==== Rechte entziehen ====
Um einem Benutzer alle Rechte zu entziehen sollte man folgendes ausführen
<code mysql>
REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'db-benutzername';
</code>

===== UFW einrichten =====

Zugriff zulassen:
<code bash>
ufw allow from 192.168.100.123 proto tcp to any port 3306
</code>
Zugriff entziehen
<code bash>
ufw delete allow from 192.168.100.123 proto tcp to any port 3306
</code>

===== AutoUpgrade =====
<code>
apt-get install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades
</code>
Interaktiver Dialogder die Datei: /etc/apt/apt.conf.d/20auto-upgrades mit folgendem Inhalt erstellt:
<code | /etc/apt/apt.conf.d/20auto-upgrades>
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
</code>
In: /etc/apt/apt.conf.d/50unattended-upgrades weitere Anpassungen tätigen. \\
Quelle: \\
https://help.ubuntu.com/community/AutomaticSecurityUpdates

===== System-E-Mails per SMTP verschicken =====

https://www.slicewise.net/debian/mta-fuer-system-mails-einrichten-ubuntudebian/

===== Journal-Log verkleinern =====

Auf jedem Server kann das Systemd-Journal viel Platz verbrauchen. Gerade bei Cloud-Servern ist dieser aber recht knapp bemessen. Weshalb man die Logs wie folgt verkleinern kann:

Mit folgendem Befehl können wir uns die Größe des Journal-Logs ansehen:
<code>
$ journalctl --disk-usage
Archived and active journals take up 1.9 GB in the file system.
</code>

Um das Journal jetzt auf die letzten 10 Tage zu beschränken führt man folgendes aus:

<code>
$ journalctl --vacuum-time=10d
....
....
Vacuuming done, freed 1.8G of archived journals from /var/log/journal/9d5dd813d72447108fe84a2f91af4384.
</code>

Nach dem aufräumen/löschen der Logs die älter als 10 Tage sind belegt das Journal nur noch 48 MB :-)
<code>
$ journalctl --disk-usage
Archived and active journals take up 48.0M in the file system.
</code>