lemmyvore

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 deny that zone 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.

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.

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.

Or, to put it another way, it will 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.

A big PSA here is to have them pass you the device activation link that pops up when they first start Tailscale, and activate their device on your tailnet.

Then you tag it, write an ACL rule for it (or you probably already have a rule for Jellyfin clients connecting only to the Jellyfin server on your tailnet by now, so just the tagging is enough) and that’s it.

MUCH simpler than having non-savvy people attempt to set up a Tailscale user account. Plus, you can only have 6 users in a free tailnet but you can have 100 devices.

Clementine

Whoa, has Clementine picked up again? I’ve long ago switched to Strawberry and then to Fooyin.

As someone who’s used all three (moved from Plex -> Emby -> Jellyfin):

Plex’s killer feature is the relay and the fact it’s completely transparent for users. You log in with a Plex client (whatever device, whatever location in the world) and it will sort out a connection to the Plex server. Complete no-brainer.

Jellyfin has been killing it lately, the last 3 versions (10, 11, 12) were all amazing leaps forward. The devs have been really hitting their stride and are addressing fundamental design issues and making Jellyfin better from the ground up. If you want complete independence, openness and control, excellent performance, this is it.

Emby for me sits somewhere in-between and it’s not necessarily the better off for it. Feels like a compromise or the worst of both worlds. It has touches of Plex’s enshittification streak, it hasn’t addressed any of the core problems like Jellyfin has.

Both Emby and Plex have issues navigating VPNs and complex/unusual network setups because their plug’n’play approach relies too heavily on autodetection. Plex has the relay to fall back on (provided you pay for it) but Emby doesn’t.

Both Emby and Plex will move features around and really, really want you to keep paying so it’s anybody’s guess what you’ll be paying for from month to month. Lifetime passes were (can I say it?) a tremendously STUPID idea and now that ship has sailed anyway.

IMHO, one of these days someone will come up with a way for Jellyfin to provide free, transparent, aecure client+server pairing behind NAT and that will be a huge blow to both Plex and Emby.

You can do what you want with IMAP too.

I use isync, it’s a CLI tool that can sync between IMAP accounts or between IMAP and local plain storage and it has the option to delete messages over a certain age after it copies them.

Is there a set up where some remote service handles email exchange, and you just sync with it

Any regular email provider can do this as long as it offers IMAP. I use email clients with my provider’s IMAP but I also use isync on the server to periodically pull all email locally and delete messages older than 30 days. I’ve also installed a local private IMAP server and a private webmail client on top of that private IMAP, which I use to search through old emails.

This way I normally use the “live” mailbox with my PC/mobile devices, and use the private webmail when I need to search for anything over 30 days old.

It does, there’s a lot of features and UI added on top of it because it’s primarily an enterprise-oriented service and large companies tend to have a lot more complex usage scenarios than self-hosters.

Headscale is a FOSS reimplementation from scratch of some of the Tailscale proprietary features. It’s inteded as a fallback option for Tailscale users in case the Tailscale service ever enshittifies, and also as a canary for ongoing verification of the Tailscale claim that the client plane functionality is entirely FOSS and above-board.

Speaking of which, Tailscale today is a great example of a company using FOSS well. They are able to provide commercial services and have proprietary code while at the same time opening the client-facing code so users can see for themselves their privacy is cryptographically proven. They also cooperate very well with Headscale and provide a generous gratis service tier.

• I’ve taken the opportunity to update most of my hosted services to newer image versions.

  They’re all behind private access (Tailscale, mTLS, IP whitelist etc.) so I’m not usually too worried. I update images manually whenever I can find time on a slow weekend, so this wasn’t strictly speaking related to the recent vulnerabilities. Volume data and container definitions are backed up automatically once a day and I also take manual copies of the old images when I update them.

• I’ve switched to new major versions of Immich and Jellyfin in the process and I’m very pleased with the new releases, amazing great work from the developers, they’ve been killing it lately.

• I’ve been tinkering with some custom images that I use for various things like syncing specialized data (logs off FTP services, archive email over IMAP from my mail provider, grab Garmin data copies, run monitors and log parameters to Influx, run port forwarders etc.)

  I typically want to lock down this kind of images as much as possible, so I tweak them towards running with an unprivileged user, remove all caps and only grant strictly necessary ones, make the storage read-only inside the container etc.

• Some needs have been recurring inside this type of containers, like having a decent process manager to keep some things running and restart them, or having a decent cron service. So I’ve been toying with the idea of making a “universal” image for this kind of thing and maybe publishing it for others to use as a base too. If I get around to it I’ll be announcing it here.

I mean, “plain WG” doesn’t have the ability to connect multiple sites seamlessly, nevermind from behind NAT. That’s what Headscale/Tailscale do, they enable multiple WG backends to connect together on the fly into a common VLAN, with almost zero extra config.

It may seem overkill if you only want to connect two sites but once you solve this problem for 2 it’s basically also solved for N so why not take advantage of the capability.

There’s Headscale, but it can’t be fully selfhosted because you need an external host if both clients are behind NAT.

Wireguard may be more obviously public, but they both technically are, right? Otherwise accessing a node just wouldn’t be possible.

There is something exposed to the Internet in both cases, yes, but it works very differently.

With WG it’s a client-server pattern; the server exposes a port, waits for authorized clients to connect, and when a client connects successfully the server routes their connections into the private LAN with everything that entails.

With TS the public part is a supplier of control configurations and client pairing service. The pairing service needs to be contacted by two authorized clients in order to negotiate a connection between them. Once that’s done, it’s the clients that route each other’s connections into their respective LANs, the pairing server is not involved anymore.

In other words the TS public surface is not WG, it’s their (proprietary) client verification and matching service. The WG connections between clients happen later, privately.

To me, separating client authentication from routing and transport looks like a better design, because it’s multi-layered. You get the normal WG authentication and another layer on top.

If you don’t need something specific that tailscale offers, then wireguard offers probably better security.

“Security” is a relative term. It’s better to think in terms of attack surface, exposure, whether attacks are targeted or not etc. Which are all ongoing factors.

Both TS and WG are popular and being used by lots of people but it’s also important for them to be actively maintained, independently audited, maintain transparency etc.

Also, I’ve never been able to understand how something exposed to the entire internet (a WG server) is considered more secure than something that only connects peers privately to each other.

The attack surfaces are nothing alike.

Even if you limit access to WG with IP blocking there’s still no comparison to something you can’t access at all from outside.

Why not use PHP hardened (distroless) images as a base for the final image?

Why build your own images at all? I’m not sure I understood what advantage that gives you.

Harbor looks interesting but that install procedure is ridiculous. Why would I run an installer script just to pull docker images, just give me a compose file ffs. The only way I’d ever consider it is inside an LXC container or a VM.

Also, it sounds like they’ve never heard of a reverse proxy and don’t know you can do TLS that way? That does not inspire confidence.

Yeah I can understand small self-hosters having maybe a handful of domains but some users were coming in with thousands. I mean if you have thousands of domains there’s obviously something else going on and maybe you should be paying someone for that.

If they find anything we fix it, update our services, and move on.

The chances of being hit by a zero-day as a random self-hoster are very small, but anyway if you keep backups and can restore a clean state (and patch your system) you should be good.

The goal is not to have perfect security, it’s to mitigate the risks and to handle fallout correctly.

Get a .nl and call it a day?

the exploit has been out for over 10 hours

According to the PHP Foundation the OOM vulnerability was originally found by the security audit they commissioned back in 2024.

They never fixed it because there was no working exploit at the time and also because all the fixes had important downsides and they went into decision paralysis.

I do believe that two years is plenty of time for someone to figure out a working exploit, especially with AI assists.

Bottom line, the timing of this recent debacle is centered around the moment that the PHP Foundation decided to finally eat crow, not around when the exploit was actually available. The embargo was just for spectacle. PHP circles are already spinning it as “see how important PHP is, how much of the internet runs on it, how it’s critical infrastructure”.