Um einmal aufzuzeigen, wie effektiv Werbung die Bandbreite fressen kann erinnere ich mich an ein Studentenwohnheim, wo ein DNS Blocker als letzter Versuch herhalten musste um bei der damaligen Internet-Leitung etwas Linderung zu bringen. Remote-Desktop-Verbindungen in das Studentenheim waren erst durch den Einsatz des Blockers wieder möglich, da er die vielen eingebetteten Werbe-Videos auf Webseiten blockierte. Eine Idee auf die ich heute noch stolz bin.

Wenn man nach DNS Blockern im Netz sucht, stößt man unweigerlich auf AdGuard Home und PiHole und schier endlose Debatten, welcher nun besser sei. Da ich aber lieber Fakten und Zahlen sehe, habe ich mir in meinem Homelab auf meinem Proxmox Server, einem AMD EPYC 7282 16-Kerner, zwei Container eingebaut. Selbe Hardware, selbe Voraussetzungen via Docker.

Auf den ersten Blick sind beide Kandidaten Open Source Projekte mit ihrer Community, vielen (zusätzlichen) Blocklisten die man laden kann – also ziemlich alles was man so braucht. AdGuard Home kann auch noch DoH und DoT, welche ich hier in meinem Heimnetzwerk als Funktion nicht brauche, da ich meinem Netzwerk vertraue – Irgendwo muss man einmal die Linie ziehen. Um aber auch Verschlüsselung testen zu können habe ich einfach Traefik vor PiHole geklemmt. AdGuard punktet in Sachen Funktionalität noch zusätzlich dadurch, dass ’safe-search‘ erzwungen werden kann. Interessant mit Kindern, aber da ich hier das einzige Spielkind bin, vernachlässigbar. AdGuard punktet hier deutlich mit einfacheren Setup, wobei ich die Konfiguration über docker-compose ohne Assistenten bei piHole für meinen Andwendungsfall praktischer finde.

Die Einrichtung ist aber nicht wirklich etwas, was ich besonders oft mache – im Normalfall einmal und das war’s – also gibt es für mich nicht viel Unterschied. Also ab zur Benutzung.

Ich habe mich für die firehol.net-Blocklisten entschieden, welche ich der Fairness halber in beide Systeme eingespielt habe. Klarer Gewinner: PiHole, weil er diese auf einmal importieren kann. AdGuard hingegen mit seinem schickeren UI kann diese Funktion nicht.

Wie sieht es mit RAM Verbrauch aus? AdGuard hatte sich bei etwa 250 MB eingependelt:

PiHole, da ich diesen länger laufen hatte, hatte sich bereits bei 100 MB angesiedelt.

Angeblich sollte piHole mehr RAM fressen als AdGuard. Nichts was ich in meinem Versuch hier reproduzieren konnte – im Gegenteil.

Um jetzt zum DNS zu kommen – dort wo es nun wirklich interessant wird – schauen wir uns die Latenz an. Der Versuch besteht aus 2 Abfragen hintereinander, damit der DNS Zeit hat die Anfrage zu cachen und wir nicht auf externe DNS zurückgreifen müssen, die uns den test verfälschen. Um einfach einmal eine Baseline zu haben, fragte ich erstmal bei Googles 8.8.8.8 an und verwendete ‚time‘ um den ‚dig‘ command zu timen. Dabei zeigt ‚real‘ die vergangene Zeit an.

test@ts ~ $ time dig google.de @8.8.8.8

; <<>> DiG 9.16.41 <<>> google.de @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55953
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.de.                     IN      A

;; ANSWER SECTION:
google.de.              299     IN      A       142.250.180.227

;; Query time: 64 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Aug 02 15:00:37 CEST 2023
;; MSG SIZE  rcvd: 54


real    0m0.078s
user    0m0.004s
sys     0m0.004s

Google legt dank Netzwerklatenz mit 78ms vor. Nicht schlecht.

Mein interner Bind9 Server legte mit 43ms nach. Nicht wirklich super, aber auch nicht schlecht für das LDAP Backend und Krempel die dieser intern macht. PiHole zieht allen mit 18ms davon, während AdGuard Home mit 21ms den zweiten Platz belegt. Mit anderen Worten, die 3ms Unterschied merkt man im realen Betrieb nicht. Was heißt das jetzt für jeden Einzelnen? Ganz ehrlich: Ich würde beide Lösungen testen und dann sehen wie wichtig einem Statistiken bzw ein schickes UI sind. Ich für meinen Teil bleibe auf jeden Fall bei piHole, da mir adGuard Home keine Vorteile bringt.

Aber nun zum versprochenen Problem. Mein Server war installiert und ich begann die Kiste nach meinem Gutdünken mit Bridges zu erweitern – auch mit einem eigenen Push Server, da ich nicht unbedingt meine eigenen Apps bauen wollte, nur um mit dem Google Push Service zu interagieren. Die Installation lief und alles sah gut aus, außer dass der Matrix client nie aufgeweckt wurde. Eigene Push-Mitteilungen, die ich als Alarme nutzte, kamen sehr wohl an. Ich muss zugeben, Anfangs hatte mich die Ruhe nicht wirklich gestört, bis es einfach mal zu ruhig war und ich dieses ‚hier stimmt etwas nicht‘-Gefühl sich in der Magengegend manifestierte.

Unser Container produzierte brav Logfiles – und da war auch ein Hinweis, der mich alles nur nicht erleichterte:
Mar 18 23:30:14 matrix matrix-synapse[2213]: 2023-03-18 22:30:14,267 - synapse.push.httppusher - 432 - WARNING - httppush.process-17 - Failed to push event $bLGuzRj3t4p6Z6h16aTmfw9YA5gEhZZ0fZOebFToL04 to @user:domain/im.vector.app.android/https://ntfy.domain/upv5aFQWe5uAHe?up=1: DNS lookup failed: no results for hostname lookup: ntfy.domain.

Was war da los? War das Docker-Netzwerk im Eimer? War der DNS down oder nur falsch eingestellt? Ich hab‘ mir gleich einmal eine Shell an den Container geheftet und mit einigermaßen Frust festgestellt, dass der Container weder ‚ping‘ noch anderes Netzwerk-Werkzeug enthielt (was ja eigentlich nicht schlecht ist!). Nach einigen Geräuschemissionen fand ich dann aber doch die curl Binary und konnte versuchen, eine Nachricht an den Push Service abzusetzen…. Erfolgreich?

Okay – dann hatte die Meldung offenbar nichts mit dem DNS zu tun und hatte die gleiche Glaubwürdigkeit wie die Aussage eines Politikers. Demnach war der Schuldige definitiv der Synapse Server und ich hatte absolut keine Lust voreilig in dessen (teilweise echt furchteinflößendem) Code zu wühlen. Also nahm ich mir als erstes das Twisted Framework vor, welches dazu benutzt wurde den Service zu programmieren. Ein DNS Test Script war eine einfache Möglichkeit zu sehen, woran es liegen könnte. Zwei Sekunden und einen Wutschrei später war auch Twisted als Unschuldig außen vor.

Mit einer frischen Tasse Tee hatte ich mich dann ans Suchen und Code lesen gemacht und nach Stunden einen Hinweis in der Config gefunden:


# Prevent outgoing requests from being sent to the following blacklisted IP address
# CIDR ranges. If this option is not specified then it defaults to private IP
# address ranges (see the example below).
#
# The blacklist applies to the outbound requests for federation, identity servers,
# push servers, and for checking key validity for third-party invite events.
#
# (0.0.0.0 and :: are always blacklisted, whether or not they are explicitly
# listed here, since they correspond to unroutable addresses.)
#
# This option replaces federation_ip_range_blacklist in Synapse v1.25.0.
#
# Note: The value is ignored when an HTTP proxy is in use
#
#ip_range_blacklist:
# - '127.0.0.0/8'
# - '10.0.0.0/8'
# - '172.16.0.0/12'
# - '192.168.0.0/16'
# - '100.64.0.0/10'
# - '192.0.0.0/24'
# - '169.254.0.0/16'
# - '192.88.99.0/24'
# - '198.18.0.0/15'
# - '192.0.2.0/24'
# - '198.51.100.0/24'
# - '203.0.113.0/24'
# - '224.0.0.0/4'
# - '::1/128'
# - 'fe80::/10'
# - 'fc00::/7'
# - '2001:db8::/32'
# - 'ff00::/8'
# - 'fec0::/10'

# List of IP address CIDR ranges that should be allowed for federation,
# identity servers, push servers, and for checking key validity for
# third-party invite events. This is useful for specifying exceptions to
# wide-ranging blacklisted target IP ranges - e.g. for communication with
# a push server only visible in your network.
#
# This whitelist overrides ip_range_blacklist and defaults to an empty
# list.
#
#ip_range_whitelist:
# - '192.168.1.1'


Mein ntfy Service war in meiner DMZ und wurde auch (erfolgreich) von anderen Diensten verwendet. Das setzte ihn jedoch auf die Blockliste von Synapse und verursachte somit das Problem. Ein Einfacher Eintrag in der Whitelist hat die Sache dann erledigt. Ich fühlte mich für einen Moment echt großartig, das Problem gelöst zu haben… bis die Benachrichtigungen über ungelesene Nachrichten bei mir wieder eintrudelten. Vermisse ich die Ruhe nachdem ich den Fehler repariert hatte? Manchmal.

Um den Kernel überhaupt mit LTO zu bauen, sollte die Config mit folgenden Optionen versehen sein:

# CONFIG_STACKPROTECTOR is not set
CONFIG_LTO=y
CONFIG_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
CONFIG_HAS_LTO_CLANG=y
# CONFIG_LTO_NONE is not set
CONFIG_LTO_CLANG_FULL=y
# CONFIG_LTO_CLANG_THIN is not set

Compiling wäre ziemlich einfach, sobald wir die clang-11 Binaries (debian buster default) mit Symlinks in den Griff kriegen, damit sie von den Scripts auch gefunden werden. Ein Job für update-alternatives:

update-alternatives \
–verbose \
–install /usr/bin/llvm-config llvm-config /usr/bin/llvm-config-11 100 \
–slave /usr/bin/llvm-ar llvm-ar /usr/bin/llvm-ar-11 \
–slave /usr/bin/llvm-as llvm-as /usr/bin/llvm-as-11 \
–slave /usr/bin/llvm-bcanalyzer llvm-bcanalyzer /usr/bin/llvm-bcanalyzer-11 \
–slave /usr/bin/llvm-cov llvm-cov /usr/bin/llvm-cov-11 \
–slave /usr/bin/llvm-diff llvm-diff /usr/bin/llvm-diff-11 \
–slave /usr/bin/llvm-dis llvm-dis /usr/bin/llvm-dis-11 \
–slave /usr/bin/llvm-dwarfdump llvm-dwarfdump /usr/bin/llvm-dwarfdump-11 \
–slave /usr/bin/llvm-extract llvm-extract /usr/bin/llvm-extract-11 \
–slave /usr/bin/llvm-link llvm-link /usr/bin/llvm-link-11 \
–slave /usr/bin/llvm-mc llvm-mc /usr/bin/llvm-mc-11 \
–slave /usr/bin/llvm-nm llvm-nm /usr/bin/llvm-nm-11 \
–slave /usr/bin/llvm-objdump llvm-objdump /usr/bin/llvm-objdump-11 \
–slave /usr/bin/llvm-ranlib llvm-ranlib /usr/bin/llvm-ranlib-11 \
–slave /usr/bin/llvm-readobj llvm-readobj /usr/bin/llvm-readobj-11 \
–slave /usr/bin/llvm-rtdyld llvm-rtdyld /usr/bin/llvm-rtdyld-11 \
–slave /usr/bin/llvm-size llvm-size /usr/bin/llvm-size-11 \
–slave /usr/bin/llvm-stress llvm-stress /usr/bin/llvm-stress-11 \
–slave /usr/bin/llvm-symbolizer llvm-symbolizer /usr/bin/llvm-symbolizer-11 \
–slave /usr/bin/llvm-tblgen llvm-tblgen /usr/bin/llvm-tblgen-11 \
–slave /usr/bin/llvm-objcopy llvm-objcopy /usr/bin/llvm-objcopy-11 \
–slave /usr/bin/llvm-strip llvm-strip /usr/bin/llvm-strip-11

update-alternatives \
–verbose \
–install /usr/bin/clang clang /usr/bin/clang-11 100 \
–slave /usr/bin/clang++ clang++ /usr/bin/clang++-11 \
–slave /usr/bin/asan_symbolize asan_symbolize /usr/bin/asan_symbolize-11 \
–slave /usr/bin/clang-cpp clang-cpp /usr/bin/clang-cpp-11 \
–slave /usr/bin/ld.lld ld.lld /usr/bin/ld.lld-11

Nachdem das alles erledigt ist, kann man ans Compilen denken: make LLVM=1 LLVM_IAS=1 CC=clang HOSTCC=clang LD=ld.lld -j5 deb-pkg – aber Vorsicht: LTO wird einiges an RAM brauchen um seine Arbeit zu verrichten. Was Ergebnis betrifft, wie die Kernels performen oder wie stabil sie sind, kann ich noch nicht sagen. Aber Tests werden das in der Zukunft zeigen…

Der zweite Schritt war ein Build-Script, damit ich nicht alle Schritte händisch zu machen hatte und das Zeug sich selbst baut anstatt auf mich zu warten. Es war keine große Sache, ein einfaches Batch-Script, das seinen Job tat. Aber unterm Strich war es mir zu unflexibel für das, was ich das Script gebraucht habe. Aufgrund der fehlenden Fehlererkennung funktionierte das Script obendrein nur, wenn alles glatt lief – also in einer nicht-vorhandenen, perfekten Welt.

Also zurück an den Start:

Das Erste was ich brauchte, war Config-Management um die Konsistenz der Config für jeden Kernel zu gewährleisten. Git ist für solche Sachen großartig und Github bietet mir entsprechende Sicherheit gegen Plattenausfälle. Super.

Das nächste Problem, das ich lösen wollte war eine ‚Ein Script sie zu knechten‘-Lösung um nicht vier Scripts zu haben, die alle relativ das Gleiche tun. Also war es an der Zeit alles in Funktionen zu kapseln und einige IFs in den Code zu werfen um die vier Geschmacksrichtungen zu erhalten. Nicht ganz perfekt, aber schon eine weitere Verbesserung.

Unser nächstes Ziel war nun kaputte Builds bzw. Patches die nicht funktionierten – also alles was mir die Builds ruiniert – abzufangen. Das war kein großes Ding mehr, da ich ja alles in Funktionen aufgebrochen hatte. Bei Auftreten eines Fehlers konnte ich so sauber aussteigen ohne die Config wieder in mein Repo zurückzuschreiben, was mir am Ende einige Rollbacks meines Repos erspart.

Jetzt ist die Sache zwar schon funktionstüchtig, aber wenig komfortabel, da ich immer noch die exakte Kernel-Version heraussuchen musste um den neuen Kernel zu bauen. Ein bisschen curl hier, grep da und schon hatten wir die neueste Version herausgefunden:

KERNEL_VERSION=`curl -s https://www.kernel.org | grep -A1 latest_link | tail -n1 | egrep -o '>[^<]+' | egrep -o '[^>]+'`

Warum eigentlich alles in Bash? Ich muss zugeben, diese Frage wurde mir bereits einige male gestellt und die Antwort ist eigentlich nicht schwer: Ich will das Script leicht pflegen können und es in zB C zu schreiben würde mir keinen nennenswerten Vorteile bringen, da ich ohnehin viele shell-exec Aufrufe tätigen muss.

Das Script selbst tut seinen Job und was noch blieb war die Config auszulagern, wie ich in diesem Beitrag beschreibe, da ich diesen Artikel nicht noch weiter in die Länge ziehen wollte.

Erstmal vorweg: Konfigurationen in Scripts sind Benutzernamen, Server, entfernte Repositories, you name it. Alles was man halt so an Daten in so einem Script braucht. Gerade wenn man seine Scripts öffentlich macht, sollte man darauf achten, nichts zu leaken – denn Leute werden mit dem Zeug rumexperimentieren.

Also was ist die Lösung? Für mich war es vorweg einmal alle Benutzernamen und anderen Krempel in Variablen zu packen um sie leichter anpassen zu können und eventuelle Fehler von der vorherigen Problematik zu lösen. Ist jetzt nichts Großes, aber eine Voraussetzung für eine saubere Lösung.

Der nächste logische Schritt wäre ein externes Config-File. In Bash könnte so eine Lösung wie folgt aussehen:

source /home/myuser/test/config

Und das ist genau das, wo ich mir angefangen habe, Gedanken zu machen. Ein Script zu sourcen heißt es auszuführen. Mit anderen Worten, source ist eine Möglichkeit mit der Config – sofern jemand bösen Code reinbastelt richtig in Schwierigkeiten zu kommen – was sich jedoch durch einfache Tricks vermeiden lässt.

Meine Lösung sieht vor, die Config zu parsen anstatt sie auszuführen. Da Json sehr einfach und lesbar ist, habe ich mir gedacht, kann ich es auch gleich verwenden. Durch den Shell-Parser ‚jq‘ lassen sich Werte auslesen ohne die Datei auszuführen. Wenn ihr mehr auf XML steht, empfehle ich das XML Startlet.

Aber genug der Theorie. Gehen wir die Sache an einem Beispiel an. Eine einfache Config könnte wie folgt aussehen:

{ 
"username": "username-or-email",
"password": "the-password" 
}

In unserem Hauptscript können wir nun Daten mit jq auslesen:

USERNAME="$( jq -r '.username' "$config_file" )"

Und die Moral von der Geschicht‘: Parse deine Config, Exekutiere sie nicht!

Unter Linux ist es dank PAM sehr einfach, sich am System „irgendwie“ zu authentifizieren und auch diese Methoden zu kombinieren. In meinem Fall war ich es leid, beim Befehl ’su‘ oder ’sudo‘ immer wieder mein Passwort eingeben zu müssen und habe mir das U2F Modul namens pam_u2f.so geholt. Für Debian und Gentoo habe ich das Glück, dass das Modul als Paket verfügbar ist.

Die Konfiguration ist erschreckend einfach:

In /etc/pam.d/ finden sich diverse Services mit deren Modul-Konfigurationen – Manche davon sind Symlinks, aber das macht ja nichts. Man bekommt relativ schnell eine Idee, welche Config für welchen Dienst zuständig ist. Ich für meinen Teil habe mich für ’su‘ entschieden, da ich das am lokalen System – wie oben beschrieben – doch sehr häufig brauche.

Der Inhalt der Datei ist in meinem Fall sehr einfach gestrickt

auth            sufficient      pam_rootok.so 
auth            required        pam_wheel.so use_uid 
auth            include         system-auth 
account         include         system-auth 
password        include         system-auth 
session         include         system-auth 
session         required        pam_env.so 
session         optional        pam_xauth.so

Zugegeben, es ist der Standard-Inhalt der Datei unter Gentoo, den ich bislang nicht wirklich angefasst habe.  Hier finden sich die einzelnen Module mit ’sufficient‘ bis ‚required‘, was die Regeln der PAM Module in der letzten Spalte festlegt. Für meine Zwecke reicht es mir aus, dass ich eine Zeile in der auth-Sektion einfüge:

auth            sufficient      pam_u2f.so cue

Durch diese Zeile gebe ich an. dass es ‚ausreichend‘ ist, wenn ich mich mit dem Yubikey anmelde, und den zugehörigen PIN eingebe. Durch die Verwendung von ‚required‘ anstelle von ’sufficient‘ kann man natürlich auch die Authentifizierung zusätzlich zum Passwort verlangen, um das System noch sicherer zu gestalten, wovon ich bei der ersten Einrichtung tunlichst abrate um sich nicht aus dem System zu sperren!

Der Parameter ‚cue‘ sagt dem PAM Modul, dass es eine Nachricht ausgeben soll, wenn der Key gedrückt werden sollte. Alle weiteren Parameter finden sich unter https://developers.yubico.com/pam-u2f/

Nun haben wir zwar PAM gesagt dass es den Yubikey verwenden soll, aber das Ganze ist noch nicht fertig. Das System benötigt noch eine Registrierung der einzelnen Schlüssel und die Zuordnung zu den Benutzern: Dies passiert entweder in der Datei /etc/u2f_mappings oder für jeden User in ~/.ssh/u2f_keys

Die Dateien sind ähnlich und wie folgt aufgebaut:

<username1>:<KeyHandle1>,<UserKey1>,<Options1>:<KeyHandle2>,<UserKey2>,<Options2>:...
<username2>:<KeyHandle1>,<UserKey1>,<Options1>:<KeyHandle2>,<UserKey2>,<Options2>:...

Die Key-Handles bekommen wir durch

pamu2fcfg -uusername -opam://myorigin -ipam://myappid

Damit bekommen wir die eindeutige ID des Schlüssels und können sie so dem Benutzer zuordnen.

Um das Ganze zu testen ist es nicht nötig zu rebooten oder irgendetwas neu zu laden, da PAM seine Konfigurationen bei jedem Login liest.

Ich betreibe Graylog als meinen zentralen Log.Server, damit ich einfacher suchen und überhaupt in den Logs herumstochern kann. Eigentlich keine große Sache, bis ich mal ein Auge auf meinen DNS Traffic geschaut habe, welcher mit mehr als 3000 Anfragen auf 10 Minuten doch etwas viel zu hoch war. Am Ende waren es einfach Anfragen nach der IP des Log-Servers von zwei Access Points.

Ich hätte mir jetzt schon etwas wie Caching oder Ähnliches erwartet – aber offensichtlich wurde das nicht implementiert. Ich hab’s kapiert: Für Log-Server die IP verwenden.

In einem älteren Blogpost über ccache habe ich über die (un)Sinnhaftigkeit von ccache bei einem Gentoo-System geschrieben, da ein Cache erst bei wiederholtem Bauen der selben Prozedur greift. Also genau bei diesem Anwendungsfall, wo der Kernel mehrmals gebaut wird. Die Implementation ist einfach – der make Befehl wird mit CC=“ccache gcc“ erweitert und wir sind im Geschäft.

Damit dieser Post hier nicht nur leere Worte sind, hier ein paar Zahlen nach dem ersten gebauten Kernel, der wie üblich etwa eine Stunde baute:

cache hit (direct)                     0
cache hit (preprocessed)               0
cache miss                         15556
cache hit rate                      0.00 %
called for link                       29
called for preprocessing            2857
unsupported code directive             4
no input file                        682
cleanups performed                     0
files in cache                     46654
cache size                           7.2 GB
max cache size                      10.0 GB

Der erste Compile brachte keine Treffer im Cache und somit auch keine Zeitersparnis. Der zweite Durchgang hingegen zeigte ein paar Treffer. Die Ergebnisse:

cache hit (direct)                    34
cache hit (preprocessed)             774
cache miss                          7318
cache hit rate                      9.94 %
called for link                       28
called for preprocessing            1964
unsupported code directive             4
no input file                        682
cleanups performed                    17
files in cache                     53763
cache size                           8.8 GB
max cache size                      10.0 GB

Um noch mehr Geschwindigkeit herauszuholen wäre der Einsatz von distcc denkbar. Die Implementation ist genauso einfach durch die Erweiterung der CC Variable auf CC=’ccache distcc gcc‘ machbar, aber der Aufwand mit gleichen Compilern und besserem Netzwerk als ich hier zur Verfügung habe…

Damit dieses einzeln Installieren ein Ende hat, hilft nur ein sogenanntes Meta-Paket – ein Debian-Paket, das nur aus Abhängigkeiten besteht. Diese bauen wir mit dem Tool ‚Equivs‘, welches wir uns erstmal installieren müssen:

apt install equivs

Ist das Paket installiert, folgt das Erstellen der Paketkonfiguration:

equivs-control my-kernel-package

Dieser Befehl gibt uns eine Datei, die es anzupassen gilt – Augenmerk liegt dabei auf der Zeile „Depends:“, da wir dort unsere Abhängigkeiten, die gebauten Debian-Pakete, eintragen. Für den heute aktuellen Kernel sieht diese Datei wie folgt aus:

### Commented entries have reasonable defaults.
### Uncomment to edit them.
# Source: <source package name; defaults to package name>
Section: misc
Priority: optional
# Homepage: <enter URL here; no default>
Standards-Version: 5.9.10

Package: vanilla-kernel
Version: 5.9.10
Maintainer: Viktoria Rei Bauer <debian@example.com>
# Pre-Depends: <comma-separated list of packages>
Depends: linux-image-5.9.10,linux-headers-5.9.10,linux-libc-dev
# Recommends: <comma-separated list of packages>
# Suggests: <comma-separated list of packages>
# Provides: <comma-separated list of packages>
# Replaces: <comma-separated list of packages>
Architecture: amd64
# Multi-Arch: <one of: foreign|same|allowed>
# Copyright: <copyright file; defaults to GPL2>
# Changelog: <changelog file; defaults to a generic changelog>
# Readme: <README.Debian file; defaults to a generic one>
# Extra-Files: <comma-separated list of additional files for the doc directory>
# Links: <pair of space-separated paths; First is path symlink points at, second is filename of link>
# Files: <pair of space-separated paths; First is file to include, second is destination>
# <more pairs, if there's more than one file to include. Notice the starting space>
Description: <short description; defaults to some wise words>
Meta-Package for vanilla kernel built based on debian .config

Nachdem die Datei geschrieben ist, gilt es das Debian-Paket zu bauen:

equivs-build my-kernel-package

Das Ergebnis ist eine schicke deb-Datei, die man dann in sein Repository hinzufügen kann. Ich selbst nutze dafür den Sonatype Nexus.

Auf den Client-PCs muss dann nur das Repository in die sources.list aufgenommen und der PGP Key importiert werden und schon steht der Installation nichts mehr im Wege.