letsencrypt-auto updates on each run

[paulschreiber]

Every time I run letencrypt, like so:

./letsencrypt-auto --agree-dev-preview

I get this message:

Updating letsencrypt and virtual environment dependencies......

Even if I just ran the client a few seconds before.

[IzzySoft]

That annoyed me as well, so I've patched letsencrypt-auto to do that no more than once a day (interval configurable). Unfortunately I cannot attach the diff here, hence I've posted it to pastebin. It's rather a "quick-and-dirty hack" (so I didn't feel like forking and submitting a pull request for that), but it works. Certainly could need some improvements – e.g. having the interval as config variable, or a command-line parameter to force/skip.

[centminmod]

why not check if there's updates before updating ?

[IzzySoft]

Looks like those checks are left to the update process: if there are no updates, it won't update anything. Still, that (implicit) check needs some time. IMHO it's not required on each run – once a day should be sufficient.

[DavidVentura]

Any updates on this?

[BurakDev]

+1

[IzzySoft]

My patch (see above) proved successful on multiple machines meanwhile. Feel free to pick it ( @kuba feel free to integrate it ).

[caseif]

@IzzySoft I have very limited experience with raw diff files - mind briefly explaining how to apply it?

[IzzySoft]

@caseif easy on Linux (on Windows, I don't know whether the patch command is available). Download (or copy-paste) the patch to a file in the same directory as letsencrypt-auto, name it e.g. le.diff. Then just run patch letsencrypt-auto le.diff, done.

In case of difficulties, I can also upload my entire letsencrypt-auto to a pastebin – but as there were updates to it (which I didn't yet apply) meanwhile, that might not be optimal.

[caseif]

I wasn't able to get it to apply properly on Debian (Git seemed to think it was malformed for some reason), so I ended up manually modifying the file.

[IzzySoft]

@caseif You didn't use Git to apply the patch, did you? It wasn't created with Git. If you rather mean the resulting file was thought being malformed: did the patch command fully succeed – or was there a message that it failed partially? Due to the meanwhile updated script, that might have happened – and the resulting file then indeed is malformed.

Indeed this seems to be the case: You can no longer apply my patch to the lastest version:

Hunk #1 FAILED at 12.
Hunk #2 FAILED at 73.

Sorry for that! If you could create a new diff from your working copy (as you've already manually applied the changes; diff -u letsencrypt-auto.orig letsencrypt-auto > letsencrypt-auto.diff, assuming you've kept the original file as letsencrypt-auto.orig), put it to a pastebin, and link it here, that would be great – so others wouldn't have to repeat the manual work.

@kuba If you'd then integrate that patch, it would be even better :)

[bmw]

This has been resolved. letsencrypt-auto still checks for updates on every run, however, it now does so with a single GET request. When this issue was written, letsencrypt-auto would check for updates for all of our Python dependencies which really slowed down the script.

Furthermore, if you don't want it to check for updates at all, you can now provide the --no-self-upgrade flag which will skip this step entirely.