[HN Gopher] Show HN: Provisioner per-board sidecar for serial ac...
       ___________________________________________________________________
        
       Show HN: Provisioner per-board sidecar for serial access, flashing,
       and bring-up
        
       Hi HN,  I've been building a small infrastructure tool called
       Provisioner: a per-board provisioning sidecar for SBC bring-up and
       lab automation. https://github.com/alessandrocarminati/provisioner
       The model is simple: one instance per board. It sits next to the
       hardware, owns the serial console, exposes access over SSH, and
       serves boot artifacts (kernel, initramfs, rootfs) via TFTP/HTTP.
       It's designed for the phase where networking is unreliable, storage
       is half-flashed, and UART is the only thing still telling the
       truth.  What it does  - Serial console ownership + SSH multiplexing
       - Monitor shell + serial tunnels - Scriptable boot interaction -
       Artifact provisioning (TFTP + HTTP) - In-band file transfer over
       serial - gzip/base64 hacks + XMODEM - Derived from my earlier
       send_console-ng utility
       https://github.com/alessandrocarminati/send_file-ng - Pluggable
       power control - SNMP PDUs, among others cheap ESP8266/Tasmota
       devices - Serial logging - Lightweight access control  Provisioner
       also embeds a minimal init runtime (goinit) inside the kernel
       initramfs, acting as its on-board provisioning agent, handling
       flashing, artifact retrieval, and reporting management state back
       over serial.  Routing & stream handling  Internally, Provisioner
       routes serial traffic through a pluggable router:  -
       Producers/consumers attach as components - Human vs machine clients
       handled differently - Unicast control sessions - Broadcast
       multiplexing to multiple observers  This allows several users or
       services to watch the same console without interfering.  Filters  A
       filter subsystem can intercept and modify serial streams on the
       fly.  Originally added to mitigate ANSI Device Status Reports (e.g.
       Cursor Position Report issues) when tunneling serial consoles, but
       it doubles as a general stream rewriting mechanism for automation
       and normalization.  Positioning  Not trying to replace large
       systems like LAVA.  This is aimed at:  - Homelabs - Bring-up
       benches - Kernel/BSP work - Small shared labs  Think lab automation
       you can deploy in an afternoon, not fleet orchestration.  Project
       is still evolving but already in daily use. Feedback and abuse
       welcome.
        
       Author : acarminati
       Score  : 6 points
       Date   : 2026-02-16 20:52 UTC (3 days ago)
        
       | s_tec wrote:
       | Nifty! I recently bought a RISC-V VisionFive 2 Lite SBC, which
       | required a lot of mucking with firmware and talking to the U-Boot
       | serial console before it would boot Linux for the first time. A
       | tool like this would have been super-handy during that time.
       | 
       | On the other hand, I'm a low-budget hobby user. I like things
       | that are cheap, easy, and hackable. It sounds like your product
       | might be for more-advanced users? Or do all these fancy features
       | stay tucked away until you need them? If you make your product
       | cheaply, that might hurt profit margins, but it might also open
       | up the low-end market. I have so many questions about the
       | business side of this.
       | 
       | But really, I am most curious about the user experience. It's not
       | super-helpful if learning the tool becomes its own project, so
       | I'm hoping it's simple.
       | 
       | Edit: Oh, it's a software project. I thought it was a hardware
       | project. My bad.
        
       ___________________________________________________________________
       (page generated 2026-02-19 23:01 UTC)