Linux für Fachinformatiker / LPIC-1 Vorbereitung / FI17-SI1

Folien

• Geschichte und Grundbegriffe
• Einführung in die Kommandozeile
• Syntax der Kommandozeile
• Datenträger und Dateisysteme
• Prozesse und Benutzer
• Softwareinstallation und Paketsysteme
• Thema Reguläre Ausdrücke: Handbuch, Kapitel 103.7, https://regexone.com/, ~$ man 7 regex
• Thema Pipelining: Handbuch, Kapitel 103.2
• Netzwerke
• Mitschrift Manuelle Installation
• CPU-Architektur

Shell dumps

• live.2026-10-12.hist.txt 8.4 KB2026-10-12 08:34:18
• root.2026-10-12.hist.txt 2.0 KB2026-10-12 08:34:18

Windows-Server

Neuer virtueller Computer

• Name: egal
• Generation 2 (wegen UEFI-Boot)

• Arbeitsspeicher: 2048 MB, oder mehr

  • Dynamischen Speicher deaktivieren
• Festplatte: egal, sollte aber vorhaden sein
• Installationsmedium: live-dvd.iso
• Netzwerk: default Switch oder externer Switch

• Rechtsklick auf die Maschine → Einstellungen

  • → Sicherheit → "Sicheren Start" ausschalten
  • → Firmware → DVD-Laufwerk nach oben etzen

Hinweis

Es braucht mehrere Aufrufe von ls um alle Zeilen zu erzeugen.

Zusatz

Erledigt die Aufrufe für alle Anzeigen in einer einzigen Zeile, so dass die Ausgaben direkt untereinander stehen.

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.

Hinweis

Die Tutorials lassen sich im Linux-Terminal nachbilden via:

~$ grep  -P  "…"

Hinweis

Bei einigen Lessons kann man mogeln. Achtet bitte darauf, welcher Lösungsweg im Text beschrieben wird. Versucht die Aufgabe so zu lösen wie jeweils beabsichtigt.

Zusatz

Auf der Seite gibt es auch noch "Practice Problems". (Aber pingt mich an, wenn ihr bei Lesson 15 seid).

Hinweis

Straßennamen können Leerzeichen enthalten, Bezirke sind aber glücklicherweise durch Tabs vom Straßennamen abgesetzt.

Hinweis (Für WSL-Nutzer)

Einige Tastenkombinationen funktionieren schlecht im Windows-Terminal.

Zusatz

1. lade das Berliner Straßenverzeichnis zweimal herunter
2. ändere ein paar Straßennamen in einer der Kopien
3. öffne beide Dateien gleichzeitig mit vimdiff datei1 datei2
4. mit Strg + W → Bewegung kann man zwischen den Panelen wechseln

Zusatz

Sucht online nach dem "besten", "ultimativen", "idealen" .vimrc-File. ;-)

SFTP

(gibt es auch in Windows) Das SFTP-Programm benutzt eine interaktive Subshell \> sftp user@host > cd remote_ordner > pwd > lcd lokaler_ordner > lpwd > ls > lls > get remote_file > put local_file

SCP

(gibt es auch in Windows) \> scp user@host:datei ./ \> scp datei user@host: (Remote-Pfade müssen einen Doppelpunkt enthalten)

Allein via ssh

(braucht eine Unix-Shell) ~$ ssh user@host cat datei > lokale_datei ~$ cat lokale_datei |ssh user@host cat ">"datei (Anführungszeichen beachten)

Tar-Streams durch remote STDIN/STDOUT

~$  ssh user@host tar -c ordner | tar -x
~$  tar -c ordner |ssh user@host tar -x

RSync

Bedienung ähnlich wie scp. Effizient bei mehrfacher Übertragung der gleichen Dateien. Braucht rsync auf der Remote-Seite. \> rsync user@host:datei ./ \> rsync datei user@host:

Beispiel Domainname

www.plutz.net → eigentlich www.plutz.net. (mit abschließendem Punkt)

DNS-Namen werden von hinten nach vorne gelesen.

Beispiel rekursive Abfrage

• Der DNS-Rekursor muss Kenntnis über die Root-Nameserver haben

  • Root Name servers

• dig @193.0.14.129 NS net. (Anfrage an europäischen RIPE-Nameserver)

  • → Zuständig für net.-Zone: z.B. 192.12.94.30 (Verisign)

• dig @192.12.94.30 NS plutz.net. (Anfrage an Verisign)

  • → Zuständig für plutz.net.: z.B. 46.38.225.225 (Netcup)

• dig @46.38.225.225 NS www.plutz.net. (Anfrage an Netcup)

  • → kein untergeordneter Nameserver

• dig @46.38.225.225 A www.plutz.net (Anfrage weiterhin an Netcup)

  • → 46.38.234.157 (der eigentliche Webserver!)

→ Rekursive Abfragen werden idR. nicht direkt von Client-PCs aus gemacht. Ein lokaler Nameserver führt rekursive Abfragen durch und cached die Ergebnisse. Zusätzliche kann er lokale Hostnamen auflösen und ggf. öffentliche Einträge übersteuern (Jugendschutz-, Zensur-, u. Werbefilter).

Hinweis

Es ist OK, wenn die Ausgabedateien auf .jpg.avif enden.

Zusatz

Lasst alle .avif-Dateien in einem Ordner "bilder_avif" anlegen, der neben dem "Wikimedia_Katzenbilder"-Ordner liegt.

Zusatz

Recherchiert, wie man die doppelte Dateiendung loswerden kann, so dass die Namen einfach auf .avif (ohne .jpg) enden.

Hinweis

Das test-Programm unterstützt verschiedene Tests. Siehe man-Page.

Hinweis

if-Abfragen kann man verschachteln

  if …; then
  else
    if …; then
    fi
  fi

oder elif benutzen (lesbarer)

if …; then
elif …; then
elif …; then
else
fi

Zusatz

Der Pfad soll nicht von stdin gelesen werden, sondern als Parameter an das Script übergeben werden. Aufrufparameter stehen in den Spezialvariablen ${0}, ${1}, ${2}, usw.

Hinweise

• Die Reihenfolge der Bedingungsprüfungen spielt ggf. eine Rolle.
• Auch ein Fehlerdokument hat einen Content-Type

Zusatz

Die Meldung "$pfad ist ein Datenträger" (z.B. bei /dev/sda) soll mit lesbarem Umlaut angezeigt werden.

Softwarepakete

1. • openbsd-inetd
   • git
   • busybox
2. • apache2

Useraccounts

~#  useradd  -rUm -b /srv -c "Shellscript Webserver" webserver
~#  useradd  -rUm -b /srv -c "Webpoll" webpoll
~#  useradd  -rUm -b /srv -c "Shellwiki" shellwiki

Applikationen in /opt

• /opt/webserver.sh

  • → Ausführungsrechte nicht vergessen
• /opt/shellwiki/ (git clone http://git.plutz.net/git/shellwiki)
• /opt/webpoll/ (git clone http://git.plutz.net/git/webpoll)

Datei /etc/inetd.conf

/srv/webpoll.sock    stream  unix  nowait  webpoll    /opt/webpoll/index.cgi    /opt/webpoll/index.cgi   --data=/srv/webpoll
/srv/shellwiki.sock  stream  unix  nowait  shellwiki  /opt/shellwiki/index.cgi  /opt/shellwiki/index.cgi --data=/srv/shellwiki
/srv/webserver.sock  stream  unix  nowait  webserver  /opt/webserver.sh         --

Nicht vergessen: ~$ systemctl reload inetd

Apache-Konfiguration

~$ wget -O- http://plutz.net/training/damago_2026_03/[attachment]/Wikimedia_Katzenbilder.tar  |sudo tar -xC /var/www/html/

<VirtualHost *:80>
  ServerAdmin   webmaster@localhost
  DocumentRoot  /var/www/html/Wikimedia_Katzenbilder

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

<VirtualHost *:80>
  ServerName    pollwiesel
  ServerAdmin   webmaster@localhost
  DocumentRoot  /dev/null

  RewriteEngine  on
  RewriteRule    ^/(.*)$  unix:/srv/webpoll.sock|http://egal/$1  [P]

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

<VirtualHost *:80>
  ServerName    wikiwiesel
  ServerAdmin   webmaster@localhost
  DocumentRoot  /dev/null

  RewriteEngine  on
  RewriteRule    ^/(.*)$  unix:/srv/shellwiki.sock|http://egal/$1  [P]

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

~# a2ensite  000-default webpoll shellwiki
~# systemctl reload apache2
~# a2enmod  rewrite  proxy  proxy_http
~# systemctl restart apache2

Hostnamen eintragen

• Wir haben kein DNS, benutzen also die hosts-Datei.
• Alle Clientsysteme (webbrowser) brauchen entsprechende Einträge!
• Windows-Clients: C:\Windows\System32\drivers\etc\hosts
• Linux-Clients: /etc/hosts

# Ip.vom.apache.server
23.42.47.11     wiesel   pollwiesel   wikiwiesel

→ Zwischenstand:

Nextcloud funktioniert noch nicht, aber statische Dateien aus dem Verzeichnis sind schon zugreifbar. index.php wird noch als Text ausgeliefert.

Nextcloud benutzt PHP-Scripte um seinen HTML-Output zu generieren. Diese werden über den integrierten PHP-Interpreter des Apache-Servers ausgeführt.

• → Installiert und aktiviert die mod-php des Apachen

• Nextcloud hat viele Abhängigkeiten von PHP-Bibliotheken

  • nutzt die error-Log-Datei des Webservers, um herauszufinden, welche PHP-Libraries noch installiert werden müssen.
  • Die Nextcloud-Installation selbst liefert auf ihrer defekten Startseite Hinweise auf fehlende Bibliotheken
  • Verzichtet zunächst auf den MySQL/MariaDB-Server. Datenbankbackend soll sqlite sein.

Hinweis

• https://docs.nextcloud.com/server/latest/admin_manual/installation/source_installation.html#apache-web-server-configuration
• https://docs.nextcloud.com/server/latest/admin_manual/installation/php_configuration.html#required-php-modules

Zusatz

Auf der Administrator-Seite der Nextcloud-Installation gibt es Hinweise zu Sicherheits- und Performance-Einstellungen. Versucht hier weiter die Warnungen zu reduzieren. Ausnahme sind HTTPs-Einstellungen, das machen wir später.

Statisch

• Webserver liefert nur HTML-Dateien aus
• keine dynamisch generierten Dokumente
• Vorteil: extrem performant
• z.B. Handgeschriebenes HTML
• z.B. "Hugo" static site generator

Direkt

• Webapplikation spricht selbst HTTP

  • via Unix-Socket
  • oder TCP-Port auf Localhost

• Geht theoretisch ohne Webserver

  • Vorteil: ohne Webserver ausführbar (einfach zu testen)
  • Nachteil: jede Applikation hat eigene Sicherheitslücken im HTTP-Handling
• Reverse-Proxy für Webserverfunktionalität (z.B. VHosting, Sicherheit)
• z.B. Solr-Suchmaschine, Elastic-Search

CGI

• Webserver startet eine Datei als Programm

  • anstelle von index.html tritt index.cgi / index.php
  • kann in beliebiger Programmiersprache geschrieben sein
  • CGI-Programm generiert nur HTML-Dokumente (u. ggf. einzelne HTTP-Header)

• Nachteil

  • jeder Seitenaufruf startet das Programm neu (Interpreter u. Bibliotheken werden von Amfang an geladen)
  • Session-Informationen müssen persistent gespeicher werden (SQL-Datenbank, Dateien)
• wird nicht (mehr) von allen Webservern unterstützt
• z.B. Mailman (Mailinglistensoftware)

mod-php in Apache

• Verhält sich ähnlich wie CGI
• PHP-Interpreter u. Bibliotheken bleiben dauerhaft geladen
• wird nicht von allen Webservern unterstützt
• Vorteil: effizienter als CGI
• Nachteil: nur für PHP

FastCGI

• Webapplikation startet selbstständig (ähnlich wie bei direkter Webapplikation)
• Nutzt idR. Unix-Socket f. Webserver-Anbindung
• Kommuniziert in binärem HTTP (inkompatibel mit Webbrowser)
• Webserver läuft als Reverse-Proxy HTTP ↔ Unix-Socket/FastCGI

WSGI, PHP-FPM, u.ä.

• ähnliches Konzept wie FastCGI
• WSGI: Unix-Socket-Protokoll für Python-Webapps
• PHP-FPM: Unix-Socket-Protokoll für PHP

Andere Webserver

NGINX hat keine Unterstützung für php/cgi, oder mod-php. Webapplikationen laufen immer via FastCGI oder PHP-FPM (o.ä).

• häufiger Fehler:

  • NGinx-VHosts laufen unter eingeschränkten User-Rechten
  • aber Webapplikationen werden alle im selben php-fpm ausgeführt (nicht isoliert)

Lighttpd alternativer leichtgewichtiger Webserver, mit CGI- u. FastCGI-Unterstützung

CertificateAuthority

Am besten als dedizierter, unprivilegierter User-Account

~$  openssl  genrsa  >ca-root.key
~$  openssl  req  -x509 -key ca-root.key -days 14 -subj "/C=DE/ST=Berlin/
L=Berlin/O=damago/OU=fi17si1/CN=MeineKleineCA" >ca-root.cer

→ .cer-Datei aud dem Client einspielen

Site-Zertifikate

1. Site-Betreiber erstellt Key

2. Site-Betreiber erstellt Signing-Request

   • enthält Informationen, Domainnamen, etc. zur Zertifizierung
   • enthält Public Key
   • Wird an Certificate Authority (CA) gesendet
3. CA zertifiziert den Request (mit eigenem Private Key) → Dabei entsteht Site-Zertifikat (.cer-Datei)
4. Zertifikat wird an Site-Betreiber zurückgeschickt → enthält signierten ("zertifizierten") Public Key

~$  openssl  genrsa  >meine.domain.key
~$  openssl  req  -new  -subj /CN=meine.domain --addext "subjectAltName = DNS:meine.domain,DNS:nochne.domain,DNS:weitere.domain" --key meine.domain.key >meine.domain.req

Zertifizierung durch CA: openssl x509 -CA ca-root.cer -CAkey ca-root.key -req -in meine.domain.req -copy_extensions copy >meine.domain.cer

SSL-Webserver

Im Apachen werden TLS-VHosts analog zu HTTP-VHosts angelegt:

<VirtualHost *:443>
  ServerName    wikiwiesel
  ServerAdmin   webmaster@localhost
  DocumentRoot  /dev/null

  RewriteEngine  on
  RewriteRule    ^/(.*)$  unix:/srv/shellwiki.sock|http://egal/$1  [P]

  SSLEngine  on
  SSLCertificateFile     /etc/ssl/private/wikiwiesel.cer
  SSLCertificateKeyFile  /etc/ssl/private/wikiwiesel.key

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

<VirtualHost *:80>
  ServerAdmin webmaster@localhost
  DocumentRoot /var/www/html

  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>

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

~# apt install dehydrated
~# dehydrated --register

SSL-Zertifikate installieren

Für Chromium (als Benutzer):
~$ certutil -d ~/.pki/nssdb/ -A -t -C,, -n "Freitextname" -i ca-root.cer

Firefox (systemweit):
/etc/firefox/policies/policies.json:
{ "policies": { "Certificates": { "Install": [ "/etc/ssl/...", "/usr/share/ca-certificates/..." ] } } }

Debian für alle anderen Porgramme (systemweit):

• Datei kopieren nach /usr/share/ca-certificates
• eintragen in /etc/ca-certificates.conf
• ~# update-ca-certificates