Wood-IT

SSL-Truststores

2026-04-01T20:00:00+02:00

OK, dann wollen wir mal schauen. Zum einen wollen wir uns über die Systeme her machen. Zum anderen aber auch über Browser.

System-Truststores

Was ist denn nun ein "System-Truststore" im allgemeinen ?

Grundsätzlich kennen wir im Linux-Umfeld hier mehrere, z.b. betreffend der Paketverwaltung, wo viele Distributionen einen GPG-Truststore pflegen. Diesen wollen wir hier aber nicht betrachten.

Wir wollen uns hier einmal mit SSL/TLS-Truststores beschäftigen. Viele Systeme kennen hier Pakete wie bspw. ca-certificates.

Debian/Ubuntu

Unter Debian/Ubuntu ist die Sache relativ einfach. Es gibt hier das Paket ca-certificates, welches auch ein paar Helper-Scripte beinhaltet. Die Dateien befinden sich in 2 Pfaden. /usr/share/ca-certificates sowie /etc/ssl/certs. Wobei hier die Truststore-Datei selbst unter /etc/ssl/certs/ca-certificates.crt zu finden ist.

Die Truststore_Datei ist dabei einfach eine Liste aller konfigurierten und somit erlaubten Zertifikate im PEM-Format.

Bearbeiten

Allgemein kann man die vorhandenen Zertifikate anhand einer Konfigurationsdatei unter /etc/ca-certificates.conf ggf. ausschließen. Hier werden alle im Paket enthaltenen Zertifikate gelistet. Einträge beginnend mit ! deaktivieren einen Eintrag. Gleichzeitig kann diese Datei auch über den Konfigurationshelper per dpkg-reconfigure ca-certificates erstellt/bearbeitet werden.

Nachfolgend ist auf jeden Fall die Neuerstellung des Truststores notwendig, welche per update-ca-certificates¹ durchgeführt wird.

Manuelle Einträge

Zusätzlich dazu werden bei der Neuerstellung zusäzlich Zertifikate im Pfad /usr/local/share/ca-certificates berücksichtigt. Diese werden bei Script-Ausführung automatisch dem Truststore hinzugefügt.

Fedora

Auch in anderen Distributionen wird dies natürlich entsprechend behandelt. Hier gilt ähnliches, auch das Paket nennt sich bei Fedora ca-certificates.

Auch eine wie unter Debian beschriebene Funktion ist verfügbar, und auch die Endpfade sind durchaus ähnlich. Der Pfad ist wieder /etc/ssl/certs/ca-certificates.crt, hier jedoch ein Symlink auf eine andere Datei tls-ca-bundle.pem. Das Utility nennt sich hier update-ca-trust, und die automatisch einzupflegenden Cert-Files kommen nach /etc/pki/ca-trust/source/anchors/.²

Bearbeiten

Des weiteren gibt es aber noch ein allgemeines Bearbeitungsutility namens trust. Hier gibt es dann wieder die Möglichkeit, Zertifikate manuell hinzufügen zu können. Ebenfalls aber auch die Möglichkeit, Zertifikate zu entfernen.

Das Entfernen geschieht hier über 2 Möglichkeiten. Zum einen kann man das jeweilige Zertifikat als Parameter nutzen, wobei hier der Pfad zur Zertifikatsdatei gemeint ist. Des weiteren kann man eine ZertifikatsID nutzen, welche beim auflisten der Zertifikate mit dem Befehl dargestellt wird.

Nachstehend einmal ein einzelner Eintrag aus dem Truststore dargestellt:

pkcs11:id=%AD%6C%AA%94%60%9C%ED%E4%FF%FA%3E%0A%74%2B%63%03%F7%B6%59%BF;type=cert
 type: certificate
 label: thawte Primary Root CA - G3
 trust: anchor
 category: authority

ArchLinux

Und um es am Ende unserer Distributionen-Liste etwas kurz zu machen, können wir hier eine einfache Aussage treffen.

Unter ArchLinux gibt es ebenfalls ein Paket namens ca-certificates, und beim Tooling kommt das vorher beschriebene Tooling von Fedora zum Einsatz.³ Somit können wir dies einfach abkürzen.

Browser-Truststores

Doch wenn wir bereits einen Truststore im System haben, warum müssen wir dann auch noch über Browser reden ? Warum können Browser nicht einfach auch auf den Truststores des Systems aufbauen ?

Die Browser-Hersteller haben ihre eigenen Richtlinien, was die CAs angeht, welchen sie vertrauen. Bei Linux-Systemen wird hier sogar im genannten Paket der Truststore von Mozilla als Basis verwendet. Jedch möchten sich die Browser-Hersteller hier eine gewisse Unabhängigkeit wahren, und nutzen somit ihren eignen Truststore.

Somit können sie systemübergreifend, sowie auch plattformübergreifend einen vergleichbaren Truststore verwenden. Gleichzeitig können Anpassungen am Truststore unabhängig von den Betriebssystemen durchgeführt werden. Bspw. im Bereich der mobilen Endgeräte kann das von essentieller Notwendigkeit sein. Somit können wir auch auf älteren Android-Versionen noch mit aktuellen Webseiten kommunizieren. Zwar können ggf. Apps nicht mehr auf Schnittstellen zugreifen, aber die Browser-App funktioniert weiterhin. Und gleichzeitig definiert der Browser das Sicherheitsniveau.

Des weiteren besteht aber auch die Möglichkeit, bspw. in Firmenumgebungen benötigt, dass die Browser zur Laufzeit auch den System-Truststore mit verwenden. Ein Windows-AD-Server bspw. verwendet eine eigene CA zur Absicherung der Verbindungen. Oder auch interne Systeme verwenden aus Sicherheitsgründen eine eigene CA, damit außenstehende hier ggf. auf Probleme stoßen, bzw. weitere Absicherungsmaßnahmen getroffen werden können.

Somit muss dann natürlich dem Browser die notwendigen CA-Zertifikate bekannt gemacht werden.

Manuelle Bearbeitung

Doch was kann man tun, wenn man den Truststore des Browsers manuell bearbeiten will. Nachfolgend schauen wir uns dies einmal am Beispiel eines Firefox-Browsers an.

Unter Eistellungen -> Datenschutz und Sicherheit finden wir den Menu-Punkt Zertifikate verwalten.

Daraufhin öffnet sich dann ein Menu, welches unter anderem die Zertifizierungsstellen auflistet, welchen der Browser vertraut.

Hier können sie dann auch die vorher genannten Optionen durchführen. Sie können konfigurieren, was mit den einzelnen CAs durchgeführt werden darf, und ob diesen vertraut werden soll/darf. Sie können Zertifikate auch im Detail ansehen, falls gewünscht. Nachfolgend einmal eine kurze Übersicht über ein solches Zertifikat:

Aber das wichtigte, neben dem exportieren, ist wohl das importieren von CA-Certifikaten. Aus diesem Menu heraus können sie manuell eigene CA-Zertifikate im Truststore des Browsers hinterlegen.

Und auch wenn wir diesen Exkurs anhand des Browsers Firefox durchgeführt haben, gilt dies durchaus allgemein. Auch die anderen Browser können in ähnlicher Art konfiguriert werden.

ArchLinux, NVidia und Steam

2026-01-06T21:00:00+01:00

OK, zweiter Teil, neuer Spaß.
Aber was ist eigentlich passiert.

Linux und ältere Hardware

Eigentlich ist man ja gewohnt, dass bei Linux eher die ältere Hardware gut unterstützt wird. Doch an mancher Stelle ist dies etwas anders.

Daher noch einmal kurz zusammengefasst.
ArchLinux hat den Grafiktreiber für NVidia zum einen auf den OpenSource-Treiber umgestellt. Zum anderen wurde durch die entsprechende Version wieder mal eine Reihe von älteren Grafikkarten "vom Support abgeschnitten". Somit waren mit dem normalen Paket aus dem Repo keine Karten der Reihen GTX10xx¹ mehr zu betreiben. Und die Fachpresse² musste natürlich wieder berichten.

Doch ist das wirklich ein Problem ?
Allgemein eher nicht, denn auch bei ähnlichen Situationen konnte man früher bereits auf entsprechende Paket-Rezepte von Nutzern zurückgreifen, welche die älteren Treiber-Versionen weiterhin bereitstellen. Ja, wir reden hier vom AUR³, somit reden wir hier auch von "user-generated content", was ein pot. Unsicherheitsfaktor sein kann.

AUR und die Unsicherheit

Doch schauen wir uns das ganze einmal etwas genauer an. Welche Quellen⁴ nutzen wir denn hier eigentlich ?

Alle Inhalte werden von einem Nutzer namens "Ventureo" bereitgestellt. Dieser Nutzername sagt erst einmal nur wenig, mag aber durchaus bekannt sein. Und schauen wir uns einmal ein Paket⁵ genauer an, dann sehen wir 2 weitere Infos, voller Name, und EMail-Addresse.

Also zusammengefasst (Maintainer-Infos):

Name: Vasiliy Stelmachenok
Nickname: ventureo
EMail: ventureo@cachyos.org

Es handelt sich hier um einen Maintainer von CachyOS⁶, welcher auch dort die entsprechenden Pakete betreut. Und dieses System ist eine Abwandlung von ArchLinux, somit wird hier die gleiche Toolchain, und der gleiche Paketmanager verwendet. Ja, gewisse Optimierungen für die Architekturen werden hier getroffen, doch wenn wir einmal genauer hinschauen, dann werden sogar AUR-Pakete⁷ direkt für das CachyOS-Repository⁸ gebaut.

Der Vergleich

Wenn wir dies einmal im Detail vergleichen, dann finden wir folgendes:

Paket nvidia-580xx-dkms -> Bereitgestellt durch Paket-Branch nvidia-580xx-utils.git
Paket nvidia-580xx-dkms -> Soll seitens CachyOS aus Source-File https://aur.archlinux.org/cgit/aur.git/tree/?h=nvidia-580xx-dkms gebaut werden.

Ersteres beschreibt die Herkunft betreffend ArchLinux und AUR, letzteres kommt aus der Info-Seite von CachyOS. Wenn wir die erste Info kennen, und uns somit nicht von der Meldung abschrecken lassen, dass der Branch nicht existiert, haben wir die Quelle gefunden.

Somit ist hier einfach nachgewisen, dass die entsprechenden Inhalte nicht unsicher sind, sondern sogar in anderen Derivaten ebenfalls eingesetzt werden. Betreut auf beiden Seiten von der gleichen Person.

Und was ist nun das Problem

Doch was ist jezt das eigentliche Problem, ggf. auch in Richtung Steam⁹ ?

Wir reden hier davon, dass Steam nicht aus den normalen Repositories heraus installiert wird, sondern bereits ein zusätzliches Repository erfordert. Wir haben hier Multilib als zusätzliches Repository¹⁰ in Verwendung.

Somit mischen wir hier 32Bit-Pakete in ein 64Bit-System. Und auch dies ist natürlich betreffend der Grafikfunktionen zu beachten. Somit muss bei der entsprechenden Nacharbeit natürlich auch das Paket lib32-nvidia-580xx-utils mit installiert werden. Dann sollte es auch mit Steam und den Games klappen.

Und wie installiere ich aus diesem AUR ?

Es gibt in diesem Universum auch für diesen Fall ein paar Helfer¹¹. Diese geben verschiedentliche Funktionen, mglw. auch erweiterte Funktionen zur Paketinstallation, als auch Hinweise, bspw. diese offiziellen Announcements. Somit bekommt man bei der Paketinstallation auch bereits weitere Infos mit, ohne immer wieder auf die News-Seite schauen zu müssen.

Und natürlich halten viele dieser Helfer-Tools auch etwas auf sich. So melden diese normalerweise auch, dass das Paket aus dem AUR kommt, und ermöglichen eine vorherige Betrachtung, bevor das Paket gebaut wird. Der Nutzer wird also aktiv darauf hingewiesen, dass hier ein AUR-Paket verwendet wird, und dieses nun explizit lokal erstellt wird. Ebenso werden bei Updates die Änderungen dargestellt, so dass man ggf. böswillige Veränderungen erkennen kann.

Und was haben wir am Ende ?

Wenn wir dies nun einmal abschließend betrachten, was bleibt denn nun noch zu sagen ?

Wir haben ein Paket, was wir lokal bauen.
Die Informationen werden von einer vertrauenswürdigen Person bereitgestellt.
Die Informationen sind in einem GIT-System abgelegt, womit Veränderungen nachvollziehbar sind.
Der Nutzer wird aktiv informiert, und zur Kontrolle angehalten.

Wenn man dem Grundsatz¹² von ArchLinux nachgeht, und sich gewisse Diskussionen anschaut, dann versteht man gewisses Vorgehen etwas besser. Und betreffend der Treiber-Struktur betreffend NVidia war es bereits immer so. In den normalen Repos gibt es immer nur den aktuellen Treiber. Ggf. notwendige LTS-/Deprecated-Treiber werden allgemein per AUR bereitgestellt.

Nachfolgend noch eine Beispiel-Liste aus dem AUR:

nvidia-340xx-dkms
nvidia-390xx-dkms
nvidia-430xx-dkms
nvidia-470xx-dkms
nvidia-510xx-dkms
nvidia-525xx-dkms
nvidia-535xx-dkms
nvidia-550xx-dkms
nvidia-575xx-dkms
nvidia-580xx-dkms

Also wo ist hier etwas anders als zuvor ? Ich stelle durchgehendes Verhalten, und immer gleicher Umgang mit der Situation fest.

Und wenn wir die zugehörigen 32Bit-Pakete mit installiert haben, dann sollte auch Steam funktionieren.

ArchLinux, AUR und Downgrades

2026-01-04T17:30:00+01:00

Ein kleines Zwischenintermezzo mit ArchLinux und AUR. Doch was ist passiert ?

Das Problem

Ein ganz normaler Tag, und ein paar Updates, auch von Paketen aus dem ArchUserRepository¹ später. Es passieren Fehler.

Doch was ist das eigentliche Problem hier ?
Auch in diesem Fall kommt wieder der Community-Gedanke dazu, denn hier werden direkt an dem Paket auch entsprechende Kommentarfunktionen ermöglicht. Somit ist die Chance da, dass bereits andere dieses Problem analysiert² haben.

Und es stellt sich heraus, ist ein Upstream-Problem³ eines anderen Pakets, welches zwischenzeitlich aktualisiert worden ist.

Die Lösung

Also stellt sich die Frage, was man tun kann. Auch hier bietet der Kommentar entsprechende Möglichkeiten.

Zum einen hat bereits jemand dies gemeldet, und scheinbar gibt es auch bereits eine korrigierte Version des Codes. Nur leider hat noch niemand das Paket⁴ aktualisiert. Entsprechend ist aber bereits ein Hinweis am Paket, dass die Version "out of date" ist.

Also verbleibt noch Variante 2. Ein Downgrade⁵ auf eine vorherige Version, zumindest für die Zeit der Paketerstellung.

Paket-Archive

Also müssen wir uns einmal die Möglichkeiten klar machen.

Zum einen besteht die Möglichkeit, wie auch bei meinem System, dass im lokalen Dateisystem eine ältere Version noch existiert. Allgemein ist die Möglichkeit eines lokalen Paket-Caches ja durchaus verbreitet. Im Falle von ArchLinux ist hier der Pfad /var/cache/pacman/pkg/ der entsprechende Suchpfad. Hier befindet sich dann die notwendige Paketdatei.

Installation wäre somit möglich über bspw. pikaur -U /var/cache/pacman/pkg/deno-2.5.6-1-x86_64.pkg.tar.zst

ALternativ gibt es ein Archiv-Projekt⁶, unter welchem die älteren Paket-Versionen auf verschiedene Arten abgefragt werden können. Dieses beinhaltet einerseits alle Pakete, andererseits aber auch entsprechende Repository-Trees der einzelnen Tage. Somit besteht einerseits die Möglichkeit, der Installation einzelner älterer Pakete. Andererseits aber auch die Möglichkeit der Installation eines Paketstandes eines definierten Tages.

Auch hier wäre die Installation des notwendigen Pakets direkt per URL möglich. Also auf unser Beispiel bezogen mit pikaur -U https://archive.archlinux.org/packages/d/deno/deno-2.5.6-1-x86_64.pkg.tar.zst

Exkurs: AUR-Helper

Hier noch ein kleiner Zwischeneinwurf.

Es mag auffallen, dass ich hier nicht pacman als Befehl verwende, welcher ja der eigentliche Paketmanager unter Archlinux ist. Da wir hier auch mit dem Arch-User-Repository arbeiten, empfielt sich der Einsatz eines AUR-Helpers⁷.

Dies ist ein Helfer-Tool, welches die einfache Installation von AUR-Paketen ermöglicht. Ebenfalls aber auch deren Aktualisierung, wenn diese bereits installiert sind.

Und was die Sicherheit solcher Tools angeht, so ist hier, zumindest von organisatorischer Seite vorgeschrieben, eine entsprechende Prüf-Funktion eingebaut.

Somit wird zumindest immer abgefragt, ob man sich die Änderungen zur vorher installierten Version vor dem Update anschauen möchte. Gleiches gilt auch bei der Erstinstalltion, wobei dann der gesammte Inhalt visualisiert wird.

Die Durchführung

Und am Ende kommt es genau dazu.
Wir bringen das problematische Paket einmal auf die vorherige Paket-Version, mit dem oben bereits genannten Befehl.

Und nachfolgend können wir die normale Aktualisierung aller Paket nochmals anstoßen. Also ganz normal pikaur -Syu als Befehl verwenden. Doch würde dann nicht auch das aktuell manuell zurückgesetzte Paket erneut aktualisiert ?

Grundsätzlich ja, aber es gibt da einen Trick.

Anhand des Screenshots einmal genezeigt, verfügt der verwendete AUR-Helper hier über eine Komfort-Funktion, welche hier eingesetzt werden kann. Mit dem ShortKey m kann man die Paketliste der aktuell zu aktualisierenden Pakete manuell bearbeiten. Somit wurde hier einfach das problematische Paket, welches ja nur für die Erstellung des eigentlichen AUR-Pakets in dieser Version notwendig ist, manuell einmalig ignoriert.

Dadurch konnte das Paket am Ende erstellt und installiert werden. Und nachfolgend steht auch einer normalen Aktualisierung aller Pakete nichts mehr im Wege.

ArchLinux und NVidia-Treiber

2025-12-31T16:00:00+01:00

Was passiert, wenn mal wieder die "Fachpresse" gewisse Strukturen und Vorgehensweisen einer Distribution nicht richtig versteht?
Richtig, es hagelt komische Artikel!

Was ist passiert?

OK, was ist denn nun passiert?
Es gibt zum einen ein Announcement, welches zum einen eine Änderung des verwendeten Treibers ankündigt. Es wird zukünftig nicht mehr der proprietäre Treiber verwendet ¹, womit dabei auch gleichzeitig die Treiber-Version angehoben wird. Aus der Version 580.119.02 wird die Version 590.48.01, womit ältere Grafikkarten (namentlich genannt als "Pascal or older" -> GTX 10xx und älter) nicht mehr unterstützt werden.

Wer aber ArchLinux kennt, der wird auch wissen, dass hier nur eine Version seitens der offiziellen Paketrepos geschippt wird, und somit das Verhalten kein Problem seitens Archlinux, sondern seitens NVidia. Zumindest in der Auffassung von der Maintainer von Archlinux. Gleichzeitig wird aber auch ein entsprechender Weg für Personen mit älteren Grafikkarten aufgezeigt ².

Weitere Informationen findet ihr dann auch unten in den Notes zu diesem Beitrag.

Und warum regt man sich dann so auf?

Das muss man halt einmal die "Fachpresse"³ fragen.
Als Nutzer von ArchLinux kann ich mir dies nur mit "Unkenntnis" erklären. Auch deren verlinkte Quelle⁴ geht hierauf nicht weiter ein.

Dennoch können wir die Sache einmal weiter untersuchen. Ein Vertrauensproblem sehe ich hier auch nicht. Auch wenn es AUR-Pakete sind, und diese somit nicht seitens der Paket-Maintainer von ArchLinux selbst stammen, so ist der entsprechende Maintainer doch in der Community bekannt. Also sollte dies auch entsprechend passen.

Und was ist jetzt mit Steam ?
Naja, alles verraten will ich ja auch noch nicht. Wer hier weiteres wissen will, der kann im kommenden Jahr dann einmal an der ersten Runde Linux am Dienstag partizipieren. Dort werde ich das Problem einmal im Detail erläutern. Ebenso wird aber auch an dem Abend ein weiterer Artikel hier online gehen, welcher das Problem dann ebenfalls noch einmal im Detail erläutern wird.

Bis dahin, einen guten Rutsch ins neue Jahr, und wir hören uns.

Debian-Package-Dependencies

2025-12-16T22:00:00+01:00

Wieder einmal ein Dienstag, und die Verwirrung kommt einmal mit rein. Was man nicht so alles in seinem Alltag vorfindet, aber dann doch doch am Ende irgendwie sinn ergibt.

Aber kommen wir einmal zum Anfang des Problems.

Die Arbeit und der Azubi

Eines schönen Tages kommt der Azubi, und hat Fragen betreffend eines Tickets. Ziel der Aktion war es, einmal zu evaluieren, welche Pakete in den aktuellen Systemen wirklich benötigt werden.

Da wir uns im Umfeld von Debian-artigen Systemen, in diesem Fall sogar Debian selbst befinden, geht es um die Konfiguration betreffend Install-Recommends. Die Frage ist, welche Pakete "mitinstalliert" worden sind, weil die Konfiguration APT::Install-Recommends aktiviert ist. Und somit gab ich ihm ein Tool zur einfachen Generierung von Basis-systemen. debootstrap regelt hier durchaus gut.

Doch dann nahm das Schicksal seinen Lauf.

Das verschwundene Paket

Später am Tag kam der Azubi wieder, und fragte nach einem Paket, was in dem erstellten Verzeichnis existiert, aber manuell nicht installiert bekommt. Und so begann die Odyssey des Paketwahnsinns.

Ein Paket als Abhängigkeit von openssh-server, in diesem Fall lsb-base wurde nicht installiert. Wenn man allerdings das Paket als weiteres zu installierendes Paket bei debootstrap listet, dann wird das Paket installiert. Was ist hier also los ?

Die Analyse

LSB ist ein obsoleter Standard, welcher seitens Debian im Jahre 2015 gedroppt worden ist. Das Paket ist nur noch ein Meta-Paket, welches aufgrund vorhandener Abhängigkeiten existiert, und somit einfach ignoriert werden kann.

Also geben wir mal an den Azubi weiter, sich hier nicht weiter verwirren zu lassen, und das Paket zu ignorieren. Und der lustige Abend am Dienstag vor den heiligen Tagen war zumindest ein wenig von Gruppenverwirrung erfüllt, und das kollektive Wissen hat mal wieder obsiegt.

Auf jeden Fall haben wir mal wieder Dinge dazugelernt.

FrOSCon

2025-08-21T01:00:00+02:00

Und wieder ist ein Jahr vergangen. Es war mal wieder FrOSCon am letzten Wochenende.

Wieder einmal hat es mich nach Sankt Augustin verschlagen. Diesmal sogar mit mehr als der normalen Mission, ein paar Helfer-Schichten zu machen.

Der Workshop

Nachdem ich meinen Workshop bereits auf der GPN halten durfte, habe ich dies nun nochmals auf dieser Veranstaltung getan. Anhand des Publikums war es eher schwer, direkte Mitarbeit zu erhalten, da niemand so wirklich etwas vorzustellen hatte. Somit war die ganze Sache im Anfang etwas zäher als gedacht.

Der Eintieg war zwar wieder mit meinem eigenen Task betreffend "systemd-nspawn" erfolgt, aber danach kamen nur ein paar Fragen. Des weiteren kamen dann ein paar allgemeine Fragen, und wir waren weitegehend am Ende. Gut, dass ich hier ein paar Learnings aus der vorherigen Iteration von der GPN hier dann wieder erzählen konnte.

Falls hier jemand an den Details betreffend meinem Einstiegsbeispiel hat, so habe ich dies hier entsprechend dargestellt.

Die Helfer-Schichten

Auch in diesem Jahr habe ich mich wieder als Herald gemeldet. Somit konnte ich auch in diesem Jahr dem einen oder anderen Vortragenden eine Freude bereiten, und die Video-Crew unterstützten. Diese konnten sich somit auf die Aufzeichnung konzentrieren, und ich habe mich um den Vortragenden, und die Zuhörer bekümmert. Moderation der Fragerunden, und eine kurze Einführung in die Vorträge selbst, und alle hatten es etwas einfacher.

Dazu konnte ich dabei auch dem jeweiligen Vortrag lauschen, und ggf. sogar bereits vorher mich mit den Vortragenden austauschen. Es ist immer gut, das Thema ggf. bereits vorher zu kennen, damit man die Einführung dann besser gestalten kann.

Kleine Erkenntnisse

Und so nebenbei musste ich auch noch meine Garderobe etwas ergänzen. Da sitzt man sonntags Morgens gemütlich in einer Ecke, und wird doch für einen Studenten gehalten ?
Gut, dass gleich jemand anderes das aufklären konnte. Doch dass ich da schon zum Inventar gehören soll, war mir selbst nicht unbedingt bewusst. Dennoch konnte ich mich dann kurzfristig passend einkleiden, damit das auch für jeden ersichtlich wird.

Somit danken wir dem Floss-Shop, der den Merch-Verkauf hier übernommen hat.

Zusammenfassung

Also alles in allem wieder einmal eine schöne Veranstaltung.

Zwischenzeitlich ein wenig Zeit gehabt, mich mit einzelnen Personen auszutauschen. Verschiedenen Vorträgen beigewohnt und ansonsten die Aufzeichnungen der Vorträge auf dem System abgelegt, damit man sich dies nachfolgend noch anschauen kann.

Ansonsten ein kleines Problem betreffend dem Social-Event am Abend, aber das konnte die Orga noch bereinigen. Der Caterer hatte wohl etwas "verplant", weshalb die "Notfall-Pizzabestellung" ausgelöst werden musste. Trotzdem hatten wir alle Spaß am Abend, und konnten uns nochmals in etwas ungezwungenerer Atmosphäre austauschen.

Ein schönes Wochenende mal wieder in anderen Welten verbracht, so dass ich nun wieder erholt in eine Arbeitswoche starten konnte. Manchmal ist sowas einfach besser als Urlaub.