Debian has a policy of only cherry picking security updates, or critical bugfixes, in order to ensure maximum system stability. In general, they don’t do entire program updates or additional features. For the 4 year lifecycle of a Debian release, it will behave the same as it did yesterday.

As of today, current version of rsync in Debian’s stable’s packages is 3.4.1: https://packages.debian.org/stable/rsync (archive).

The versions with significant LLM assistance are 3.4.3 and later.

Certbot?

It can automate provisioning of certificates using DNS-01 challenges, which have wildcard certificates.

https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins

Example tutorial: https://www.digitalocean.com/community/tutorials/how-to-create-let-s-encrypt-wildcard-certificates-with-certbot

Once you do that it puts the cert in /etc/letsencrypt/live/ so you can then do whatever you want with it. You would have to handle distribution manually.

If you want to automate stuff across of a bunch of machines at once, I recommend Ansible: https://docs.ansible.com/projects/ansible/latest/index.html

One thing I read about is that Ubuntu provides unattended updates, so it can automatically update packages and restart the server (that seems a bit too far ;) ). It’s probably possible on Debian but not out of the box.

Ubuntu automatically has unattended upgrades, which makes I think makes it a popular choice for VPS providers to push (beyond being popular in corporate/institutions overall), since they don’t have to worry about users forgetting security updates. However, it doesn’t enable automatic reboots. But, it does look like automatic restarts of services updated via unattended upgrades is done, but only as of Ubuntu 24.

Another thing to note is that Ubuntu has updates that are explicitly for security, and then everything else, including more general bugfixes and program updates with additional features. By default, unattended upgrades on Ubuntu only do security updates.

Of course, both a unattended upgrades and automatic reboots are possible on Debian (same software, Ubuntu just preconfigures it), although default configurations can vary. I wouldn’t be suprised if a VPS provider was shipping a default Debian configuration that enabled automatic upgrades.

On Debian, for the most part, ALL updates are only for security issues or severe bugfixes (program crashes or the like). Debian, for the most part, doesn’t do minor bugfixes at all, or do program feature updates. I prefer this model, since it’s easier to manage than having separate types of package updates. It ensures absolute stability, a guarantee that the system tomorrow will behave the same as it did yesterday, while still enabling automatic security updates. This model is ideal for a server I don’t want to babysit, or for your grandpa who loses his mind when the button he is supposed to click was moved one spot over.

In addition to that, I like the policy of automatic reboots. With the stable, slow moving nature of both distros, it’s safe to automatically reboot to ensure that kernel vulnerabilities, or vulnerabilities in other critical systems are fixed. Automatic updates and reboots can be the difference between someone being able to escape a docker container or someone not being able to.

There is one thing to note, is that adding additional repos (or PPA’s which technically you aren’t supposed to work on Debian), can be dangerous, and you have to be careful: https://wiki.debian.org/DontBreakDebian/#Don.27t_make_a_FrankenDebian

The main problem is that if a third party repo and Debian provide the same package, and the system is configured to prefer the third party repo, then you can be installing a potential dependency to the rest of your system that isn’t actually tested against your system, or compatible.

You have to be really careful to ensure that the programs in the repo are actually built and designed for your system, and also that the your system does not default to installing them.

Third party repos also break the guarantee of stability that automatic updates depend on. Third party repos don’t have a separate security channel, so Ubuntu will probably avoid touching them, even if critical security fixes are needed. Debian will update them, but unlike Debian’s packages, the overall program updates won’t be guaranteed to be behave the same due to potential major/minor version changes.

For example, if you get Docker from docker’s repo instead of Debian’s/Ubuntu’s, now your version of docker can no longer auto update and receive potential security fixes safely.

Overall, I prefer Debian but Ubuntu is fine. If I was in an environment that used Ubuntu already, I would also just use Ubuntu. If you are already using Debian, then Debian is probably preferable.

What made moodle frustrating?

I have also heard the opposite take, that canvas sucks and moodle is great.

Did you use it as a student/user, or as an administrator?

There is also moodle.

Canvas and moodle are really popular in schools and universities.

Paperless ngx seems to support fulltext search of PDF’s, in addition to other document types.

It looks like criticisms similar to mine were offered in the comments of the youtube video you linked at first, and now the youtuber has released a second video, a correction. In this video he uses nginx proxy manager and DNS-01 challenges:

https://www.youtube.com/watch?v=XEltHEZU6aE

Big respect for doing that.

You can use local certs with nginx proxy manager as well. You can upload certs via the web ui.

Rather than local certs though, I would recommend buying a domain and using it locally, with https. The problem with the local cert approach outlined in the video, is that importing a root cert opens up a big security hole to MITM attacks. If an attacker gets the root certificate, they can now MITM everything else your browser is accessing. You turn the browser from one of the most secure components of a modern OS, into only as secure as the server hosting the root certificates.

The approach I would prefer, is to buy a domain, and use it locally, using DNS-01 challenges to get letsencrypt signed certificates even from within an internal network. Both Caddy and NPM have support for DNS-01 challenges.

No, they are trivial to block using techniques like deep package inspection.

In addition to that, they aren’t truly decentralized (no decentralized network really is), both rely on relay/bootstrap servers to start up the connection. So, if you block the public relay/bootstrap servers, you effectively block access to the network.

Tailscale, netbird also can traverse NAT.

Iroh (the actually pretty interesting software which the vibecoded rayfish is based on) and Yggdrassil do have their uses, but evading blocks isn’t one of them.

You want a reverse proxy. A reverse proxy reads requests to subdomains and then forwards them to ports and back.

The easiest GUI one is: https://nginxproxymanager.com/

But there is also just straight nginx, or you can use Caddy or traefik or anything else.

Yes, I do lock it down. It’s still worth securing it because “internal servers” can still get exposed and touched, even though there are less paths to them, and it’s not as punishing to slip up vs a public server. For example, One of the wireguard client devices downloads a virus, and now you have a cyberattacker with access.

Another problem is supply chain issues. If the distributor of a docker container is hacked, it’s not that bad… as long as your kernel is up to date and is protected against some of the recent vulns, that would enable someone to break out of a docker container

Blajah.zone’s lemmy instance was hacked partially becuase internal servers weren’t being held to the same security standards as the public ones:

https://pen.blahaj.zone/supakaity/weve-been-hacked

I had not patched these internal servers that nobody should have access to against this. Rebooting DB servers causes downtime, and in my hubris – I thought nobody should (nay COULD) be on my servers except me, right?

I have a comment on that post with some potential solutions, that would have cut off attack paths.

Though, I guess, it still does depend. Like if it’s just gonna you wireguarding in and no one else, then the data on your devices is probably worth more than the data on the server, so no, it wouldn’t be worth spending too much effort to secure less valuable data.

But if you are handing out internal access to people, including to some relative who keeps falling for scammers, then yeah, I’d take some time to harden the systems.

https://programming.dev/comment/24515044

Same problem is present here. Uses JWT’s for auth.

Edit:

Using jwt’s for auth isn’t bad, it’s good and quite common The problem is when they are used in place of actual bearer/cookie/session auth methods. As I understand it at least, a jwt token with a lifespan greater than 5 minutes is a red flag.

I don’t use a UI.

I don’t use flux’s kustomize (there is also kustomize by kubernetes.

I use flux for installing helm charts, mostly.

Repo: https://github.com/moonpiedumplings/flux-config

It’s not up right now though. I am currently revamping it, which will also involve reorganizing the repo. I really dislike that I didn’t use (flux’s) kustomize, which is one of the things I would like to fix.

I’m on my phone rn, if I get to this post again from my computer later I will add longer/further thoughts.

Second comment, but if you need/want Caddy we can help that too. It looks like the documentation link in the github page you linked is dead, and the correct one is: https://caddyserver.com/docs/json/apps/tls/automation/policies/issuers/acme/

I found that from this page: https://caddy.community/t/how-to-use-dns-provider-modules-in-caddy-2/8148

Setup legit Let’s Encrypt as wildcard locally to test services at *example.domain.com, then put them into production on mainsite wildcard *.domain.com on VPS or similar.

Just to be clear, why wouldn’t simply provisioning a certificate for each subdomain under the wildcard work?

Like, if you have a test site test.example.domain.com, you could have nginx (using acme) create a certificate for that. And then when you move to test.domain.com, nginx would do the same thing.

Now, technically letsencrypt does have a rate limit, but it’s a fairly generous rate limit:

Up to 50 certificates can be issued per registered domain (or IPv4 address, or IPv6 /64 range) every 7 days. This is a global limit, and all new order requests, regardless of which account submits them, count towards this limit. The ability to issue new certificates for the same registered domain refills at a rate of 1 certificate every 202 minutes.

I would do my testing this way, and I didn’t hit any limits, although I was careful to keep certificates and reuse them, and to not spam.

If you need more domains with SSL than that rate limit would provide, then it would make sense to investigate Caddy with porkbun, since DNS-01 challenges are the only way to get wildcard certificates, which apply to a whole wildcard.

Calling an enterprise-grade platform

Except you use JWT’s for auth, which is idiotic and a security nightmare. No enterprise that cares about security would ever accept this.

More info: https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452

There are other problems, some of which I can see… and some of which I can’t. The problem is that I am not a comprehensive expert, I can only spot a few things here and there. Even if I was an expert, why would I audit your software for free lmao? Pay me for that shit.

What I do know, is that vibecoded apps are bad at security. Many, many vibecoded apps have been hit by horrific security bugs like remote code execution, xss, or authentication bypasses. That shit is simply unacceptable and should be extremely rare in modern apps. The fact that I’m not skilled enough to find them reliably makes me even more cautious and concerned around apps like yours.

It’s not just about the app architecture, but also about you. When a known community figure creates an app, I have confidence that they will have a good security posture and architecture. With vibecoding… not so much.

If you have an actual architectural critique

Nice bait, but the problem is this: Just because you get people to audit “critique” your software, doesn’t fix the root cause of those problems — you. Just because you manage to re-vibecode the app to not use JWT’s or to fix any other number of issues someone would point out, doesn’t actually mean more issues exist that that person missed. Like if someone specialized in python, then they might miss database issues, and so on. The second problem is that inevitably, you will expand this software, adding more features… and vulnerabilities. That is to say, even if you manage to fix the architecture and security now, you have not demonstrated the requisite skill needed in order to keep it fixed.