I spend some time on clean up, most notably, the catalog move of the repositrory due to its name realted to my first modul, additionally, there are three new NS8 modules and four updates.
New
Open WebUI — AI chat front end for an external Ollama, with AD/LDAP login
netboot.xyz — PXE/TFTP boot server with optional proxyDHCP (works alongside an existing DHCP server)
Plex Media Server — official Plex image, media from iSCSI/NFS mounts of the node, one Traefik route or host network mode
Updated
Huginn 1.2.1 — timezone finally reaches Rails (TIMEZONE), schedules fire at the configured hour
Hashtopolis 1.1.0 — one Traefik route instead of seven path routes, https download URLs for the agents
Open WebUI 1.0.1, ARSnova 1.1.1, SageMath 1.0.1 — LDAP login now works when the domain controller runs on the same node
Worth knowing for every module author. Since Podman 5 the default rootless network is pasta, and pasta mirrors the node’s IP into the container. Consequence: a module cannot connect to its own node’s LAN IP — the connection is refused inside the container, it never reaches the host. This hits as soon as a module talks to the Samba DC, affecting any module on the same node; two of the updates above are exactly this fix.
Workarounds: --network=host, or host.containers.internal (169.254.1.2) as target for services on the node’s LAN IP; for services bound to 127.0.0.1 only, pasta:--map-gw plus the gateway address (the pasta equivalent of the old slirp4netns / 10.0.2.2 recipe).
pasta documents this in one sentence of its man page (--map-guest-addr); but I have not found on the NS8 developer manual — core/user_domains.md still shows the slirp4netns recipe, modules/network.md only covers inbound ports. I’ve written a short “Reaching services on
the same node” section for modules/network.md and an update for user_domains.md, verified on Rocky 9.7 / Podman 5.6 — shall I open the PR against ns8-core?
The catalog moved to its own repo. New URL for the Software Center:
On the pasta topic: thanks for raising this, it’s a real gap. With Debian 12 support now sunset we can finally forget about the old slirp4netns recipe and standardize the docs around Pasta. Before we write up the guidelines, let me ping the other developers to see if they already have opinions or experiences with it — then we can make sure documentation update reflects a shared consensus rather than just one approach. /cc @stephdl@mrmarkuz@Amygos@Stll0@giacomo
To reach the ldapproxy with pasta instead of slirp4netns, the following worked for an ldap client app like Dokuwiki or WebTop. I needed to set IP and gateway like in slirp4netns to make it work.
@mrmarkuz thanks — that lines up with what I see. Three points:
1. ldapproxy (services bound to 127.0.0.1) — same mechanism: --map-gw redirects the gateway address to the host loopback. Your -a 10.0.2.0 -g 10.0.2.2 on top keeps the well-known 10.0.2.2 working, so modules that hardcode it don’t need to change. I’d put exactly your line into the docs:
--network pasta:--map-gw,-a,10.0.2.0,-g,10.0.2.2
2. Another app via Traefik by FQDN (Collabora ↔ Nextcloud) — works with pasta too; the trick is to point the name at the host instead of the node IP, which pasta mirrors into the container:
--add-host nextcloud.example.org:host-gateway
Podman resolves host-gateway to 169.254.1.2 (its default --map-guest-addr) and Traefik on the node answers there — HTTP 200 both with the default pasta network and inside a custom bridge network; TLS/SNI is fine because the request still carries the FQDN. With your 10.0.2.x mapping --add-host <fqdn>:10.0.2.2 works the same way. --add-host <fqdn>:<node IP> does not — that’s the mirrored address, connection refused.
3. Loki / Webserver with slirp4netns:port_handler=… — that’s about the client source IP behind published ports. Tested with the node itself as client: port_handler=rootlesskit shows 10.0.2.100 (source lost), port_handler=slirp4netns shows the real address, plain pasta shows 169.254.1.2 for a connection from the host. For remote clients pasta preserves the original source IP according to the Podman docs, so those modules should not need a special option any more — I couldn’t verify the remote case myself (single test machine), so someone with two boxes should confirm before we write it down.
Everything verified on Rocky 9.7 / Podman 5.6 / passt 2025_05 on my dev system:
@thorsten@davidep three things to add before writing the guidelines:
Package availability isn’t a blocker yet. Debian 13 (trixie) still ships “slirp4netns” 1.2.1 in main. Rocky/RHEL 10 marks it as deprecated but hasn’t removed it. RHEL 10 says it “will be removed in a future major release”, with no date given. So there is no need for an urgent flag-day migration.
Both backends can coexist per module, not just per host. “–network=” can be set explicitly in each systemd unit:
ns8-loki and ns8-webserver already do this. Modules can therefore migrate one at a time, with no coordinated cutover.
For the FQDN-via-Traefik case (Collabora → Nextcloud): this is specific to pasta. Pasta mirrors the host’s LAN IP inside the container, so the connection is refused. “–add-host :host-gateway” fixes it.
With slirp4netns, the container uses its own NATed “10.0.2.0/24” network, so this issue does not occur.
Happy to help draft the “modules/network.md” section once we agree on the scope.
I’d like to propose a slightly different direction for the ldapproxy case before we put --map-gw into the docs.
--map-gw (and --map-host-loopback) exposes the whole host loopback to the container. That covers every service bound to 127.0.0.1 on the node, not just ldapproxy, and the connections look like they come from localhost. For isolation reasons I’d rather not make that the recommended pattern.
Proposal: change ldapproxy to listen on any host address instead of 127.0.0.1. Containers can then reach it through host.containers.internal (169.254.1.2, via Podman’s default --map-guest-addr) with the default pasta network. There are no special --network options and no 10.0.2.x addressing. This also matches what @thorsten found for the Traefik/FQDN case with host-gateway, so the docs can state one consistent rule: “to reach the node, use host.containers.internal”.
The change is low risk:
The ldapproxy ports (20000+) are closed by the node firewall, so listening on any address doesn’t expose them outside the node.
Nothing breaks for existing modules. 127.0.0.1 is still reachable, so the advertised address and the current workarounds (--map-gw,-a,10.0.2.0,-g,10.0.2.2, slirp4netns) keep working. New and migrating modules just follow the documented rule.
It seems cluster-localnode which resolves to the node’s VPN IP is a good alternative. The only limitation I see is that it’s defined after create-cluster / join-cluster, which is relevant to core apps.
what happenes if we update a Module, to the new pasta, and is living iside an old OS, will the application break being able to connect to ldap and samba?
Yes, some application changes would break older distributions, mostly Debian 12, whose Podman 4.3 does not support Pasta. Apps that only need to reach node services, like the LDAP proxy, can migrate without breaking it; apps that need Pasta-specific options cannot, until Debian 12 is gone.
As announced in the 8.8 release notes, Debian 12 support is ending, but new NS8 installations on it are still allowed. Starting from core 8.10 they will be forbidden, and upgrading to Debian 13 (Trixie) will be recommended: the 8.8 release notes include the upgrade commands.
is there a way to block app version installation, based on Version of NS8 installation, this way, for someone who does not upgrade their server, meaning they have older version of NS8 can not install the Apps with the new convention to avoid breaking things.
similar to how app pinning was implemented for Nextcloud, when we had multiple release versions.