Wenn 4 vnd nicht reichen!

Gut ob man gleichzeitig mehr als 4 verschlüsselte Container benötigt ist eine andere Frage. Wenn man sich aber per VMM oder QEMU eine Umgebung bauen will. Normalen Benutzern zwar das Programmieren ermöglichen will, aber nicht andauernd für installation irgendwelcher Module einen root bemühen zu müssen. Schon beim lernen, wie das mit Software RAIDs unter OpenBSD funktioniert, sind bei einem Raid10 gleich mal alle Plätze voll.

Bei den vnd (Virtual Node Device Driver) handelt es sich um fest in den Kernel eingebackene pseudo-devices. Wie oben schon erwähnt hat der Installationskernel 4 vnd eingbacken:vnd{0..3}
In einem meiner früheren Artikel hab ich schon mal gezeigt wie man sehen kann, wieviele vnd’s einem zur Verfügung stehen… hier eine kleine Auffrischung:

OpenBSD 6.1-current (GENERIC.MP) #72: Sat Jul  1 08:47:33 MDT 2017

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

$ doas vnconfig -l
vnd0: not in use
vnd1: not in use
vnd2: not in use
vnd3: not in use
$

Woraus man folgern kann, das man einen neuen Kernel braucht.

Beschaffen der Quellen

Ein Kernel zu bauen ist recht einfach unter OpenBSD… ich finde sogar wesentlich einfacher als unter Linux.
Das erste … nunja eigentlich sogar das einzige neben dem Grundsystem… was man braucht sind die Quellen.
Die BSD’s beschreiben sich ja als komplette Betriebssysteme. Also sind die Quellen auch für ein gesamtes Betriebssystem vorhanden. Da man aber nicht unbedingt alles braucht gibt es dort eine Aufteilung in 2 Paketen. Wobei das Paket src die Userland Quellen enthält, und das Paket sys, die des Kernels. Da für viele Anwendungen weder zusätzliche Programme noch ein x-window system benötigt werden, lasse ich ports und xenocara hier aussen vor.
Für die release und die stable Versionen sowie als basis für ein leichteres herunterladen von current aus der Versionverwaltung, kann man die sys.tar.gz von dem Mirror seines Vertrauens herunterladen… eine Liste gibts bei openbsd.org.
User der Gruppe wsrc dürfen, genauso wie root in den Ordner /usr/src schreiben, der traditionell der Pfad zu den Quellen ist. /sys (den Pfad brauchen wir nachher noch beim backen des Kernels) ist auch nur ein symlink zum Pfad /usr/src/sys, der vor nicht all zu langer Zeit eingeführt wurde, in 5.9 gabs den IMHO noch nicht.
Der Befehl cvs -qd anoncvs@mirror.osn.de:/cvs get -P sys im Pfad /usr/src, legt den Ordner sys an und speichert die aktuellen Kernel Source’n darin. Für den stable branch fügt man seinen cvs Befehlen noch ein (aktuell) -rOPENBSD_6_1 hinzu.
Ich hab da mal was vorbereitet:
Den User hatte ich kurz vorher in die Gruppe wsrc gesteckt und neu verbunden damit die neuen Gruppenrechte auch zur verfügung stehen. Hier sieht man auf einem current OpenBSD, wie man die aktuellen Kernel Quellen zur verfügung stellen kann, um dort einen neuen Kernel backen zu können.

OpenBSD 6.1-current (GENERIC.MP) #72: Sat Jul  1 08:47:33 MDT 2017

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

$ cd /usr/src
$ ftp -o sys.tar.gz http://ftp.halifax.rwth-aachen.de/openbsd/6.1/sys.tar.gz
Trying 137.226.34.46...
Requesting http://ftp.halifax.rwth-aachen.de/openbsd/6.1/sys.tar.gz
100% |***********************************************************************| 18754 KB    00:03
19204781 bytes received in 3.53 seconds (5.19 MB/s)
$ tar xzf sys.tar.gz
$ rm sys.tar.gz
$ cvs -qd anoncvs@mirror.osn.de:/cvs up -Pd
The authenticity of host 'mirror.osn.de (194.45.27.107)' can't be established.
ECDSA key fingerprint is SHA256:plj+1CPTaKi0AIId/aDMCGgZZnkxc1ow+ffBNMvYW4A.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mirror.osn.de,194.45.27.107' (ECDSA) to the list of known hosts.
U sys/arch/alpha/alpha/locore0.S
U sys/arch/amd64/amd64/locore0.S
U sys/arch/arm64/arm64/cpu.c
U sys/arch/arm64/arm64/locore0.S
U sys/arch/arm64/dev/agintc.c
U sys/arch/armv7/armv7/locore0.S
U sys/arch/hppa/hppa/locore0.S
U sys/arch/i386/i386/locore0.S
U sys/arch/landisk/conf/ld.script
U sys/arch/landisk/landisk/locore0.S
U sys/arch/loongson/loongson/locore0.S
U sys/arch/macppc/conf/ld.script
U sys/arch/macppc/macppc/locore0.S
U sys/arch/octeon/dev/octciu.c
U sys/arch/octeon/octeon/cn3xxx.dts
U sys/arch/octeon/octeon/cn3xxx_dts.S
U sys/arch/octeon/octeon/locore0.S
U sys/arch/sgi/sgi/locore0.S
U sys/conf/makegap.sh
U sys/crypto/aes.c
U sys/crypto/aes.h
U sys/dev/acpi/efi.h
U sys/dev/fdt/dwmmc.c
U sys/dev/fdt/ehci_fdt.c
U sys/dev/fdt/if_dwge_fdt.c
U sys/dev/fdt/rkclock.c
U sys/dev/fdt/rkclock_clocks.h
U sys/dev/fdt/rkgpio.c
U sys/dev/fdt/rkgrf.c
U sys/dev/fdt/rkpinctrl.c
U sys/dev/fdt/sdhc_fdt.c
U sys/dev/pci/drm/drm_atomic.c
U sys/dev/pci/drm/drm_atomic_helper.c
U sys/dev/pci/drm/drm_atomic_helper.h
U sys/dev/pci/drm/drm_bridge.c
U sys/dev/pci/drm/drm_crtc_internal.h
U sys/dev/pci/drm/drm_displayid.h
U sys/dev/pci/drm/drm_dp_mst_helper.h
U sys/dev/pci/drm/drm_dp_mst_topology.c
U sys/dev/pci/drm/drm_internal.h
U sys/dev/pci/drm/drm_linux_atomic.h
U sys/dev/pci/drm/drm_mipi_dsi.c
U sys/dev/pci/drm/drm_mipi_dsi.h
U sys/dev/pci/drm/drm_modes.h
U sys/dev/pci/drm/drm_modeset_lock.c
U sys/dev/pci/drm/drm_modeset_lock.h
U sys/dev/pci/drm/drm_panel.c
U sys/dev/pci/drm/drm_panel.h
U sys/dev/pci/drm/drm_plane_helper.c
U sys/dev/pci/drm/drm_plane_helper.h
U sys/dev/pci/drm/drm_probe_helper.c
U sys/dev/pci/drm/linux_list_sort.c
U sys/dev/pci/drm/linux_types.h
U sys/dev/pci/drm/linux_ww_mutex.h
U sys/dev/pci/drm/i915/i915_cmd_parser.c
U sys/dev/pci/drm/i915/i915_gem_batch_pool.c
U sys/dev/pci/drm/i915/i915_gem_batch_pool.h
U sys/dev/pci/drm/i915/i915_gem_fence.c
U sys/dev/pci/drm/i915/i915_gem_gtt.h
U sys/dev/pci/drm/i915/i915_gem_render_state.c
U sys/dev/pci/drm/i915/i915_gem_render_state.h
U sys/dev/pci/drm/i915/i915_gem_userptr.c
U sys/dev/pci/drm/i915/i915_guc_reg.h
U sys/dev/pci/drm/i915/i915_guc_submission.c
U sys/dev/pci/drm/i915/i915_params.c
U sys/dev/pci/drm/i915/i915_vgpu.c
U sys/dev/pci/drm/i915/i915_vgpu.h
U sys/dev/pci/drm/i915/intel_atomic.c
U sys/dev/pci/drm/i915/intel_atomic_plane.c
U sys/dev/pci/drm/i915/intel_audio.c
U sys/dev/pci/drm/i915/intel_csr.c
U sys/dev/pci/drm/i915/intel_dp_mst.c
U sys/dev/pci/drm/i915/intel_dsi.c
U sys/dev/pci/drm/i915/intel_dsi.h
U sys/dev/pci/drm/i915/intel_dsi_panel_vbt.c
U sys/dev/pci/drm/i915/intel_dsi_pll.c
U sys/dev/pci/drm/i915/intel_fbc.c
U sys/dev/pci/drm/i915/intel_fifo_underrun.c
U sys/dev/pci/drm/i915/intel_frontbuffer.c
U sys/dev/pci/drm/i915/intel_gtt.c
U sys/dev/pci/drm/i915/intel_guc.h
U sys/dev/pci/drm/i915/intel_guc_fwif.h
U sys/dev/pci/drm/i915/intel_guc_loader.c
U sys/dev/pci/drm/i915/intel_hotplug.c
U sys/dev/pci/drm/i915/intel_lrc.c
U sys/dev/pci/drm/i915/intel_lrc.h
U sys/dev/pci/drm/i915/intel_mocs.c
U sys/dev/pci/drm/i915/intel_mocs.h
U sys/dev/pci/drm/i915/intel_psr.c
U sys/dev/pci/drm/i915/intel_renderstate.h
U sys/dev/pci/drm/i915/intel_renderstate_gen6.c
U sys/dev/pci/drm/i915/intel_renderstate_gen7.c
U sys/dev/pci/drm/i915/intel_renderstate_gen8.c
U sys/dev/pci/drm/i915/intel_renderstate_gen9.c
U sys/dev/pci/drm/i915/intel_runtime_pm.c
U sys/dev/pci/drm/radeon/radeon_dp_auxch.c
U sys/dev/pv/hvs.c
U sys/kern/kern_mutex.c
U sys/kern/subr_witness.c
U sys/kern/sys_futex.c
U sys/lib/libkern/arch/mips64/sync.S
U sys/net/fq_codel.c
U sys/net/fq_codel.h
U sys/sys/_lock.h
U sys/sys/futex.h
U sys/sys/witness.h
$

Das manuell Aufwendigste sollte damit geschafft sein. Wer sich tiefer für das Thema AnonCVS interessiert, kann sich hier die offizielle OpenBSD FAQ dazu anschauen.

Vorbereitung des Custom Kernels

Die Anleitung für eigene Kernel von OpenBSD rät zum Wechsel in den Ordner /sys/arch/$(machine)/conf was wie ich vorhin schon erwähnt habe durch den symlink auf /sys dem Ordner /usr/src/sys/arch/$(machine)/conf entspricht. OpenBSD rät ebenfalls, eine Kopie von GENERIC zur erstellen und diese dann zu bearbeiten. Das ist in unserem Fall aber nicht sonderlich hilfreich… da sich die vnd Einträge garnicht dort befinden.
Man sollte ausserdem das GENERIC als Kopie anlegen, das man wirklich verwenden will… in meinem Beispiel ist zu sehen, das ich einen MultiProcessor Kernel verwende. GENERIC ist allerdings der SingleProcessor Kernel den ich je diesmal eh nicht ändern möchte. Ich lege eine Kopie von GENERIC.MP an, die ich zwar auch nicht ändern werde, aber mit einen anderen Namen will. Der GENERIC.MP greift auf den GENERIC Kernel zu. Wenn ich Änderungen daran in einer anderen Datei speichere, muss ich diese include verlinkungen ebenfalls anpassen. Wäre am saubersten… aber dafür bin ich zu pragmatisch, oder faul je nachdem wie man es sieht. Ich will nur die Dateien anpassen müssen die ich auch wirklich brauche. Im Fall mit den vnd’s: /sys/config/GENERIC. Verwiesen wird auf diese im GENERIC der Architektur mit der Zeile: include "../../../conf/GENERIC". Dort befinden sich, wer hätte es gedacht, Architektur übergreifende Konfigurationen. Wie z.B. pseudo-device vnd 4 # vnode disk devices.
Ich will davon Fünfzehn, nur so als POC. Also diesen Eintrag von 4 auf 15 ändern und speichern.

Backen des Kernels

Man macht danach sinngemäss mit der Anleitung weiter. In meinem Beispiel:

$ config CUSTOM.MP
$ cd ../compile/CUSTOM.MP
$ make

Wartet bis alles durchgelaufen ist.
Bewegt den alten Kernel /bsd an eine anderen Platz bzw. Namen. Kopiert den neuen Kernel obj/bsd nach /bsd und passen den Besitzer noch mit chown root:wheel /bsd an.
Diesen Vorgang beendet man dann noch mit einem reboot.

via boot-config

update 2017-12-11

Man kann auch den laufenden Kernel mit config -ef /bsd entsprechend anpassen:

doas cp /bsd /bsd.4vnd
doas config -ef /bsd
OpenBSD 6.2-current (GENERIC.MP) #267: Sat Dec  9 19:08:28 MST 2017
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Enter 'help' for information
ukc> find vnd
443 vnd count 4 (pseudo device)
ukc> help
        help                                Command help list
        add             dev                 Add a device
        base            8|10|16             Base on large numbers
        change          devno|dev           Change device
        disable         attr val|devno|dev  Disable device
        enable          attr val|devno|dev  Enable device
        find            devno|dev           Find device
        list                                List configuration
        lines           count               # of lines per page
        show            [attr [val]]        Show attribute
        exit                                Exit, without saving changes
        quit                                Quit, saving current changes
        timezone        [mins [dst]]        Show/change timezone
        bufcachepercent [number]            Show/change BUFCACHEPERCENT
        nkmempg         [number]            Show/change NKMEMPAGES
ukc> change 443
443 vnd count 4 (pseudo device)
change [n] y
count [4] ? 15
443 vnd changed
443 vnd count 15 (pseudo device)
ukc> quit
Saving modified kernel.
doas reboot

Das sollte einen genauso weit bringen, wie der Weg über die Kernel Quellen. Es ist aber sicher kein Fehler beide Wege zu kennen und einmal ausprobiert zu haben.

Nachbereitung und Abschluss

Das er mit dem richtigen Kernel gestartet hat erkennt man normalerweise an der Hinweiszeile in /etc/motd oder mit dem Befehl uname -v in denen jetzt der neue Kernel genannt wird.
Ganz fertig ist man zu diesem Zeitpunkt aber immer noch nicht. Zwar zeigt vnconfig -l schon die richtige Anzahl an vnd’s,

OpenBSD 6.1-current (CUSTOM.MP) #1: Fri Jul  7 17:29:30 UTC 2017

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

$ doas vnconfig -l
vnd0: not in use
vnd1: not in use
vnd2: not in use
vnd3: not in use
vnd4: not in use
vnd5: not in use
vnd6: not in use
vnd7: not in use
vnd8: not in use
vnd9: not in use
vnd10: not in use
vnd11: not in use
vnd12: not in use
vnd13: not in use
vnd14: not in use
$

vnd4 bis vnd14 sind aber noch nicht nutzbar.
Schuld daran ist, das die Devices nicht automatisch vom System mit angelegt werden.

$ ls /dev/vnd*
/dev/vnd0a /dev/vnd0i /dev/vnd1a /dev/vnd1i /dev/vnd2a /dev/vnd2i /dev/vnd3a /dev/vnd3i
/dev/vnd0b /dev/vnd0j /dev/vnd1b /dev/vnd1j /dev/vnd2b /dev/vnd2j /dev/vnd3b /dev/vnd3j
/dev/vnd0c /dev/vnd0k /dev/vnd1c /dev/vnd1k /dev/vnd2c /dev/vnd2k /dev/vnd3c /dev/vnd3k
/dev/vnd0d /dev/vnd0l /dev/vnd1d /dev/vnd1l /dev/vnd2d /dev/vnd2l /dev/vnd3d /dev/vnd3l
/dev/vnd0e /dev/vnd0m /dev/vnd1e /dev/vnd1m /dev/vnd2e /dev/vnd2m /dev/vnd3e /dev/vnd3m
/dev/vnd0f /dev/vnd0n /dev/vnd1f /dev/vnd1n /dev/vnd2f /dev/vnd2n /dev/vnd3f /dev/vnd3n
/dev/vnd0g /dev/vnd0o /dev/vnd1g /dev/vnd1o /dev/vnd2g /dev/vnd2o /dev/vnd3g /dev/vnd3o
/dev/vnd0h /dev/vnd0p /dev/vnd1h /dev/vnd1p /dev/vnd2h /dev/vnd2p /dev/vnd3h /dev/vnd3p
$

Zum anlegen von Devices gibt es das sh script /dev/MAKEDEV welches mit root Rechten ausgeführt werden muss. Das legt dann im momentanen Arbeitsverzeichnis das Device mit den gewünschten Namen an.
Man kann zwar alle benötigten Namen in eine Zeile packen aber das ist mir bei 11 Namen schon zu müssig:

# cd /dev/
# for i in $(jot 11 4); do ./MAKEDEV vnd$i;done
# ls vnd*
vnd0a  vnd10c vnd11e vnd12g vnd13i vnd14k vnd1m  vnd2o  vnd4a  vnd5c  vnd6e  vnd7g  vnd8i  vnd9k
vnd0b  vnd10d vnd11f vnd12h vnd13j vnd14l vnd1n  vnd2p  vnd4b  vnd5d  vnd6f  vnd7h  vnd8j  vnd9l
vnd0c  vnd10e vnd11g vnd12i vnd13k vnd14m vnd1o  vnd3a  vnd4c  vnd5e  vnd6g  vnd7i  vnd8k  vnd9m
vnd0d  vnd10f vnd11h vnd12j vnd13l vnd14n vnd1p  vnd3b  vnd4d  vnd5f  vnd6h  vnd7j  vnd8l  vnd9n
vnd0e  vnd10g vnd11i vnd12k vnd13m vnd14o vnd2a  vnd3c  vnd4e  vnd5g  vnd6i  vnd7k  vnd8m  vnd9o
vnd0f  vnd10h vnd11j vnd12l vnd13n vnd14p vnd2b  vnd3d  vnd4f  vnd5h  vnd6j  vnd7l  vnd8n  vnd9p
vnd0g  vnd10i vnd11k vnd12m vnd13o vnd1a  vnd2c  vnd3e  vnd4g  vnd5i  vnd6k  vnd7m  vnd8o
vnd0h  vnd10j vnd11l vnd12n vnd13p vnd1b  vnd2d  vnd3f  vnd4h  vnd5j  vnd6l  vnd7n  vnd8p
vnd0i  vnd10k vnd11m vnd12o vnd14a vnd1c  vnd2e  vnd3g  vnd4i  vnd5k  vnd6m  vnd7o  vnd9a
vnd0j  vnd10l vnd11n vnd12p vnd14b vnd1d  vnd2f  vnd3h  vnd4j  vnd5l  vnd6n  vnd7p  vnd9b
vnd0k  vnd10m vnd11o vnd13a vnd14c vnd1e  vnd2g  vnd3i  vnd4k  vnd5m  vnd6o  vnd8a  vnd9c
vnd0l  vnd10n vnd11p vnd13b vnd14d vnd1f  vnd2h  vnd3j  vnd4l  vnd5n  vnd6p  vnd8b  vnd9d
vnd0m  vnd10o vnd12a vnd13c vnd14e vnd1g  vnd2i  vnd3k  vnd4m  vnd5o  vnd7a  vnd8c  vnd9e
vnd0n  vnd10p vnd12b vnd13d vnd14f vnd1h  vnd2j  vnd3l  vnd4n  vnd5p  vnd7b  vnd8d  vnd9f
vnd0o  vnd11a vnd12c vnd13e vnd14g vnd1i  vnd2k  vnd3m  vnd4o  vnd6a  vnd7c  vnd8e  vnd9g
vnd0p  vnd11b vnd12d vnd13f vnd14h vnd1j  vnd2l  vnd3n  vnd4p  vnd6b  vnd7d  vnd8f  vnd9h
vnd10a vnd11c vnd12e vnd13g vnd14i vnd1k  vnd2m  vnd3o  vnd5a  vnd6c  vnd7e  vnd8g  vnd9i
vnd10b vnd11d vnd12f vnd13h vnd14j vnd1l  vnd2n  vnd3p  vnd5b  vnd6d  vnd7f  vnd8h  vnd9j
#

Damit sind die virtuellen Laufwerke bereit für den Einsatz. Als crypto Laufwerke, oder für einen Einsatzzweck den ich demnächst noch näher beschreiben möchte.

Dieser Beitrag wurde unter OpenBSD veröffentlicht. Setze ein Lesezeichen auf den Permalink.