Difference between revisions of "Talk:Letsencrypt"
| Line 3: | Line 3: | ||
At least for the time being, I'd propose putting it in /root/letsencrypt. Thoughts? | At least for the time being, I'd propose putting it in /root/letsencrypt. Thoughts? | ||
| + | |||
| + | * /root should never never be a place to store 'compiling stuff', nor any other 3rd party code. Normally /usr/src is being used for source code. I rather see it to be stored in /opt/letsencrypt, so we are able to have control over permissions | ||
==Repositories== | ==Repositories== | ||
Revision as of 15:48, 7 December 2015
Filesystem
I think another filesystem location for the letsencrypt client would be more appropriate--it doesn't seem that we should need to create a new root-level directory called /src, just to put the letsencrypt client in. The Linux Filesystem Hierarchy doesn't call for any such directory, and since the standard SME installation doesn't contain a /src directory, it wouldn't be backed up either. Since it's an executable system maintenance script, it probably really belongs in either /usr/sbin or /usr/local/sbin, but retrieving the script using git puts it in a subdirectory, so it still wouldn't be in any user's path.
At least for the time being, I'd propose putting it in /root/letsencrypt. Thoughts?
- /root should never never be a place to store 'compiling stuff', nor any other 3rd party code. Normally /usr/src is being used for source code. I rather see it to be stored in /opt/letsencrypt, so we are able to have control over permissions
Repositories
Second, the Letsencrypt client documentation states "On RedHat/CentOS 6 you will need to enable the EPEL repository before install." Is this known to be incorrect? That is, has letsencrypt-auto been shown to run properly without having the EPEL repository enabled? If not, this page should include instructions for installing and enabling that repo.
- No idea, but we have to wait until the SCL repo is back on-line correctly.
