Create an official PPA for Ubuntu letsencrypt packages

[mithro]

It would be awesome if there was an official Ubuntu PPA for letsencrypt packages.

[gfairchild]

👍

[rask]

👍

[tgagor]

👍

[jaywink]

👍

[infoscav]

pretty please?

[RobinVanCauter]

Yes please!

[paddylandau]

Yes, please.

[stanislavromanov]

+1

[gslin]

+1

[slavach]

+1

[kuba]

There has been a ton of effort spent on letsencrypt-auto and none here. What's going on? I find this situation absolutely awkward, as letsencrypt-auto was meant to be temporary solution until we get packaged. @hlieberman and @fmarier invested a lot of time into the debs and we're now wasting time on some home-cooked "auto-magical" script that tries to basically replace all the packaging solutions (and, despite great efforts, fails miserably at it). There has been numerous complaints about how ridiculously complicated the client is and I thought it's obvious that things should be cut down rather than infinitely extended.

@pde - please clarify above and provide ETA on the PPA.

[fmarier]

For recent versions of Ubuntu, the package in Debian unstable should work fine. Once we have backported the package to Debian jessie, making it work in Ubuntu 14.04 should be easier.

This will of course require packaging a number of dependent libraries as well.

[bmw]

+1 for a PPA to provide a more traditional/standardized way of installing unpackaged software.

[pde]

The update we got last week from Harlan was that various debian maintainers had done a great job of backporting all of our python dependencies, but the outstanding blocker was sphinx-doc for the doc packages, and that it was going to be a non-trivial undertaking. Not sure if PPA's are sigificantly different or easier.

[mgedmin]

Can't the Sphinx doc building be temporarily disabled for PPA packages? As a user, I'm perfectly fine with having to go online to check documentation (in fact I prefer that instead of reading local HTML files in /usr/share/doc/).

[zwetan]

if it's only the sphinx-doc building of the doc then where is the problem ?

• provide 2 packages letsencrypt and letsencrypt-doc
• provide a man letsencrypt.1 for letsencrypt_x.y.deb
• pre-build the doc as HTML
  and package into letsencrypt-doc_x.y.deb

reason:
automatically build the doc is nice but it is optional
removing the sphinx-doc to build the doc does not prevent letsencrypt
to be build, installed and to work which is what everyone want

[paddylandau]

The proposal by @zwetan to separate the debs for the application and the documentation is already well proven by many other applications, from GIMP to LibreOffice. It benefits the developers, who don't have to rebuild the documentation every time there is a security upgrade, and it gives them have the freedom to update the documentation during application quiet-times. I commend the idea.

[jaywink]

There is already letsencrypt in xenial (16.04 upcoming): http://packages.ubuntu.com/xenial/letsencrypt

The docs seem to be optional deps there.

[zwetan]

my point exactly, some servers in prod only rolls with LTS -> security patches -> next LTS
having to wait for 16.04 LTS, when 14.04 LTS could already have the deb package
only because the doc build is problematic? com'on :)

[pde]

Most recent update is that a sphinx backport has unblocked packaging for Debian 8, and a PPA will be on the way shortly afterwards.

[mynameisdaniil]

@zwetan 👍 I can't use letsencrypt since I'm using 14.04 and there is no official repo for 14.04

[bachp]

👍

[ghost]

👍

[ppKrauss]

Hi all, can I use the cited PPA https://launchpad.net/~certbot/+archive/ubuntu/certbot
?

It is secure, reliable, and updated?

[jonathonf]

As for all PPAs, this is your call.

However, @oerdnj is a Debian packager and already does an awful lot of work in other PPAs for Ubuntu (e.g. his incredibly useful PHP PPA).

If you trust him, you can trust his PPAs.

It seems to me that the Git version installs more packages...

The git version sets up a Python virtualenv to build the software and installs all of the associated dependencies locally. A PPA does this behind the scenes so there are fewer end-result packages.

[bmw]

This PPA is ready for use! We'll be updating certbot.eff.org to tell people to use it over certbot-auto or the current Ubuntu packages (see certbot/website#198). We can finally close this issue.

@hlieberman, @oerdnj: can you remove "(semi-official)" from the title of the PPA?

[elyscape]

Any chance of getting the PPA renamed to ppa so that people can run sudo add-apt-repository ppa:certbot instead of sudo add-apt-repository ppa:certbot/certbot? This was mentioned in this comment: #1706 (comment)

[enoch85]

When will the PPA be updated? Version 12 has been out for 13 days.

[chrismccoy]

im pretty sure you need a prefix to a ppa so it knows which user and repo it belongs too, or else it wont know which repo in that username to pick, I may be wrong, someone else can chime in, of all the ppa i use none just have a prefix.

…

Sent from my iPhone

On Mar 15, 2017, at 5:18 PM, Geoffrey Fairchild ***@***.***> wrote: I like @elyscape's suggestion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[oerdnj]

@elyscape That would force all the people that are already using the ppa to change their configurations just for aesthetics, so sorry, no, that's not an option at this stage.

[digitalcircuit]

@chrismccoy , ppa is the assumed repo if you only specify a user for a PPA.

user@ubuntu-device:~$ sudo add-apt-repository ppa:certbot
Cannot add PPA: 'ppa:~certbot/ubuntu/ppa'.
The team named '~certbot' has no PPA named 'ubuntu/ppa'
Please choose from the following available PPAs:
 * 'certbot':  Certbot PPA (semi-official)
 * 'certbot-build':  Certbot Build PPA (don't use this, use ppa:certbot/certbot)

As I was writing this, @oerdnj replied, so the point is now moot anyways :)

[jonathonf]

A PPA named just 'ppa' can be added, as @elyscape says, with a shortened apt-add-repository command, but this is really just bike-shedding at this point. It's the certbot PPA for the certbot project and the extra nine characters is hardly onerous.

In terms of updates, 0.12 has not yet landed in Debian (not even sid or experimental). Once it has, and has been suitably wrangled, it should make its way into the PPA:

This is the PPA for packages prepared by Debian Let's Encrypt Team and backported for Ubuntu(s).

I assume you want a tested, working package to deploy? :)

--edit
Two other updates while typing... meh, I'm posting anyway. :P

[oerdnj]

@enoch85 Is there anything broken for you? #4233 is troubling, but that's it.

I usually follow @hlieberman workflow and he apparently hasn't had time to update Debian packages yet, and I don't want to step on his toes.

I can pull a patch from #4243 on top of 0.11.1 if this gives problems for more people using this PPA, but I don't really follow this "new version just for a sake of new version" worldview.

[oerdnj]

@bmw "(semi-official)" removed. If you have any other suggestions for the title or description, I would be happy to change it.

[enoch85]

@oerdnj No, not yet but maybe soon, as I converted to this PPA from the git version which is 12 and I get warnings about the certs generated with 12. Would be awsome with an update. And as always, you rock!

[chrismccoy]

how long does it usally take to get an update from the launchpad maintainers, i see certbot/certbot on launchpad is at 0.11.1 and 0.12 is out on github.com

[jonathonf]

@chrismccoy Read the comment by the maintainer of the PPA three comments back from yours, i.e. #1706 (comment).

[abackstrom]

@oerdnj I ended up here specifically because of #4233. I'm just one person and this was a simple personal project, but I look forward to the 0.12 release.

[enoch85]

Getting this when trying to install a new cert with Certbot 12 from the PPA in this issue. Don't know if it's a Let's Encrypt bug or something with the PPA. Also reported it here: https://community.letsencrypt.org/t/ubuntu-14-04-with-certbot-auto-failing-tls-sni-challenge-with-apache/33439/2

tls-sni-01 challenge for cloud.domin.com
/usr/lib/python2.7/dist-packages/OpenSSL/rand.py:58: UserWarning: implicit cast from 'char *' to a different pointer type: will be forbidden in the future (check that the types are as you expect; use an explicit ffi.cast() if they are correct)
  result_code = _lib.RAND_bytes(result_buffer, num_bytes)
Waiting for verification...

My certs are generated correctly, but I think someone should look into the python warning message.

[shaneog]

@oerdnj Sorry to bother you, but is there any way I can follow the packaging of the new versions? i.e. when a new package will/could be ready.

I'm waiting for new packages (v0.14.x) so I can auto-renew certs using Cloudflare and DNS auth.

[oerdnj]

@shaneog There's no plan as it's on "free time right now" basis (unless there would be a critical bug). However update to 0.14.1 seems as a simple update, so I am uploading the builds right now.

[shaneog]

Thank you!

[drewcking]

Since the crontab created by installing from the PPA doesn't include the /bin/run-parts bit anymore, what's the recommended way of specifying renew hooks?

For now, I'm just changing my /etc/cron.d/certbot script back to what @oerdnj had in place a few months ago (I'm on Ubuntu 16.04):

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew --pre-hook '/bin/run-parts /etc/letsencrypt/pre-hook.d/' --post-hook '/bin/run-parts /etc/letsencrypt/post-hook.d/' --renew-hook '/bin/run-parts /etc/letsencrypt/renew-hook.d/'

...and putting my hook scripts in those directories. Is there a better way to go about this?

[bmw]

It depends on what you'd like to accomplish. There are two main options, but make sure you read the warnings I placed at the bottom of this post.

Global configuration file

You can get behavior similar to the run-parts solution by including hooks in Certbot's configuration file. Your file at /etc/letsencrypt/cli.ini could look like:

pre-hook = /bin/run-parts /etc/letsencrypt/pre-hook.d/
post-hook = /bin/run-parts /etc/letsencrypt/post-hook.d/
renew-hook = /bin/run-parts /etc/letsencrypt/renew-hook.d/

The only behavioral difference between this and the previous crontab is these hooks sometimes also run when obtaining a certificate with other Certbot subcommands such as certbot certonly, certbot run, certbot (with no subcommand), etc. Pre and post hooks will always run if a certificate is obtained, while renew hook is only run if renewing a certificate at an existing path.

Certificate configuration file

Another option is to define hooks per certificate. This allows you to run different hooks depending on the certificate. When you obtain a certificate, the hooks you used to obtain that certificate are stored in /etc/letsencrypt/renewal/domain.conf. When you run certbot renew, these hooks will automatically be run again when the certificate is renewed. You can also edit these files manually by placing hooks under the [renewalparams] section header using the same syntax as I included above.

Warnings

1. These two options are not compatible. Hooks placed in a global configuration file are treated the same as if they were included on the command line which overrides the values found in the configuration file for the certificate.
2. Whatever method you use, make sure you run certbot renew --dry-run after editing the files to make sure everything still works properly.

[drewcking]

Perfect, the global config file is exactly what I need, thanks!

[jult]

So what's the actual status of renewal hooks? Strange how this has become so messy. First it was a cronjob calling parts in different dirs, then a cli file, and now all I see with a clean install are the dirs, since the cli doesn't hold any info on it anymore.
Could anyone at certbot dev lead please just place clear comments with directions in its config files? How hard can that be? For an example, please check how they've done that for CSF/LFD: https://gist.github.com/skt-bford/4987434

[orrd]

I agree it's super confusing and there is a ton of conflicting or outdated info about this. My understanding is that the current best practice is to use --deploy-hook (which is better than --renew-hook) using the certbot command line, and that causes it to save the hook info to the domain in /etc/letsencrypt/renewal, so the hook will get run each time automatically. I think that's considered to be a preferred solution rather than editing /etc/letsencrypt/cli.ini directly, and it also has the advantage that it lets you have different hooks for different certificates.

This is the best info I've found on it: https://community.letsencrypt.org/t/certbot-dovecot-postfix-certificate-renewal-issue/72226/11

[ppKrauss]

I agree it's super confusing and there is a ton of conflicting or outdated info about this.

yes, confusing (!)... But your link is also confuse and its content not reliable....

Hi all, can some of the experts to clean and summarize? Express a "reliable summary for 2020".

[ppKrauss]

Well, about title of this issue, "PPA for UBUNTU", the summary is there, seems perfect!
https://certbot.eff.org/lets-encrypt/ubuntubionic-nginx

[jmooo]

@oerdnj I was curious what it takes to get an updated certbot + dns plugins in the repo nowadays? Specifically because certbot 1.2 is adding support for limited-scope Cloudflare DNS-01 tokens, which is a big security boost over the old way which required global API keys

https://github.com/certbot/certbot/milestone/81?closed=1

[sbrl]

So what's the actual status of renewal hooks?

I don't think this is the right issue to be discussing that. This closed issue is about an apt repository for installing the certbot tool - which appears to be completely unrelated to your query.

[jult]

So what's the actual status of renewal hooks?

I don't think this is the right issue to be discussing that. This closed issue is about an apt repository for installing the certbot tool - which appears to be completely unrelated to your query.

Well, I was merely continuing on what drewcking asked, since the answer to that actually did not work in my case. Which has to do with the ubuntu LE packages (that aren't up to date)..