Benutzer-Werkzeuge

Webseiten-Werkzeuge


lpi14:start

LPI 2014/2015/2016

Mailingliste

Grundsätzliches

Vereinbarungen für die nächsten Veranstaltungen:

  • Jeder Teilnehmer bringt einen Rechner mit vorinstalliertem Linux mit.
  • Es wird ein Wiki eingerichtet. Gerüchteweise pflegt Thoto das Wiki.
  • Für ein Kapitel aus dem Prüfungskanon werden etwa zwei Sitzungstage kalkuliert.
  • Informationen laufen über die Kanäle Wiki und Mailingliste.

Lageplan:

Terminierung

Die Sitzungen finden 14-tägig Mittwochs um 19:00 Uhr statt.

Nächster Termin ist Mittwoch, 22.04.2015. Thema: fg bg jobs

Wir hoffen immer noch auf eine Boot-Demo eines efi-Laptops

Vorträge

  • 04.12.2014: Lothar – IRQs & Ressourcen
  • ??.??.20??: Julian – Rechte rwx
  • ??.??.20??: thoto – sort

Vergangene Themen

22.10.2014: Systemarchitektur

  • lspci, modprobe, insmod, rmmod also insgesamt Module
  • Festplatten
  • Kernel-Dinge im sysfs und proc, wie Interrupts und Ports
  • Rechte

05.11.2014: Systemarchitektur

  • MBR, dd, file
  • Hexadezimalzahlen mit $((0x...)), printf '%d\n' 0x… und perl
  • /proc/partitions
  • Rechte
  • Module, lspci -vv… und -k (1337 4223 vendor:device), …
  • /etc/modprobe.d, /etc/modules, …
  • dmidecode -t …

19.11.2014: Init

  • Runlevels
  • Berechtigungen
  • inittab
  • INSERT TOPIC HERE (kann mich nicht mehr erinnern … — thoto)

03.12.2014: Diverses

17.12.2014

14.1.2015

Frank erklärt uns am Mittwoch den Bootmanager grub2 mit(evtl. in einem 2. Teil) und ohne EFI sowie MBR und GPT

28.1.2015

Desaster!
Weil beide Vorträge nicht gehalten werden , weil die Leut' nicht da sind, kam der Rest umsonst und konnte unverrichteter Dinge wieder nach Hause.
Inzwischen klärte sich 50% dadurch, dass der Eine genau nur den Anderen informierte über unerwartet längere Arbeit/Verhinderung. Vom Anderen wissen wir noch nichts.
Alle Welt kommuniziert, und wir kriegen das nicht auf die Reihe ?
Also diesmal rechnen wir aber wirklich mit den Vorträgen (grub u. lilo)!

Da Jens Festplattenverschlüsselung betreibt/truecrypt nicht mehr ist und außerdem ein Linuxtreiber für Touch noch nicht zufriedenstellend arbeitet, ist sein Notebook leider z.zt. nur mit einem Win8.1 als einzigem OS versehen.

25.02.2015 lilo

Philipps lilo Vortrag zusammen mit den Fragen waren interessant:
Grub kennt bestimmte Filesysteme und ist komfortabler. Lilo ist unabhängig vom Filesystem, muß aber nach jeder Installation eines neuen Kernel mit „lilo“ aufgerufen werden und notiert sich neu die Sektoren in einer Datei namens map bzw. .map Ebenso nötig wenn man defragmentiert hat. Lilo eignet sich für Filesysteme die grub nicht kennt, die Platte/Partition darf allerdings weder verschlüsselt noch komprimiert sein. Kein „interactive command interface“ im Gegensatz zum Grub,

ansonsten einfach funktionierend gestrickt nach dem KISS-Prinzip: Keep It Simple Stupid.
lilo.example.conf und man-Page liefern weitere Infos.
Im Fehlerfall ist Grub toleranter und einfacher zu händeln. Im Nachgang stelle ich die Frage ob lilo noch hdd-Größenprobleme hat bzw. Lage der Partition ?
Ältere Diskussionen http://unix.stackexchange.com/questions/6498/what-is-the-difference-between-lilo-and-grub http://lwn.net/Articles/89772/

08.03.2015

Frank: VI Phip: Awk Thoto: sources und keys als Liste

22.4.2015

Fundsache: Leitfaden zur Installation auf UEFI-Rechnern http://wiki.ubuntu-forum.de/index.php?title=Benutzer:Klaus_P
fg bg jobs

6.5.2015

ergänztes Gedächnisprotokoll:

truecrypt vorige noch downloadbare,validierte Version sei nutzbar
www.abusemyskill.de/viewtopic.php?t=54

Truecrypt-Audit abgeschlossen: Truecrypt noch sicher? 
	https://www.youtube.com/watch?v=7oE5URUixuE
https://www.youtube.com/results?search_query=TrueCrypt+ist+sicher+
darunter Truecrypt-Container knacken mit Truecrack
	https://www.youtube.com/watch?v=Dgj11otG6w8

luks
cryptsetup benötigt superuser privileges
cryptsetup luksFormat /dev/sdc ;# dabei Passwort wählen
ls -la /dev/mapper ;# zeigt 	control

cryptsetup luksOpen /dev/sdc [Containername] ;# ??? Label ident. mit [Containername] ???
ls -la /dev/mapper ;# zeigt 	control
				[Containername] -> ../dm-0

cryptsetup luksClose /dev/sdc
cryptsetup luksDump /dev/sdc
	zeigt u.a. cipher mode
		Reinhard: xts-plain64
		Arno:     cbc-essiv:sha256
Container ist noch nicht formatiert
erst umount, dann luksClose ,dann sync (#welches kein sleep braucht, sondern es einfach synct)

pmount

bettercrypto.org pdf:

20.05.2015

Das Mapping eines verschlüsselten Gerätes erfolgt dynamisch über DeviceMapper. Hierzu lassen sich die aktuell verbundenen Geräte mittels

# dmsetup info

anzeigen. Hier erscheinen auch andere dynamisch verbundenen Block-Geräte, wie z.B. LVM-Geräte. Es wird ein dynamisches Mapping zwischen dem virtuellen Gerät (z.B. ein LVM-Volume wo kein zusammenhängendes physikalisches Gerät existieren muss) und einem virtuellen Namen z.B. „cryptfoo“ erstellt.

Zunächst wird mittels cryptsetup ein LUKS-Device wie gewohnt via

# cryptsetup luksFormat /dev/loop0

erstellt. /dev/loop0 sollte hierzu durch den Namen des physikalischen Gerätes getauscht werden. Hierbei können wie gewohnt auch die Cipher, der Hashalgorithmus und ähnliches angegeben werden.

Mittels

# dmsetup remove_all

können alle Mappings entfernt werden, die aktuell existieren. Obacht! Dies entfernt auch LVM-Geräte. Sei hier vorsichtig und hänge lieber mittels

# dmsetup remove /dev/loop0

aus.

Informationen über das LUKS-Volume können wir uns – ebenfalls wie gewohnt – mit

# cryptsetup luksDump /dev/loop0

anzeigen. Besondere Beachtung schenken wir nun den „Key Slot“s. Hier lassen sich wie nachfolgend erläutert Schlüssel eintragen. Standardmäßig sollte bereits das Schlüsselloch 0 gefüllt sein, dies geschieht gewöhnlich beim Erstellen des LUKS-Containers: Es enthält die Passphrase die wir eingangs eingegeben haben.

Unser Ziel ist es nun einen weiteren Schlüssel diesem Gerät hinzuzufügen, der als Datei vorliegt. In der Praxis könnte dieser beim Starten des Rechners auf einem USB-Stick an einem Server angestöpselt werden, damit kein Mensch extra zur Maschine laufen muss und dort eine Passphrase eingeben muss.

Hierzu ändern wir ein leeres Schlüsselloch auf den in der Datei „foo.key“ vorliegenden Schlüssel. Diesen erzeugen wir aus Zufallsdaten. Wer auf ausreichend Entropie warten möchten verwendet hierzu

# dd if=/dev/random of=foo.key bs=1024 count=4 iflag=fullblock

. Wer dies nicht möchte verwendet /dev/urandom.

 iflag=fullblock 

ist nötig, da /dev/random auch unvollständige Blöck ausgibt, die zu mangelhaften Schlüssel führen können.

Den soeben erstellten Schlüssel fügen wir nun mittels

# cryptsetup luksAddKey /dev/loop0 foo.key

hinzu. Hierzu muss ein valider Schlüssel des LUKS-Gerätes angegeben werden um das Gerät zu entsperren. Dies ist keine Phrase, die den angegebenen Schlüssel sperrt.

Weiterhin existiert die /etc/crypttab in der cryptsetup-Definitionen definiert werden können, sodass sie beim Systemstart automatisch geladen werden. Hier lassen sich der DeviceMapper-Name, des Containers, das physische Gerät und der zum entsperren notwendige Schlüssel angeben sowie weitere Optionen.

Ein beispielhafter Inhalt der Datei wäre folgender:

# <target name> <source device>                                         <key file>                      <options>
cryptfoo        /dev/disk/by-uuid/deadbeef-caff-ee12-3456-deadbeef1234  /home/thoto/cryptfoo.key        luks

Man beachte hierbei die erste, auskommentierte Zeile: Hier ist schon die Reihenfolge der Einträge angedeutet. Zunächst muss der Name für den DeviceMapper-Eintrag angegeben werden, gefolgt von dem physischen Gerät, auf dem der Container liegt. Im Beispiel wird das physikalische Medium mittels UUID (s.u.) referenziert und später unter /dev/mapper/cryptfoo entsperrt eingebunden. Eine Refernzierung mit UUID=… ist ebenfalls möglich.

Nachfolgend soll der Schlüssel zum Entsperren des Containers angegeben werden. Dieser kann per Datei, wie im Beispiel beschrieben, angegeben werden oder mittels „-“ oder „none“ über eine manuelle Eingabe während des Systemstarts angefordert werden. Beachte, dass während des Systemstarts nicht immer eine Person vor dem Rechner sitzt und dass Eingabegeräte bei allzu modernen Geräten nicht zwangsläufig zur Verfügung stehen (z.B. Bluetooth-Tastaturen: Hallo, Max! ;-)).

Zuletzt können Optionen für den Container angegeben werden. Würden wir dm_crypt o.ä. mittels cryptsetup verwenden, können wir hier nun cipher, hash u.ä. definieren. Wir verwenden jedoch LUKS und dies würde automatisch anhand der Signatur der Partition erkannt. Wir gaben hier jedoch LUKS an um den LUKS-Modus zu erzwingen. Daher werden auch hash, cipher, size usw. vollkommen automatisch erkannt. Weiterhin können hier auch Optionen wie noauto angegeben werden, die ein Entsperren der Partition während des Bootvorganges verhindern.

Beachte: Der Schlüssel steht bei nicht eingehängter Partiton während des Bootvorganges u.U. nicht zur Verfügung. Sorge dafür!

Schlussendlich erstellen wir einen Eintrag in der /etc/fstab der uns das Medium automatisch an eine bestimmte Position einhängt. Hierfür erstellen wir für unser ordnungsgemäß erstelltes xfs-Dateisystem im Container den folgenden Eintrag in der /etc/fstab:

/dev/mapper/cryptfoo    /media/cryptfoo xfs defaults,noatime    0   0

Die Spalten dieser Datei werden in einer nachfolgenden Veranstaltung genauer behandelt.

Ein Automounter kann auch dafür Sorgen, dass ein entsperrtes Medium automatisch eingehangen wird, oder dass ein heiß angeschlossenes Medium eine Abfrage zu dessen Entsperrung erzeugt (sofern LUKS verwendet wird, da dieses über einen entsprechenden Header inklusive Informationen u.A. auch über verwendete Verschlüsselungsalgorithmen und dessen Parameter verfügt). Als Beispiel hierfür seien UDisks und pmount erwähnt, wobei letzteres kein klassischer Automounter ist sondern vielmehr ein Tool ist, was einem Nutzer (ohne Superuser-Rechte) erlaubt eine Partition in den Dateisystembaum einzuhängen.

(Das war nun das gröbste … zufrieden, Reinhard? ;-) —thoto)

portforwarding 20.1.2016

bei Account ohne loginshell demonstrierte Max.
https://www.howtoforge.com/reverse-ssh-tunneling

3.2.2016

Da der Raum leider abgeschlossen und nebenan kein Internet war, wichen wir thematisch aus: Thoto zeigte uns erste Einblicke in KVM auf einem mit Knoppix-DVD 7.6.1 gebootetem Laptop.

Grundlegendes KVM mit serieller (und paralleler) Konsole, QEMU-Monitor und graphischer Anzeige über Ctrl-Alt-1 bis 4.

Erstellen von Festplatten-Abbildern für KVM in den Formaten qcow2 und raw (als sparse File):

qemu-img create -f qcow2 image.qcow2 100M
dd if=/dev/null of=image.img bs=1k count=0 seek=100k ;# 100 MB groß

Letzteres ist als Loop-Device mittels

 fdisk image.img 

formatierbar und mit kpartx als Partitionen ins System mapbar. Die Ausgabe von kpartx sollte wie folgt aussehen:

$ sudo kpartx -av image.img
add map loop0p1 (250:0): 0 202752 linear /dev/loop0 2048

Mittels kpartx -d … lässt sich das Device-Mapping wieder rückgängig machen. QCOW2 lässt sich ohne weiteres zunächst nicht mounten, ohne es zu konvertieren (mittels qemu-img convert …) oder per NBD-Server einzuhängen.

Danach wie üblich partition formatieren

sudo mkfs.xfs -L virtroot /dev/mapper/loop0p1

und einhängen

mount /dev/mapper/loop0p1 /mnt

und danach könnte man mittels debootstrap oder sonstigen Methoden ein System installieren.

Beim Booten lässt sich mittels -kernel und -initrd QEMU ein Kernel und Initramfs übergeben, was statt des gewöhnlichen emulierten BIOS-Bootloaders geladen wird. Über -append lässt sich die Kernel-Commandline angeben.

Die Installation eines Systems mit debootstrap konnte leider nicht erfolgen, da keine Pakete auf der Knoppix-Live-DVD und keine Internetverbindung zur Verfügung standen.

er ermittelte Bootparameterzeile

$ cat /proc/cmdline 
lang=de video=vga16fb:off apm=power-off nomce libata.force=noncq hpsa.hpsa_allow_any=1 loglevel=1
BOOT_IMAGE=linux64 lang=de apm=power-off initrd=minirt.gz nomce libata.force=noncq hpsa.hpsa_allow_any=1
loglevel=1

OpenVSwitch bietet gewisse Vorteile gegenüber herkömmlichen Verfahren zur Vernetzung von Virtuellen Maschinen wie VDE oder Bridges, da es switcht und OpenFlow-Unterstützung hat. Für Openvswitch ist bei altem Debian die Kompilierung des Datapath-Modules erforderlich (umständlich) bei hinreichend neuen Kernelversionen und Distributionen sollte dies bereits vorhanden sein. Z.Zt. ist OpenFlow ein Hype im Bereich SDN=SoftwareDefinedNetworking

Folgende Parameter haben wir KVM übergeben:

        -m 256M

256 MB RAM

        -display none -nographic -vga none

Mach alles aus, was Graphik ist. Sprich: Der Rechner verfügt letztendlich über keine virtuelle Graphikkarte.

        -chardev socket,server,port=12345,host=0.0.0.0,nowait,id=ser1
        -serial chardev:ser1

Mach eine serielle Schnittstelle und leite sie (wenigstens theoretisch) auf TCP-Port 12345 weiter.

        -chardev socket,id=mon1,server,path=foo,nowait
        -monitor chardev:mon1

Leite den QEMU-Monitor durch den man die laufende VM steuern kann in den UNIX-Socket ./foo weiter.

Für das Knoppix übergaben wir

        -cdrom /dev/sr0 -hda image.qcow2
        -kernel /mnt-system/boot/isolinux/linux64
        -initrd /mnt-system/boot/isolinux/minirt.gz
        -append "lang=de video=vga16fb:off apm=power-off nomce libata.force=noncq hpsa.hpsa_allow_any=1 loglevel=1 BOOT_IMAGE=linux64 lang=de apm=power-off nomce libata.force=noncq hpsa.hpsa_allow_any=1 loglevel=1 console=ttyS0"

was jedoch nicht erfolgreich war.

Auch eine serielle Konsole konnten wir nicht erreichen.

Ein Display, das nur über VNC erreichbar ist und keine SDL-Ausgabe macht erreichten wir durch

        -display none -vnc none 

Zum QEMU-Monitor verbindet man sich (entsprechendes netcat vorausgesetzt…) nun mittels

nc -U foo

Dort kann man beispielsweise ein VNC-Bildschirm öffnen mittels:

change vnc password
cnange vnc :1,password

Ersteres sollte eine Passworteingabe erzwingen, letzteres öffnet einen durch ein Passwort geschützen VNC-Server auf VNC-Display :1 (Port 5801 *fixme*).

Für VNC sollte vorher mit Parameter -k ein Tastaturlayout gesetzt sein, wenn man nicht en-us verwendet.

Weiterhin kann man im QEMU-Monitor ein Ctrl-Alt-Del senden mittels

sendkey ctrl-alt-delete

17.2.2016

kvm, diesmal mit bootstrap, dass allerdings mehr Platz=größere virtuelle Festplatte benötigte als vorher angezeigt wurde, Max wunderte sich darüber welche Pakete da alles trotz FIXME ohne recommended FIXME mitkommen.

lpi14/start.txt · Zuletzt geändert: 24.02.2016 00:12 von arno