Show & Tell: Raspberry PI 3 B+ Network & Nginx Configuration

[JasonKleban]

I want to share this netplan & nginx configuration so far. It is incomplete.

rpi3b+, usb drive dock, PoE injector, and HNC304-WDA (manufacturer unknown). Ethernet is for the camera(s) LAN and onboard wifi is for the external WAN.

I started with Ubuntu 20 64-bit for Raspberry PI image. I removed snapd for boot speed, added zram-config for eventual memory issues, and removed cloud-init and replaced it with the following Netplan .yaml configuration and added sudo apt install avahi-daemon for zeroconf mdns:

network:
    version: 2
    ethernets:
        eth0:
            addresses:
            - 192.168.1.1/24
            dhcp4: false
    wifis:
        wlan0:
            optional: true
            dhcp4: true
            access-points:
                "*****":
                    password: "*****"

I got moonfire working on port 8080 by the guides, but I want to also have access to the camera configuration directly. I think I could use a network bridge and firewall or port forwarding, but it seems that it will be easier to use Nginx. As of 10 years ago unfortunately, avahi seems to not support subdomains (aliasing) even though they seem easy to support in Nginx and would be the most user-friendly in my opinion (assuming that rtsp streams can be proxied with nginx too) compared to port numbers, and the most compatible compared to "virtual directory" mounting (by path). RTSP wouldn't work yet and I haven't really tried moonfire yet beyond being able to reach the page, but being able to configure the camera directly instead of having to physically plug in is nice. dhcp with camera hostnames mapped to a subdomain automatically would be even nicer - although every camera would need some kind of static configuration initially anyway...

# No catchall.  Exact matches only
server {
    listen      80 default_server;
    server_name "";
    return      444;
}

# server_name won't work because of avahi/mdns "aliasing" limitations?  But ports will.
server {
        listen  81;
        server_name moonfire.*;
        location / {
            proxy_pass       http://127.0.0.1:8080;
        }
}

server {
        listen  82;
        server_name camera1.*;
        location / {
            proxy_pass       http://192.168.1.64:80;
        }
}

Thoughts on this configuration?

[scottlamb]

Thanks! It's fun to see your progress. I like your custom mounting / cable management.

Re: avahi: too bad about that limitation. I wonder if it's a fundamental protocol limitation somehow that there's only one name per IP or if it's "just" that avahi doesn't support it. Maybe you could request several IP addresses on the wlan0 network segment to get around it. Another approach is that some home routers (eg OpenWRT) support creating a DNS zone for your home. You can either hardcode the setup (fix the address in your NVR machine and set a static hostname for it in the DNS server) or request the hostname(s) through DHCP. Not as slick as your avahi idea but it can work if you have the right router setup.

Re: nginx RTSP: I hadn't thought of this, but apparently nginx supports plain TCP proxying, so RTSP-over-TCP should work. (Not RTSP-over-UDP unless nginx has specific RTSP protocol support that I missed.) RTSP-over-HTTP / RTSP-over-WebSockets should also be possible if your camera supports them.

In my own setup I use routing to let my laptop access the camera UIs. I put my OpenWRT on both network segments and configured it route between them, with firewall rules so my "trusted" segment can initiate connections to "surveillance" but not vice versa. I suppose the NVR machine could also do the routing between the two, and you could have an OpenWRT router tell DHCP clients about that via something like dhcp-option=option:classless-static-route. But again that's config on both the NVR machine and the main router; I can see the appeal of avoiding this...

[JasonKleban]

Thanks! Yeah, I'm aiming for a solution that could make the eventual setup a little more turn-key. The networking seems like the hardest part of an install. The rest could get stuffed in a docker more easily, right? (Though, I have nearly zero experience with Docker to talk).

I found https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/#configuring-reverse-proxy which I haven't attempted and don't fully understand.

I found avahi/avahi#40 (comment) with a service definition hack that I haven't tried and don't fully understand.

Being able to proxy UDP RTSP streams from the cameras is not so critical since ultimately the streams themselves will be visible in moonfire app anyway - except for various configurations that involve the image itself, I bet most camera UI will just be degraded about as much as not having the ActiveX plugin installed, which can't have much more life in them anyway. Moonfire will serve the video through a html video anyway, right?

[scottlamb]

The networking seems like the hardest part of an install. The rest could get stuffed in a docker more easily, right?

It could. I haven't been focusing on improving the install experience (yet), but @dolfs contributed a Dockerfile that builds Moonfire NVR. We could probably push this further; my ideal would be to cross-compile and publish a docker image that just has Moonfire NVR itself, not the rust and node/yarn development stuff.

It'd also be possible to make a dpkg for installing on Raspbian Pi OS and latest Ubuntu (/x86-64 and arm64), which I think are the most popular configurations.

I bet most camera UI will just be degraded about as much as not having the ActiveX plugin installed, which can't have much more life in them anyway.

There's some hope. My old Hikvision DS-2CD2032 cameras have this problem. But my Dahua IPC-HDW5231R-Z (since a firmware upgrade a while back) no longer needs ActiveX. It works fine on Chrome on my Macbook Pro.

Moonfire will serve the video through a html video anyway, right?

For recorded videos, yes. For live view, that's a feature in progress (#59) but in theory also yes.

[JasonKleban]

@scottlamb this looks promising, but I haven't gotten it to work yet. https://askubuntu.com/questions/1175380/avahi-name-resolution-not-respected-for-subdomains-in-19-04#comment2118752_1189644

[polarathene]

@JasonKleban since StackExchange(AskUbuntu) comments are kind of limited, feel free to reach out to me here instead.

If I understand the issue correctly, you've got an RPi device with this Moonfire project offered as a service and the camera reachable on a separate network IP but you want the RPi to proxy the IP+port with a subdomain via a reverse proxy like nginx?

What's the intended flow here? The nginx config with IP addresses is going to remain manual? You just want zeroconfig for other systems to reach the RPi with several subdomains to interact with? As discussed on AskUbuntu, you're probably not going to get that without configuring clients to support (if even possible for the client), it'd be easier to provide your own local DNS at that point.

I did also suggest just publishing multiple hostnames to point to the same device if needed. That should work just as well if subdomains aren't actually required. Do you see an issue with that approach? Any client that supports mDNS (not Android) would then have no issue?

---

I noticed in my original answer I stated that publishing additional hostnames to the same IP would not be discovered, I believe that was due to not having a related service published to point to them for discovery, but that they should still respond to an mDNS lookup.

If you need the ability to discover, it needs a service published to a domain and service type that would be searched/filtered. For example in the coredns-mdns plugin that's local domain (not same as .local TLD in the hostname) and _workstation._tcp service IIRC.

Instead of Avahi, you could also try mdns-publisher, which lets you use a config file that supports publishing multiple services to the same IP with different hostnames to respond to.

[JasonKleban]

The goal is a turnkey ("zero-config"?) setup of moonfire with lan cameras directly reachable in a typical home network "wan"-side with no centralized dns or non-minimal manual configuration. Moonfire would have some minimal registration or discovery of cameras on the camera lans and reliably proxy inbound connections from wan for whatever variety of management software and protocols that each camera supports.

I generally try to minimize the dependencies - I've seen reference to python scripts but I sense that such solutions are brittle. How reliably and seamlessly would topology updates be adjusted for? What extra cpu does running the python script take up? What additional knowledge must the operator know to troubleshoot this extra mechanism? What extra bugs will introduced by the complexity? If there's nothing lower-energy, then so be it. Just searching.

[polarathene]

The goal is a turnkey ("zero-config"?) setup of moonfire with lan cameras directly reachable in a typical home network "wan"-side with no centralized dns or non-minimal manual configuration.

Is this in relation to you having control over everything that needs to know about the cameras? Or is a regular user meant to be able to just lookup camera.hostname.local on a client? (web browser or desktop/mobile app)

If you need the user to have access to such, you need to consider the clients available to the audience. Windows/macOS and default Linux setups are not going to support multi-label mDNS lookups. You'll have to stick to single label.

If you have full control of the device discovery/handling, and the user only needs to be concerned with their client accessing a single location (eg hostname.local, potentially not even visible to the user depending on client and default setup), then you could use DNS-SD to advertise on mDNS devices on the local network like your cameras to a central host/hub device like the RPi, that can discover and register/setup those for using as needed. Doing so would involve some glue code to make this service become zeroconfig (for a user, not entirely for the developer per se but mostly it achieves the goal).

If the RPi has multiple services that need to be reachable via mDNS, since a Reverse Proxy is not going to be able to support subdomains to any client the user may have, if you need this functionality, publish with service prefixes on the hostname label (eg camera-hostname.local), you can do that with Avahi or something like mdns-publisher if it's a static sort of config, if it's dynamic you'll need to write some code which will add maintenance burden etc.

---

I've seen reference to python scripts but I sense that such solutions are brittle. How reliably and seamlessly would topology updates be adjusted for?

I can't comment on that, it's not something I've needed enough to try. Presumably your network wouldn't be needing updates for this very often, but IIRC one of the Avahi python scripts uses DBUS API so it should update on the fly, whereas for a Golang binary like mdns-publisher, I think you'd just update the config file and restart the process, fairly trivial and should involve minimal downtime, not likely to cause any problems with this setup as it's only for IP lookup which would not be happening at a high frequency.

What extra cpu does running the python script take up?

Probably minimal, profile it if it's important to you, not likely to be a concern.

What additional knowledge must the operator know to troubleshoot this extra mechanism?

As you're aware the mDNS stuff can get complicated, especially when you get stuck and unsure of something as you encountered yourself. This wouldn't be much different I imagine, you should be comfortable with Google, contacting an author on Github, possibly looking into the Python code yourself, etc if you really need to.

If it works as intended, you'd likely not have much to worry about. This should be transparent to the user, but their role is a bit vague (they're either only dealing with a client and have received access to the RPi and any other devices either setup for them already or with some instructions to follow), assuming the user doesn't need much technical competence, this shouldn't be something that bothers them, it'd be part of the complexity of the entire project they're relying on.

What extra bugs will introduced by the complexity?

First you'd need to measure what exactly the complexity is and how that compares to the complexity already in the project to weigh that up. I would assume it's not worth worrying about it if it serves the required purpose well, you naturally are preferring additional complexity/burden to simplify and reduce burden on the user by not requiring them to know as much and minimize config/setup as much as possible.

If there's nothing lower-energy, then so be it. Just searching.

The broader the audience/clients and the less control you have over the environment, the more effort it requires to support. If it were just a personal project and you knew it'd all be linux devices under your control, then you have a bit more freedom (such as using subdomains with mDNS).

If you require HTTPS / TLS, you'll run into other problems for example. You won't be able to use LetsEncrypt for non-public domains, self-signed certs will often raise insecure warnings/errors from clients, and while you can provide your own private/internal CA signed certificates, the clients would need to add the CA public cert to their system trust stores, which imposes it's own security risks and complications.

If this RPi device is meant to be reachable from the public internet however (presumably with some auth to restrict access), using a public domain you register makes all this easier, but may trade a different set of expectations on what a user would need to do that may or may not be better for that audience.