Local infrastructure
Started by A. Non ·
Just wanted to get an idea of what people are running at home. I currently run the rns daemon in transport mode, but I'm thinking about switching to nomadnet since it starts up the rns and lxmf daemons according to documentation.
I know Nomadnet will probably start rnsd, but I prefer to not bootsrtap any time I restart Nomadnet. That's why I prefer to keep them separated. I'm not sure, whether that's reasonable. I'm quite new.
Right now we're starting the shared RNS transport instance on our NAS by starting the rngit service. There's also rncp service running (for transferring rngit work documents and releases to our "internet mirror").
I'm planning to add also a LXMF propagation node to facilitate us being offline quite often (this is on a boat).
On our Signal K Raspberry Pi we have reticulum-js running inside the Signal K Node.js process and set to connect to the one on our NAS via TCP.
The NAS has a connected RNode.
nLupo wrote:
I know Nomadnet will probably start rnsd, but I prefer to not bootsrtap any time I restart Nomadnet. That's why I prefer to keep them separated. I'm not sure, whether that's reasonable. I'm quite new.
I'm fairly new to this as well. What's the reason for needing to restart nomadnet?
bergie wrote:
Right now we're starting the shared RNS transport instance on our NAS by starting the rngit service. There's also rncp service running (for transferring rngit work documents and releases to our "internet mirror").
I'm planning to add also a LXMF propagation node to facilitate us being offline quite often (this is on a boat).
On our Signal K Raspberry Pi we have reticulum-js running inside the Signal K Node.js process and set to connect to the one on our NAS via TCP.
The NAS has a connected RNode.
Wow, a boat! That sounds like a perfect test environment for all of this. I've been thinking about a lxmf propagation node as well, but I'm usually not too far from a connection and I had a bit of luck with my rNode tonight around town. I'll definitely keep an eye for what you're up to next!
A. Non, When I update scripts or the settings of Nomadnet I need to restart it, which is a completely different thing from the interfaces settings on rnsd. In my mind the first is "the driver" the second is "the server" or "the client", depending on the situation. Also I prefer to have the option to run multiple applications reusing the same rnsd.
P.S. I have no idea how to do a quote on this forum 😓 from Nomadnet.
nLupo wrote:
A. Non, When I update scripts or the settings of Nomadnet I need to restart it, which is a completely different thing from the interfaces settings on rnsd. In my mind the first is "the driver" the second is "the server" or "the client", depending on the situation. Also I prefer to have the option to run multiple applications reusing the same rnsd.
P.S. I have no idea how to do a quote on this forum 😓 from Nomadnet.
Thanks for the explanation, in that case, your setup seems totally logical. I imagine there will be a way to kick the daemon and have it restart gracefully similar to apache in the future
I'm also quite new and wondered about the nice quoting all the time. But I have found out that this place is mirrored in "the Internet" - here: https://rns.recipes/forum/general/local-infrastructure - and the browser interface for that url supports posting and text quoting.
I run rnsd as a shared instance in my home server, so that any other applications that use Reticulum on the same server will use it as their Reticulum instance.
You could probably manage this with systemctl and have any other Reticulum apps wait for rnsd to be ready, but for some reason I prefer doing things the hard way and have them all in a k3s pod along with yggdrasil.
rnsd, lxmd for a propagation node, and MeshchatX are what I use on a semi regular basis, but I also have nomadnet hosting the Columba releases site, LXMFy, a rrcd hub for testing, classic meshchat for occasional testing, rrc-web, rnmon feeding a grafana dashboard, and a reti-bbs hub I should probably disable since I never use it.
Anyway all of that is super overkill, but overkill is fun for me lol
Currently running drupol's rnsd nixos module and custom nixos modules to run lxmd, lxmf-group (@melsner-codeberg), and nomadServe (@int-codeberg). After some struggling its turned out to be a satisfyingly resiliant little box.
A raspi 4 with an upstream connection to a local backbone node, autointerface active and a connected rnode thats just sitting in the living room, so not perfect right now. I plan to plant the rnode outside at least, with a raspi zero and a wifi connection to the other node. I tried out microreticulum with wifi and a udp interface aswell, but I wanted to publish the rnode and discoverable interfaces arr not yet a thing there. On the raspis I am running only rnsd with no propagation node or anything. Just the example service files from the documentation. I had issues starting lxmd reliable after rnsd on reboots for some reason and decided to just use other prop nodes.
FWIW, I run nomadnet (hosting pages) as a daemon with systemctl. That becomes a shared instance for any other Reticulum tools I spin up. I prefer that to first running rnsd and then nomadnet, as nomadnet would have to wait for rnsd to spin up. Having one service makes it easier to restart, eg. after upgrading rnsd and/or nomadnet or changing configs. I could also run a propagation node with that setup.
AnonymousPierre wrote:
FWIW, I run nomadnet (hosting pages) as a daemon with systemctl. That becomes a shared instance for any other Reticulum tools I spin up. I prefer that to first running rnsd and then nomadnet, as nomadnet would have to wait for rnsd to spin up. Having one service makes it easier to restart, eg. after upgrading rnsd and/or nomadnet or changing configs. I could also run a propagation node with that setup.
That's what I might eventually move to, but nLupo mentioned that you need to restart nomadnet for page or script changes to get picked up. You can add the After condition to your systemD nomadnet unit so it says for rnsd to be up first, that might help
That should say "... So it waits for rnsd to be up first"
Something like
[Unit]
Description=nomadnet
After=rnsd.service
A. Non wrote:
That should say "... So it waits for rnsd to be up first"
Something like
[Unit] Description=nomadnet After=rnsd.service
This will not work reliably unfortunately. rnsd reports as "up" too early and will be in a state where you cant connect to the shared interface yet. Add a delay or check via logfile if its really up.
Anonymous wrote:
A. Non wrote:
> That should say "... So it waits for rnsd to be up first"
>
> Something like
>
>> [Unit] > Description=nomadnet > After=rnsd.service >
>
>This will not work reliably unfortunately. rnsd reports as "up" too early and will be in a state where you cant connect to the shared interface yet. Add a delay or check via logfile if its really up.
Good to know, thanks!
Anonymous wrote:
This will not work reliably unfortunately. rnsd reports as "up" too early and will be in a state where you cant connect to the shared interface yet. Add a delay or check via logfile if its really up.
Here's what I do: https://rns.recipes/forum/help/lxmd-and-rnsd-service#post-67 (web link only, sorry)
There are some other solutions in that thread.