I have a few question about some of the wiki content that, in short, seems overly-cautious, or to show misplaced caution. Since it's a wiki, I could, of course, just edit it, but it's always possible I'm missing something. This seems like a better venue to discuss than the talk page on the wiki.
1. Under Prerequisites, there's discussion of noting, or backing up, the modSSL configuration. Then follows this: "or to be sure, a copy of the complete configuration database (
a good practice before any action such as manual changing of db values or installing a contrib)".
Really? Are we really going to recommend that any time someone installs a contrib, or makes any manual change to the configuration database, that they make a complete backup copy of the database? This seems entirely unnecessary to me, particularly since any changes to the database are logged in /var/log/messages. Noting existing values (if any) of properties you're going to change, or even making a backup of those properties, would make sense. A backup of the entire config database, with hundreds of lines to dig through to find what you're looking for, just seems like overkill. I might feel differently on this if there were a way of doing a "config import" from the backup file (thus reverting the config database to the time the backup was made), but AFAIK there's no way to do that.
2. In the installation section are commands to set the modSSL properties for the cert, key, and chain file. Following those commands is this note:
We need to see if setting the above db variables disturbs other SME Server default functionality and contribs that work with certificates such as VPN solutions.
Those same db variable settings appear on the wiki in at least five other places (
http://wiki.contribs.org/Custom_CA_Certificate,
http://wiki.contribs.org/Certificate_Concepts,
http://wiki.contribs.org/Certificate_Integration_GoDaddy_Certificate,
http://wiki.contribs.org/Certificate_Integration_Thawte_Certificate, and
http://wiki.contribs.org/Certificate_Integration_startssl.com_Server_Certificate), with no such warning. They appear to be the well-documented "SME way" to specify a certificate, key, and chain file. I can't see any reason why this warning needs to uniquely appear on the page for letsencrypt.
3. There's a note in the renewal section, partly about the script, and partly about software collections in general:
The above commands enable Python 2.7, but do not disable it again. In general we need to examine the effect of using SCL Python 2.7 on production servers where the default Python version is being used.
As to the first issue, I'd think that running the script properly (i.e., './letsencrypt-renew.sh' rather than 'source letsencrypt-renew.sh') would itself take care of disabling Python 2.7--it will spawn its own shell, and when the script exits, any environment changes it makes should go away, right? But another way to make sure that python27 is only enabled for that script would seem to be deleting lines 2 and 3 of the script, and calling the script with
scl enable python27 '/opt/letsencrypt-renew.sh'As to "examin[ing] the effect of using SCL Python 2.7"--isn't that pretty much the point of using the software collections? To allow you to install a newer version of some software package, so that it can be used when required, but still doesn't interfere with the rest of the system unless explicitly called? If we aren't confident that they'll work in that way, it seems that should be noted on
http://wiki.contribs.org/Software_Collections
236 Replies
63501 Views