Daniel Wellermann

3D-Scan trifft Roller-Tuning: Passgenauen Ansaugbogen aus TPU drucken

Daniel Wellermann — Sun, 08 Nov 2026 00:00:00 GMT

# 3D-Scan trifft Roller-Tuning: Passgenauen Ansaugbogen aus TPU drucken **Kurzfassung:** Wer mich kennt, weiß: Ich liebe es, Probleme zu lösen. Praxisnah, machbar und ohne unnötigen Bullshit. Der originale Piaggio-Luftfilterkasten der ersten Serie, der "Herzkasten", ist in der Szene heilig, passt ab Werk aber an keinen großen Tuning-Vergaser. Statt Heißluftföhn und Baumarkt-Schläuchen habe ich den Einbauraum per Photogrammetrie gescannt und einen strömungsoptimierten Ansaugbogen aus TPU gedruckt. ## Das Problem mit dem Gummi Wer einen Polini CP 19 auf einem Piaggio-Hyper2-Motor fahren, aber unauffällig und leise unterwegs sein will, behält den originalen Herzkasten. Das Problem: Winkel und Abstand zwischen Vergaserflansch und Luftfilterkasten passen einfach nicht zusammen. Die Standardlösung aus der Tuning-Szene: Den alten Originalschlauch mit dem Heißluftföhn weichkochen, mit Gewalt über den großen Vergaser würgen, drei Schlauchschellen drum und hoffen, dass das Konstrukt hält. Das sieht nicht nur nach Pfusch aus, es ist auch die Fehlerquelle Nummer eins für Falschluft und abgemagerte Motoren. Ein harter Knick im Ansaugweg sorgt zudem für Strömungsabrisse. Die Anforderung war für mich also klar: ein perfekt sitzender, strömungsoptimierter Bogen, der den Unterdruck bei 9.000 U/min problemlos aushält – und das mit Mitteln, die für jeden Maker erreichbar sind. ## Der Workflow: High-Tech trifft Low-Tech Um so einen Bogen im CAD sauber zu zeichnen, braucht man exakte Winkel und Abstände. Mit dem Messschieber im eingebauten Zustand am Moped herumzufuchteln, endet meist in zig fehlerhaften Prototypen. Meine Lösung: den kompletten Bauraum digitalisieren. Das Geniale an diesem Workflow: Ein Großteil der genutzten Programme ist Freeware oder Open Source. Man braucht keine teuren Lizenzen, um Probleme professionell zu lösen. ![Vergleich zwischen dem digitalen Modell in Blender und dem realen Einbauraum am Roller](/blog/reverse-tpu-ass/Vergleich-Plan-vs-Auswführung.webp) *Plan gegen Realität: Das CAD-Modell wird direkt mit dem bereinigten 3D-Scan abgeglichen.* ### 3D-Scan & der Zollstock-Trick Motor, Vergaser und Herzkasten wurden im eingebauten Zustand mit der Photogrammetrie-App Kiri Engine gescannt. Die nötigen Tracking-Marker habe ich mir einfach selbst gebastelt und aufgeklebt. Der wichtigste Low-Tech-Trick dabei: Ein simpler Zollstock lag mit im Scan-Bereich. Photogrammetrie-Scans haben oft keinen echten Maßstab. Mit dem Zollstock im Bild hatte ich eine perfekte Referenzgröße. ### Bereinigung in Blender Der rohe Scan ist oft krumpelig und voller Stördaten. In Blender, ebenfalls Open Source, habe ich das Modell anhand des Zollstocks mit wenigen Klicks auf den exakten Millimeter skaliert und bereinigt. ### CAD in Shapr3D Den maßstabsgetreuen Scan habe ich als 3D-Schablone in Shapr3D importiert. Mit den exakten Anschlusspunkten aus der Realität ließ sich der Radius für den Ansaugbogen millimetergenau modellieren. Kein harter Knick, sondern ein sanfter Sweep, damit die Luftsäule nicht abreißt. ### Kontrolle in Blender Abschließend wurden CAD-Modell und 3D-Scan noch einmal übereinandergelegt und geprüft. Das digitale Gummiteil saß im virtuellen Raum saugend zwischen Vergaser und Kasten. ## Druck & Material: Warum TPU? Ein starres Bauteil aus ASA oder PETG würde hier gnadenlos versagen. Der Motor vibriert in Gummi-Silentblöcken, der Kasten ist starr verschraubt – ein hartes Rohr würde brechen oder an den Schellen undicht werden. Das Material der Wahl: **TPU (Thermoplastisches Polyurethan)**. - Es ist flexibel genug, um die Motorvibrationen zu entkoppeln. - Es dichtet durch seine eigene Shore-Härte perfekt am Vergaser ab. - Es ist resistent gegen Benzin und Öl. Gedruckt wurde das Ganze mit OrcaSlicer, ebenfalls Open Source. TPU verzeiht keine Fehler bei Flow Rate oder Pressure Advance. Damit der Bogen bei vollem Ansaug-Unterdruck nicht wie ein leerer Strohhalm in sich zusammenfällt, braucht er Wandstärke – Fleisch. Mehrere Außenwände, also Perimeter, sorgen dafür, dass das Gummi flexibel, aber gegen den Unterdruck absolut formstabil bleibt. ## Ein pragmatisches Fazit Das Ergebnis spricht für sich. Vergaser und Luftfilter sind absolut spannungsfrei und zu 100 % dicht verbunden. Keine Falschluft, keine Strömungsabrisse, keine Kompromisse. Für mich ist dieses Projekt wieder der beste Beweis für meine Philosophie: Ein konkretes, mechanisches Problem erkennen und es dann mit den passenden, zugänglichen Werkzeugen praxisnah lösen. Handwerk ist Logik zum Anfassen – auch wenn es am Ende "nur ein Gummi" ist. Dein Browser unterstützt dieses Video nicht. *Der montierte TPU-Ansaugbogen.*

Zylinder abdrehen mit einem 3D-gedruckten Spreizdorn

Daniel Wellermann — Mon, 20 Jul 2026 00:00:00 GMT

# Custom-Werkzeug aus dem 3D-Drucker: Die perfekte Quetschkante **Kurzfassung:** Die 1,3 mm Quetschkante meines Malossi Sport 70ccm Zylinders war mir für den Alltag zu ineffizient. Um 0,3 mm auf der Drehbank plan und sicher abzutragen, habe ich mir kurzerhand einen Spreizdorn aus ASA-X gedruckt. Ein perfektes Zusammenspiel aus klassischer Zerspanung und modernem 3D-Druck. ## Das Problem mit dem Einspannen Grauguss-Zylinder lassen sich auf der Drehbank wunderbar zerspanen, aber das Einspannen ist oft ein heikles Thema. Spannt man außen an den empfindlichen Kühlrippen, machen sie bei etwas zu viel Druck schnell "Knack". Nimmt man stattdessen das dünne Kolbenhemd (den Laufbuchsen-Ansatz), droht man die feine Laufbahn unrund zu quetschen. Das Abdrehen des Zylinderkopfs wäre eine Alternative (z. B. sicher eingespannt über einen Dorn im Zündkerzengewinde), jedoch verringert man dabei gleichzeitig die Tiefe der O-Ring-Nut. Diese müsste dann aufwendig auf den Zehntelmillimeter exakt nachgestochen werden. Die eleganteste Lösung ist also, den Zylinder schonend, formschlüssig und zentriert von *innen* in der Laufbahn zu fixieren. Klassischerweise dreht man sich dafür einen Spreizdorn aus POM. Da bei mir aber ein 3D-Drucker steht, dachte ich mir: Warum an der Drehbank mühsam sägen und feilen, wenn man das Werkzeug im CAD auch smart konstruieren und drucken kann? ## Die Konstruktion: Smarter Vorrichtungsbau Ich habe mich als Material für **ASA-X (von CR3D)** entschieden. Es ist extrem temperaturstabil, schlagfest, hat eine bombastische Layerhaftung und lässt sich (im Gegensatz zu PLA) hervorragend auf der Drehbank zerspanen, ohne weich zu werden oder zu schmieren. Das Design im CAD war simpel, aber mit einigen technischen Kniffen versehen: * **Massiver Spannschaft:** Ein solider Block für den festen Sitz im 4-Backenfutter der Drehbank. * **Anschlagbund:** Ein breiter Teller, an dem der Zylinderfuß absolut plan im 90°-Winkel anliegen kann. * **Spreiz-Schaft:** Der Teil, der nachher saugend in die Zylinderbohrung ragt. * **Der 60°-Konus:** Vorne im Schaft direkt integriert, passend für die mitlaufende Körnerspitze meines Reitstocks. * **Integrierte Längsschlitze:** Vier Schlitze auf 75 % der Länge, die den vorderen Schaft flexibel machen. **Ein extrem wichtiges Detail (Der Kerbspannungsabbau):** Am Ende jedes Schlitzes, kurz vor dem Anschlagbund, habe ich Entlastungsbohrungen (kleine runde Löcher) eingefügt. Würden die Schlitze in einer harten 90°-Ecke enden, würde der Kunststoff beim Spreizen entlang der Schichten aufplatzen. Durch die kleine Rundung verteilt sich die Kraft im Material perfekt – das ASA-X federt, bricht aber niemals. ## Slicer-Settings für die Zerspanung Damit ein 3D-gedrucktes Teil auf einer Drehbank funktioniert und spanend bearbeitet werden kann, braucht es vor allem eins: Fleisch. Die Slicer-Einstellungen müssen darauf ausgelegt sein: * **6 Außenwände (Perimeter):** Das ergibt knapp 2,4 mm massives Material am Rand. Wenn ich den Dorn später überdrehe, kratze ich nur die obersten Wände an, ohne das hohle Infill freizulegen. * **30 % Kreuzgitter-Infill:** Das war der absolute Sweet-Spot. Zu viel Infill, und der Dorn wird so steif, dass der Reitstock ihn nicht mehr auseinanderdrücken kann. 30 % stützen die Wände perfekt beim Abdrehen ab und lassen dem Dorn trotzdem die nötige Flexibilität. * **6 Schichten (Boden/Decke) bei 0,2 mm Schichthöhe:** Sorgt für maximale Stabilität an den Auflageflächen. ![Der 3D-gedruckte ASA-X Spreizdorn in der Hand](/blog/Zylinder-3D-Druck1.jpg) *Frisch aus dem Drucker: Der fertige ASA-X Spreizdorn. Gut zu erkennen sind die Entlastungsbohrungen am Ende der Schlitze, die ein Einreißen des Kunststoffs verhindern.* ## Perfektion durch absichtliches Übermaß Ein 3D-Drucker produziert immer kleine Z-Naht-Pickel oder minimale Schrumpfungen. Um einen 100 % perfekten Plan- und Rundlauf für das Werkzeug zu garantieren, habe ich den Spreiz-Schaft absichtlich mit Übermaß (47,3 mm) gedruckt. Ab damit ins 4-Backenfutter. Bei laufender Spindel habe ich den Anschlagbund einmal kurz plangezogen und den Schaft auf saugende ~46,95 mm abgedreht. Dadurch eliminiert man im Handumdrehen jede noch so kleine Druckungenauigkeit. Der Dorn lief fortan in meiner Maschinenspindel auf den Hundertstelmillimeter genau rund. ## Der Moment der Wahrheit Zylinder aufgeschoben, Reitstock-Spitze nachgeführt und in den konischen ASA-X Schaft gedrückt. Die gedruckten Lamellen bogen sich butterweich nach außen und pressten sich flächig gegen die Hohnung des Grauguss-Zylinders. Da wackelte absolut nichts mehr. ![Grauguss-Zylinder aufgespannt auf der Drehbank mit dem 3D-gedruckten Dorn](/blog/Zylinder-3D-Druck1.jpg) *Bombenfester Sitz: Durch die mitlaufende Körnerspitze im Reitstock wird das ASA-X von innen gegen die Zylinderlaufbahn gepresst. Zentriert und bereit zum Abdrehen.* Mit einem scharfen Meißel und moderatem Vorschub ließen sich die 0,3 mm von der Zylinderoberkante völlig stressfrei abdrehen. Ein letzter Handgriff mit feinem Schleifpapier, um die messerscharfe Innenkante der Laufbahn leicht zu entgraten und das Projekt war erfolgreich beendet. ## Ein unaufgeregtes Fazit Aus den werkseitigen 1,3 mm ist nun eine knackige, alltagstaugliche 0,9-0,95 mm Quetschkante geworden. Aber fast noch mehr Freude als das reine Tuning-Ergebnis macht mir das Werkzeug selbst. Es beweist einmal mehr, wie genial man traditionelle Zerspanungstechnik und modernen 3D-Druck miteinander verheiraten kann. Anstatt ewig lange herumzufeilen, reichte ein kurzer Ausflug ins CAD und an den Drucker. Das Resultat ist ein passgenaues Spezialwerkzeug, das von nun an einen festen Platz in meiner Werkstattschublade hat.

Wechsel zu Arch Linux

Daniel Wellermann — Sun, 24 May 2026 00:00:00 GMT

# Gedanken zum Wechsel: Warum ich von Fedora zu CachyOS gewandert bin **Kurzfassung:** Nach einer wirklich guten und stabilen Zeit mit Fedora nutze ich aktuell CachyOS mit der COSMIC Desktop-Umgebung. Kein Drama, kein "Fedora ist plötzlich schlecht". Es ist vielmehr eine kleine Reise zurück zu den eigenen Open-Source-Wurzeln, getrieben von einem leisen Bauchgefühl. ## Die Zeit mit Fedora: Ein ehrliches Danke Vielleicht erinnerst du dich an meinen [Beitrag über den Wechsel zu Fedora](/blog/wechsel-zu-fedora). Und um es gleich vorwegzunehmen: Ich nehme kein Wort davon zurück. Fedora hat mir exakt das geliefert, was ich damals gesucht habe. Es war die viel zitierte goldene Mitte. Eine Distribution, die einfach funktioniert, aktuelle Pakete liefert und mich nie im Stich gelassen hat. Warum also wechseln, wenn doch alles läuft? Manchmal ändern sich nicht die Systeme, sondern das Umfeld – und der eigene Blick darauf. Kürzlich wurde bekannt, dass Microsoft für seine Azure 4.0 Infrastruktur stark auf Fedora als Basis setzt. Versteh mich nicht falsch: Das ist für Fedora als Projekt vermutlich gut. Es beweist die technische Exzellenz der Distribution. Aber bei mir persönlich hat das den finalen Anstoß gegeben. Das Thema digitale Souveränität und Unabhängigkeit auf meinem privaten Desktop war mir schon immer extrem wichtig. Um ehrlich zu sein: Fedora war in diesem Bereich durch die tiefe Verwurzelung mit Red Hat (und IBM) für mich ohnehin immer schon ein kleiner Kompromiss, eine ständige Gratwanderung. Wenn nun aber weitere globale Tech-Giganten beginnen, massiv Ressourcen in ein Projekt zu leiten, verschiebt sich unweigerlich das Zentrum der Aufmerksamkeit. Es entsteht oft eine Enterprise-Lobby. Für mich war das schlicht der Moment einzusehen, dass die Balance für mich nun gekippt ist. Es ist kein Boykott gegen Fedora. Es ist einfach der konsequente Schritt zurück zu einem System, das komplett unabhängig agiert. ## Pragmatismus trifft auf Arch-Nostalgie So rückte das Arch-Ökosystem wieder in mein Blickfeld. Arch ist in seiner Struktur herrlich unaufgeregt und unpolitisch. Eine reine Community-Meritokratie. Früher hätte ich mir nun einen Kaffee gemacht und Arch liebevoll über das Terminal von Grund auf neu aufgebaut. Heute bin ich da ehrlich gesagt pragmatischer. Ich schätze meine Zeit. Und genau hier holte mich **CachyOS** ab. CachyOS nimmt mir die Fleißarbeit ab. Es liefert unter der Haube pures Arch Linux, optimiert für moderne Hardware, mit einer unglaublich hilfsbereiten Community im Rücken. Dass bei der Installation anfangs ein paar Pakete mehr auf der Platte landen als bei einem streng asketischen Vanilla-Arch, sehe ich mittlerweile sehr entspannt. Das System fühlt sich einfach unheimlich rund und flüssig an. Ein beruhigender Gedanke im Hinterkopf: Da CachyOS zu 100 % auf den Arch-Repositories aufbaut, habe ich keinen Vendor-Lock-in. Sollte das Projekt jemals einschlafen, nutze ich einfach Arch weiter. Keine Neuinstallation, kein Stress. ## Das Sicherheitsnetz: Btrfs, Snapper und Limine Wer an Rolling Releases denkt, hat oft sofort Sorge vor zerschossenen Updates. Zu meinen alten Arch-Zeiten habe ich dem entgegengewirkt, indem ich mir mühsam eigene Update-Skripte geschrieben und mit Btrfs-Snapshots sowie der GRUB-Integration hantiert habe. Das funktionierte, war aber mit ordentlich Pflegeaufwand verbunden. Es ist unglaublich erfrischend, dass ich das im Jahr 2026 nicht mehr muss. CachyOS bringt dieses Sicherheitsnetz direkt mit – und zwar augenscheinlich perfekt vorkonfiguriert. Vor jedem Paket-Update wird nun durch Snapper vollautomatisch ein Snapshot erstellt. Sollte ein neuer Kernel wirklich mal streiken, wähle ich im **Limine**-Bootmenü (das übrigens angenehm schlicht und modern ist) einfach den Stand von gestern. Es ist genau das Setup, das ich mir früher händisch gebaut habe – nur dass es heute einfach out-of-the-box funktioniert und mir die nötige Ruhe für den Arbeitsalltag gibt. ## COSMIC: Tiling, aber nur wenn ich will Auch auf dem Desktop gab es einen kleinen Wechsel. GNOME war lange mein Zuhause, aber ich wollte der neuen **COSMIC** Desktop-Umgebung eine echte Chance geben. Was mich daran hält? Die absolute Unaufgeregtheit, mit der es sich an *mich* anpasst, nicht umgekehrt. Das Tiling-System ist fantastisch durchdacht. Aber das Beste daran: Wenn ich an einem müden Freitagabend einfach nur klassische, schwebende Fenster herumschieben möchte, schalte ich das Tiling mit einem Tastendruck ab. Keine starren Konzepte, keine Kompromisse. Einfach ein Werkzeug, das funktioniert. ## Ein unaufgeregtes Fazit Es fühlt sich an wie nach Hause zu kommen, aber in eine renovierte Wohnung. Ich habe das grenzenlose AUR zurück, gepaart mit einem pragmatischen Setup und der Gewissheit, ein OS zu nutzen, das von der Community für die Community gebaut wird. Ist CachyOS nun die ultimative, fehlerfreie Lösung für alle Zeiten? Wahrscheinlich nicht. Die Reise mit Linux hört ja glücklicherweise nie wirklich auf. Aber für den Moment passt es einfach perfekt. --- ## Mein Setup (So wenig wie möglich, so viel wie nötig) Früher habe ich Stunden in Konfigurationsdateien verbracht und seitenlange Install-Skripte gepflegt. Heute lautet meine Devise: Wenn der Standard gut ist, bleibt er. Die Zeiten, in denen ich für Node.js externe Versionsmanager wie NVM brauchte oder Go umständlich als Tarball laden musste, sind unter Arch schlicht vorbei. Die Repositories sind so aktuell, dass ich meine gesamte Entwicklungsumgebung ganz entspannt und direkt über den Paketmanager beziehen kann. Auch bei der Shell halte ich es simpel. Statt wie gewohnt Zsh mit diversen Plugins aufzubohren, nutze ich dieses Mal schlicht **Fish**. Komplett ohne Plugins. Es ist out-of-the-box pfeilschnell, bringt grandioses Highlighting sowie Autovervollständigung mit und macht genau das, was es soll. Selbst die Konfiguration von `pacman` habe ich bisher nicht angerührt – es passt einfach. Mein System besteht aktuell aus einer überschaubaren Handvoll an Werkzeugen, die einfach ihren Job machen: - **Entwicklung:** Node.js, Go, Git und VS Code (als proprietäre Version entspannt aus dem AUR via `paru` bezogen). - **Kommunikation & Orga:** Thunderbird für E-Mails und KeePassXC als Passwort-Manager. - **Medien & Kreation:** VLC (oder mpv) für Medien und OBS Studio für Screencasts. - **System & Isolation:** Flatpak für alles, was strikt isoliert bleiben soll. - **Terminal:** `btop` – ein kleines bisschen System-Monitoring im Terminal darf dann doch nicht fehlen. *Das reicht erst einmal. Falls ich in den nächsten Wochen doch noch den Drang verspüre, tiefer in das System einzugreifen, gibt es dazu sicher irgendwann einen Nachtrag.*

Mein Wechsel zu Fedora

Daniel Wellermann — Fri, 15 Nov 2024 00:00:00 GMT

# Mein Wechsel zu Fedora **Kurzfassung:** Nach einem Jahr Ubuntu auf dem Desktop bin ich zu Fedora 43 gewechselt. Vanilla GNOME, Flatpak statt Snap, aktuelle Technologien mit QA – passt besser zu meinem Workflow. ## Ausgangslage Ich nutze Linux seit 2005. Nach vielen Jahren mit Arch (XFCE und GNOME) wollte ich etwas Neues auf dem Desktop, vor allem mit GNOME als DE. Ein Jahr mit Ubuntu zeigte mir, dass dessen Entscheidungen (Snap, starke Patches) nicht zu meinem Workflow passen. Ich respektiere Ubuntu – damit bin ich in die Linux‑Welt gestartet und es hat mich die ersten Jahre begleitet. Allerdings zwangen mich Ubuntu-Versionen 25.04 und 25.10 zweimal, den Kernel zurückzurollen. Das war mir in den letzten Jahren unter Arch nicht passiert. Fedora hatte ich noch nie wirklich ausprobiert. Kurzerhand entschied ich mich für Fedora 43. ## Warum Fedora - **Vanilla GNOME:** GNOME so, wie die Entwickler es vorgesehen haben — sauber und vorhersehbar. - **Leading edge mit QA:** Aktuelle Technologien (Wayland, PipeWire, Btrfs) werden früh geliefert, aber getestet. - **Flatpak statt Snap:** Bessere Integrations- und Paketphilosophie für Desktops. ## Der Knackpunkt: LTS vs. Rolling Release Zwei Extreme prägen oft die Linux-Desktop-Welt: *LTS* (wie Ubuntu) und *Rolling Release* (wie Arch). Bei LTS-Versionen rennst du auf dem Desktop nach einem Jahr immer neueren Softwarepaketen hinterher – für Entwickler, die aktuelle Toolchains brauchen, ein echter Krampf. PPA-Chaos vorprogrammiert. Arch Linux auf der anderen Seite ist großartig, erfordert aber dauerhafte Aufmerksamkeit (*Bleeding Edge*). Für mich bringt Fedora hier die goldene Mitte: Ein Release alle 6 Monate (*Leading Edge*). Ich habe brandaktuelle Pakete, profitiere von den neuesten Wayland-Optimierungen, aber das System wird vor dem Release gründlich durch die QA-Abteilung getestet. Kein Basteln am Wochenende, um einen zerschossenen Grafiktreiber nach einem Update via Pacman händisch reparieren zu müssen. ## Server vs. Desktop Meine Server laufen weiter auf Ubuntu LTS oder Debian. Desktop und Server müssen nicht dieselbe Distribution haben. Für servernahe Tests nutze ich Container (z. B. Distrobox oder LXC): ```bash distrobox create --image ubuntu:22.04 --name server-env distrobox enter server-env ``` ## Fazit Fedora ist mein aktueller Daily Driver. Moderne Software, fühlt sich schnell und stabil an. GNOME läuft deutlich runder als unter Ubuntu. Mal sehen, wie lange das so bleibt – und ob mich der Rolling-Release-Charme von Arch irgendwann zurückzieht. 👋 Bye bye apt, pacman — hello dnf. ## System-Setup Nach der Installation habe ich das System nach meinen Bedürfnissen eingerichtet. ### DNF-Konfiguration ```bash sudo nano /etc/dnf/dnf.conf ``` ```ini [main] gpgcheck=True installonly_limit=3 clean_requirements_on_remove=True best=False skip_if_unavailable=False max_parallel_downloads=10 fastestmirror=True ``` Anschließend ein Update durchgeführt: ```bash sudo dnf upgrade --refresh ``` ### Shell-Umgebung: zsh + Oh My Zsh Als langjähriger zsh-Nutzer war das einer der ersten Schritte: ```bash sudo dnf install zsh sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" ``` Zusätzlich habe ich `eza` als modernen `ls`-Ersatz installiert und entsprechende Aliases konfiguriert. ### GNOME Extensions Um GNOME noch produktiver zu machen, habe ich folgende Tools und Extensions installiert: ```bash sudo dnf install gnome-tweaks sudo dnf install gnome-extensions-app sudo dnf install gnome-shell-extension-appindicator sudo dnf install gnome-shell-extension-gsconnect ``` **Nautilus-Erweiterungen:** ```bash sudo dnf install nautilus-extension ``` ### Entwicklungsumgebung Meine gewohnte Toolchain: **Git-Konfiguration** ```bash git config user.name "Daniel Wellermann" git config user.email "..." ``` SSH-Keys konfiguriert für GitHub und meine Server (PVE, AdGuard, etc.) **Node.js via NVM** ```bash curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash nvm install node ``` **Go Language** ```bash wget https://go.dev/dl/go1.25.5.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.25.5.linux-amd64.tar.gz export PATH=$PATH:/usr/local/go/bin ``` **Visual Studio Code** Über das offizielle Microsoft-Repository installiert, damit Updates automatisch über DNF kommen. ### Anwendungen Die wichtigsten Programme für meinen Alltag: - **Thunderbird**: E-Mail-Client - **KeePassXC**: Passwort-Manager - **VLC**: Multimedia-Player - **OBS Studio**: Für Screencasts und Aufnahmen - **Shotcut**: Video-Editing - **Gradia**: Screenshot-Tool (als Flatpak) - **btop**: System-Monitoring im Terminal

NUC im Servergehäuse

Daniel Wellermann — Wed, 15 Nov 2023 00:00:00 GMT

# Projekt: NUC im Servergehäuse **Kurzfassung:** Intel NUC im Desktop-Gehäuse ist für ein strukturiertes Setup unpraktisch. Ich hab ihn in ein kompaktes Server-Chassis umgebaut – das Ergebnis ist leise, wartungsfreundlich und passt sauber ins Rack. ![Der fertige NUC Server im Gehäuse](/images/NUC_server_1.jpeg) ## Die Komponenten Für den Umbau war überschaubare Hardware nötig. - **Basis:** Intel NUC (hier: Modell mit i3-4010U) - **Gehäuse:** Ein kompaktes Servergehäuse (z.B. ein altes Firewall- oder Router-Chassis) - **Speicher (SSD):** `HP S700 1TB SATA` - **Arbeitsspeicher (RAM):** `motoeagle 16GB Kit (2x8GB) DDR3L 1600 MHz SODIMM` - **Befestigung:** Starkes, doppelseitiges Industrie-Klebepad - **Verkabelung:** - Gewinkeltes SATA- und Stromkabel für die SSD - Gewinkelter Pin-Header-Adapter für Front-Panel-Anschlüsse (Power, LED) ## Der Umbau: Schritt für Schritt Der Prozess ist rein mechanisch und erfordert nur wenige Anpassungen. ### 1. Demontage und Vorbereitung des NUC Bodenplatte entfernen – damit hat sich die Vorbereitung erledigt. ### 2. Montage im Gehäuse Der NUC wurde kopfüber im Servergehäuse platziert. Dies ermöglicht einen direkten Zugang zu den Anschlüssen und eine bessere Luftzirkulation. - **Befestigung der Platine:** Der NUC wird von einem starken, doppelseitigen Klebepad sicher an seinem Platz gehalten. Eine Verschraubung war nicht nötig. - **Befestigung des Netzteils:** Das komplette externe Netzteil (Trafo) wurde ebenfalls mit einem Klebepad im Gehäuse befestigt. Es wurde nicht geöffnet. ### 3. Anschluss der Peripherie Die größte Herausforderung war die Verkabelung auf engstem Raum. Standardkabel waren zu sperrig. - **SATA-SSD:** Die `HP S700 1TB SSD` wurde mit einem gewinkelten SATA- und Stromkabel an die NUC-Platine angeschlossen. Die SSD selbst ist fest im Gehäuse verschraubt. Ein Foto der Verschraubung reiche ich nach, sobald die nächste Wartung ansteht und das Gehäuse geöffnet wird. - **Front-Panel (Power & LED):** Die Pins für den Power-Button und die Status-LEDs auf der NUC-Platine sind schwer zugänglich. Ein gewinkelter Pin-Adapter war die Lösung. Dieser musste mechanisch leicht angepasst (zugefeilt) werden, um exakt zu passen. ## Kühlung und Stromverbrauch (Die harten Zahlen) Ein 19"-Gehäuse hat viel Platz, aber die NUC-Platine ist darauf eigentlich nicht ausgelegt. - **Kühlung:** Der kleine originale Blower-Fan des NUC reichte im engen Desktop-Gehäuse oft kaum aus. Im neuen Servergehäuse – kombiniert mit einem langsam drehenden, leisen 120mm-Gehäuselüfter – bleiben die Temperaturen dauerhaft 10–15°C kühler, selbst unter anhaltender Last. - **Stromverbrauch:** Das war der eigentliche Knackpunkt für dieses Setup. Ein Homelab darf kein Stromfresser sein. Der NUC zieht im Idle solide 8–10 Watt. Unter Last (mehrere LXC-Container, Pi-hole, SmartHome-Logik und I/O-Spitzen) geht er auf gerade mal 15–20 Watt hoch. Damit ist dieses Setup 100% 24/7-tauglich, ohne dass mir die Stromrechnung um die Ohren fliegt. Wer sich alte Enterprise-Hardware für zu Hause ins Rack schraubt, zahlt oft das Fünffache an Strom. ## Ergebnis Der umgebaute NUC läuft stabil und leise als mein primärer Proxmox-Server. Saubere Optik, ordentliches Kabelmanagement, einfache Wartung. Simpler Umbau, spürbarer praktischer Nutzen.

Haus IT

Daniel Wellermann — Sun, 01 Oct 2023 00:00:00 GMT

# Meine Private Cloud **Kurzfassung:** Überblick über meine private IT-Infrastruktur – Hardware, Netzwerk, Dienste und WireGuard-Tunnel. Stabil, energieeffizient, unter meiner Kontrolle. Dies ist die Architektur meiner privaten IT-Infrastruktur. Das Ziel: ein stabiles, energieeffizientes und wartungsarmes System, das mir die volle Kontrolle über meine Daten und Dienste gibt. ## Das Fundament: Hardware und Netzwerk Die physische Basis muss zuverlässig sein. Ausfälle werden auf ein Minimum reduziert. ### Netzwerktopologie ![Netzwerktopologie](/images/HomeLab.drawio.png) Der Datenfluss ist linear und einfach gehalten. **WAN -> AVM Fritz!Box -> Ubiquiti US-16-PoE -> LAN & WLAN** - **Fritz!Box:** Dient als reines Modem und Gateway zum Internet. Alle weiteren Funktionen sind deaktiviert. - **Ubiquiti UniFi Switch (US-16-PoE):** Das Rückgrat des Netzwerks. Verwaltet alle kabelgebundenen Geräte und versorgt die Access Points via Power over Ethernet (PoE) mit Strom. - **Ubiquiti UniFi Access Points:** Drei APs (zwei im Haus, einer im Außenbereich) sorgen für eine lückenlose WLAN-Abdeckung. ### Server-Hardware Zwei Server nach dem Prinzip der Aufgabenteilung: ein primäres System für den Betrieb und ein sekundäres für Backups. #### 1. Proxmox Main (Produktivsystem) Ein Intel NUC, der für diesen Zweck in ein Servergehäuse umgebaut wurde. Der komplette Umbau ist im Projektartikel **[Projekt: NUC Server](/projects/NUC_Server)** detailliert beschrieben. - **CPU:** Intel Core i3-4010U - **RAM:** 16 GB DDR3 - **Speicher:** - 128 GB NVMe SSD für Proxmox und ISOs. - 1 TB SATA SSD für VMs und Container. #### 2. Proxmox Backup (Datensicherheit) Ein älteres Supermicro-System, dessen einzige Aufgabe das Sichern von Daten und VMs ist. - **CPU:** Intel Celeron 1037U - **RAM:** 4 GB DDR3 - **Speicher:** 4 TB HDD im RAID 1 Verbund (Spiegelung) für Redundanz. ## Das Gehirn: Software und Dienste Als Virtualisierungsplattform läuft auf beiden Servern `Proxmox VE`. Es ist Open-Source, stabil und bietet eine klare Web-Oberfläche. Alle Dienste sind in schlanken LXC-Containern oder VMs gekapselt. Die folgenden Dienste laufen auf dem **Proxmox Main** Server: - **UniFi Controller:** - **Zweck:** Zentrale Verwaltung der Ubiquiti Netzwerkkomponenten (Switch & APs). - **Status:** Essentiell für den Netzwerkbetrieb. - **OpenHab:** - **Zweck:** Steuerung und Automatisierung des Smart Homes. - **Status:** Die Kommandozentrale für Licht, Heizung und Sensoren. - **Webserver & Gateway:** - **Zweck:** Dient als `Nginx Reverse Proxy` für den Zugriff auf interne Dienste und als `WireGuard`-Endpunkt. - **Status:** Das sichere Tor zur Außenwelt. - **Paperless-ngx:** - **Zweck:** Digitalisierung und Archivierung von Dokumenten. OCR inklusive. - **Status:** Sorgt für ein papierloses Büro. - **Syncthing:** - **Zweck:** Dezentrale Synchronisation von Dateien zwischen meinen Geräten (PC, Laptop, Smartphone). - **Status:** In Betrieb. Wird zukünftig durch eine vollwertige Cloud-Lösung (z.B. Nextcloud) ergänzt. - **AdGuard Home:** - **Zweck:** Netzwerkweiter DNS-Server zum Blockieren von Werbung und Trackern. - **Status:** Schützt alle Geräte im Netzwerk ohne Client-Software. ## Lessons Learned: Warum Proxmox und nicht Unraid oder TrueNAS? Bevor ich bei diesem Setup gelandet bin, habe ich viel experimentiert. Für ein Homelab stürzen sich viele sofort auf Unraid (wegen der leichten Erweiterbarkeit) oder TrueNAS (wegen ZFS). Mein Problem damit: Ich wollte primär Virtualisieren und erst in zweiter Linie Filesharing betreiben. - **Die Falle:** Wenn dein primäres OS eine NAS-Software ist, klebst du zwangsläufig an deren Update-Zyklen und Limitierungen bei den VMs fest. - **Die Lösung:** Proxmox ist ein reiner Hypervisor. Er macht genau eine Sache, und die macht er brutal gut. Wenn mir ein Container zerschießt, tangiert das nicht mein Speichersystem oder andere Dienste. - **Was würde ich heute im Netzwerk anders machen?** Ich hätte direkt auf getrennte Netzwerke (VLANs) für smarte Geräte (OpenHab) und Produktivgeräte setzen sollen, anstatt alles im Nachhinein sauber trennen zu müssen. Aber aus Fehlern lernt man, und das schärft das Verständnis für Netzwerksicherheit. ## Anbindung: Der WireGuard-Tunnel Ein permanenter `WireGuard`-Tunnel verbindet mein Heimnetz mit einem gemieteten Root-Server. **[Heimnetz] <--- WireGuard ---> [Root-Server]** Dieser Aufbau erfüllt zwei Zwecke: 1. **VPN-Zugriff:** Sicherer Zugriff auf mein gesamtes LAN von unterwegs. 2. **Ressourcen-Sharing:** Bestimmte Dienste oder Anfragen können über die feste IP des Root-Servers geleitet werden. Das System ist eine kontinuierliche Weiterentwicklung. Es ist so konzipiert, dass es funktioniert, ohne ständig Aufmerksamkeit zu erfordern. --- ## Weiterführende Links - [LXC Setup — Container-Einrichtung auf Proxmox](/docs/server/lxc-setup) - [Syncthing & Photoprism Setup](/docs/server/syncthing-photoprism) - [NUC im Servergehäuse — Hardware des Homelabs](/projects/NUC_Server)