GNU+Linux Für Fachinformatiker / Vorbereitung LPIC-1

Windows-Server

Hinweis

es werden mehrere Aufrufe von ls benötigt.

Hinweis

Einige Ausgabezeilen sind kniffeliger, sendet gerne schon Teillösungen

Zusatz

Lasst alle Ausgabezeilen ohne Zwischenraum direkt untereinander erzeugen

Hinweis

Beachtet insbesondere Leerzeichen, Bindestriche und Klammern, sowie Groß- und Kleinschreibung.

Hinweis

• Durch Nutzung von cd kann man Schreibarbeit sparen
• Fehler lassen sich durch mv und rm/rmdir korrigieren

Zusatz

Man kann den Gesamten Datei- und Ordnerbaum mit zwei Programmaufrufen erstellen. Postet die Kommandos in Teams.

Zusatz

Lest den Artikel über "Brace-Expansion" in der Bash-Dokumentation um herauszufinden, wie sich die Befehle noch weiter abkürzen lassen.

Zusatz:

Wir haben einige male die Prozessliste ausgegeben mit:

~$  ps   -eo  pid,user,command

Wie kann man der Ausgabe eine Spalte für den Speicherverbrauch hinzufügen?

Manuelle Partitionierung

1. ~128 MiB EFI System Partition

2. ~16 GiB Ext4-Partition

   • Einhängepungkt: /

3. Ext4-Partition

   • Einhängepunkt: /home
4. ~8GiB Swap-Partition

Software

• "Debian Desktop"
• XFCE-Desktop
• SSH-Server
• Standard Systemwerkzeuge

XFCE-Desktop Konfigurieren

Empfehlungen: Whisker-Menü statt Standard-Anwendungsmenü, ansonsten nach Geschmack.

Andere Desktops installieren

Zunächst gibt es kein sudo...

~$ su -
~# adduser   juhser   sudo

Pakete Installieren:

~# apt  install  task-kde-desktop   task-gnome-desktop   task-german-kde-desktop
~# apt  install  marble   htop

Displaymanager: egal, kann geändert werden mittels dpkg-reconfigure gdm3

Hinweis

Die Dateisysteme werden nicht in dieser Übung angelegt.

Zusatz

• probiert cfdisk aus
• schaut in die man-Page von sfdisk

apt-get

• apt-get update

• apt-get upgrade

  • Aktualisierung bestehender Pakete

• apt-get dist-upgrade

  • ähnlich wie upgrade, kann aber zusätzliche Abhängigkeiten installieren, oder Konfliktpakete entfernen
• apt-get install ...

• apt-get --fix-broken install

  • kaputte Abhängigkeiten nachträglich auflösen
• apt-get remove ...
• apt-get purge ...

• apt-get autoremove

  • liegengebliebene Abhängigkeiten entfernen
• apt-get autoremove --purge, apt-get purge --autoremove

• apt-get clean

  • Downloadcaches in /var/cache/apt/archives/ löschen

apt-cache

• apt-cache search ...

  • sucht nach Stichworten in Beschreibungstexten

• apt-cache show ...

  • Beschreibungstext zu Paketnamen zeigen

apt

Enthält Subkommandos von apt-get und apt-cache in einem Programm. Hinzu kommt eine bessere visuelle Darstellung (Statusbalken beim Download, etc.)

CPU-Architektur

Arten der Virtualisierung

Keine Virtualisierung

• WSL-1 Benutzt keine Virtualisierung (jenseits von regulärem Multitasking)

  • Stellt Linux-Betriebssystemcalls in Windows bereit
  • → Linux-Programme können unter Windows ausgeführt werden, solange sie keine Betriebssystemfeatures verwenden die Linuxspezifisch sind

• WINE Stellt Windows-Betriebssystemcalls unter Linux bereit (WINE Is Not an Emulator)

  • → Windows-Programme können unter Linux ausgeführt werden, solange sie keine speziellen Windows-Features verwenden

Zusatz

Legt folgende Spezialdateien an. Hier geht es nicht um Berechtigungen. Es gibt verschiedene Wege die Dateien anzulegen, dazu ist Recherche nötig.

lrwxrwxrwx 1 live live 1 Apr 30 06:11 Jot -> /
prw-rw-r-- 1 live live 0 Apr 30 06:11 Kah
srwxrwxr-x 1 live live 0 Apr 30 06:12 Lel

Hinweis: Diese Dateien müssen auf einem Unix-Dateisystem liegen. Bei der Nutzung von WSL sind Ordner unterhalb von /mnt/c/ also nicht geeignet.

Normale Datei

Verzeichniseintrag (Dateiname) → Inode (Berechtigungen, Änderungsdatum, Metainformationen) → Datensektoren im Dateisystem

Symlink / Softlink / Symbolischer Link / Semantischer Link

Verzeichniseintrag → Inode (Spezialdatei) → Verzeichniseintrag

Hardlink

Verzeichniseintrag        -------->  Inode (genauso wie bei normaler Datei)  -> Datensektoren
                               /
Weiterer Verzeichniseintrag  -         (verweist auf die selbe Inode)

Webserver

web_01.sh

~$ ncat -klp 8000 -e ./web_01.sh

Vorgehen

• Versuche zuerst von Hand einen einzelnen convert-Aufruf korrekt zu schreiben.
• stelle dem convert-Aufruf testweise ein echo voran um zu sehen, wie die Variablen eingesetzt werden.

• Lasse die Schleifenvariable mittels echo ausgeben bevor das convert ausgeführt wird

  • Die Hilfsausgaben lassen sich auf der Shell besser erkennen, wenn sie ein Paar =====-Zeichen o.Ä. enthalten.
• In einem Texteditor hilft das Syntax-Highlighting dabei, einige Fehler zu vermeiden
• Anders als in python müssen Steuerstrukturen in Shellscript immer abgeschlossen werden (done und fi)

Zusatz

In verschiedenen thumb_* Unterordnern sollen zu jedem Bild Thumbnails mit den Auflösungen 480x*, 320x* und 240x* erstellt werden.

Hierzu sind mehrere Schleifen nötig. Versuche das Programm so zu schreiben, dass sich leicht eine Vielzahl weiterer Auflösungen hinzufügen lässt.

→ katzen_01.sh

Vorgehen

• schreibe erst eine funktionierende Schleife, bei der die Dateien "ausgabe.jpg.png" heißen. Damit werden alle Fehler ausgeschlossen, die mit dem eigentlichen Problem nichts zu tun haben.

Lösung

~$ for katze in *.jpg; do convert "$katze" "${katze%.jpg}.png"; done

Alternativ / Zusatz

Neben der Methode aus der Manpage gibt es auch die Möglichkeit den Dateinamen mittels sed umzuformen. Hierzu kann die "Command Substitution" dienen. z.B.

ausgabe="$(BEFEHL "$eingabe")"

output="$( echo "$input" | sed 's/.jpg/.png/' | sed 's/cat/dog/ig')"

Hinweise

• $RANDOM funktioniert nur in der Bash (Die #!-Zeile muss entsprechend lauten)
• das test-Programm hilft Fälle zu unterscheiden (siehe man-Page)
• man kann das test-Programm in if-Abfragen nutzen
• Lasst euch zum Testen die Zufahlszahl mit ausgeben, so dass ihr seht, ob die Fallunterscheidung funktioniert (wenn das Script sagt: "Meine Zahl war kleiner", obwohl das nicht stimmt, müsst ihr das beim Test sehen)
• in web_01.sh gibt es ein Beispiel für die if-Abfrage

Zusatz

Beachte das Plural-s ( Bottles ) in der letzten Strophe.

→ bottles.sh

Übung

Passe wochentag.sh so an, dass es den aktuellen Wochentag benutzt, statt der Usereingabe.

Hinweise

• das Programm date lässt sich nutzen, um den aktuellen Wochentag zu ermitteln

Beweisfoto:

Von einem Browser auf einer anderen Maschine aus (vorzugsweise M$ Edge): http://ip-adresse/

Beispiel: webapps-1

~# git  clone  https://git.plutz.net/git/shellwiki  /opt/shellwiki
~# git  clone  https://git.plutz.net/git/webpoll    /opt/webpoll
~# useradd  -rmb  /srv  wiki
~# useradd  -rmb  /srv  poll
~# vi  /etc/inetd.conf

   81  stream  tcp  nowait  wiki  /opt/shellwiki/index.cgi  /opt/shellwiki/index.cgi  --data=/srv/wiki/data  --debug=/srv/debug
   82  stream  tcp  nowait  poll  /opt/webpoll/index.cgi    /opt/webpoll/index.cgi    --data=/srv/poll/data  --debug=/dev/null

~# systemctl  restart  inetd
~# su  -  poll
  p~$ mkdir  data
  p~$ exit
~#

/etc/inetd.conf

Vorher TCP mit Hostname:Port → Nachher Unix-Sockets

/srv/live-dvd   stream  unix    nowait  web01   /opt/web_01.sh  xxx
/srv/wiki/sock  stream  unix    nowait  wiki    /opt/shellwiki/index.cgi        /opt/shellwiki/index.cgi --data=/srv/wiki/data --debug=/dev/null
/srv/poll/sock  stream  unix    nowait  poll    /opt/webpoll/index.cgi          /opt/webpoll/index.cgi   --data=/srv/poll/data --debug=/dev/null

/etc/apache2/sites-available/....conf

Rewrite-Rule .... Plain-HTTP → unix:...|http...

<VirtualHost *:80>
    ServerName  poll.local
    RewriteEngine   on
    RewriteRule     ^/(.*)$  unix:/srv/poll/sock|http://localhost/$1 [P]

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    ErrorLog  ${APACHE_LOG_DIR}/poll.error.log
    CustomLog ${APACHE_LOG_DIR}/poll.access.log combined
</VirtualHost>

Zugriffsrechte für Apache:

Der Webserver muss in den Socket-Verzeichnissen auf Sockets zugreifen können.

~# chgrp  www-data  /srv/wiki  /srv/poll
~# chmod  g+x  /srv/wiki  /srv/poll

Ziel

Im Browser unter http://nextcloud.local soll eine weiße Seite angezeigt werden.

PHP ist noch nicht ausreichend eingerichtet um Nextcloud auszuführen. Ergebnis ist daher zunächst eine weiße Seite aber keine Fehlermeldung.

Zusatz

Nextcloud hängt von diversen PHP-Bibliotheken ab. Versucht bis zum Einrichtungsdialog der Nextcloud zu kommen.

Fertige Config

→ nextcloud.conf

php-xml, php-mbstring, php-curl, php-gd, php-zip, php-sqlite3

Webbrowser

• Macht DNS-Abfrage
• Öffnet TCP/IP-Kanal
• Spricht HTTP um Dokument anzufragen
• Stellt HTML-Dokumente grafisch dar (rendering)

poll.sh, wiki.sh, web_01.sh

• Sprechen HTTP (auf stdin, stdout)
• Liefern Dokumente (HTML, text, usw.)
• Keine Handhabung von Netzwerk-Kanälen TCP/IP

ncat, inetd

ncat: CLI-Programm
inetd: Hintergrunddienst mit /etc/inetd.conf als Config-Datei

• Sprechen TCP/IP
• Rufen ggf. Programme auf, die die TCP-Connection betreuen
• Kein HTTP (das machen ggf. aufgerufen Programme)
• Keine Dokumentenauslieferung

inetd + web_01.sh = TCP/IP + HTTP + Dokument

PHP-Applikationen (*.php-Scripte)

• Generieren Dokumete (idR. HTML)
• Kein TCP/IP
• Kein HTTP
• theoretisch können PHP-Scripte normale Anwendungsprogramme sein (wie Gimp, LibreOffice, usw...)
• in der Praxis praktisch immer zur Erstellung von Webapplikationen

Apache-Webserver

• Verwaltet TCP/IP-Verbindungen

• Spricht HTTP-Protokoll

• Unterstützt völlig verschiedene Betriebsmodi

  1. Dokumente vom Dateisystem ausliefern
     (/var/www/html/index.html)

  2. Arbeitet als Reverse-Proxy für andere Webserver
     z.B. Forwarding an inetd (via TCP oder Unix-Socket)

  3. PHP-Scripte ausführen
     Script generiert dynamisch ein Dokument

     • Apache muss HTTP und Netzwerk-Teil übernehmen
     • Setzt Umgebungsvariablen für ausgeführtes Script

Nginx-Webproxy

eigentlich kein Webserver!

• Ursprünglich als Proxy entworfen (vgl. Apache, Punkt 2)
• Kann zusätzlich Dokumente vom Dateisystem ausliefern (vg. Apache, Punkt 1)
• kann keine PHP / CGI / ... Scripte ausführen!
• kann als Proxy an php-fpm, fcgiwrap, usw. forwarden

PHP-FPM

Variante vom PHP-Interpreter

• führt PHP-Scripte aus, mit Umgebungsvariablen, usw. wie in einem Webserver

• Spricht FastCGI-Protokoll auf einem Unix-Socket

  • FastCGI ~= Binäres HTTP

Aufgabe

Erstellt unter Windoze einen ssh-key und installiert diesen auf der Linux-Maschine.

Ergebnis soll sein, dass ein ssh von Windoze zu Linux kein Passwort mehr abfragt.

Zusatz:

Kopiert den ganzen /etc-Ordner auf den Windows-Rechner. (Die man-Page zu scp gibt es leider nur unter Linux)

Makefile

→ Makefile

~# make nextcloud.local.crt

Signing Authority

~$ openssl  genrsa  >RootCA.key
~$ openssl  req  -x509 -subj  /CN="MeineKleineCA"  -key RootCA.key  -days ... >RootCA.crt

Site Certificate

~$ openssl  genrsa   >nextcloud.key
~$ openssl  req  -new  -subj  /CN=nextcloud.local  -key  nextcloud.key  >rextcloud.req

Request signieren (von CA)

~$  printf  '%s\n'  '[SAN]'  'subjectAltName=DNS:nextcloud.local' >nextcloud.conf
~$  openssl  x509  -req  -in  nextcloud.req  -extensions  SAN  -extfile  nextcloud.conf  -CA RootCA.crt  -CAkey  RootCA.key  -days ...  >nextcloud.crt

Ausprobieren

~#  ncat  --ssl-cert nextcloud.crt  --ssl-key nextcloud.key  -klp 443 -e  /opt/web_01.sh

→ Webbrowser: https://nextcloud.local

Zusatz:

Die VHosts sind nur noch für SSL konfiguriert. Und auf Port 80 wird immer auf den SSL-Port der jeweils aufgerufenen Domain umgeleitet.

Zwischenschritte und Tests:

• ping wiki.local, ping poll.local und ping nextcloud.local bekommen eine Antwort von der selben IP-Adresse - von der VM
• netstat -xl |grep srv zeigt die Sockets an, die von inetd unterhalb von /srv/ bereitgestellt werden
• netstat -tln Zeigt den Apachen, der auf Port 80 lauscht
• http://localhost im Webbrowser zeigt die Default-Seite von Apache
• http://wiki.local, http://poll.local und http://nextcloud.local zeigen im Webbrowser die jeweiligen Seiten

• Es gibt eine Zertifikats- und Schlüsseldatei für das Stammzertifikat. z.B.:

  • RootCA.crt und RootCA.key

• Es gibt Zertifikats- und Schlüsseldateien für die drei Domains. z.B.:

  • wiki.local.crt und wiki.local.key
  • poll.local.crt und poll.local.key
  • nextcloud.local.crt und nextcloud.local.key
• netstat -tln zeigt den Apachen, der auch auf Port 443 lauscht

• https://wiki.local, https://poll.local und https://nextcloud.local zeigen im Webbrowser jeweils eine SSL-Warnung

  • Akzeptiert man die Warnung, werden die Seiten angezeigt
• Die Seiten sind ohne Warnung abrufbar
• Zusatz: Die Seite http://wiki.local wird im Webbrowser unmittelbar auf https://wiki.local weitergeleitet

Windows

\> certmgr.crt → rechtsklick → importieren → .pem-Datei (oder .crt, ...)

Einige Linux-Distros

.pem-Datei nach /etc/ssl/certs kopieren

Debian-Derivate

• .crt-Datei nach /usr/share/ca-certificates kopieren
• ~# dpkg-reconfigure ca-certificates

Firefox systemweit

/etc/firefox/policies/policies.json:

{ "policies": { "Certificates": { "Install": [ "/etc/ssl/...", "/usr/share/ca-certificates/..." ] } } }

Chromium automatisch

für jeden Useraccount einzeln

~$ certutil -d ~/.pki/nssdb/  -A -t -C,, -n "Freitextname" -i /etc/ssl/...

Apache SSL-Redirect und ACME

• Alle VHosts werden nur noch für SSL konfiguriert
• SSL-VHosts müssen deaktiviert sein, solange Zertifikate noch nicht vorhanden sind
• die Einzige nicht-SSL-Konfiguration beantwortet ACME-Challenges und löst für andere Anfragen einen HTTPS-Redirect aus:

<VirtualHost *:80>
 Alias         /.well-known/acme-challenge/    /var/lib/dehydrated/acme-challenges/

 <Location /.well-known/acme-challenge>
 Require     all     granted
 </Location>

 <LocationMatch        "^/(?!\.well-known/acme-challenge)">
 Redirect    301     https://%{HTTP_HOST}%{REQUEST_URI}
 </LocationMatch>
</VirtualHost>

SSL-Zertifikate werden über ACME automatisch erstellt und signiert.

• ACME-Client installieren (~# apt install dehydrated)

• Automatisch, "anonym" Account erstellen (~# dehydrated --register --accept-terms)

• Domainnamen konfigurieren (in /etc/dehydrated/domains.txt)

  • Ein Zertifikat pro Zeile
  • mehrere Domainnamen pro Zertifikat möglich
  • mehrere Zertifikate möglich
  • Datei enthält nur Domainnamen

• dehydrated -c ausführen um Schlüssel zu generieren und Zertifikate anzufordern

  • Challenge-Dateien auf dem HTTP-Server beweisen der CA, dass wir eine Domain kontrollieren (siehe Config-Datei im obigen Stichpunkt)

• Sobald die Zertifikate erstellt sind können die SSL-VHosts aktiviert werden (a2ensite)

• SSL-Zertifikate können in der VHost-Konfiguration direkt aus /var/lib/dehydrated/certs/... benutzt werden

• Ggf. muss dehydrated -c regelmäßig ausgeführt werden um die Zertifikate aktuell zu halten (cron)

  • idR. täglich

Spielübung Email

1. wir Brauchen einen lokalen DNS-Server, der MX-Records auflöst

   • in /etc/hosts:

     Netzwerk-IP für live.local, wiki.local, poll.local und nextcloud.local eintragen

     denn dnsmasq liest seine Infos aus dieser Datei

   • Im grafischen Network-Manager: "Verbindung Bearbeiten" → "Zusätzliche DNS-Server": "127.0.0.1", Neu Verbinden

     denn der DHCP-Client überschreibt sonst regelmäßig DNS-Einstellungen

   • ~# apt install dnsmasq

     gefolgt von

     ~# systemctl stop dnsmasq

     denn wir starten dnsmasq von Hand

   • dnsmasq starten:

     ~# dnsmasq -dq --selfmx

     → Service bleibt im Vordergrund und beantwortet simple MX-Queries

   • Überprüfung:

     ~$ dig MX nextcloud.local → löst auf den Namen "nextcloud.local." auf

     ~$ dig nextcloud.local → löst auf die Netzwerk-IP auf (nicht 127.0.0.1 !)

2. Anderen Rechner konfigurieren (Idealerweise Minimal-Install):

   • Aktuelle DHCP-IP-Adresse aufschreiben

   • Zur Sicherheit (falls der Rechner als Live-DVD läuft):

     ~# systemctl stop NetworkManager

     ~# ifdown eth0 (falls nicht Live-DVD)

   • /etc/network/interfaces.d/eth0

     auto eth0
     iface eth0 inet static
       address  ADRESSE/MASKE  (wie vorher notiert)
       gateway  ADRESSE  (vom Gateway, wie vorher notiert)

   • echo nameserver ADRESSE >/etc/resolv.conf

     Mit der Adresse des dnsmasq-Servers!

   • Überprüfung:

     ~$ dig MX nextcloud.local → löst auf den Namen "nextcloud.local." auf

     ~$ dig nextcloud.local → löst auf die Netzwerk-IP auf (nicht 127.0.0.1 !)

3. Zweitrechner am dnsmasq-Server eintragen

   • /etc/hosts:

     ADRESSE other.local

     Im dnsmasq-Terminal Strg+C, nochmal starten

   • Überprüfung, auf beiden Rechnern:

     ~$ dig MX other.local

4. OpenSMTPD installieren und konfigurieren

   • ~# apt install opensmtpd ca-certificates

   • /etc/smtpd.conf: smtpd.conf (auf die jeweiligen Domains achten)

   • ~# systemctl restart opensmtpd

   • Überprüfen:

     ~# netstat -tlnp → Port 25 (Nicht nur auf localhost!)

     ~# journalctl -fu opensmtpd

     ~$ mail -s "Betreff" user@lokaledomain user@remotedomain (Mailbody eingeben, mit Ctrl+D abschließen)

Zusatz:

Der Host für nextcloud.local, wiki.local, poll.local soll ein Zertifikat vorweisen, dass für alle drei Domains gilt. Hierzu müsst ihr vor dem Signierschritt die Zusätzlichen subjectAltNames in der .cfg-Datei für openssl eintragen.