• 15 Posts
  • 1.77K Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle
  • The fact that this even exists is amazing.

    That’s why I’ll believe it when it’s actually in people’s hands.

    The many qualifiers they hanged on the Signature and the uncertain date makes me believe they could pivot at any time. Also Google is not going to be happy about any manufacturer trying to get away from under their thumb. So it could still turn out to be some kind of rope tug between Google and Motorola, like Samsung duplicating all Google apps just to make a point.

    Last but not least the many supposed years of support are most likely bogus, Lenovo’s Motorola has never updated any of their phones for so long.




  • 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.








  • 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 ...
    


  • 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.