Foxy Droid here.

I’m pretty sure you can get still charged for criminal acts committed without intent.

What you shouldn’t be able to do is go “oh lol whoopsie” and walk away free. Especially when you’re dealing with state actors.

No matter how you frame this act, it’s bogus. If you have a dog and it gets into private property and causes damage, you’re responsible for it. Why not for your AI.

You should be using them depending on your needs. There’s a difference between app containers (single app per container), system containers (multiple apps in the same container) and VMs (OS + whatever, virtualized rather than containerized).

You probably need app containers most of the time so docker or podman is a good fit. But sometimes you might feel more confortable with another level of abstraction. Tools like Proxmox or Incus make it easy to manage “system”-level abstractions like system containers (with LXC) or VMs (with KVM) and give you a unified management approach.

You don’t have to give up app containers either. You can run docker or podman inside an LXC system container and have the best of both worlds.

Deciding when to take advantage of the system abstraction is the hard part. A simple rule of thumb is to do it when you’d like to manage the “machine” that holds the stack in a way that’s different from the host. Maybe you want to run a different Linux distro; maybe it’s the same distro as the host but you want to organize it differently; maybe you need to run a non-Linux OS.

I would argue that’s a bit of a perversion 😃 but on the other hand if it can serve my static page… I’ll have to reconsider HAProxy for my stuff. Thanks!

unlike stoat which requires to apply to be able to contribute which is suspicious for a supposed open source software.

They’re doing it because they require a Developer Certificate of Origin from contributors in order to mitigate legal liability. Which is probably smart, it’s good to cover your bases when you take on the likes of Discord, who would love to be given an opening to sue and/or obtain a cease & desist on copyright grounds.

Probabilistic scrabble isn’t going to cure shit.

To be more exact, if probabilistic approach could have found the cure for something, it has found it by now.

Breakthroughs typically require a new way of thinking about the problem, not throwing more brute force at it.

Apple wouldn’t have survived the 90’s because, ironically, Microsoft saved them from bankruptcy.

At this point a deathblow would be a kindness for the Halo franchise.

FWIW I’ve tried all the major CLI tools for cert renewal (certbot, lego, acme.sh) and certbot was by far the easiest to use. The others were various shades of horrible – bad documentation, obscure error messages, you name it. Wish I had tried certbot first and not wasted my time.

You can find the magical incantations online and coax them to work eventually but they made me wonder if that’s the kind of tool I want to trust with my cert renewal. Also I’m starting to think it’s not a coincidence that other tools like NPM bundle certbot (as opposed to something else).

The dirs are subdirs of /srv/letsencrypt. I like to take advantage of explicit dir assignment if the software allows it, so I don’t have any surprises if the defaults change.

ROOT=/srv/letsencrypt
SECDIR="${ROOT}/secrets"
CFGDIR="${ROOT}/config"
LOGDIR="${ROOT}/logs"
TMPDIR="${ROOT}/tmp"

for DIR in "$SECDIR" "$CFGDIR" "$LOGDIR" "$TMPDIR"; do
        mkdir -p "$DIR"
done

cd "$ROOT"

... then venv activate and run venv certbot ...

Just keep in mind that HAProxy is only a proxy (technically a performance-oriented load-balancer). It’s not a web server.

I mention it because some of us also rely on our reverse proxy to serve small static webpages for various purposes (I serve a small status page generated by a cron script, for example).

I’m also using Certbot with DeSEC. I simply run it daily with anacron. If it doesn’t need to renew the certs yet it will say so and stop. That’s basically it.

I think it’s a very good idea for your LE renewal to be independent of whatever reverse proxy or web server you’re using.

Please keep in mind that Certbot is a Python app so you can manage it with venv. Here’s how I install it in a dedicated dir (let’s say /srv/letsencrypt because using /etc is not appropriate and it bugs me 😆):

#!/bin/bash
set -e
apt install python3-venv
/usr/bin/python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install --upgrade pip
python3 -m pip install --upgrade certbot certbot-dns-desec

And to update it:

#!/bin/bash
set -e
source .venv/bin/activate
python3 -m pip install --upgrade pip
python3 -m pip install --upgrade certbot certbot-dns-desec

As for renewing certs (the script is longer, I’m making sure to create dirs and so on but this is the gist of it):

source .venv/bin/activate

./.venv/bin/certbot \
--config-dir "$CFGDIR" \
--logs-dir "$LOGDIR" \
--work-dir "$TMPDIR" \
--domain "${DOMAIN}" \
--domain "*.${DOMAIN}" \
--authenticator dns-desec \
--dns-desec-credentials "${SECDIR}/${DOMAIN}.ini" \
--non-interactive --agree-tos \
--email "$EMAIL" \
certonly

openssl x509 -text -in "${CFGDIR}/live/${DOMAIN}/fullchain.pem" |\
grep -e 'Not Before' -e 'Not After'

For DeSEC you need secrets/${DOMAIN}.ini to contain:

dns_desec_token = YOURTOKENHERE

Please note that DeSEC lets you restrict what the token can do, but setting the rights on the token has to be done through their API so you need a separate token for the API 😅.

To use the certs from Caddy, point it at the files under the config/live/${DOMAIN}/ dir (which are symlinks that are maintained by Certbot), NOT the ones under archive/.

tls /path/to/certbot/config/live/example.com/fullchain.pem /path/to/certbot/config/live/example.com/privkey.pem

Or, if you want to also add mTLS to the mix:

tls /path/to/certbot/config/live/example.com/fullchain.pem /path/to/certbot/config/live/example.com/privkey.pem {
    client_auth {
        mode verify_if_given # or whatever access mode you want
        trust_pool file /path/to/custom/ca.pem
    }
}

Let me know if you have questions.

Y’know I’ve often wondered that, but authoritarian propaganda seems to have a penchant for keeping its statements plausible. I mean they could take the piss and say it was 500% and it would be just as well. I’m guessing there’s some psychological benefit to be had from keeping it “real”, gives the rubble some kind of logic to cling to?

It does matter, just not the way you might think. Voting in dictatorships is basically a submission ritual.

You joke but behind the Iron Curtain the dictators used to win “elections” with something like 98% of votes. “See, we have some malcontents but they’re a tiny minority.” It was all doctored of course but it’s funny that they bothered to keep it believable when everybody knew the truth, both inside the country and elsewhere.

IRC supports TLS encryption. Many large networks don’t actually have it enabled or use self-signed certs because they still think it’s the 1990’s, but if you make your own server you can use TLS just fine.

It’s fairly safe as long as you add a strong enough form of access control. For example if you put it behind a VPN, or a SSH tunnel, or require mTLS. Even a key in a custom HTTP header or Basic HTTP auth can be good enough if the key is strong enough.

You can further decrease the probability of drive-by bots reaching a publicly exposed service by merely scanning IPs and ports if you use a reverse proxy and hide your service FQDNs and IP.

You can do this by using TLS certs on wildcard domains rather than explicit domains, using explicit CNAMEs for the service subdomains rather than a wildcard domain, and keeping the A/AAAA records on an obfuscated subdomain rather than the base domain. If the bots can’t figure out a FQDN they’re not getting past the reverse proxy even if they find the IP and port.

This is obfuscation not real security but it cuts down tremendously on bot hits.