Live data from Hacker News

Dehydrated: Letsencrypt/acme client implemented as a shell-script

github.com

91–100 of 111 posts

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#91

Earlier quoted context omitted.

3.6 is pretty much universally available at this point.

RHEL 7 (which still has 4 years of extended lifecycle support left) ships with Python 2.7.5 MacOS Sonoma (the latest version) doesn't include Python at all; older versions of MacOS which are still supported ship with Python 2.x

I don't think anyone using RHEL 7 is in the target audience for this software. Be realistic.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#92
post #89
post #56

Earlier quoted context omitted.

I mount webserver docroot and /etc/letsencrypt directories into the certbot container, /docroot and /etc/letsencrypt mount points respectively, it is totally prepared for this.

How did you implement reloading the modified TLS certificates after renewal tho?

it's a two line script running periodically. the first line is docker the second is nginx -s reload. As /etc/letsencrypt dir is mounted from nginx into certbot, certbot upgrades that, nginx reload picks them up. Easy as pie.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#93
post #45

Parsing json in shell? Easy! filter="$(printf 's/. \[%s\][[:space:]] \([^"]*\)/\\1/p' "$(json_path "${1:-}" "${2:-}")")" Please, no! How can you know this is safe? Why not just use Python? It is installed pretty much everywhere, supports json without such hacks.

In my experience Python software is not really nice when it comes to distribution. Hate the venv stuff and pip install hassles. Besides, it is slow. Honestly, if runtime interpretation is a requirement, PHP would be better then in these respects.

The point of using '#!/usr/bin/env python3' is that you don't have to mess with virtual environments.

Using this exact shebang line signals "This script is intended to be executed directly (not a python module) and it only needs the python3 standard library."

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#94
post #45

Parsing json in shell? Easy! filter="$(printf 's/. \[%s\][[:space:]] \([^"]*\)/\\1/p' "$(json_path "${1:-}" "${2:-}")")" Please, no! How can you know this is safe? Why not just use Python? It is installed pretty much everywhere, supports json without such hacks.

I would not trust that script. If Python is such a hassle then there is also Lego: https://github.com/go-acme/lego which supports tons of DNS providers and is very well documented.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#95
post #90
post #45

Parsing json in shell? Easy! filter="$(printf 's/. \[%s\][[:space:]] \([^"]*\)/\\1/p' "$(json_path "${1:-}" "${2:-}")")" Please, no! How can you know this is safe? Why not just use Python? It is installed pretty much everywhere, supports json without such hacks.

python hasn't been installed by default in almost any env i've worked in for the past ~5 years maybe for dev environments, but certainly not for servers

Interesting how that was achieved. Most popular Linux distributions are very hard to install without python3 an perl5. LSB https://refspecs.linuxfoundation.org/lsb.shtml defines them as standard.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#96
post #95
post #90

Earlier quoted context omitted.

python hasn't been installed by default in almost any env i've worked in for the past ~5 years maybe for dev environments, but certainly not for servers

Interesting how that was achieved. Most popular Linux distributions are very hard to install without python3 an perl5. LSB https://refspecs.linuxfoundation.org/lsb.shtml defines them as standard.

Maybe not so hard as you might think. On my openSUSE desktop, uninstalling python3 would remove only calibre and virt-manager. Most of my server/container/vm installs don't have any python version. Perl isn't much harder to get rid of depending on the use case, for example some development stuff uses it.

I'm also not sure distros generally care about LSB. Debian dropped it years ago and did any distro even bother to implement it correctly?

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#97
post #79

Earlier quoted context omitted.

Are you saying that any use of Alpine is, by definition, a supply-chain security problem?

I am, yes. Alpine is not full-source-bootstrapped, often imports and trusts external binaries blindly, has no signed commits, no signed reviews, no signed packages, and is not reproducible. It is one phished git account away from a major supply chain attack any day now. Alpine chooses low security for low contribution friction. It is the Wikipedia of Linux distros, which granted it a huge package repository fantastic…

Thanks for the detailed response!

EDIT: Also, stagex looks pretty compelling; I hope it catches on!

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#98
post #50

Earlier quoted context omitted.

APILayer = ZeroSSL

ZeroSSL are the only ones providing certificates for IP addresses and free year-long certificates. Cudos to them for disrupting this market, almost monopolized by letsencrypt. Don't have high hopes, though, big players probably will kill them as they killed other free certificate issuers. For some reason letsencrypt status-quo as the only free certificate issuer benefits big players.

Which ‘big players’?

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#99

Earlier quoted context omitted.

RHEL 7 (which still has 4 years of extended lifecycle support left) ships with Python 2.7.5 MacOS Sonoma (the latest version) doesn't include Python at all; older versions of MacOS which are still supported ship with Python 2.x

I don't think anyone using RHEL 7 is in the target audience for this software. Be realistic.

There are still machines on 2.6 kernels where I work.

> I don't think

> target audience

You != people

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#100
post #96
post #95

Earlier quoted context omitted.

Interesting how that was achieved. Most popular Linux distributions are very hard to install without python3 an perl5. LSB https://refspecs.linuxfoundation.org/lsb.shtml defines them as standard.

Maybe not so hard as you might think. On my openSUSE desktop, uninstalling python3 would remove only calibre and virt-manager. Most of my server/container/vm installs don't have any python version. Perl isn't much harder to get rid of depending on the use case, for example some development stuff uses it. I'm also not sure distros generally care about LSB. Debian dropped it years ago and did any distro even bother to…

I don't get all these arguments. You would really prefer to use hard-to-check shell script to simply installing system python package if it isn't installed already?
Post reply on HN