hardcoded paths, and hardcoded filenames
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
Research direction
Start by inspecting cron_wrapper, virtual_servers, the pythonvenv/python37 path, and the .f5creds and load-balancer configuration files. Trace how paths, filenames, credentials, and F5_HTTPS are selected, then check whether command-line overrides or multiple load balancers are supported. Done requires a defined configuration approach that avoids the reported hardcoded assumptions and preserves the needed HTTP challenge and HTTPS deployment behavior.
Written by the indexing model from the issue text.
Description
cron_wrapper is not executable in the repo. That should be changed.
paths are hardcoded which won't work for most users. Perhaps something like:
- cd $HOME/lets-encrypt-python
Also, I don't have a
pythonvenv/python37/bin/activate
what should that contain?
This code breaks our setup. I have multipe file sets.
- {loadbalancer} - contains all my setting including host, user, pass, http, https
- {loadbalancer}.cfg - DOMAINS_TXT="${BASEDIR}/{load balancer}.dom"
- {loadbalancer}.dom - all the san certs each set on one line
Having the authentication in the environment meant that I could talk to different load-balancers, potentially with different credentials all in one directory. the ONE .f5creds that can't seem to be overridden breaks that.
The file "virtual_servers" also breaks this setup, looks hardcoded, and can't be overridden on the command line. This file assumes that the virtual server name for a given hostname is the same on each load balancer, which is often not a valid assumption. It also require adding each domain on a san cert to the lookup table. This might be useful in some situations, but not for me at the moment as I'm only testing on one vs per lb.
Eventually it would be nice to be able to deploy the validation changes on multiple load balancers, test, and then remove from multiple load balancers in the case were a host uses GTM/DNS load balancing or just has multiple IPs in DNS.
This seems to remove the F5_HTTPS handling. The Let's Encrypt challenge is over http, which should be a separate vip from the one where the cert should be installed in the end. We'll want a F5_HTTPS if eventually we want to add the created ssl profile to a vip, as it won't be the same vip.
- Dominant language
- Shell
- Stars
- 50
- Forks
- 12
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from f5devcentral/lets-encrypt-python
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
-
Cert Chain Exists Open
f5devcentral/lets-encrypt-python#2 · 2 comments · 1 assignee ·
All issues in f5devcentral/lets-encrypt-python
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
danielmiessler/LifeOS#2218 ·
-
docs(agents): strengthen the no-backslash-escaped-backticks rule with an issue-creation example Open
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
package-update
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
oSoWoSo/vOid_Community_repOsitory#148 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
chore
Difficulty 1/5 Under an hour Newbie friendliness 91/100
alunduil/alunduil-chezmoi#792 ·