This PR attempts to better inform people about the problem identified at https://community.letsencrypt.org/t/certbot-auto-deployment-best-practices/91979/.
I was hesitant to add the flag --no-permissions-check, however, if there's some obscure distro out there (or custom user setup) that has a strange users and groups, I didn't want us to either:
Have to put out a bug fix release
Refuse to fix the problem and let them deal with warnings on every run
* add check_permissions.py
* Update letsencrypt-auto.template.
* build letsencrypt-auto
* Add test_permissions_warnings to auto_test
* Allow uid/gid < 1000.
* Add --no-permissions-check to Certbot.
* Add --no-permissions-check to certbot-auto.
* Add test farm test that letsencrypt-auto is quiet.
As a bonus, this new test will catch problems like the one that the caused
0.33.1 point release.
* Update CHANGELOG about permissions check.
* Update permissions comment.
* Fix symlink handling.
* Use a better default in auto_test.py.
Fixes#6912
Bash evaluate all condition in a predicate statement, eg. `"$SOMEVAR" = "test" -a "$ANOTHERVAR" = "test2"`, even if it is not necessary, for instance if the first condition is false in the example here.
As a consequence, on non-Fedora distributions, an evaluation of the distribution version could be done on non numeric value, eg. `"6.7" -eq "29"`, making certbot-auto failing in this case.
This PR fixes that, by evaluating the version on RPM distributions only if we are on Fedora. Otherwise, version will be "0".
Fixes#6698
Fedora maintainers engaged a deprecation path for Python 2.x with Fedora 29. As a first step, python2-virtualenv does not install the virtualenv binary anymore, in favor of python3-virtualenv, and so the installation of Python 3 virtual environments by default.
However, certbot-auto installs python2-virtualenv for all recent RPM distributions, and relies of the execution of virtualenv, and this is failing the process.
Since the plan in the future is to remove Python 2.x from Fedora, this PR follows this logic to fix certbot-auto: started to Fedora 29, certbot-auto will install and execute certbot on Python 3. This implies to detect that we are on Fedora 29+, install python3-virtualenv that will install also Python 3 dependencies and virtualenv binary, then instruct the process to use Python 3. This is in fact similar to EOL distributions shipping with Python 2.6, and for which Python 3.4 from EPEL is installed and used.
Older versions of Fedora continue to use Python 2.x, and their process is untouched. Four scenarios are covered here:
fresh Fedora 28: old process is used, nothing changes
fresh Fedora 29: new process is used, Python 3 is installed, certbot runs on it
update Fedora 29 from 28, already installed certbot-auto without rebootstrapping required: existing venv continue to be used, certbot runs on it
update Fedora 29 from 28, already installed certbot-auto with rebootstrapping required: new process is used, installing python3-virtualenv, python3-devel and python3-rpm-macros, Python 3 is installed, certbot runs on it
* Add a step to handle python3 on fedora29
* Update letsencrypt-auto-source/letsencrypt-auto.template
Co-Authored-By: adferrand <adferrand@users.noreply.github.com>
* Update letsencrypt-auto-source/letsencrypt-auto.template
Co-Authored-By: adferrand <adferrand@users.noreply.github.com>
* Update letsencrypt-auto-source/letsencrypt-auto.template
Co-Authored-By: adferrand <adferrand@users.noreply.github.com>
* Update rpm_python3.sh
* Rebuild certbot-auto
* Empty commit to relaunch CI pipeline
* Add changelog
* Update CHANGELOG.md
Co-Authored-By: adferrand <adferrand@users.noreply.github.com>
* Update CHANGELOG.md
This will immediately address the breakage reported in #6682 and tracked at #6685. Virtualenv downloads the latest pip, which causes issues, so tell virtualenv to not download the latest pip.
I added the flag preemptively to other files as well, they're in separate commits so it will be easy to revert any spots we don't want.
I've confirmed that this fixes the issue on a machine that fails with the version of certbot-auto currently in master: recent version of virtualenv, python 2.7.
* Update changelog
* Use an environment variable instead of a flag for compatibility with old versions
* Run build.py
With current code, the certbot-auto self-upgrade process can make it actually to downgrade itself, because the comparison done is an equality test between local certbot-auto version and the remote one. This is a flaw for attackers, that could make certbot-auto break itself by falsely advertising it about an old version as the latest one available.
A function is added to make a more advanced comparison between version. Certbot-auto will upgrade itself only if the local version is strictly inferior to the latest one available. For instance, a version 0.28.0 will not upgrade itself if the latest one available on internet is 0.27.1. Similarly, non-official versions like 0.28.0.dev0 will never trigger a self-upgrade, to help development workflows.
This implementation relies only on the Python distribution installed by certbot-auto (supporting 2.7+) and basic shell operations, to be compatible with any UNIX-based system.
* Check version with protection again downgrade
* Create a stable version of letsencrypt-auto to use correctly self-upgrade functionality
* Update letsencrypt-auto-source/letsencrypt-auto.template
* Drop support for EOL Python 2.6
* Use more helpful assertIn/NotIn instead of assertTrue/False
* Drop support for EOL Python 3.3
* Remove redundant Python 3.3 code
* Restore code for RHEL 6 and virtualenv for Py2.7
* Revert pipstrap.py to upstream
* Merge py26_packages and non_py26_packages into all_packages
* Revert changes to *-auto in root
* Update by calling letsencrypt-auto-source/build.py
* Revert permissions for pipstrap.py
* Fix rebootstrapping before venv move
* add regression test
* dedupe test
* Cleanup case when two venvs exist.
* Add clarifying comment
* Add double venv test to leauto_upgrades
* Fix logic with the help of coffee
* redirect stderr
* pass VENV_PATH through sudo
* redirect stderr
* If there's no python or there's only python2.6 on red hat systems, install python3
* Always check for python2.6
* address style, documentation, nits
* factor out all initialization code
* fix up python version return value when no python installed
* add no python error and exit
* document DeterminePythonVersion parameters
* build letsencrypt-auto
* close brace
* build leauto
* fix syntax errors
* set USE_PYTHON_3 for all cases
* rip out NOCRASH
* replace NOCRASH, update LE_PYTHON set logic
* use built-in venv for py3
* switch to LE_PYTHON not affecting bootstrap selection and not overwriting LE_PYTHON
* python3ify fetch.py
* get fetch.py working with python2 and 3
* don't verify server certificates in fetch.py HttpsGetter
* Use SSLContext and an environment variable so that our tests continue to never verify server certificates.
* typo
* build
* remove commented out code
* address review comments
* add documentation for YES_FLAG and QUIET_FLAG
* Add tests to centos6 Dockerfile to make sure we install python3 if and only if appropriate to do so.
Now we always check if we have root access if --cb-auto-has-root is not given
on the command line. This allows certbot-auto to properly acquire root when
upgrading from an older version. People upgrading from 0.18.0 to 0.18.1 may
check for root access twice, however, if root's user ID is 0, this check is
essentially a noop. If root's user ID is not 0, we'll request root access a 2nd
time during this upgrade.
* Add version number to bootstrap scripts.
* Always determine Bootstrap function and version.
* Write bootstrap version into venv.
* Add PrevBootstrapVersion function.
* Add OS bootstrapping check to phase 2.
* Differentiate -n and renew when rebootstrapping.
* Quote all environment variables.
* Correct test condition
* Add loud warning about hardcoded version list.
* s/VENV_BOOTSTRAP_VERSION/BOOTSTRAP_VERSION_PATH
* Properly handle noop bootstrap functions.
* Update comment about root usage.
* run all of certbot-auto as root
* remove other $SUDO uses from template
* remove $SUDO usage from bootstrappers
* default venv path = /opt/eff.org/certbot/venv
* Create symlinks from old default venvs
* Delete old venv path when it exists.
Also, quote expansion of paths.
* fix typo
* Separate venv_dir and le_auto_path
* Deduplicate code with test_dirs()
* Ignore cleanup errors.
This is caused by subdirectories being owned by root.
* Split test into test_phase2_upgrade.
* Rename test_dirs to temp_paths for clarity.
* Check both venvs before bootstrapping again.
* Use OLD_VENV_PATH/bin
* Preserve environment with sudo.
* Remove "esp. under sudo" comment.
* Export *VENV_PATH.
* Change check for OLD_VENV installation.
This approach better handles manually set VENV_PATH values.
* Remove SUDO_ENV.
* Print message before requesting root privileges.
* Make a function for selecting root auth method.
* Address @erikrose's feedback.
* Revert "Pin python-augeas version to avoid error with 1.0.0 (#4422)"
This reverts commit 1c51ae2588.
* make dependency-requirements
* separate certbot and dependency requirements
* fix build.py
* update hashin comment
* simplify release pinning
* separate letsencrypt dependency
* pin hashes in venv
* error out when bad things happen
* use pinned dependencies in tox
* Revert "pin hashes in venv"
This reverts commit 1cd38a9e50.
* use pip_install.sh in venv_common
* quote pip install args
* bump mock version
* say -- echo which honors quiet
* error -- echo which does not honor quiet
* switch non error echos to say
* switch error echos to error
* run letsencrypt-auto-source/build.py
* Support "certbot-auto --no-bootstrap"
* Tell people about --no-bootstrap?
* Document new certbot-auto flag in its cli help
* Rebuild
* Less variables is less variability
* Alphabetize help
* Make it extra clear we only take one branch
* Add --no-bootstrap message to experimentalbootstrap exit
* Add quiet flags to package manager invocations
Add the following flags when 'certbot-auto --quiet' is invoked:
- Add '-qq' to calls to 'apt-get' in Debian
- Add '--quiet' to calls to 'yum' or 'dnf' in CentOS or Fedora
- Add '--quiet' to calls to 'urpmi' in Mageia
- Add '--quiet' to calls to 'pkg install' in FreeBSD
* Fix $QUIET flag in bootstrappers
- Set the value of $QUIET properly (i.e. s/$QUIET/QUIET when setting the
variable) in
- deb_common.sh
- mageia_common.sh
- rpm_common.sh
- Actually use $QUIET when running $tool in rpm_common.sh
* Add handling of $QUIET to Arch and Open Suse
* Add logic to set --non-interactive if --quiet
* Add missing $QUIET_FLAG to rpm_common.sh
* Run build.py
* Limit --help to 80 cols
* Update indentation within bootstrappers
* Add $QUIET_FLAG to second call to `urpmi` (redux)
When certbot-auto cannot find the currently installed version, output the error to the end-user, instead of not showing anything, and re-installing the virtualenv.
Fixes#4034
* Added support for shells without default variable support
* Added support for BusyBox installs that do not have `command` but has `which`
* Style fixes as suggested by reviewer
* Renamed `WHERE_IS` to `EXISTS` as suggested by review
* Removed expansion of `$LE_AUTO_SUDO` to `x` as the `-n` can check empty strings.
* Added `EXISTS` to debian bootstrap as suggested in review
* certbot-auto: Print link to doc on debugging pip install error
Also, update the doc to teach the user to workaround problem on a low
memory system.
* Correct formatting
* grep the PIP_OUT and print useful info if the problem is about memory allocation
* Fix logic on string to grep
Not resetting OPTIND between each call of getopts skips all short args except the first one.
It fixes this automated command:
./certbot-auto certonly --webroot -w /tmp -d example.com --agree-tos --email contact@example.com -n
Where "-w" was parsed by getopts and not "-n"
* When getopts is called multiple time we need to reset OPTIND. Issue #3459
* Adding OPTIND reset in the certbot-auto source file
* Building new letsencrypt-auto from template
