I second the option of Git + SSH. That will scale to one hundred repos. And if you don’t want the repos to be checked out, use “git clone -n” to not do that. It’ll just be dozens of repos which only have the minimal .git/ directory. All other repos that specify this one as the upstream will have no issues pulling or pushing code.

You won’t have PR features nor a web UI though.

Did ATT specifically say that their modem will factory resets due to loss of power? Because that’s genuinely unbelievable as a design feature for domestic-grade equipment. More reasonable would be that the modem will reboot when it encounters a brown-out condition, where the AC voltage briefly dips too low for the circuitry to continue operating.

A power strip with just an MOV circuit would only help if the problem was a brief spike in voltage. A power conditioner would only help if it’s the shape of the AC voltage that needs to be cleaned up. That is to say, no dips or spikes, but rather the sinusoidal shape is messy due to other devices in the building.

A UPS (which almost always includes an MOV circuit and power conditioner) would switch to battery power whenever there’s a problem with the AC voltage, so any momentary issues will be addressed. This switchover tends to happen within 2 cycles of the 60 Hz AC frequency, and that’s generally good enough most home appliances. I’m guessing the modem has a switch-mode power supply, so even a cheap UPS with square/stepped wave output will work.

Firstly, I wish you the best of luck in your community’s journey away from Discord. This may be a good time to assess what your community needs from a new platform, since Discord targeted various use-cases that no single replacement platform can hope to replace in full. Instead, by identifying exactly what your group needs and doesn’t need, that will steer you in the right direction.

As for Element, bear in mind that their community and paid versions do not exactly target a hobbyist self-hosting clientele. Instead, Element is apparently geared more for enterprise on-premises deployment (like Slack, Atlassian JIRA, Asterisk PBX) and that’s probably why the community version is also based on Kubernetes. This doesn’t mean you can’t use it, but their assumptions about deployments are that you have an on-premises cloud.

Fortunately, there are other Matrix homeservers available, including one written in Rust that has both bare metal and Docker deployment instructions. Note that I’m not endorsing this implementation, but only know of it through this FOSDEM talk describing how they dealt with malicious actors.

As an aside, I have briefly considered Matrix before as a group communications platform, but was put off by their poor E2EE decisions, for both the main client implementation and in the protocol itself. Odd as it sounds, poor encryption is worse than no encryption, because of the false assurance it gives. If I did use Matrix, I would not enable E2EE because it doesn’t offer me many privacy guarantees, compared to say, Signal.

Are ham radio operators in the EU able to use LoRa radios and be exempt from duty cycle limitations?

Admittedly, I haven’t finished reflashing my formerly-Meshtastic LoRA radios with MeshCore yet, so I haven’t been able to play around with it yet. Although both mesh technologies are decent sized near me, I was swayed to MeshCore because I started looking into how the mesh algorithm works for both. No extra license, since MeshCore supports roughly the same hardware as Meshtastic.

And what I learned – esp from following the #meshtastic and #meshcore hashtags on Mastodon – is that Meshtastic has some awful flooding behavior to send messages. Having worked in computer networks, this is a recipe for limiting the max size and performance of the mesh. Whereas MeshCore has a more sensible routing protocol for passing messages along.

My opinion is that mesh networking’s most important use-case should be reliability, since when everything else (eg fibre, cellular, landlines) stops working, people should be able to self organize and build a working communications system. This includes scenarios where people are sparsely spaced (eg hurricane disaster with people on rooftops awaiting rescue) but also extremely dense scenarios (eg a protest where the authorities intentionally shut off phone towers, or a Taylor Swift concert where data networks are completely congested). Meshtastic’s flooding would struggle in the latter scenario, to send a distress message away from the immediate vicinity. Whereas MeshCore would at least try to intelligently route through nodes that didn’t already receive the initial message.

Very interesting! Im no longer pursuing Meshtastic – I’m changing over my hardware to run MeshCore now – but this is quite a neat thing you’ve done here.

As an aside, if you later want to have full networking connectivity (Layer 2) using the same style of encoding the data as messages, PPP is what could do that. If transported over Meshtastic, PPP could give you a standard IP network, and on top of that, you could use SSH to securely access your remote machine.

It would probably be very slow, but PPP was also used for dial-up so it’s very accommodating. The limiting factor would be whether the Meshtastic local mesh would be jammed up from so many messages.

Sadly, I’m not familiar enough with Nginx Proxy Manager to know. But I would imagine that there must be a different way to achieve the same result.

BTW, when I read “NPM”, I first think of Node.JS Package Manager. The title of your post may be confusing, and you might consider editing it to spell out the name of Nginx Proxy Manager.

I’ll take a stab at the question. But I’ll need to lay some foundational background information.

When an adversarial network is blocking connections to the Signal servers, the Signal app will not function. Outbound messages will still be encrypted, but they can’t be delivered to their intended destination. The remedy is to use a proxy, which is a server that isn’t blocked by the adversarial network and which will act as a relay, forwarding all packets to the Signal servers. The proxy cannot decrypt any of the messages, and a malicious proxy is no worse than blocking access to the Signal servers directly. A Signal proxy specifically forwards only to/from the Signal servers; this is not an open proxy.

The Signal TLS Proxy repo contains a Docker Compose file, which will launch Nginx as a reverse proxy. When a Signal app connects to the proxy at port 80 or 443, the proxy will – in the background – open a connection to the Signal servers. That’s basically all it does. They ostensibly wrote the proxy as a Docker Compose file, because that’s fairly easy to set up for most people.

But now, in your situation, you already have a reverse proxy for your selfhosting stack. While you could run Signal’s reverse proxy in the background and then have your main reverse proxy forward to that one, it would make more sense to configure your main reverse proxy to directly do what the Signal reverse proxy would do.

That is, when your main proxy sees one of the dozen subdomains for the Signal server, it should perform reverse proxying to those subdomains. Normally, for the rest of your self hosting arrangement, the reverse proxy would target some container that is running on your LAN. But in this specific case, the target is actually out on the public Internet. So the original connection comes in from the Internet, and the target is somewhere out there too. Your reverse proxy simply is a relay station.

There is nothing particularly special about Signal choosing to use Nginx in reverse proxy mode, in that repo. But it happens to be that you are already using Nginx Proxy Manager. So it’s reasonable to try porting Signal’s configuration file so that it runs natively with your Nginx Proxy Manager.

What happens if Signal updates that repo to include a new subdomain? Well, you wouldn’t receive that update unless you specifically check for it. And then update your proxy configuration. So that’s one downside.

But seeing as the Signal app demands port 80 and 443, and you already use those ports for your reverse proxy, there is no way to avoid programming your reverse proxy to know the dozen subdomains. Your main reverse proxy cannot send the packets to the Signal reverse proxy if your main proxy cannot even identify that traffic.

I loaded True Nas onto the internal SSD and swapped out the HDD drive that came with it for a 10tb drive.

Do I understand that you currently have a SATA SSD and a 10TB SATA HDD plugged into this machine?

If so, it seems like a SATA power splitter that divides the power to the SSD would suffice, in spite of the computer store’s admonition. The reason for splitting power from the SSD is because an SSD draws much less power than spinning rust.

Can it still go wrong? Yes, but that’s the inherent risk when pushing beyond the design criteria of what this machine was originally built for. That said, “going wrong” typically means “won’t turn on”, not “halt and catch fire”.

If I understand the Encryption Markdown page, it appears the public/private key are primarily to protect the data at-rest? But then both keys are stored on the server, although protected by the passphrase for the keys.

So if the protection boils down to the passphrase, what is the point of having the user upload their own keypair? Are the notes ever exported from the instance while still being encrypted by the user’s keypair?

Also, why PGP? PGP may be readily available, but it’s definitely not an example of user-friendliness, as exemplified by its lack of broad acceptance by non-tech users or non-government users.

And then, why RSA? Or are other key algorithms supported as well, like ed25519?

Please explain what you mean by “rotate”. The thermostat is physically turning in-place, as though a wall clock?

Weather station, terrestrial/satellite TV DVR (TVHeadend), Git repository (Forgejo for a nice web UI, cgit for a classic UI), DNS resolver.

For my own networks, I’ve been using IPv6 subnets for years now, and have NAT64 translation for when they need to access Legacy IP (aka IPv4) resources on the public Internet.

Between your two options, I’m more inclined to recommend the second solution, because although it requires renumbering existing containers to the new subnet, you would still have one subnet for all your containers, but it’s bigger now. Whereas the first solution would either: A) preclude containers on the first bridge from directly talking to containers on the second bridge, or B) you would have to enable some sort of awful NAT44 translation to make the two work together.

So if IPv6 and its massive, essentially-unlimited ULA subnets are not an option, then I’d still go with the second solution, which is a bigger-but-still-singular subnet.

This doesn’t answer OP’s question, but is more of a PSA for anyone that seeks to self-host the backend of an E2EE messaging app: only proceed if you’re willing and able to upkeep your end of the bargain to your users. In the case of Signal, the server cannot decrypt messages when they’re relayed. But this doesn’t mean we can totally ignore where the server is physically located, nor how users connect to it.

As Soatok rightly wrote, the legal jurisdiction of the Signal servers is almost entirely irrelevant when the security model is premised on cryptographic keys that only the end devices have. But also:

They [attackers] can surely learn metadata (message length, if padding isn’t used; time of transmission; sender/recipients). Metadata resistance isn’t a goal of any of the mainstream private messaging solutions, and generally builds atop the Tor network. This is why a threat model is important to the previous section.

So if you’re going to be self-hosting from a country where superinjunctions exist or the right against unreasonable searches is being eroded, consider that well before an agent with a wiretap warrant demands that you attach a logger for “suspicious” IP addresses.

If you do host your Signal server and it’s only accessible through Tor, this is certainly an improvement. But still, you must adequately inform your users about what they’re getting into, because even Tor is not fully resistant to deanonymization, and then by the very nature of using a non-standard Signal server, your users would be under immediate suspicion and subject to IRL side-channel attacks.

I don’t disagree with the idea of wanting to self-host something which is presently centralized. But also recognize that the network effect with Signal is the same as with Tor: more people using it for mundane, everyday purposes provides “herd immunity” to the most vulnerable users. Best place to hide a tree is in a forest, after all.

If you do proceed, don’t oversell what you cannot provide, and make sure your users are fully abreast of this arrangement and they fully consent. This is not targeted at OP, but anyone that hasn’t considered the things above needs to pause before proceeding.

I mean, at the USA average price of electricity of $0.13 per kWh, then for a halving of 70 Watts, it’s about 11 cents per day, or $40 per year. But at the California average price of $0.35, then the savings is 29 cents per day, or $107 per year.

That’s not small money, especially if it’s free to make these gains by ripping out unneeded functionality. But the point is taken that it’ll be hard to find savings from older hardware, which simply didn’t prioritize energy efficiency.

But how do they connect to your network in order to access this web app? If the WiFi network credentials are needed to access the network that has the QR code for the network credentials, this sounds like a Catch 22.

Also, is a QR code useful if the web app is opened on the very phone needing the credentials? Perhaps other phones are different, but my smartphone is unable to scan a QR code that is on the display.

I’m not immediately understanding what the user scenario/story is. Would a family member open this web app on a desktop computer, in order to obtain the WiFi credentials to configure their phone or tablet?

Typically, business-oriented vendors will list the hardware that they’ve thoroughly tested and will warranty for operation with their product. The lack of testing larger disk sizes does not necessarily mean anything larger than 1 TB is locked out or technically infeasible. It just means the vendor won’t offer to help if it doesn’t work.

That said, in the enterprise storage space where disks are densely packed into disk shelves with monstrous SAS or NVMeoF configurations, vendor specific drives are not unheard of. But to possess hardware that even remotely has that possibility kinda means that sort of thing would be readily apparent.

To be clear, the mobo has a built-in HBA which you’re using, or you’re adding a separate HBA over PCIe that you already have? If the latter, I can’t see how the mobo can dictate what the HBA supports. And if it’s in IT mode, then the OS is mostly in control of addressing the drive.

The short answer is: you’ll have to try it and find out. And when you do, let us know what you find!

Congrats on the acquisition!

DL380 G9

Does this machine have its iLO license? If so, you’re in for a treat, if you’ve never used IPMI or similar out-of-band server management. Starting as a glorified KVM, it then has full power control authority (power on/off, soft reset, hard reset), either a separate or shared Ethernet connection, virtual CD and USB, SNMP reporting, and other whiz-bang features. Used correctly, you might never have to physically touch the machine after installation, except for parts replacement.

What is your go-to place to source drive caddies or additional bays if needed?

When my Dell m1000e was missing two caddies, I thought about buying a few spares on eBay. But ultimately, I just 3d printed a few and that worked fine.

Finally, server racks are absurdly expensive of course. Any suggestions on DIY’s for a rack would be appreciated.

I built my rack using rails from Penn-Elcom, as I had a very narrow space I wanted to fit my machines. Building an open-frame 4-post rack is almost like putting a Lego set together, but you will have to take care to make sure it doesn’t become a parallelogram. That is, don’t impart a sideways load.

Above all, resist the urge to get by with a two-post rack. This will almost certainly end in misery, considering that enterprise servers are not lightweight.

I agree with this comment, and would suggest going with the first solution (NAT loopback, aka NAT hairpin) rather than split-horizon DNS. I say this even though I have a strong dislike of NAT (and would prefer to see networks using flat IPv6 addresses, but that’s a different topic). It should also be fairly quick to configure the hairpin.

Specifically, problems arise when using DNS split-horizon where the same hostname might resolve to two different results, depending on which DNS nameserver is used. This is distinct from some corporate-esque DNS nameservers that refuse to answer for external requests but provide an answer to internal queries. Whereas by having no “single source of truth” (SSOT) for what a hostname should resolve to, this will inevitably make future debugging harder. And that’s on top of debugging NAT issues.

Plus, DNS isn’t a security feature unto itself: successful resolution of internal hostnames shouldn’t increase security exposure, since a competent firewall would block access. Some might suggest that DNS queries can reveal internal addresses to an attacker, but that’s the same faulty argument that suggests ICMP pings should be blocked; it shouldn’t.

To be clear, ad-blocking DNS servers don’t suffer from the ails of split-horizon described above, because they’re intentionally declining to give a DNS response for ad-hosting hostnames, rather than giving a different response. But even if they did, one could argue the point of ad-blocking is to block adware, so we don’t really care if SSOT is diminished for those hostnames.