Dieses Tutorial ist VALID.

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Haftungsausschluss / Disclaimer

Debian 10 (Buster) Installation Teil 2 – Basissystem einrichten

Weitere Systemeinstellungen

Tools nachinstallieren, Update-Script anlegen und ausführen

Das Post-Install-Script von Netcup hat ja die Installation von Debian 10 auf den neuesten Stand gebracht. Wir holen uns jetzt ein paar Tools dazu, die wir später brauchen, und legen ein Update-Script an, um Updates in Zukunft schneller durchzuführen. Außerdem erstellen wir auch gleich noch ein “Backup”-Verzeichnis.

apt install --no-install-recommends -y debian-goodies curl pwgen htop apache2-utils unzip mc lnav rsync

nano ~/upup-system.sh
#!/bin/bash
apt update
apt upgrade
apt autoremove
checkrestart
## Speichern mit "Strg+x" und "y"

chmod 700 ~/upup-system.sh
./upup-system.sh

mkdir /var/backup

Hostname und Hosts einrichten

Wenn wir unseren Server auf eine Domain laufen lassen möchten, dann richten wir den “Hostname” und die “Hosts-Datei” entsprechend ein. Mit dem Tool “hostctl” können wir den Hostname schnell und einfach setzen. Die “Hosts”-Datei ändern wir klassisch mit dem Editor. Es kommt aber nur eine Zeile mit dem Domainnamen und der IP des Servers hinzu.

hostnamectl set-hostname xp-server.de

hostnamectl

   Static hostname: xp-server.de
         Icon name: computer-vm
           Chassis: vm
        Machine ID: a6d392...
           Boot ID: 154d2a...
    Virtualization: kvm
  Operating System: Debian GNU/Linux 10 (buster)
            Kernel: Linux 4.19.0-5-amd64
      Architecture: x86-64

nano /etc/hosts
## unter die 127.0.0.1 - Anweisung anfügen (Bitte Deine IP und Deinen Hostname eintragen :))
94.16.119.127     xp-server.de     xp-server
## Speichern mit "Strg+x" und "y"

Die IP und der Hostname müssen natürlich von Deiner Maschine sein… :)

Unattended Upgrades

Damit Debian 10 auch ohne unser Zutun mit wichtigen Sicherheitsupdates versorgt wird, aktivieren wir die “Unattended Upgrades”:

apt install -y unattended-upgrades apt-listchanges
dpkg-reconfigure -plow unattended-upgrades
### [Ja] / [Enter]

cat /etc/apt/apt.conf.d/20auto-upgrades
### Beide Werte müssen auf "1" stehen, dann laufen die Updates:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Rotierte LOGs komprimieren

nano /etc/logrotate.conf
# uncomment this if you want your log files compressed
compress

Also den “Hash” vor “compress” löschen und mit “Strg+x” und “y” speichern…

Terminal in Farbe und weitere nette Einstellungen

Damit die Ausgabe auf dem Schirm ein wenig farbenfroher wird, geben wir der “Bash” ein paar Einstellungen mit auf den Weg. Wir legen auch gleich einen “Shortcut” für “docker-compose” an, damit wir später nur noch “dco” tippen brauchen.

Nach dem Öffnen von “.bashrc” löschen wir mit einigen “Strg+k” erst mal den ganzen Inhalt und ersetzen ihn mit folgenden Anweisungen:

nano ~/.bashrc

## Start
# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

# don't put duplicate lines or lines starting with space in the history.
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color) color_prompt=yes;;
esac

force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
        # We have color support; assume it's compliant with Ecma-48
        # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
        # a case would tend to support setf rather than setaf.)
        color_prompt=yes
    else
        color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    alias grep='grep --color=auto'
fi

alias dco=docker-compose
##EOF

Anzeige *

21 Kommentare zu „Debian 10 (Buster) Installation Teil 2 – Basissystem einrichten“

  1. Tilmann Rückauer

    Vielen Dank für dieses sehr gut verständliche Tutorial! Es wird dem erklärten Anspruch (alle Schritte von A-Z erläutern) gerecht.

    Ich bin gerade noch in der Entschlussphase, habe es also bislang nur theoretisch nachgespielt. Dabei ist mir die Frage gekommen, warum die Entscheidung bei einem Versionen-basierten System wie Debian (nicht rolling-release wie Arch Linux, das ich privat verwende), was ja für einen Server eine sehr richtige Wahl ist, bei der Partitionierung eine einzelne große Partition gewählt werden soll, anstatt dass eine Partition für / (root) und eine weitere für /home und /var erstellt wird? Sollte dann mal ein Versions-Upgrade von Buster auf Bullseye durchzuführen sein, bleibt bei getrennten Partitionen die zweite Partition vom Upgrade unangetastet. Gut, die ganzen Dotfiles sollte man vorher trotzdem sichern, wenn die Einstellungen hinterher wieder gleich sein sollen. Wie siehst Du das?

    Nochmals vielen Dank!
    Tilmann

    1. Peter Fiedler

      Hallo Tilmann,
      danke für Deinen Beitrag!

      Hmm… Du hast recht, ich muss dringend im Vorspann meine Server-Situation näher erklären. Daraus ergibt sich dann, warum ich das so mache, wie ich es mache:

      Mit Arch hatte ich ein traumatisches Erlebnis. Server Purge. Alles hin. Ganz normal Updates gezogen, installiert, Start – Kaputt. Ein Verschlüsselungsmodul hat sich da getauscht, ich konnte nicht mehr entschlüsseln und aus die Maus.

      Debian und Ubuntu haben ja gute 5 Jahre Laufzeit, in denen die Version Support erfährt. Und danach steht bei mir sowieso ein neuer Server an, weil die Hardware sich in der Zeit dramatisch weiterentwickelt hat und man fürs gleiche Geld die dreifache Leistung bekommt – oder halt für einen ähnlichen Server weniger zahlen muss.
      Warum ich selten die ganze Support-Zeit ausgereizt hab, war schlicht die Tatsache, dass irgendwann eine Bibliothek des Kernsystems veraltet und nicht mehr gepatcht wird. PHP 5.6 war damals so ein Fall. Da muss man dann auf ein aktuelles Betriebssystem zwangsumsteigen.
      Aber genau hier kommt das Docker-Prinzip ins Spiel! Und aus dem Grund ist mir die Umgebung vom Host auf einmal nicht mehr wichtig. So lange das System noch Sicherheitsupdates bekommt, bin ich glücklich. PHP ist in den Containern aktuell. Genau wie die Datenbank und der Webserver.

      Für mich macht es daher keinen Sinn, die Verzeichnisse in Partitionen zu unterteilen, weil ich sowieso kein Update des Betriebssystems machen werde. Am Laufzeitende stirbt es zusammen mit dem Server. Und ein neuer Server wird geboren, der dann wieder fünf Jahre halten wird. So Gott will :)

      Wenn jemand einen anderen Update-Zyklus fährt oder die Partitionen entsprechend anlegen möchte, kann er das natürlich gerne machen. Aber für meinen Fall macht es, wie dargelegt, halt keinen Sinn.

      Beste Grüße
      Peter.

      1. Tilmann Rückauer

        Guten Abend, Peter,

        danke sehr für die Erklärungen. Wieder mal sehr verständlich (anders als meine verschachtelten Sätze…). Ich plane nicht, Arch für den Server zu nehmen, dafür ist Debian tatsächlich besser geeignet. Und ich hatte den langen Support für die Server-Version ausgeblendet, das ist natürlich in Kombination mit der technischen Weiterentwicklung ein echtes Argument.
        Da ich bisher mit Docker nicht gearbeitet hatte, war mir auch nicht bewusst, dass die darin enthaltenen Komponenten unabhängig vom zugrundeliegenden Basissystem aktuell gehalten werden. Mir war nur bewusst, dass sich die unterschiedlichen Docker-Container nicht wechselseitig beeinflussen. Gutes Konzept.

        Danke + Gruß
        Tilmann

  2. Moin Peter
    da ich win nur auf einem Noti habe und seit letzen November linuxmint benütze, habe ich Probleme die Schlüssel von Putty zu übernehmen.
    In der Linux-Konsole komme ich vor der Absicherung des Ports problemlos rein.
    Dann aber abgesichert erscheint direkt nach dem Befehl:
    ssh root@192.168.1.130 -p 44422 die Antwort
    root@192.168.1.130: Permission denied (publickey).
    Wie muss ich das in der Linux-Konsole händeln, damit es klappt?

    1. Hallo Jakob,
      Du musst dem ssh-Befehl auch den Schlüssel an die Hand geben.
      Wenn Du Deine Schlüssel im .ssh Ordner von Root abgelegt hast, sollte der Befehl wie folgt heißen:

      ssh -i ~/.ssh/id_rsa[bzw-wie-du-deinen-schlüssel-genannt-hast] -p 44422 root@192.168.1.130

      Beste Grüße
      Peter.

      1. Du erstellst ja irgendwo das Schlüssel-Schloss-Paar.
        Die Datei, die dabei raus kommt, die musst Du in das .ssh Verzeichnis legen. Und mit chmod 600 absichern.

  3. Norbert Schmidt

    Ich habe mir auf einem VPS einen Teil Deiner Installation, also Traefik, Nextcloud und WordPress installiert. Ich wundere mich aber warum Du an keiner Stelle eine Firewall einrichtest??
    Ich habe mir dann UFW so eingerichtet, wie ich es für andere Linux Server auch getan hätte, bin dann aber darüber gestolpert, dass Docker die Regeln der UFW außer Kraft setzt und die UFW somit nicht wirklich die Docker Container schützt.
    Von Extern konnte ich per Telnet server.mydomain.de 49156 direkt auf meinen Nextcloud Server zugreifen unter Umgehung von traefik.
    Tante Google sagt mir dazu, dass dies ein bekanntes Problem ist, aber eine Dummylösung noch nicht wirklich vorhanden. Was ist Deine Meinung? Brauche ich bei Deinem Setup keine Firewall?
    Gruß
    Norbert

    1. Hallo Norbert,
      wie ich im Tutorial geschrieben habe, verwendete ich früher eine Shorewall, um Docker nach außen zu schließen. Was aber alles andere als “gut” funktioniert hat.

      Sicherheit ist durchaus wichtig. Aber was hilft es, wenn der Container direkt von außen erreichbar ist? Das ist auch nichts anderes, als wenn er über Traefik durchgereicht würde. Eine Sicherheitslücke in der Anwendung kann auf die eine wie auf die andere Weise ausgenutzt werden. Die Nextcloud blockt eine Verbindung über “IP:Port” ab, weil diese Verbindung nicht als “vertrauensvolle Domain” konfiguriert ist. “Subdomain.Domain:Port” lässt die Verbindung nicht zu, weil kein SSL-Tunnel aufgebaut werden kann.

      WordPress das Gleiche in gelb.

      Die Datenbank wäre eventuell gefährlich. Aber die wird nur auf das Loopback-Device auf dem Host gelegt und nicht geroutet.

      Klar wäre mir eine Firewall auf dem Server lieber. Aber ich hab kein vernünftiges Vorgehen dafür gefunden. Und alle anderen Tutorials, die ich besucht habe, lassen Docker auch so auf dem Server laufen.

      Solltest Du über eine Anleitung stolpern, wie man eine Firewall in das Setup integriert bekommt, wäre ich Dir für einen Hinweis sehr dankbar…

      Beste Grüße
      Peter.

  4. Kleiner Vertipper gefunden: Benutzer zulegt und dann jedes Mal mit „sodo“ die nötigen Berechtigungen erlangt.
    Soll wohl nicht “sodo”, sondern “sudo” heißen.

    1. Das ist absolut korrekt, da hab ich mich verhaut! Vielen Dank für den Hinweis…
      Ist echt einer meiner “Standard-Vertipper” :/

  5. Vielen Dank für die Howtos, tolle Arbeit und sehr versändlich.

    … aber ;-) :
    Warum installierts du noch den NTP-Server? Die Maschine wird doch mit dem Systemd-Timesync aktuell gehalten. Ist das dann nicht Doppelt, da ja auch der ntp die Urzeit stellen kann?

    1. Peter Fiedler

      Hallo Sven,
      danke für Deine Rückmeldung!

      Einen Server hatte ich, da lief die Uhrzeit wirklich nicht synchron, was allerlei seltsame Fehler provoziert hat.
      Seit ich zusätzlich den ntp (oder ganz neu: Chrony) installiert hab, hatte ich keine Probleme mehr.

      Beste Grüße
      Peter.

      1. Moin Peter,
        dann lieber Chrony anstelle von ntp, da Chrony keine Ports nach außen öffnet. und dann kann man auch den systemd-timesyncd abschalten.

        viele Ostergrüße
        Sven

  6. Nice, Herzlichen Dank, bis auf den Hostnamen ändern, (werde ich machen wenn ich es brauche) hat alles wunderbar Funktioniert, Vielen Vielen Dank
    etz muss ich nur noch CSGO zum laufen bringen mit Docker, dann ist alles Perfekt :D

    1. Hallo Rainer,
      vielen Dank für das Lob!
      Hoffe, dass deine restliche Installation auch noch einwandfrei läuft :)
      Liebe Grüße
      Peter.

      1. Hi, ich hab ein Problem mit der Blauen Schrift, meine Augen sind nicht mehr die Besten, kannst du Bitte die Blaue Farbe in etwas Blaueres ersetzen?
        müsste ja :
        PS1=’${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ ‘ hier sein oder ?
        Wenn ich nun die Blaue mit Cyan auswechseln möchte, muss ich da denn die 34m mit 36m ersetzen oder?

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Verwendung
von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Scroll to Top