Earlier quoted context omitted.
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
Dehydrated: Letsencrypt/acme client implemented as a shell-script
101–110 of 111 posts
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#102Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#103Earlier 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.
I know of a couple large organizations that have tens of thousands of RHEL 7 machines that use letsencrypt for customer websites, and I sent this project to sysadmins on their teams, so it's very realistic to expect that businesses are still using supported software.
Not everyone can just upgrade to the latest version of Ubuntu every 6 months for their production workloads like you might expect.
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#104Earlier quoted context omitted.
There are still machines on 2.6 kernels where I work. > I don't think > target audience You != people
And do those machines have web servers exposed to the world?
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#105Earlier quoted context omitted.
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?
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#106Earlier quoted context omitted.
Why would you use this for anything else than a joke given that Certbot exists, and is even in most repositories? (asking seriously)
The only joke here is Certbot, a tool intended for use on servers but distributed on a channel intended for consumer use - Snap. The only package manager that will update on its own, when it feels like it, without a killswitch, runs as a daemon intertwined with the system. Icing on the cake is that the Certbot team advertises alternative install methods, of which none work and all of the lengthy guides for them recom…
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#107Earlier quoted context omitted.
There are still machines on 2.6 kernels where I work. > I don't think > target audience You != people
And do those machines have web servers exposed to the world?
Then address this to the owners of those machines. And get a load of cash ready to give it to them, so they could migrate to somehitng newer.
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#108Earlier quoted context omitted.
Seems to work in zsh too. Both bash and zsh are shells like c-shell ksh etc. Nowhere is it implied that shell-scripts are written for Bourne shell.
I am not familiar with zsh, but is it really interpreted by zsh? Because the script has #!/usr/bin/env bash in its shebang, isn't it executed by bash on your system, even if launched from zsh?
They seem to have gone through some effort for this to be true.
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#109Earlier quoted context omitted.
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?
Why would I want a system level python install?
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#110Earlier quoted context omitted.
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?