I would go with a normal size PSU and mATX motherboard in the smallest PC case that will take 2x HDD bays and still have some decent airflow. Very easy to find and replace components.

If you want to spend more money and have the smallest possible case you can go for SFX PSU and mITX motherboard, but remember to allow for HDD cooling – I wouldn’t drop below 80mm for the cooling fan, and if you’re gonna use just one single fan be careful with the positioning, ideally it should be doing evac right next to the HDDs.

I don’t have a suggestion for what you’re searching but my 2 cents are that maybe reconsider replacing OpenWRT routers with custom boxes. Generally speaking it’s a bad idea to mix a router with other purposes, especially if maintenance is such a big issue and the router connection is their only internet.

You may not like OpenWRT but it’s reliable, and devices that were designed to be a router are much more reliable for this purpose than a NAS box with an USB adapter.

Add the servers next to the router, sure. Maybe add a JetKVM Mini to the server to help with remote maintenance. But leave their routers alone IMHO.

You can install the stack in an LXC container and take snapshots instead. Incus makes managing that very easy.

App stack in a system container + snapshots is a different approach from stack of app containers that you provision/tear-down but it gets you most of the same advantages.

Bit of time needed to re-learn Docker concepts in another form but I think it’s a good tool to have on your belt. Sometimes apps aren’t available for Docker, or they ship very poorly made images, or you simply feel that a system container that you upgrade in-place is the better fit.

Oh and Incus can also do VMs (KVM) with the exact same command interface as for LXC so you get that option too at the cost of learning one tool.

You can’t use dependencies cross-stack.

If you know the IP that the gluetun interface is supposed to have you tell the BT client to use that interface as output interface. Usually BT clients have this option, other apps might not.

Another thing you can do is wrap the client in a script that waits for the interface to be up (respond to ping) before it moves one. Something like (in sh):

while ! ping -c 1 -q -W 1 "$IP" &>/dev/null ; do
    echo "Waiting for ${IP} to come up..."
    sleep 5
done
# run BT client here

Alternatively if the gluetun interface itself doesn’t respond to ping, you can ping something else (like 1.1.1.1) through the interface, and use the -I ${IP} option for ping to bind to it for output.

IPP is a universal printer protocol aka “print anywhere”. Some printers support it natively, some need some help from a PC. If that PC runs Linux the most likely method is to run CUPS and connect it to the printer over USB.

By IPP autodiscovery, do you mean mDNS? If so, does the router needs to install avahi as well for single-network discovery to work? Or just the client?

Yes the autodiscovery is done with mDNS, which on Linux is done with Avahi.

Typically Avahi is needed if you consume services over mDNS or provide them.

So the Linux clients need Avahi. But the router only needs Avahi if the printer is connected to it, or to propagate broadcasts across zones.

I’ve thought users could just manually input the IP addresses

You can, but it’s really nice to have the printer available automagically (on any OS).

BTW one extra potential benefit of solution 3 might be that the “printer” would always appear to be present on the network and accept print jobs, even if the actual printer is off, because the Pi running the print server would actually be on. Otherwise if the printer itself is providing the connectivity and announcement it will not appear in the list when it’s off. Whether you consider this a plus or not depends on how you handle your printers, I turn mine off when not in use, but some people let it go into powersaving mode so it’s always ready to print.

TBH it do be like that when you’re a solo developer.

Branches come in after a certain level of complexity, if you need to do some kind of separate feature and you’re not sure how it would fit into the main project or something like that.

They can also be useful if you start automating things. Updating a branch can be used to signal that a commit needs testing or deployment.

And of course branches are super helpful when multiple people are involved.

[On a side note, it’s interesting we still use the “branch” terminology even though modern source control systems aren’t trees anymore.]

If it’s a networked printer it needs to be able to broadcast to the LAN if you want IPP to work – which you probably do, since it’s well supported by all OS and lets you autodiscover the printer and print directly from most of your devices.

This means you can’t isolate it fully from the LAN, so solution 2 is out.

Solution 1 is good if you can trust the thing not to change or disguise its MAC address. I’ve heard of devices that have a 3rd dynamic MAC in addition to the wifi and ethernet MACs, that they use to bypass such restrictions. 🤪

In order to do (1) properly you should create a firewall zone specifically for the printer, and allow that zone access to LAN but deny access to WAN. Then associate that zone with either a wifi access point created specifically for the printer, or with a specific switch plug if connected via Ethernet. This way the printer can’t bypass the restriction because it comes packaged with the only way it has of getting any connectivity.

However OpenWRT firewall zones also have issues with cross-zone broadcast, but can be bypassed I think by installing and using Avahi on the router. Don’t quote me on that.

Solution 3 seems best if you want to fully isolate it as well as retain IPP capability. That’s what I did with my printer, I connected it with USB to the server and I run CUPS + Avahi in a docker container that uses an ipvlan network to broadcast.

The tailnet devices report their status to the central servers along with the version they run, the state of their connections to the rest of the tailnet and (unless you disable it) they also send in their logs. But the central server can’t see inside node-to-node connections.

What about Tailscale, can they see http traffic over my Tailscale connection?

No, they can’t see anything inside node-to-node connections. They are encrypted end-to-end with keys that are only kept on each node and the node clients are open source so you can verify yourself that’s how it works.

The Tailscale servers only help the nodes find each other and establish connections to each other, they don’t have any access to the connections themselves.

The only way for Tailscale to intervene would be for them to silently add their own nodes to your tailnet but (1) even then the rogue node would only see connections between itself and other nodes, not connections between other nodes, and (2) at some point they added a setting that requires existing nodes to approve any new node, so you can use that to completely prevent it.

There’s no cartel, you can buy a HTTPS cert from lots of places all over the world. Most domain registrars can set you up. It just won’t be free like Let’s Encrypt and also will have a very different renewal process (most likely once a year manually rather than every 90 days automatically).

It’s not even that hard to imagine, this is exactly what rogue wifi access points do. It’s surprisingly common for wifi access at places like coffee shops to be compromised and used to silently conduct these types of attacks. The people that set them up are not very knowledgeable and also they don’t ever check up on them as long as they keep working.

This is also why you want to enable HSTS on top of your HTTPS, so that rogue requests to downgrade the connection to plain HTTP are ignored.

Another good idea is to place all the services that should only be accessed over VPN only in private DNS (home LAN DNS and the VPN’s DNS), never in public DNS. A simple and effective way of doing that is to place them on a deep subdomain like *.private.example.com rather than *.example.com. That way if your VPN drops when you try to resolve those subdomains you don’t get any response anymore and there’s no connection for the rogue wifi to hijack.

One problem is that it’s not much use applying secondary auth methods on the server side if the mobile app can’t use them.

Yes, and that’s what I disagree with. Neither AI nor scripts will make a script kiddie into an actual hacker.

“AI makes hacking easy” is like saying “building houses is now easy because we have cranes”. Sure, but if you jump into a crane without knowing what you’re doing it’s not magically going to make a house appear.

Ah I agree it’s easier to hack. What I don’t agree with is the notion that it enables a class of people that couldn’t hack before. It’s easier to hack, yes, but for the same people who were hacking before.

Ignorant people trying to use ready-made tools for hacking isn’t a new thing, it goes back a while, there’s even a term for it (script kiddies).

I expect it’s a common trend though, people generally use Dropbear on embedded devices for the same reasons they prefer Alpine, it’s more compact.

That’s because it turns out there are tons of vulnerabilities out there introduced by very lazy and/or dumb code.

It isn’t that AI has lowered the bar for hacking, it’s that it’s showing us just how much bad code is out there. The bar was already on the ground, we just didn’t know it.

After all is said and done AI will actually end up raising the bar for security everywhere.

Unfortunately we have a lot of legacy crap to clean first.

Most Android apps that make a ssh server use dropbear afaik.

I mean, anybody who’s still using password login for SSH is kind of asking for it.

It’s not quite as simple as that. The author in this case followed a pretty specific trail to find the bug.

Where AI helped was as the last step. They already knew what the bug would do and where to look, but actually looking through the source code for all the possible musl implementations out there would have taken a lot of time.

So they brute-forced it instead and asked AI to spin up actual running instances of all those implementations and simply tried the bug against each of them, rather than looking at all the code.

Unless it’s explicitly installed no. The default Alpine image doesn’t come with OpenSSH.