I certainly understand that SME Server is not, and is not intended to be, a bleeding-edge distro--its focus is on stability (which it's built on CentOS/RHEL rather than Fedora or Ubuntu). I also understand the need for caution, especially when dealing with beta software. I don't have any issue with labeling the page as WIP, nor identifying the skill level as Advanced. My concern with at least two of the three points I raised was that they just seemed to be overly cautious, possibly bordering on FUD.
1. Database backup. I can see value in a text backup of the config keys you're altering. "config show modSSL > backup.txt" makes perfect sense. I can see value in a restore-able backup of the entire config database--if you manage to hose it, just revert to the backup. We don't have that (yet?). I just don't see the value in a text backup of the entire config database--you can't restore from it, so you have to manually look through it to find how things were before you changed them. If you're going to do that, you might as well grep through /var/log/messages and find the changes you've made. All the changes are logged there, so you can see whatever you've changed. IMO, if we're going to call something a best practice, it should give some specific benefit that we don't already have, and I'm just not seeing it here.
2. Note on the certificates. Is the concern here that the cert files are in /etc/letsencrypt rather than /home/e-smith/? I could understand that (I raised the question myself up-thread), though so far it doesn't seem to be a problem. Everything in /etc/letsencrypt is owned by root:root, as in /home/e-smith/ssl.key and /home/e-smith/ssl.crt. OTOH, those config properties clearly call for full paths, so any config file that's going to use them should be able to deal with a proper (i.e., PEM-encoded) cert or key wherever located. I think the LE-generated cert/key have already been demonstrated to work with the base install; if they somehow break a contrib, that would be a bug against the contrib. But I wouldn't have a problem with noting that the SSL key and certificate have traditionally been located in /home/e-smith, and it's not certain at this time whether placing them in /etc/letsencrypt instead would cause any problems.
3. On SCL. I know I use that approach for php56 in a cron job, and that works without issue. I just set up one with a test letsencrypt script (it just calls letsencrypt --help), and it does seem to work--letsencrypt-auto runs, and it doesn't give the Python 2.6 warning, so that indicates it is running in a Python 2.7 environment.
Edit: Just to be clear, my cron entry is:
38 9 18 12 * scl enable python27 '/opt/letsencrypt-test.sh'...and /opt/letsencrypt-test.sh is:
[root@e-smith opt]# cat letsencrypt-test.sh
#!/bin/bash
/opt/letsencrypt/letsencrypt-auto --help all
Since I know that letsencrypt-auto will error out if run under Python 2.6 without the --debug flag set, I figured this would be a valid test. It did run, and emailed me the help output.
236 Replies
63517 Views