Security through obscurity never works, so changing you SSH port does barely anything

… for security that is.

What it does is keep a lot of automated bots from spamming your server. No, they don’t have any chances to get access when key authentification is used (and they won’t try either… most go for the incredible low hanging fruits like admin/admin user/password sets), but they can become a strain on your own ressources.

What actually helps (and is usually configurable with any firewall) is rate limiting access. Just blocking someone’s access for 10 seconds after a failed attempt will make absolutely no difference for you but a big one for those spammers. Now add some incremental increase after multiple fails and you are perfectly set.

PS: 53 is the standard port for DNS when your server operates as such.

PPS: Don’t use it. People should really let that stuff die and exclusively run encrypted DNS (via TLS, HTTPS or Quic…)

What I ask myself here is why I should have unused phones lying around in the first place?

If I somehow think constantly wasting money on a new model just because there is a new number written on its packaging is worth it, I would not actually think in terms of reusing old hardware.

If I am however thinking about using hardware instead of just throwing it away while still functional why wouldn’t I use a phone as anyone else as a phone?

I didn’t have any actual issues with the native install either.

But with [multilib] activated there were dozens and dozens of 32bit libraries pulled alongside their regular version that I didn’t actually need. And I use Wine a lot more than Steam anyway. So once Wine went fully 64bit I decided to get rid of all that legacy multilib 32bit stuff.

Steam via flatpak also works and will do until they, too, fully switch over to WoW64 implementation.

Mainly my normal phone app. But for a long time it’s not sync’d to some google cloud (which would be the default) but a Radicale instance.

I used Nextcloud before but honestly it’s a mess to maintain. So much that I would not suggest it without planning to extensively use a lot of the different available addon functions.

Just for file sharing and caldav/carddav I will pick some simple solutions (like Radicale and Syncthing) over Nextcloud any day.

And to give you a reference to some of the details glossed over…

The anubis instance listening to a socket doesn’t work as described there. Because the systemd service is running as root by default but your web server would need access to the socket. So you first need to harmonise the user the anubis service runs as with the one from your web server with the permissions of the /run/anubis directory.

(see Discussion here for example)

Also having one single setup example in the docs with unix sockets when that isn’t even the default is strange in the first place…

Half the Environmental Variables are just vaguely describing what they do without actual context. It probably makes perfect sense when you know it all and are writing a description. But as documentation for third-person use that’s not sufficient.

Oh, and the example setup for caddy is nonsensical. It shows you how to route traffic to Anubis and then stops… and references Apache and Nginx setups to get an idea how to continue (read: understand that you then need a second caddy instance to receive the traffic…).

PS: All that criticsm reads harsher than it is meant to be. Good documentation needs user input and multiple view points to realize where the gaps are. That’s simply not going to happen with mostly one person.

More than once. But -not actually surprsing by a work in progress by mostly one single person- it’s not actually what I would call well-structured or even coherent. 😅

More than once googled for a detail I didn’t understand and ended up on the issue tracker realizing I’m not alone and some behavior is indeed illogical or erratic.

And then some of it is of course referencing forwarding- and header-information, how it’s handled, where it’s flattened… and as my question should have told you, I don’t even much clue how it is handled normally.

It isn’t webdav per se. It’s the website presented by a webdav server. So there should be no functional difference between this and yet another webserver in a decentralized setup.

Yes I know that I can easily change things around to have the reverse proxy run ignored. I was more interested in the “why it happens” than a practical solution (for that I could just move the reverse proxy one block up…).

Logs of what exactly? I don’t even know where to look. Neither is nginx logging an error, nor is a request ending on an unavailable port and just timing out logged anywhere. How would I set up extensive logging of anything but errors and accesses?

As far as I’m concerned this is not some error but something regarding the details how proxy_pass works, that I don’t understand.

In fact it isn’t even an actual problem per se. I can easily move the reverse proxy up one block so only the actual pages are protected. But the point is that I want to understand why a request that should be routed internally (and is without Anubis in the mix) ends up there. I would suspect some way the default headers are transmitted screwing things up.

I have tried localhost and 127.0.0.1 after initially using the internal 192.168.x.x IP and the behavior is always identical.

Paru, so Pacman & AUR…

With exactly one exception: Steam via flatpak because that’s the single package left that would need 32bit libraries from multilib-repo since Wine finally left those dependencies behind.

I don’t think there is a better “default” because the default has to be the general setting everyone can live with. But that of course also means it’s not particularly good for any use case.

In general desktop users prefer lower values for snappy behavior when switching thorugh different apps (~10 often recommended). People mainly focusing on preformance of the primary running app prefer higher values (which may, depending on setup) include gamers.

Also there is zram/zswap now (basically compressed swap in memory instead of on disk) which is faster than tradittional swap.

But in the end you can only try out values and watch your systems behavior or run benchmarks to find the proper value for you personally,

wtf?

Pleass tell me you are just talking about discord channels instead of proper issue trackers and not something even more stupid…

Oh, I assumed you already had setup OBS…

And WHIP is probably unneccessarily complicated anyway.

I was able to stream the output of my V4L2loopback-device (the virtual camera created with OBS’ output) to a browser accessing localhost:<port> with Motion without any setup other than creating a single-line config file defining the port…

Teamspeak and Mumble (which I prefer because it’s free and open-source… also already vastly superior sound quality years ago when Teamspeak was stil the common option most peope used) are indeed “separate applications” doing only one of the jobs… voice communication in this case.

Discord alternatives are complicated, because Discord is conceptual bullshit. It started as voice communication, yet became popular for the text communication.

So you won’t find a good replacement (unless something new created in particular to mimic discord), because the things it now provides are better handled by seperate applications.

PS: OBS should already work on it’s own, without a dedicated webserver on your side. Basically every media program (also browser) should be able to handle streams

OBS’ WHIP (WebRTC-HTTP Ingestion) support should allow direct connection to web browsers.

(I’ll will take a look at it when I’m home)

Fun fact: Contrary to popular believe you are better off using a channel already used by a strong signal than a weak one. Your router will be better at filtering which packets do not belong to your wifi when the signal is strong and clear.

Because the default is set for healthy performance. But users in actual reality don’t care for raw performance but want responsive systems. If you are opening a browser to pass time while some longer process runs in the background, you are less interested in that background process being done 10% faster than in your browser not being sluggish.

PS: Sidenote… Many recommendations are based on older kernels. Since 5.8 swappiness is not measured from 0 to 100, but 0 to 200. So the 60 default is already half of what it was many years ago.

But distros are comparably tiny. So you can use up all those ancient sticks with a few GB you got as advertising that are collecting dust in some corner of a drawer for years. Sometimes they are even actually tiny when you free them from their tacky mascot- or logo-shaped exterior.

“It’s not a professional’s job to read the manuals they need to know for their job unless I specifically tell them to” is an interesting take. A really stupid one but interesting non-the-less…

“Some people don’t like Snaps” 😂