crontab mit bash-Script

crontab kann per Bash-Script ausgeführt werden. In diesem Beispiel erstellen wir uns einen crontab, der jeweils um 23:30 Uhr auf unserem Rocket.Chat Server ein Backup erstellt.

# nano /etc/crontab
/etc/crontab zeigt beim ersten Aufruf die Tutorialseite an. Tippe hier die systemweiten crontab ein.

# /etc/crontab: system-wide crontab

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Starte Backup um 23:30 Uhr
30 23 * * * root bash /root/backup_chat.sh
# lösche Backups > 3 Tage. Überprüfe jeweils um 23:45 Uhr.
45 23 * * * root find /var/snap/rocketchat-server/common/backup/*.* -mtime +3 -exec rm {} \;
#

dieser crontab ruft somit um 23:30 Uhr das backup-Script backup_chat.sh auf. Das Script liegt hier unter /root/backup_chat.sh
#!/bin/bash
service snap.rocketchat-server.rocketchat-server stop
snap run rocketchat-server.backupdb
service snap.rocketchat-server.rocketchat-server start

das Script kann im Voraus noch geprüft werden:

# bash /root/backup_chat.sh
[*] Creating backup file...
[+] A backup of your data can be found at /var/snap/rocketchat-server/common/backup/rocketchat_backup_20231113.0944.tar.gz

grep und find

grep und find sind ideale Werkzeuge um nach einer Datei oder einem bestimmten Muster zu suchen. Typo3 schreibt z. B. folgende Konfiguration für die php.ini vor:

; memory_limit >= 256MB
memory_limit=256M

; max_execution_time >= 240 seconds
max_execution_time=240

; max_input_vars >= 1500
max_input_vars=1500

falls wir jetzt keinen Plan haben, wo wir diese Einstellungen finden, hilft uns grep und find. Mittels grep finden wir das Suchmuster in der Datei. find findet uns die Datei php.ini, falls wir nicht wissen, wo diese abgelegt ist.

# grep -r memory_limit * /etc

/etc/php/8.2/cli/php.ini:memory_limit = -1
/etc/php/8.2/apache2/php.ini:memory_limit = 512M

oder

# find . /etc -name php.ini

/etc/php/8.2/cli/php.ini
/etc/php/8.2/apache2/php.ini

SSH-Keys generieren und verwenden

Normalerweise erstellt der Befehl ssh-keygen einen Schlüssel id_rsa unter dem Home Verzeichnis. Was aber, wenn wir mehrere SSH-Keys verwenden wollen? Den SSH-Key erstellen wir hier für einen normalen Benutzer und niemals für root!

Server IP: 123.45.678.90
Benutzer: USER
SSH-Key: id_rsa_local

auf dem Server (hier die IP 123.45.678.90)

Erstelle mittels ssh-keygen den Schlüssel (hier id_rsa_local) und kopiere diesen mittels cat nach ~/.ssh/authorized_keys

$ ssh-keygen -m PEM -t rsa -b 4096
$ cat ~/.ssh/KEYNAME.pub | ssh USER@123.45.678.90 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

läuft der Server auf einem anderen Port als 22, ist der Port (hier 1004) anzugeben:

$ cat ~/.ssh/KEYNAME.pub | ssh USER@123.45.678.90 -p 1004 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
$ ssh-keygen -m PEM -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/USER/.ssh/id_rsa): /home/USER/.ssh/id_rsa_local
  (...)
  (...)
  (...)
$ cat ~/.ssh/id_rsa_local.pub | ssh USER@123.45.678.90 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
The authenticity of host '123.45.678.90 (123.45.678.90)' can't be established.
ED25519 key fingerprint is SHA256:bL8trr2HdSSw777CXIanpYeXvo1826v1Kj78UMa5NtE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '123.45.678.90' (ED25519) to the list of known hosts.
USER@123.45.678.90's password: DEIN USER PASSWORT

Nun lassen wir uns den SSH-Key anzeigen und kopieren diesen Schlüssel auf unseren Client-PC:

$ less ~/id_rsa_local

Client PC

auf dem Client PC benötigen wir den ssh-key und ein config-File. Der ssh-key (hier id_rsa_local) muss die Berechtigung 600 haben. Diese Berechtigung ist per root zu setzen:

# chmod 600 /home/BENUTZER/.ssh/id_rsa_local

Erstelle unter ~.ssh ein config File mit:

$ nano ~/.ssh/config

# ssh configuration file
# BEISPIEL / EXAMPLE
# HostName = IP Adresse des Servers, z.B. 123.45.67.890

Host local
HostName 123.45.678.90
Port 123456
User USER
IdentityFile ~/.ssh/id_rsa

Host mailserver
HostName 25.10.200.4
Port 22
User dana
IdentityFile ~/.ssh/id_rsa_mailserver

Host backupserver
HostName 9.12.200.5
Port 22
User annalena
IdentityFile ~/.ssh/id_rsa_backupserver

Nun reicht die Übergabe des Host nach ssh:

$ ssh local

root-Login und Passwort verbieten

Vorsicht! Mach dies nur, wenn mit der Anmeldung SSH-Key wirklich alles klappt. An sonst kannst du dich vom System aussperren. Editiere dazu die /etc/ssh/sshd_config

# nano /etc/ssh/sshd_config

Setze nun PasswordAuthentication und PermitRootLogin auf den Wert no
PermitRootLogin no
PasswordAuthentication no

starte den Dienst neu:

# systemctl restart sshd

weitere Verschlüsselungen

Erstellen wir den Schlüssel mittels ED25519 oder ECDSA ist das Vorgehen analog! Der öffentliche Schlüssel (z.B. id_ecdsa.pub) muss nach ~/.ssh/known_hosts kopiert werden, während der geheime Schlüssel (z.B. id_ecdsa) auf dem Client-PC landen muss.

$ ssh-keygen -t ed25519
$ cat ~/.ssh/id_ed25519.pub | ssh USER@123.45.678.90 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

oder alternativ

$ ssh-keygen -t ecdsa -b 521
$ cat ~/.ssh/id_ecdsa.pub | ssh USER@123.45.678.90 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Windows

Nun übertragen/kopieren wir den privaten Schlüssel id_rsa nach: C:\Users\BENUTZER\.ssh

Achte darauf, bei Windows die Dateierweiterung .txt zu entfernen. Die Datei heisst hier id_rsa und nicht id_rsa.txt

Bei einem Login wird nun der private Schlüssel auf Deinem PC mit dem Schlüssel auf dem Server abgeglichen. Passen die zusammen, wird die Verbindung akzeptiert.

Linux

Hier muss zwingend die Berechtigung vom id_rsa Schlüssel unter ~/.ssh/id_rsa auf 600 gesetzt werden. Ansonst kommt es zu diesem Vorfall:

$ ssh yuna@192.168.0.81 -p 22
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0770 for '/home/BENUTZER/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/BENUTZER/.ssh/id_rsa": bad permissions
yuna@192.168.0.81's password: 
(...)

Die korrekte Berechtigung setzen wir mittels:

# chmod 600 /home/BENUTZER/.ssh/id_rsa

crontab in Debian

crontab erstellen

Mittels crontab lassen sich auf deinem Server Prozesse automatisieren. Angenommen, ich möchte jeden Tag um 00:10 Uhr die gesamte Datenbank sichern.

Starte crontab:

$ crontab -e

Im Editorfenster geben wir nun den gewünschten crontab ein:
# sichere die Datenbank alle Tage um 00:10. Überschreibe das aktuelle File jeweils:
10 0 * * * /usr/bin/mysqldump --all-databases --single-transaction --quick --lock-tables=false -r /opt/dbfull.sql

crontab sorgt dafür, dass die jeweiligen Files zum angegebenen Zeitpunkt auf dem Server liegen.

root darf alles, wirklich alles!

Dabei spielt es eine wesentliche Rolle, ob wir crontab als normalen Benutzer oder als root ausführen. root darf alles!
Editiere in diesem Fall die /etc/crontab – hier kannst du den Benutzer, welcher den Befehl ausführen soll auch gleich mitgeben. Doch Vorsicht! root kann wirklich alles. Du kannst hier auf Kommando auch dein gesamtes System zerstören!

# crontab -e

Zeitstempel

Geben wir der Zielatei keinen Zeitstempel mit, überschreibt crontab das jeweilige File. Einen Zeitstempel geben wir mittels date an:

example_$(date +"\%Y-\%m-\%d_\%H-\%M").sql

wird z. B. zu:
example_2004-03-05_09-58.sql
In diesem Beispiel entspricht dies dem 05. März 2004 um 09:58 Uhr. (YYYY/mm/DD/HH/MM)

Zeit bestimmen (Beispiele)

# Zeitbeispiele
.---------------- Minuten (0 - 59)
| .------------- Stunden (0 - 23)
| | .---------- Tag im Monat (1 - 31)
| | | .------- Monat (1 - 12) oder jan,feb,mar,apr ...
| | | | .---- Tag der Woche (0 - 6) (Sonntag=0 oder 7) oder mon,tue,wed,thu,fri,sat
| | | | |
* * * * *
# sendet jeden Tag um 12:00 Uhr einen ping an example.com
0 12 * * * ping -c1 example.com

# sendet jeden Montag, Mittwoch und Freitag um 04:05 Uhr einen ping an example.com
5 4 * * mon,wed,fri ping -c1 example.com

# sendet alle 20 Minuten einen ping an example.com
*/20 * * * * ping -c1 example.com

Damit lässt sich z. B. eine einfache Backuplösung realisieren.

Let’s encrypt (certbot) um eine Domain erweitern

Let’s encrypt bietet kostenlose Zertifikate zur Verschlüsselung an. In diesem Beispiel erweitern wir unser bestehendes Zertifikat um die Domain newexample.com. Das Vorgehen für eine Subdomain ist dasselbe. Mittels:

# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: example.com
    Serial Number: 1234567890acb1234567890abc1234567890
    Key Type: ECDSA
    Domains: example.com test.example.com example2.com example3.com
    Expiry Date: 2023-07-28 17:09:45+00:00 (VALID: 87 days)
    Certificate Path: /etc/letsencrypt/live/nyx7.ch/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/nyx7.ch/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

wird uns der Zertifikatsname mit allen zugehörenden Domains angezeigt. Möchten wir nun das bestehende Zertikikat um eine Domain oder Subdomain (newexample.com) erweitern, müssen wir das Zertifikat example.com für alle Domains und Subdomains erweitern.

Die Erweiterung des Zertifikates per expand:

# certbot --expand -d example.com,test.example.com,example2.com,example3.com,newexample.com
# certbot --expand -d example.com,test.example.com,example2.com,example3.com,newexample.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate for example.com and 4 more domains

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2023-07-30.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for example.com to /etc/apache2/sites-enabled/000-default-le-ssl.conf
Successfully deployed certificate for test.example.com to /etc/apache2/sites-enabled/000-default-le-ssl.conf
Successfully deployed certificate for example2.com to /etc/apache2/sites-enabled/000-default-le-ssl.conf
Successfully deployed certificate for example3.com to /etc/apache2/sites-enabled/000-default-le-ssl.conf

We were unable to find a vhost with a ServerName or Address of newexample.com.
Which virtual host would you like to choose?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: 000-default-le-ssl.conf        | Multiple Names        | HTTPS | Enabled
2: 000-default.conf               |                       |       | Enabled
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Successfully deployed certificate for newexample.com to /etc/apache2/sites-enabled/000-default-le-ssl.conf
Your existing certificate has been successfully renewed, and the new certificate has been installed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Um jedoch ein neues Zertifikat für die Domain zu bekommen, tippen wir:

# certbot certonly -d newexample.com

ein. Mehrere Domain und Subdomain werden durch ein Komma getrennt.

Klartextpasswort verbieten

Nachdem ein ssh-key generiert wurde und die Anmeldung geklappt hat, können wir noch einen Schritt weitergehen und verbieten die Anmeldung mittels Passwort. Öffne die sshd-Konfigurationsdatei:

# nano /etc/ssh/sshd_config

und kommentiere die Passwort-Authentifizierung aus und setze den Wert auf Nein:

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

Vorsicht: Damit kannst Du dich vom gesamten System aussperren. Mache dies nur, wenn Du sicher bist, was du hier genau tust!

Hinweis

es kann vorkommen, dass dies nicht auf Anhin klappt. Dann beginnen wir mit der Fehlersuche:

# ls -la /etc/ssh/sshd_config.d/*.conf
# sshd -T | grep -iE 'KbdInteractiveAuthentication|password|usepam'

der erste Befehl kann u.a. ausgeben:

# ls -la /etc/ssh/sshd_config.d/*.conf
-rw------- 1 root root 27 13. Jun 09:58 /etc/ssh/sshd_config.d/50-cloud-init.conf

der zweite Befehl kann u.a. ausgeben:

# sshd -T | grep -iE 'KbdInteractiveAuthentication|password|usepam'
usepam yes
passwordauthentication yes
kbdinteractiveauthentication no
permitemptypasswords no

Bedeutet: /etc/ssh/sshd_config.d/50-cloud-init.conf übersteuert unseren Befehl in sshd_config. Ein:

nano /etc/ssh/sshd_config.d/50-cloud-init.conf

mit dem Eintrag:
PasswordAuthentication no
bringt hier Abhilfe.

einen externen Server einbinden

sshfs lässt zu, einen entfernten Server in Debian einzubinden. Dieser Server wird als normales Laufwerk in Debian angezeigt und kann auch als solches verwendet werden. Dazu benötigen wir lediglich einen Debian-Server in der Minimalinstallation. Port 22 ist der einzige Port, der geöffnet werden muss. Falls der Server zusätzlich unter Windows 11 verfügbar sein soll, ist die Installation eines Samba-Servers notwendig.

Installiere nun auf der Workstation (nicht auf dem Server) das Paket sshfs:

# apt install sshfs

Das war’s bereits. Eingehängt wird der entfernte Server mittels sshfs und dem Zielpfad auf deinem Debiansystem.

$ sshfs benutzer@12.345.678.90:/home /home/benutzer/share

Dabei gilt:

benutzer = Benutzername auf dem entfernten Server.
benutzer = Benutzername deines aktuellen Systems.
12.345.678.90 = IP-Adresse vom Server.

Hinweis

Das Einhängen vom Server niemals mit root-Rechten ausführen. Es ist ausreichend, einen normalen Benutzer zu erstellen und diesen Benutzer zu verwenden.

# adduser share

eigenes, kleines Netzwerk erstellen

Vorbereitung: ssh-Server

Mit Debian lässt sich ein kleines Netzwerk recht schnell realisieren. Hier wird das Grundprinzip eines einfachen Heimnetzwerk erklärt. Ein in die Jahre gekommener Laptop kann als ssh-Server eingesetzt werden. In meinem Beispiel entschied ich mich für einen HP Pavilion dv6 und dem Betriebssystem Debian GNU/Linux Bullseye.

Auf dem Laptop/Tower setzen wir nun unseren ssh-Server auf. Falls auf dem Laptop bereits ein Debian läuft, kann per

# apt install openssh-server

das nötige Paket nachinstalliert werden. Setzen wir Debian frisch auf, wählen wir bei der Softwareauswahl lediglich
[*] SSH Server
[*] Standard-Systemwerkzeuge

aus. Ein Desktopenvironment ist in diesem Fall nicht nötig. Alle anderen Dienste wie apache2, php und MariaDB lassen sich nachträglich installieren.

Melde Dich beim Server an und überprüfe den Status vom ssh Server. Der ssh-Server ist in diesem Beispiel gestartet und lauscht auf Port 22 (Standard).

# systemctl status ssh

Jetzt benötigen wir die IP-Adresse vom Server:

# ip address
(...)
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 98:4b:e1:9b:48:0d brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.172/24 brd 192.168.0.255 scope global dynamic enp3s0
       valid_lft 2557sec preferred_lft 2557sec
    inet6 2a02:aa10:4201:8a80:9a4b:e1ff:fe9b:480d/64 scope global dynamic mngtmpaddr 
       valid_lft 936435sec preferred_lft 331635sec
    inet6 fe80::9a4b:e1ff:fe9b:480d/64 scope link 
       valid_lft forever preferred_lft forever
(...)

Von der Workstation aus können wir per ssh auf den Server zugreifen. Der allgemeine Befehl lautet:

$ ssh USERNAME@IPADRESS -p PORTNUMMER

Bei deiner allerersten Anmeldung wird der Fingerabdruck überprüft:

$ ssh lightning@192.168.0.172 -p 22
The authenticity of host '192.168.0.172 (192.168.0.172)' can't be established.
ECDSA key fingerprint is SHA256:VO+yY396S/SxMxo/VQDx55ZVLKpC2idiVSvQKu+6qrE.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

HINWEIS
Nicht jede Fehlermeldung muss gleich auf einen Angriff hinweisen. Im Beispiel unten hat sich beim Server lediglich der Fingerabdruck geändert und stimmt mit dem gespeicherten Fingerabdruck auf der Workstation nicht überein. Dies ist der Fall, wenn Du deinen ssh-Server z. B. neu aufgesetzt hast und nun versuchst, mit dem alten Fingerabdruck den neuen Server zu erreichen. Entferne den Schlüssel mit:

# ssh-keygen -f "/home/BENUTZERNAME/.ssh/known_hosts" -R "192.168.0.172"

oder lösche die Datei unter:

# rm ~/.ssh/known_hosts
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:VO+yY396S/SxMxo/VQDx55ZVLKpC2idiVSvQKu+6qrE.
Please contact your system administrator.
Add correct host key in /home/yuna/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/yuna/.ssh/known_hosts:5
  remove with:
  ssh-keygen -f "/home/yuna/.ssh/known_hosts" -R "192.168.0.172"
ECDSA host key for 192.168.0.172 has changed and you have requested strict checking.
Host key verification failed.

Netzwerk verbinden (samba)

Client-PC
Hier läuft Windows 11 und es muss nichts weiteres unternommen werden. Prüfe lediglich, ob unter der Systemsteuerung die Netzwerkkennung eingeschaltet ist. PuTTY als SSH und Telnet Client ist optional, jedoch nicht nötig. Alle Einstellungen können auch direkt am Server vorgenommen werden.

Server
Hier läuft Debian GNU/Linux. Bevor samba installiert wird, kläre folgendes ab:

  • IP-Adresse vom Server (ip address)
  • Welcher Ordner bzw. Mountpunkt wird geteilt? Hier ist es /pfad/zum/mountpunkt

Installiere das Paket samba. Damit später auch ntfs-Dateisysteme (Partitionen) eingebunden werden können, ist das Paket ntfs-3g nötig. Werden ext4-Datesysteme eingebunden, kann auf das Paket verzichtet werden.

# apt install samba
# apt install ntfs-3g

Optional kann jetzt die Konfigurationsdatei gesichert werden. Dazu genügt ein:

# cp /etc/samba/smb.conf /etc/samba/samba.original

Öffne das Konfigurationsfile:

# nano /etc/samba/smb.conf

Editiere nun die smb.conf wie in diesem Beispiel.
# ======================= Global Settings ======================= #

[global]

## Browsing/Identification ###

# Change this to the workgroup/NT-domain name your Samba server will part of
workgroup = smb

####### Authentication #######

security = user

# This option controls how unsuccessful authentication attempts are mapped
# to anonymous connections
map to guest = bad password

# ======================= Share Definitions ===================== #

[homes]
comment = Home Directories
browseable = no

# By default, the home directories are exported read-only. Change the
# next parameter to 'no' if you want to be able to write to them.
read only = no
create mode = 0750

[public]
path = /pfad/zum/Ordner
public = yes
writable = yes
comment = smb share
printable = no
guest ok = yes

Starte den Samba-Server neu:

# systemctl restart smbd.service

Client-PC (hier Windows 11)
Auf dem Client-PC kann nun ein Netzlaufwerk verbunden werden. Wähle dazu in Windows 11 «Dieser PC»  > weitere Optionen anzeigen > Netzlaufwerk verbinden… und vergib einen Laufwerkbuchstaben und die IP des Servers, gefolgt von \public

Je nach Mountpunkt gibst du nach public noch die exakte Bezeichnung ein.
Einhängepunkte findest du bei Debian mittels df -h

# df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            3.9G       0  3.9G    0% /dev
tmpfs           790M    7.4M  783M    1% /run
/dev/sdb2        19G    4.5G   13G   26% /
tmpfs           3.9G       0  3.9G    0% /dev/shm
tmpfs           5.0M    4.0K  5.0M    1% /run/lock
/dev/sdb3       205G    121G   85G   59% /home/yuna/share/VMs
/dev/sdb1       240M    3.4M  236M    2% /boot/efi
/dev/sda1       932G    153G  780G   17% /home/yuna/share/BACKUP
tmpfs           790M     36K  790M    1% /run/user/112
tmpfs           790M     68K  790M    1% /run/user/1000

Partition /dev/sda1 wird in diesem Fall per
\\192.168.0.172\public\BACKUP
eingebunden.

Bei einem # apt upgrade werden auch die Pakete von deinem Sama-Server berücksichtig:

Die Installationsroutine von apt fragt danach, was mit deiner eigenen smb.conf geschehen soll. In der Regel ist es immer eine gute Idee, die lokal installierte Version zu behalten.

Sprache und Zeitzone einstellen (Debian GNU/Linux)

timedatectl gibt dir nähere Angaben zur Zeitzone und der locale:

# timedatectl
               Local time: Sun 2022-10-02 11:09:03 UTC
           Universal time: Sun 2022-10-02 11:09:03 UTC
                 RTC time: Sun 2022-10-02 11:09:03
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Für mein Beispiel stimmen gleich zwei Angaben nicht. Die lokale Zeit und die Zeitzone. Höchste Zeit, dies zu ändern.

locale

# dpkg-reconfigure locales

Generiere danach die locale neu:

# locale-gen

Zeitzone

die Zeitzone ändern wir mit:

# dpkg-reconfigure tzdata

Setze einen symbolischen Link mit:

# ls -l /etc/localtime
lrwxrwxrwx 1 root root 33  2. Okt 13:22 /etc/localtime -> /usr/share/zoneinfo/Europe/Zurich

Ab jetzt stimmt Localzeit und Zeitzone:

# timedatectl
               Local time: So 2022-10-02 13:29:30 CEST
           Universal time: So 2022-10-02 11:29:30 UTC
                 RTC time: So 2022-10-02 11:29:31
                Time zone: Europe/Zurich (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Tastaturlayout einstellen (Keyboard)

Falls das falsche Keyboard gewählt wurde, kann dies geändert werden.

# dpkg-reconfigure keyboard-configuration
# service keyboard-setup restart