2 ms·

I know it doesn't address the root of the problem, but if you are running Python in production, you should always be using a virtualenv. Virtualenv is essential

I know it doesn't address the root of the problem, but if you are running Python in production, you should always be using a virtualenv. Virtualenv is essentially a separate Python runtime with it's own packages and interpreter. You can have as many virtualenvs as you like on the same machine and have them all configured completely separately. > At one point a simple letsencrypt refresh ended up re-installing some critical python component eventually resulting in a full re-install of a server. The letsencrypt developers explicitly recommend using a virtualenv to run the certbot script. The best part of virtualenvs is that you can almost use them like little containers. For instance, let's say you have a script running a web interface and another script that performs data calculations both on the same server. Your web application can have its own virtualenv and be listening for proxied requests from an nginx instance. The data processing script can be running in it's own virtualenv as well and listening on a local unix socket for incoming data to process. The data processing script is 100% independent of the web application script and vice-versa. They each have their own interpreter and dependencies. Hell, you could even run your data processing script in Python 2 and your web application in Python 3 if you needed to.

jacquesm 9y ago
> The letsencrypt developers explicitly recommend using a virtualenv to run the certbot script. Yes, but virtualenv is not always available and updating a certificate should not require a large amount of software to be installed on the sly on a machine, it should just upgrade the certificate and be done with it.
- scriptkiddy 9y ago
  How is virtualenv not always available? ``` pip install virtualenv virtualenv -p python3 venv ``` If you have a heavily locked-down server or something, talk to the administrator. > updating a certificate should not require a large amount of software to be installed on the sly on a machine, it should just upgrade the certificate and be done with it. I respectfully disagree. First, updating a certificate can be done by hand without the use of any software. The point of letsencrypt is to automate the process. Automation requires software. If letsencrypt were written in C you would still need to ensure that the executable was compiled for your architecture and that you have the correct header files available in the correct locations. I'm also not sure what you mean by "on the sly" here either. If we assume that you mean that the letsencrypt package automatically creates a virtualenv, how is this any different from postgres installing libxml2 as a dependency for example?
  - jacquesm 9y ago
    > ``` pip install virtualenv virtualenv -p python3 venv ``` Yes, if everything always worked as advertised that is how you would do it. Unfortunately it isn't. > First, updating a certificate can be done by hand without the use of any software. Yes, I'm aware of that. > The point of letsencrypt is to automate the process. Automation requires software. Exactly. So, how difficult can it be to upgrade a certificate that was already there, nothing on that machine needed 'upgrading' over and beyond the certificate, especially not without doing so in an irreversible way. All the software required to do the upgrade was in place because it worked 90 days before then.
    - scriptkiddy 9y ago
      > Yes, if everything always worked as advertised that is how you would do it. Unfortunately it isn't. You'll have to explain. Any problems that arise would be problems that would arise with installing any package from any packaging system. I fail to see your point. Errors and bugs are always possible in any situation. This isn't really an argument against vurtualenvs, it's an argument against software in general. > Exactly. So, how difficult can it be to upgrade a certificate that was already there, nothing on that machine needed 'upgrading' over and beyond the certificate, especially not without doing so in an irreversible way. All the software required to do the upgrade was in place because it worked 90 days before then. When dealing with security measures such as SSL, it's extremely important that all packages involved in the process are secure and up to date, Therefore, it makes sense to me that an SSL library would want to ensure that all of it's dependencies have the latest bugfixes and security patches.

jacquesm 9y ago

> The letsencrypt developers explicitly recommend using a virtualenv to run the certbot script. Yes, but virtualenv is not always available and updating a certificate should not require a large amount of software to be installed on the sly on a machine, it should just upgrade the certificate and be done with it.

scriptkiddy 9y ago
How is virtualenv not always available? ``` pip install virtualenv virtualenv -p python3 venv ``` If you have a heavily locked-down server or something, talk to the administrator. > updating a certificate should not require a large amount of software to be installed on the sly on a machine, it should just upgrade the certificate and be done with it. I respectfully disagree. First, updating a certificate can be done by hand without the use of any software. The point of letsencrypt is to automate the process. Automation requires software. If letsencrypt were written in C you would still need to ensure that the executable was compiled for your architecture and that you have the correct header files available in the correct locations. I'm also not sure what you mean by "on the sly" here either. If we assume that you mean that the letsencrypt package automatically creates a virtualenv, how is this any different from postgres installing libxml2 as a dependency for example?
- jacquesm 9y ago
  > ``` pip install virtualenv virtualenv -p python3 venv ``` Yes, if everything always worked as advertised that is how you would do it. Unfortunately it isn't. > First, updating a certificate can be done by hand without the use of any software. Yes, I'm aware of that. > The point of letsencrypt is to automate the process. Automation requires software. Exactly. So, how difficult can it be to upgrade a certificate that was already there, nothing on that machine needed 'upgrading' over and beyond the certificate, especially not without doing so in an irreversible way. All the software required to do the upgrade was in place because it worked 90 days before then.
  - scriptkiddy 9y ago
    > Yes, if everything always worked as advertised that is how you would do it. Unfortunately it isn't. You'll have to explain. Any problems that arise would be problems that would arise with installing any package from any packaging system. I fail to see your point. Errors and bugs are always possible in any situation. This isn't really an argument against vurtualenvs, it's an argument against software in general. > Exactly. So, how difficult can it be to upgrade a certificate that was already there, nothing on that machine needed 'upgrading' over and beyond the certificate, especially not without doing so in an irreversible way. All the software required to do the upgrade was in place because it worked 90 days before then. When dealing with security measures such as SSL, it's extremely important that all packages involved in the process are secure and up to date, Therefore, it makes sense to me that an SSL library would want to ensure that all of it's dependencies have the latest bugfixes and security patches.