Certbot: Crie um PPA oficial para pacotes de permite criptografar o Ubuntu

: +1:

: +1:

:afirmativo:

: +1:

bonito por favor?

Sim por favor!

Sim por favor.

+1

+1

+1

Muito esforço foi gasto em letsencrypt-auto e nenhum aqui. O que está acontecendo? Acho essa situação absolutamente estranha, já que letsencrypt-auto era para ser uma solução temporária até sermos empacotados. @hlieberman e @fmarier investiram muito tempo no debs e agora estamos perdendo tempo em algum script "auto-mágico" caseiro que tenta basicamente substituir todas as soluções de empacotamento (e, apesar de grandes esforços, falha miseravelmente em isto). Tem havido inúmeras reclamações sobre o quão ridiculamente complicado o cliente é e eu pensei que era óbvio que as coisas deveriam ser reduzidas em vez de estender infinitamente.

@pde - esclareça acima e forneça o ETA no PPA.

Para versões recentes do Ubuntu, o pacote no Debian instável deve funcionar bem. Depois de fazer o backport do pacote para o Debian jessie, fazê-lo funcionar no Ubuntu 14.04 deve ser mais fácil.

Obviamente, isso também exigirá o empacotamento de várias bibliotecas dependentes.

+1 para um PPA para fornecer uma maneira mais tradicional / padronizada de instalação de software não empacotado.

A atualização que recebemos na semana passada de Harlan foi que vários mantenedores debian fizeram um ótimo trabalho de backporting todas as nossas dependências python, mas o bloqueador pendente era sphinx-doc para os pacotes de doc, e que seria um empreendimento não trivial. Não tenho certeza se os PPAs são significativamente diferentes ou mais fáceis.

A construção de documentos Sphinx não pode ser temporariamente desativada para pacotes PPA? Como usuário, estou perfeitamente bem em ter que ficar online para verificar a documentação (na verdade, prefiro isso em vez de ler arquivos HTML locais em / usr / share / doc /).

se for apenas a construção sphinx-doc do documento, onde está o problema?

• forneça 2 pacotes letsencrypt e letsencrypt-doc
• fornecer um homem letsencrypt.1 por letsencrypt_x.y.deb
• pré-construir o documento como HTML
  e empacote em letsencrypt-doc_x.y.deb

razão:
construir automaticamente o documento é bom, mas é opcional
remover sphinx-doc para construir o documento não impede letsencrypt
para ser construído, instalado e funcionar que é o que todos desejam

A proposta de @zwetan de separar os debs do aplicativo e da documentação já é bem comprovada por muitos outros aplicativos, do GIMP ao LibreOffice. Isso beneficia os desenvolvedores, que não precisam reconstruir a documentação toda vez que há uma atualização de segurança, e dá a eles a liberdade de atualizar a documentação durante os períodos de silêncio do aplicativo. Recomendo a ideia.

Já existe o letsencrypt em xenial (16.04 em breve): http://packages.ubuntu.com/xenial/letsencrypt

Os documentos parecem ser departamentos opcionais lá.

meu ponto exatamente, alguns servidores em produção só funcionam com LTS -> patches de segurança -> próximo LTS
ter que esperar por 16.04 LTS, quando 14.04 LTS já poderia ter o pacote deb
apenas porque a compilação de doc é problemática? vamos :)

A atualização mais recente é que um backport do sphinx desbloqueou o empacotamento para o Debian 8, e um PPA estará a caminho logo em seguida.

@zwetan : +1: Não posso usar o letsencrypt porque estou usando 14.04 e não há repositório oficial para 14.04

: +1:

: +1:

+1 Eu nunca na minha vida vou executar o letencrypt-auto novamente ....

Criei um PPA para o Ubuntu Wily. Use por sua conta e risco; em grande parte não foi testado no momento.

https://launchpad.net/~letsencrypt/+archive/ubuntu/letsencrypt

@hlieberman esse pacote poderia rodar em 14.0.4 alias TrustyThar ou isso pode ser negado?

apenas um aviso, o PPA não cria os diretórios para as configurações em / etc e / opt

E agora o letsencrypt-auto está falhando com problemas de dependência (urllib3, acme). Este deve ser um processo simples e rápido, devido ao problema que ele resolve. Você não quer gastar horas discutindo com dependências e outros, faz com que pareça frágil.

(PS: PPA não funciona com 14.04)

dos meus últimos testes no Ubuntu 14.04.5 LTS
é mais simples ignorar o PPA

apenas faça uma instalação "manual"

git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
/opt/letsencrypt/letsencrypt-auto --help

(a segunda linha é para forçar a instalação das dependências)
isso funcionou bem para mim em uma dúzia de servidores

Uma sugestão adicional: se você não se sentir confortável com o número relativamente grande de dependências, basta criar uma pequena instância lxc (aproximadamente 350 MB de tamanho no momento) e seguir a instalação manual mencionada acima:
lxc-create -n letsencrypt -t ubuntu

Para usar os certificados no host e permitir os testes automatizados, basta adicionar duas montagens de ligação à sua configuração da seguinte forma (a ideia é que um servidor web externo - seja no host ou morando em outro contêiner - levará cuidar disso):
lxc.mount.entry = /var/www/letsencrypt var/www/letsencrypt none bind 0 0
lxc.mount.entry = /etc/letsencrypt etc/letsencrypt none bind 0 0

(Claro, você precisa acionar renovações sincronizadas / reinicializações de serviço do servidor da web de fora do contêiner _letsencrypt_, mas é muito conveniente ...)

pessoalmente não me importo com as dependências

o que eu realmente preciso é de automação para poder adicionar um script de provisionamento
para saber se desejo adicionar suporte para Let's Encrypt em um servidor
vai funcionar, foi testado e demorará cerca de 10 minutos para configurar

Um grande número de dependências é um problema para mim, pois tenho recursos limitados.

Se houver interesse em contêineres, posso criar um contêiner Docker que faria o trabalho muito rapidamente. Parece haver algum trabalho nesse sentido no hub do Docker, mas parece abandonado / antigo.

Isso significaria que seria tão simples quanto docker run -v/etc/letsencrypt:/etc/letsencrypt -p80:80 -p443:443 letsencrypt <FQDN> gerar certificados.

EDIT: Aqui estão vocês. https://hub.docker.com/r/samyaple/certbot/
Vai puxar cerca de 250 MB para baixo, incluindo a imagem de base. Estou trabalhando para reduzir essa pegada agora. Esta foi apenas uma implementação grosseira em alguns minutos. As compilações são automatizadas para que você possa ver exatamente o que está sendo construído, sem graça.

Estou mais do que feliz em apoiar isso sob o banner letsencrypt, se isso for desejado.

: +1:

Para os interessados, tenho uma pequena função Ansible ligada para automatizar a instalação de certificados para meus sites Ubuntu. É muito limitado no momento, apenas para a funcionalidade de que preciso, RP é bem-vindo se alguém quiser usá-lo também.

A função usa o cliente oficial do git e faz a instalação / renovação do certificado no modo certonly .

https://galaxy.ansible.com/jaywink/letsencrypt/

A reatribuição de Harlan após o movimento de recompra o removeu. Isso ainda é importante, mas agora terá uma prioridade menor do que renomear letsencrypt -> certbot nos locais onde já estamos empacotados.

👍

+1

+1

+1

+1

Seria bom ter o PPA atualizado com a versão mais recente. Ele está ficando para trás - parece que ainda está na 0.4.1: https://launchpad.net/ubuntu/xenial/+package/letsencrypt

@larssn Isso não é um PPA - esse é o pacote nos repositórios do Ubuntu. Duas considerações: Primeiro, há um processo SRU [1] a ser seguido para obter atualizações de pacote em um lançamento do Ubuntu. Em segundo lugar, o pacote está em 'universe', portanto não é oficialmente suportado pelo Ubuntu / Canonical.

[1] https://wiki.ubuntu.com/StableReleaseUpdates

(editar: adicionar URL)

Entendi.

Em todo o caso; ainda desejando uma atualização. :)

Pessoal, este não é um repositório "oficial", mas eu tenho alguma credibilidade como desenvolvedor Debian e membro do Ubuntu (e meu PPA de PHP é usado por milhares), então criei o PPA para certbot 0.8.x. Ele foi construído a partir do Xenial apenas no momento, mas posso olhar para o backporting mais da pilha para o Trusty se encontrar algum tempo.

O PPA está aqui: https://launchpad.net/~ondrej/+archive/ubuntu/letsencrypt

acabei de testar no ubuntu 16.04 funciona muito bem, já usando seu material para php, apache e mysql

@oerdnj Você acabou de salvar meu dia mais uma vez. Muito obrigado pelo seu trabalho!

@oerdnj , você acha que seu PPA é confiável o suficiente para que devamos considerar apontá-lo em nosso gerador de instruções?

wrt Trusty: Eu acredito que Harlan ficou com um pouco de medo do conjunto de dependências que precisava ser construído para que Trusty tivesse um PPA confiável em funcionamento. Mas @jonathonf parece ter feito algum progresso nessa frente, então pode ser um problema tratável.

@pde É estável o quanto pode. Eu fico ocupado de vez em quando e alguém pode me enviar um ping ou resolver um problema no meu rastreador gh aqui: https://github.com/oerdnj/deb.sury.org/issues

Mas eu tendo a liberar e consertar coisas críticas em poucas horas-dias e coisas menos críticas em semanas.

Estarei participando de algumas conferências durante o mês de outubro e geralmente preencho o tempo ocioso com embalagens, para poder terminar a embalagem do Trusty. Claro, se eu já houver trabalho nessa frente, ficaria feliz em receber dicas / patches / ajuda.

Como alternativa, ficaria feliz em criar um grupo de empacotamento "oficial" no launchpad e convidar mais pessoas e adicionar alguém do LE como administrador.

A equipe de empacotamento do Debian fez um ótimo trabalho, portanto, para o Xenial, era basicamente apenas backporting / reembalagem do pacote existente. Para Trusty, pode exigir mais algumas modificações, mas ainda não olhei para isso.

Para registro, estou usando o PPA de @jonathonf no trusty e tudo funciona bem, só precisava de alguns pacotes python- * atualizados.

@pde Existe https://launchpad.net/~letsencrypt e parece abandonado. Talvez LE pudesse pedir à Canonical para conceder a alguém do LE acesso de administrador a esta equipe do launchpad e então me adicionar e @jonathonf , e nós criaremos um repositório oficial para certbot sob este namespace? Parece ser a melhor abordagem para combinar esforços.

@oerdnj Um repositório certbot em letsencrypt seria bom. Pessoalmente, sempre procuro por um pacote letsencrypt e ficaria confuso se não conseguisse encontrar ti procurando por letsencrypt.

Eu concedi a @oerdnj a propriedade da organização ~ letsencrypt.

Se alguém de Letsencrypt quiser ser adicionado à organização e tornado proprietário, envie um ping.

Agora copiei meus certbot pacotes para ppa:letsencrypt/letsencrypt ? Vou dar uma olhada no repositório @jonathonf trusty para verificar quais pacotes precisam ser transportados para o Ubuntu Trusty.

@floe Este https://launchpad.net/~jonathonf/+archive/ubuntu/letsencrypt é o repositório Trusty correto que você está usando?

Sim, é o certo. Do meu sources.list :

deb http://ppa.launchpad.net/jonathonf/letsencrypt/ubuntu trusty main

Se quisermos fazer uma Certbot PPA oficial, eu acho que devemos configurá-lo sob https://launchpad.net/~certbot em vez de ~ letsencrypt devido à Certbot não ser mais do projeto de um Let Criptografar ( source1 , source2 ). ~ certbot é propriedade de @hlieberman, que é o mantenedor do pacote Debian.

ppa:letsencrypt/certbot seria uma combinação melhor? Estou bem com ou mudando para @hlieberman ~ certbot. Estou até bem em não fazer nenhum trabalho se não for necessário. Vamos apenas concordar em algo e seguir em frente, então há um repositório oficial.

Eu concordo que ter um Certbot PPA oficial seria um grande benefício para os usuários. Como exatamente queremos fazer isso é algo que os desenvolvedores de certbot centrais devem falar. Temos uma reunião toda quarta-feira. Vou trazer isso à tona então e retorno para vocês após a reunião.

@bmw @oerdnj @ArchimedesPi Acho que a coisa correta a fazer é provavelmente desacelerar ppa:letsencrypt , de preferência fazendo com que o launchpad o redirecione para certbot , mas por outros meios, se necessário?

@oerdnj Prazer em vê-lo aqui novamente :) Na verdade, acabei de tropeçar neste tópico durante o backporting para trusty. Eu já fiz backport dos pacotes Debian para o xenial em julho, mas apenas aqueles dois pacotes que rodamos agora em produção (https://launchpad.net/~trio-interactive/+archive/ubuntu/stable/+sourcepub/6825687/+listing-archive -extra & https://launchpad.net/~trio-interactive/+archive/ubuntu/stable/+sourcepub/6825689/+listing-archive-extra).

@oerdnj @pde @bmw Além do problema de nomenclatura do PPA, quem já fez um backport limpo do Debian para o confiável? E onde é o melhor lugar para sincronizar nossos esforços nisso, já que nossos aplicativos PHP5 realmente querem o LE também? ;)

O Debian tem seus pacotes 0.8.1 backported para jessie-backports, então há um backport muito limpo de lá para o xenial. Reduzir as dependências nos pacotes Debian para pyopenssl e python-cryptography significará que python-acme e python-certbot farão backport sem nada mais necessário. Se você estiver fazendo isso, no entanto, você pode muito bem apenas transportar o pacote yakkety.

O Trusty ainda precisa de um patch para o pacote python-acme - todo o resto é compatível (principalmente) com as versões jessie-backport. Ainda existe um grande número de pacotes atualizados de bibliotecas de dependências que podem ter sabe-se lá quais efeitos indiretos.

@ -todos usando ppa: jonathonf / letsencrypt : isso vai desaparecer em breve em favor do backport mais limpo em ppa: jonathonf / certbot baseado nos pacotes Debian jessie-backport. Eu também posso estar re-jigging aquele PPA mais novo ligeiramente para limpar o backport xenial como acima.

Edit: meu certbot PPA traz algumas bibliotecas Python extras de Jessie - isso torna o backporting direto de Sid muito mais fácil ao custo de desviar da pilha Trusty Python. Esta não é uma grande preocupação se as bibliotecas estiverem em universe qualquer maneira.

@jonathonf Bom saber :) Você pode dar mais dicas sobre o patch para "python-acme" no trusty? Para efeitos colaterais, terei uma fase de estabilização enquanto o coloco em produção e, claro, sempre precisamos quebrar os servidores de desenvolvimento;) Como posso ajudá-lo com os pacotes confiáveis ​​ou quem está trabalhando nisso?

@jonathonf Ao testar seus pacotes confiáveis ​​de ppa: jonathonf / certbot eu obtenho:
pkg_resources.DistributionNotFound: The 'python2-pythondialog>=3.2.2rc1' distribution was not found and is required by certbot
Mas com um backport rápido sem mudança de fonte para que a dependência o cliente funcionasse agora: https://launchpad.net/~trio-interactive/+archive/ubuntu/unstable/+sourcepub/7045266/+listing-archive-extra

@todos : Para um backport limpo, as dependências do Python são um grande incômodo, pois precisamos atualizar vários pacotes do Python que vêm com o lançamento da distro. Isso pode quebrar outras ferramentas Python com as mesmas dependências e também tornar a carga de manutenção um pesadelo de segurança, já que o PPA precisaria enviar todas as atualizações de segurança para todas as dependências portadas. Este é um problema não trivial para o envio de pacotes confiáveis! Mesmo se você construir o canal de backporting de xenial ou jessie, sempre precisaríamos estar em sincronia com as equipes de segurança ... enquanto mexemos com a pilha Python na versão;) O que você acha?

Hrm. Você poderia visitar as versões necessárias das dependências localmente dentro do pacote certbot?

@ bhat3 : se você procurar no debian.tar.gz por python-acme você encontrará o patch de colcha. Tenho certeza que entendi no início deste tópico, mas não vi depois de uma rápida verificação agora.

@jonathonf Tento dar uma olhada na embalagem hoje, mas não posso prometer tempo ainda. Ao lado do seu patch, o que você veria como dependências mínimas para o trusty, então não precisamos tanto da bagunça com a pilha Python do trusty?
@oerdnj Sabendo que está totalmente sincronizado com o pessoal de segurança, você tem interesse em fornecer pacotes confiáveis ​​por meio do PPA?

Depende de quanta embalagem você deseja fazer. As dependências em meu letsencrypt PPA original são as mínimas que eu poderia obter, mas tornam os backports do Debian mais difíceis. As dependências backported em meu certbot PPA são mais numerosas / abrangentes, mas tornam as backports diretas muito mais fáceis.

Se as bibliotecas Python estão em universe , não precisamos nos preocupar tanto - nada na pilha central do Ubuntu depende de nada em universe (e os pacotes em universe não são atualizado de qualquer maneira, mesmo por questões de segurança).

@jonathonf Bom pensamento sobre o caso do "universo" no Ubuntu;) Na verdade, eu não pude continuar meus esforços ontem e nenhuma chance para esta semana :( Mas espero fazê-lo na segunda ou após 7 de novembro. Até então :)

Passamos quase um ano desde que esse problema foi criado pela primeira vez e ainda não concordamos com nada?

Podemos conseguir algum impulso aqui? De um jeito ou de outro.

Https://launchpad.net/~jonathonf/+archive/ubuntu/certbot é tão oficial quanto vamos considerar?

@jonathonf e tudo - me juntei a @hlieberman em ppa: certbot / certbot e acho que tenho a maioria dos deps de compilação para trusty, xenial e yakkety. A única coisa que falta é a esfinge recente e espero que haja alguma solução alternativa para isso.

@oerdnj Está pronto para uso?
Recebo um "Erro: a impressão digital da chave de assinatura não existe" ao tentar adicioná-la.

Desculpe, ainda não, mas será concluído em ~ semana. Estou saindo para a IETF amanhã e terei algum tempo livre lá para terminar.

Se for apenas como um builddep, tenho um PPA de backport Sphinx que pode ser adicionado
como uma dependência do PPA. Você poderia usar isso, copiar os pacotes para um "suporte"
PPA ou backport do mesmo conjunto de pacotes.

J

Em 9 de novembro de 2016, 12:39, "Ondřej Surý" [email protected] escreveu:

@jonathonf https://github.com/jonathonf e todos - eu me juntei a
@hlieberman https://github.com/hlieberman em ppa: certbot / certbot e I
acho que tenho a maioria dos deps de compilação para trusty, xenial e yakkety. o
a única coisa que falta é a esfinge recente e espero que haja alguma
solução alternativa para isso.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/certbot/certbot/issues/1706#issuecomment -259405442,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAiJCY1dmSHhspzOgNcT8tQu4XigyNJdks5q8b7ygaJpZM4Guho5
.

@oerdnj @jonathonf @hlieberman
Obrigado pelo seu trabalho nisso.

Acho que todos podemos esperar mais uma semana.

@oerdnj @jonathonf Há algo que eu possa ajudá-lo nos backports confiáveis ​​dentro do meu horário de trabalho?

@ bhat3 Seria incrível se você pudesse fazer um teste extensivo do que agora está em ppa:certbot/certbot . Tive que apertar algumas (Build-) Depends antes que parasse de lançar erros de tempo de execução, mas tudo parece bem agora.

JFTR, o ppa: certbot / certbot agora contém pacotes que podem ser usados ​​com algum cuidado. Por favor, relate quaisquer quebras aqui por enquanto.

@oerdnj Okay fará isso e substituirá minha própria embalagem em nossos servidores de desenvolvimento por ppa:certbot/certbot . Mas, além das ferramentas padrão do Debian / Ubuntu, não usamos Python, mas sim o seu PHP, então não poderei enfatizar essas quebras;)

No Ubuntu-16.04-xeinal, fiquei preso no 0.4.1, que não conseguia renovar com o seguinte erro:

AVISO: letsencrypt.cli : A tentativa de renovar o certificado de /etc/letsencrypt/renewal/gableroux.com.conf produziu um erro inesperado: 'servidor'. Pulando.

Após a atualização, as renovações estão funcionando novamente, obrigado! : D

python -mplatform

Linux-3.11.0-12-generic-x86_64-with-Ubuntu-16.04-xenial

letsencrypt --version

letsencrypt 0.4.1

sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install --upgrade letsencrypt
letsencrypt --version

letsencrypt 0.9.3

letsencrypt renew --agree-tos 

Parabéns, todas as renovações foram bem-sucedidas.

:coração:

@oerdnj Até agora parece bom no servidor de desenvolvimento que usei os pacotes confiáveis ​​de @jonathonf mais um backport próprio:

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  certbot letsencrypt python-acme python-certbot python-cffi-backend
  python-configargparse python-cryptography python-dialog python-dnspython
  python-idna python-ipaddress python-ndg-httpsclient python-openssl
  python-parsedatetime python-pkg-resources python-pyasn1 python-requests
  python-rfc3339 python-setuptools python-six python-urllib3
21 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,410 kB of archives.
After this operation, 398 kB of additional disk space will be used.
Do you want to continue? [Y/n]

Renovei com sucesso um certificado LE pré-criado com 99 subdomínios e funciona bem. Mais testes virão amanhã ...

Como disse, estou um pouco cético com o backporting completo das dependências, visto que o LE já estava trabalhando no mesmo sistema sem atualizar toda a cadeia de dependências;) Caso contrário, estou feliz por finalmente "mainline" nossos sistemas :)

BTW, se você renomear o certbot / certbot PPA para o nome padrão (certbot / ppa), os usuários podem usar a versão abreviada do nome, ou seja:

sudo add-apt-repository ppa:certbot

@oerdnj O próximo teste do trusty foi uma renovação automatizada via cron e shell, mas na verdade eu encontrei alguns problemas que não encontrei antes:

/usr/bin/letsencrypt certonly --force-renewal --webroot -w /var/www/letsencrypt -d DOMAIN.TLD
An unexpected error occurred:
Bug in pythondialog: expected an empty output from u'infobox', but got: u'Error opening terminal: unknown.\n'Please see the logfile 'certbot.log' for more details.

Embora eu registre todas as saídas desse script de renovação e receba uma notificação por e-mail, não encontro o certbot.log e não consigo depurá-lo. Você tem alguma dica sobre isso?

@ bhat3 você deve usar --noninteractive ou --quiet (o que implica --noninteractive ) se estiver invocando o certbot a partir de um cron script.

(Eu procuraria certbot.log em / var / log /, talvez em / var / log / letsencrypt /? TBH Só tenho letsencrypt.log lá; certbot.log parece algo novo.)

o certbot não renova tenta renovar tudo? eu corro isso e ele faz isso

@ bhat3 é um cronjob padrão fornecido pelo pacote?

@oerdnj Não, esse é o seu próprio e a opção --noninteractive não era necessária antes com o pacote de @jonathonf . A razão para este cronjob é que precisamos reiniciar o Nginx se a renovação for bem-sucedida e essas coisas precisarem acontecer em um período de tempo fixo. O último requisito pode ser feito em /etc/cron.d/certbot, mas não tenho certeza sobre a interação com nginx -t && systemctl restart nginx .

@chrismccoy E como você reinicia seu servidor web após a renovação?

@mgedmin Thx, funcionou com o switch. Mas ainda estou curioso se o certbot.log é apenas um problema de marca e /var/log/letsencrypt/letsencrypt.log se refere a isso, que parecia não ter sido criado sem a opção.

/usr/bin/letsencrypt certonly --noninteractive --force-renewal --webroot -w /var/www/letsencrypt -d DOMAIN.TLD
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Olhe para o novo trabalho de colheita, ele tem diretório de ganchos

@oerdnj Você quer dizer que só posso fazer um gancho após renovações bem-sucedidas para cuidar do Nginx?

A chamada certbot renew agora inclui: /usr/bin/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/'

E acabei de enviar a @hlieberman o patch para o bug do Debian # 838548

# cat /etc/letsencrypt/post-renewal.d/nginx 
#!/bin/sh
set -e
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
nginx -t -q && nginx -s reload
exit 0

@oerdnj , pedimos a @hlieberman especificamente para não adicionar diretórios como esse no Debian em favor de desenvolvermos uma solução upstream da qual todas as distros poderiam se beneficiar. O que você acha de remover esses diretórios e esperar por uma solução nossa?

A versão empacotada do certbot no PPA tem o plug-in de configuração do apache? Percebi que ele não tem um pacote equivalente a python-letsencrypt-apache como o Universe.

Eu tenho Certbot / Letsencrypt trabalhando com a versão do Universe, mas quando eu atualizo usando o PPA, recebo erros em torno do plugin do apache. por exemplo

$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/XXXXXX.conf
-------------------------------------------------------------------------------
Renewal configuration file /etc/letsencrypt/renewal/XXXXXX.conf produced an unexpected error: 'Namespace' object has no attribute 'apache_enmod'. Skipping.
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

No renewals were attempted.

Additionally, the following renewal configuration files were invalid: 
  /etc/letsencrypt/renewal/XXXXXXXXX.conf (parsefail)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
0 renew failure(s), 1 parse failure(s)

e

$ sudo certbot --apache
The requested apache plugin does not appear to be installed

Eu tentei deletar o arquivo de configuração (renomeado / etc / letscrypt) mas nenhuma melhoria. Felizmente, é simples fazer o downgrade para 0.4.1.

@bmw Para ser honesto, eu realmente

Existem soluções tão horríveis em aberto com relação à renovação e a interação necessária com o serviço usando os certificados, que eu realmente defendo que

@bmw eu discordo de todo o coração. A extensão do Debian está entrando em um período de congelamento e se você não quiser que todos elaborem seus próprios scripts nos próximos 2 anos ou mais, as integrações do Debian são a melhor coisa que você pode obter agora, pois está sob controle e quando ( e se) você fornecer um equivalente oficial do run-parts, seria bastante fácil migrar.

Talvez eu esteja neste campo há muito tempo, mas esperar por uma solução perfeita geralmente é o único caminho para um desastre, porque as pessoas vão começar a ser criativas.

Eu realmente apreciaria se @hlieberman integrasse a solução run-parts no pacote principal do Debian, já que oferece uma solução funcional para a extensão do Debian agora e se integra bem de uma maneira como o Debian funciona.

Olá @oerdnj , dois pontos:

1. Como controlamos o upstream e temos um pipeline muito bom de nossos lançamentos em unstable e testing , sentimos que é hora de colocar um patch no Certbot upstream que funcione tanto para o Debian quanto para a maioria / todas as outras distros , e colocá-lo no Debian. Isso pode acontecer facilmente antes do congelamento de fevereiro, se você quiser; envie-nos um PR ou incentive @hlieberman a fazê-lo :)
2. Temos conversado muito sobre como lidar com o congelamento do alongamento. Não achamos que o Certbot seja maduro o suficiente para ser fixado em uma determinada versão pelos mais de 5 anos que as pessoas parecem tentar impor para versões estáveis ​​do Debian. Ainda estamos tentando decidir o que fazer a respeito. No Ubuntu, estamos passando pelo processo SRU para obter versões mais novas do Certbot no Xenial LTS, mas não estamos tão otimistas que o Debian vai levá-los para longe. Nosso plano atual é pedir à lista debian-devel para escolher entre (1) se comprometer a aceitar uma versão bem testada do Certbot para atualizações do Stretch a cada 6 meses; (2) pedir ao Debian para não lançar o Certbot em versões estáveis ​​e, em vez disso, confiar em dar aos nossos usuários instruções de backport, que é o que estamos fazendo com Jessie agora, e sentimos que é bastante sensato.
3. Se desejar, você pode participar de nossas ligações semanais para o desenvolvedor do Certbot para conversar conosco sobre esses problemas! Acho que Brad lhe enviou um convite, mas se não, lmk e vamos consertar isso.

@pde ok, faz sentido. Vou tentar reservar algum tempo livre para preparar algo semelhante a run-parts , mas em código python nativo.

Sim, recebi o convite (vou verificar com você no Freenode para saber a hora exata). Eu simplesmente não posso prometer nada além deste problema em particular, já que há apenas uma quantidade finita de tempo no dia / semana / mês / ano :)

Editado: Talvez seja a experiência IETF dentro de mim, mas na verdade eu prefiro um código em execução a falar :). Se eu apenas tiver mais tempo para produzir mais código em execução.

Seria bom se o plugin apache pudesse ser adicionado também :)

Olá, só queria saber quando poderemos ver um PPA? Estou prestes a instalar o certbot-auto em curto prazo para nos ajudar em nossa primeira renovação, desde que começamos o Lets Encrypt. Parabéns e obrigado pelo trabalho que vocês estão fazendo para resolver isso.

@jesseiqmi Você já pode dar uma carona:

sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install --upgrade letsencrypt
letsencrypt --version

Eu também o uso na produção, mas ainda sem integração de renovação adequada, mas minha produção testou o script caseiro. Mas eu sugeriria pelo menos que você sempre teste novas versões nos sistemas de desenvolvimento e teste antes de tocar na produção. Você pode se manter enxuto com o KISS apenas usando apt-mark hold PKGNAME , desabilitar o PPA na produção até que o próximo teste seja aprovado no teste ou usar os próprios PPAs para encaminhar os pacotes entre seus sistemas na cadeia de QA.

O PPA não parece incluir nenhum dos plug-ins, como certbot-apache. Qual é o procedimento correto para instalá-los?

@oerdnj alguma atualização ou algo em que você gostaria de ajuda?

@pde Se você tem alguma ideia de como consertar a documentação com sphinx-build 1.2.2, isso pode ajudar: https://launchpadlibrarian.net/301768953/buildlog_ubuntu-trusty-i386.python-certbot-nginx_0.9.3-1+certbot ~ trusty + 2_BUILDING.txt.gz

Isso parece ser um bug de código em certbot_nginx/nginxparser.py , nada a ver com o Sphinx (exceto que o Sphinx tenta importar o módulo para fins autodoc, o que falha por causa do bug).

O AFAICS pyparsing deseja que você use ... + restOfLine vez de ... + restOfLine() .

@mgedmin Obrigado, tentarei corrigir isso no pacote e enviado como https://github.com/certbot/certbot/pull/3989

Ok, então o PPA agora contém os plug-ins apache e nginx. Obrigado pela cutucada.

Obrigado por todo o seu trabalho aqui @oerdnj! Você acha que o PPA está em um ponto em que podemos começar a sugeri-lo para o usuário médio do Certbot?

@bmw eu acredito que sim. Bem, além do problema de que ainda tenho o hack rundirs no repositório, não quero desistir - mas ficaria feliz em preparar um caminho de migração estável assim que o recurso chegar ao certbot upstream.

@oerdnj Sim! Adoraria finalmente consolidar o "hack" de rundirs sem a necessidade de bifurcar o PPA mais tarde: +1:
@bmw Eu posso entender sua necessidade de abordagem Python upstream, mas aqui se trata de pacotes Debian, certo ?! ;)

Desculpe por postar minha pergunta aqui, pois há tantos assinantes para este problema, mas não consegui encontrar uma boa resposta em nenhum outro lugar, então aqui vai:

Ubuntu 16.04.2
Instalando pacotes com apt install letsencrypt :
letsencrypt --version me dá 0.4.1, mas ao instalar de git recebo 0.12.0 - então, quando o Ubuntu atualizará o pacote ou o 0.4.1 é apenas a versão do Ubuntu para 0.12.0 ?

O Ubuntu nunca atualiza pacotes em versões lançadas (exceto quando eles precisam consertar bugs sérios - veja a política de atualizações de lançamento estável ).

O Ubuntu atualizará o pacote para 16.04 conforme e quando ele passar pelo processo SRU. O pacote Ubuntu não está vinculado ao repositório git.

É melhor usar o PPA, então um apt-get install letsencrypt instalará a versão empacotada mais recente.

A menos que você queira a versão mais recente do git, nesse caso faça o que você fez.

@jonathonf Instalei o PPA nessa edição, mas sem diferença. : /

Eu não acho que você fez. ;)

Experimente este: https://launchpad.net/~certbot/+archive/ubuntu/certbot

@jonathonf Incrível! Perdi isso.

Então, isso será mantido? Percebi que é "semi-oficial". Além disso, isso instalará todas as dependências necessárias? Parece-me que a versão Git instala mais pacotes ...

Olá a todos, posso usar o PPA citado https://launchpad.net/~certbot/+archive/ubuntu/certbot
?

É seguro, confiável e atualizado?

Como para todos os PPAs, a decisão é sua.

No entanto, @oerdnj é um empacotador Debian e já faz um trabalho terrível em outros PPAs para Ubuntu (por exemplo, seu PPA PHP incrivelmente útil).

Se você confia nele, você pode confiar em seus PPAs.

Parece-me que a versão Git instala mais pacotes ...

A versão git configura um virtualenv Python para construir o software e instala todas as dependências associadas localmente. Um PPA faz isso nos bastidores para que haja menos pacotes de resultados finais.

Este PPA está pronto para uso! Estaremos atualizando certbot.eff.org para dizer às pessoas para usá-lo sobre certbot-auto ou os pacotes atuais do Ubuntu (veja certbot / website # 198). Podemos finalmente encerrar este problema.

@hlieberman , @oerdnj : você pode remover "(semi-oficial)" do título do PPA?

Alguma chance de renomear o PPA para ppa para que as pessoas possam executar sudo add-apt-repository ppa:certbot vez de sudo add-apt-repository ppa:certbot/certbot ? Isso foi mencionado neste comentário: https://github.com/certbot/certbot/issues/1706#issuecomment -260585028

Quando o PPA será atualizado? A versão 12 foi lançada há 13 dias.

Tenho certeza de que você precisa de um prefixo para um ppa para que ele saiba a qual usuário e repo ele pertence também, ou então não saberá qual repo naquele nome de usuário escolher, posso estar errado, outra pessoa pode intervir, de todos os ppa i use none apenas com um prefixo.

Enviado do meu iPhone

Em 15 de março de 2017, às 17:18, Geoffrey Fairchild [email protected] escreveu:

Eu gosto da sugestão de @elyscape .

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

@elyscape Isso forçaria todas as pessoas que já estão usando o ppa a mudar suas configurações apenas por

@chrismccoy , ppa é o repo assumido se você especificar um usuário para um 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)

Enquanto eu escrevia isso, @oerdnj respondeu, então o ponto agora é discutível de qualquer maneira :)

Um PPA chamado apenas 'ppa' pode ser adicionado, como @elyscape diz, com um comando apt-add-repository encurtado, mas isso é realmente apenas um corte de bicicletas neste ponto. É o certbot PPA para o projeto certbot e os nove caracteres extras dificilmente são onerosos.

Em termos de atualizações, 0.12 ainda não chegou ao Debian (nem mesmo sid ou experimental). Uma vez que tenha sido devidamente discutido, ele deve entrar no PPA:

Este é o PPA para pacotes preparados pela equipe Debian Let's Encrypt e backport para Ubuntu (s).

Presumo que você queira um pacote testado e funcional para implantar? :)

--editar
Duas outras atualizações enquanto digito ... meh, estou postando de qualquer maneira. : P

@ enoch85 Há algo quebrado para você? # 4233 é preocupante, mas é só isso.

Eu geralmente sigo o fluxo de trabalho de @hlieberman e ele aparentemente não teve tempo de atualizar os pacotes Debian ainda, e eu não quero pisar nele.

Posso puxar um patch de # 4243 em cima de 0.11.1 se isso causar problemas para mais pessoas usando este PPA, mas eu realmente não sigo esta visão de mundo "nova versão apenas por uma questão de nova versão".

@bmw "(semi-oficial)" removido. Se você tiver alguma outra sugestão para o título ou a descrição, ficarei feliz em alterá-lo.

@oerdnj Não, ainda não, mas talvez em breve, pois converti para este PPA da versão git que é 12 e recebo avisos sobre os certs gerados com 12. Seria incrível com uma atualização. E como sempre, você é demais!

quanto tempo normalmente leva para obter uma atualização dos mantenedores do launchpad, vejo que certbot / certbot no launchpad está em 0.11.1 e 0.12 está disponível em github.com

@chrismccoy Leia o comentário do mantenedor do PPA três comentários de volta do seu, ou seja, https://github.com/certbot/certbot/issues/1706#issuecomment -286890691.

@oerdnj Acabei aqui especificamente por causa do # 4233. Eu sou apenas uma pessoa e este foi um projeto pessoal simples, mas estou ansioso para o lançamento do 0.12.

Conseguir isso ao tentar instalar um novo certificado com Certbot 12 do PPA nesta edição. Não sei se é um bug do Let's Encrypt ou algo com o PPA. Também relatou aqui: 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...

Meus certificados são gerados corretamente, mas acho que alguém deveria olhar a mensagem de aviso do python.

@oerdnj Desculpe incomodá-lo, mas há alguma maneira de acompanhar a embalagem das novas versões? ou seja, quando um novo pacote estará / poderá estar pronto.

Estou esperando por novos pacotes (v0.14.x) para que eu possa renovar certificados automaticamente usando Cloudflare e autenticação de DNS.

@shaneog Não há nenhum plano, pois é em "tempo livre agora" (a menos que haja um bug crítico). No entanto, a atualização para 0.14.1 parece uma atualização simples, então estou enviando as compilações agora.

Obrigado!

Como o crontab criado pela instalação do PPA não inclui mais o bit / bin / run-parts, qual é a maneira recomendada de especificar ganchos novos?

Por enquanto, estou apenas mudando meu script /etc/cron.d/certbot de volta para o que

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/'

... e colocar meus scripts de gancho nesses diretórios. Existe uma maneira melhor de fazer isso?

Depende do que você gostaria de realizar. Existem duas opções principais, mas certifique-se de ler os avisos que coloquei no final deste post .

Arquivo de configuração global

Você pode obter um comportamento semelhante à solução run-parts incluindo ganchos no arquivo de configuração do Certbot . Seu arquivo em /etc/letsencrypt/cli.ini pode ter a seguinte aparência:

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/

A única diferença comportamental entre este e o crontab anterior é que esses ganchos às vezes também são executados ao obter um certificado com outros subcomandos do Certbot, como certbot certonly , certbot run , certbot (sem subcomando ), etc. Os ganchos pré e pós sempre serão executados se um certificado for obtido, enquanto o gancho de renovação só será executado se um certificado for renovado em um caminho existente.

Arquivo de configuração de certificado

Outra opção é definir ganchos por certificado. Isso permite que você execute ganchos diferentes, dependendo do certificado. Quando você obtém um certificado, os ganchos usados ​​para obter esse certificado são armazenados em /etc/letsencrypt/renewal/domain.conf . Quando você executa certbot renew , esses ganchos serão executados automaticamente novamente quando o certificado for renovado. Você também pode editar esses arquivos manualmente colocando ganchos sob o cabeçalho da seção [renewalparams] usando a mesma sintaxe que incluí acima.

Avisos

1. Essas duas opções não são compatíveis. Ganchos colocados em um arquivo de configuração global são tratados da mesma forma como se estivessem incluídos na linha de comando, que substitui os valores encontrados no arquivo de configuração para o certificado.
2. Qualquer que seja o método usado, certifique-se de executar certbot renew --dry-run após editar os arquivos para garantir que tudo ainda funcione corretamente.

Perfeito, o arquivo de configuração global é exatamente o que eu preciso, obrigado!

Então, qual é o status real dos ganchos de renovação? Estranho como isso se tornou tão confuso. Primeiro foi um cronjob chamando partes em diretórios diferentes, depois um arquivo cli, e agora tudo o que vejo com uma instalação limpa são os diretórios, já que o cli não contém mais nenhuma informação sobre ele.
Alguém no certbot dev lead poderia colocar comentários claros com instruções em seus arquivos de configuração? Quão difícil pode ser? Por exemplo, verifique como eles fizeram isso para CSF / LFD: https://gist.github.com/skt-bford/4987434

Eu concordo que é super confuso e há uma tonelada de informações conflitantes ou desatualizadas sobre isso. Meu entendimento é que a prática recomendada atual é usar --deploy-hook (que é melhor do que --renew-hook ) usando a linha de comando do certbot, e isso faz com que ele salve as informações do gancho no domínio em / etc / letsencrypt / renewal, então o gancho será executado a cada vez automaticamente. Acho que é considerada uma solução preferida em vez de editar /etc/letsencrypt/cli.ini diretamente, e também tem a vantagem de permitir que você tenha diferentes ganchos para diferentes certificados.

Esta é a melhor informação que encontrei sobre ele: https://community.letsencrypt.org/t/certbot-dovecot-postfix-certificate-renewal-issue/72226/11

Eu concordo que é super confuso e há uma tonelada de informações conflitantes ou desatualizadas sobre isso.

sim, confuso (!) ... Mas o seu link também é confuso e seu conteúdo não é confiável ....

Olá a todos, alguns dos especialistas podem limpar e resumir? Expresse um "resumo confiável para 2020" .

Bom, sobre o título dessa edição, "PPA para UBUNTU", o resumo está aí, parece perfeito!
https://certbot.eff.org/lets-encrypt/ubuntubionic-nginx

@oerdnj Eu estava curioso para

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

Então, qual é o status real dos ganchos de renovação?

Não acho que essa seja a questão certa para discutir isso. Este _closed_ problema é sobre um repositório apt para instalar a ferramenta certbot - que parece não estar completamente relacionado à sua consulta.

Então, qual é o status real dos ganchos de renovação?

Não acho que essa seja a questão certa para discutir isso. Este _closed_ problema é sobre um repositório apt para instalar a ferramenta certbot - que parece não estar completamente relacionado à sua consulta.

Bem, eu estava apenas continuando o que drewcking perguntou, uma vez que a resposta a isso realmente não funcionou no meu caso. O que tem a ver com os pacotes ubuntu LE (que não estão atualizados).