Certbot: Créer un PPA officiel pour les packages Ubuntu Letsencrypt

:+1:

:+1:

:pouces vers le haut:

:+1:

jolie s'il-vous-plaît?

Oui s'il vous plaît!

Oui s'il vous plaît.

+1

+1

+1

Il y a eu une tonne d'efforts dépensés sur letsencrypt-auto et aucun ici. Ce qui se passe? Je trouve cette situation absolument gênante, car letsencrypt-auto était censé être une solution temporaire jusqu'à ce que nous soyons emballés. @hlieberman et @fmarier ont investi beaucoup de temps dans les debs et nous perdons maintenant du temps sur un script "auto-magique" fait maison qui essaie de remplacer fondamentalement toutes les solutions d'emballage (et, malgré de gros efforts, échoue lamentablement à ce). Il y a eu de nombreuses plaintes sur la complexité ridicule du client et j'ai pensé qu'il était évident que les choses devaient être réduites plutôt que prolongées à l'infini.

@pde - veuillez clarifier ci-dessus et fournir l'ETA sur le PPA.

Pour les versions récentes d'Ubuntu, le paquet dans Debian unstable devrait fonctionner correctement. Une fois que nous avons rétroporté le paquet sur Debian jessie, le faire fonctionner dans Ubuntu 14.04 devrait être plus facile.

Cela nécessitera bien sûr également l'empaquetage d'un certain nombre de bibliothèques dépendantes.

+1 pour un PPA afin de fournir un moyen plus traditionnel/standardisé d'installer des logiciels non emballés.

La mise à jour que nous avons reçue la semaine dernière de Harlan était que divers mainteneurs de Debian avaient fait un excellent travail en rétroportant toutes nos dépendances Python, mais le bloqueur exceptionnel était sphinx-doc pour les paquets doc, et que cela allait être un engagement non négligeable. Je ne sais pas si les PPA sont significativement différents ou plus faciles.

La construction de documents Sphinx ne peut-elle pas être temporairement désactivée pour les packages PPA ? En tant qu'utilisateur, je n'ai aucun problème à devoir aller en ligne pour vérifier la documentation (en fait, je préfère cela au lieu de lire des fichiers HTML locaux dans /usr/share/doc/).

si c'est seulement la construction sphinx-doc de la doc alors où est le problème ?

• fournir 2 forfaits letsencrypt et letsencrypt-doc
• fournir un homme letsencrypt.1 pour letsencrypt_x.y.deb
• pré-construire le doc en HTML
  et emballer en letsencrypt-doc_x.y.deb

raison:
construire automatiquement la doc c'est bien mais c'est facultatif
supprimer le sphinx-doc pour construire la doc n'empêche pas letsencrypt
être construit, installé et fonctionner, c'est ce que tout le monde veut

La proposition de @zwetan de séparer les debs pour l'application et la documentation est déjà bien prouvée par de nombreuses autres applications, de GIMP à LibreOffice. Cela profite aux développeurs, qui n'ont pas à reconstruire la documentation à chaque mise à niveau de sécurité, et cela leur donne la liberté de mettre à jour la documentation pendant les périodes d'inactivité des applications. Je recommande l'idée.

Il y a déjàletsencrypt dans xenial (16.04 à venir) : http://packages.ubuntu.com/xenial/letsencrypt

Les documents semblent être des deps facultatifs là-bas.

mon point exactement, certains serveurs en prod ne fonctionnent qu'avec LTS -> correctifs de sécurité -> prochain LTS
devoir attendre 16.04 LTS, alors que 14.04 LTS pouvait déjà avoir le package deb
uniquement parce que la version doc est problématique ? allez :)

La mise à jour la plus récente est qu'un backport sphinx a débloqué l'empaquetage pour Debian 8, et un PPA sera en route peu de temps après.

@zwetan :+1: je ne peux pas utiliserletsencrypt car j'utilise 14.04 et il n'y a pas de référentiel officiel pour 14.04

:+1:

:+1:

+1 Je ne recommencerai plus jamais de ma vie Letsencrypt-auto....

J'ai créé un PPA pour Ubuntu Wily. À utiliser à vos risques et périls; il est en grande partie non testé pour le moment.

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

@hlieberman ce package pourrait-il s'exécuter sur 14.0.4 alias TrustyThar ou cela peut-il être refusé ?

juste un avertissement, le PPA ne crée pas les répertoires pour les configurations dans /etc et /opt

Et maintenant, letsencrypt-auto échoue avec des problèmes de dépendance (urllib3, acme). Cela devrait être un processus simple et rapide, étant donné le problème qu'il résout. Vous ne voulez pas passer des heures à vous disputer avec les dépendances et autres, cela le rend fragile.

(PS : PPA ne fonctionne pas avec 14.04)

de mes derniers tests sur Ubuntu 14.04.5 LTS
il est plus simple d'ignorer le PPA

il suffit de faire une installation "manuelle"

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

(la deuxième ligne est de forcer les dépendances à installer)
cela a bien fonctionné pour moi sur une douzaine de serveurs

Une suggestion supplémentaire : si vous n'êtes pas à l'aise avec le nombre relativement important de dépendances, créez simplement une petite instance lxc (environ 350 Mo pour le moment) et suivez l'installation manuelle susmentionnée :
lxc-create -n letsencrypt -t ubuntu

Afin d'utiliser les certificats sur l'hôte et de permettre les tests automatisés, ajoutez simplement deux montages de liaison à votre configuration comme suit (l'idée est qu'un serveur Web externe - sur l'hôte ou vivant dans un autre conteneur - prendra s'en occupe):
lxc.mount.entry = /var/www/letsencrypt var/www/letsencrypt none bind 0 0
lxc.mount.entry = /etc/letsencrypt etc/letsencrypt none bind 0 0

(Bien sûr, vous devez déclencher des renouvellements synchronisés/redémarrages du service du serveur Web depuis l'extérieur du conteneur _letsencrypt_, mais c'est assez pratique...)

personnellement, les dépendances ne me dérangent pas

ce dont j'ai vraiment besoin, c'est de l'automatisation pour pouvoir ajouter un script d'approvisionnement
pour savoir si je veux ajouter le support de Let's Encrypt sur un serveur
cela fonctionnera, a été testé et prendra environ 10 minutes à configurer

Un grand nombre de dépendances est un problème pour moi car je suis limité en ressources.

S'il y a un intérêt pour les conteneurs, je peux créer un conteneur Docker qui ferait le travail très très rapidement. Il semble y avoir du travail dans ce sens sur le hub Docker, mais il semble abandonné/ancien.

Cela signifierait qu'il serait aussi simple que docker run -v/etc/letsencrypt:/etc/letsencrypt -p80:80 -p443:443 letsencrypt <FQDN> de générer des certificats.

EDIT : vous voilà tous. https://hub.docker.com/r/samyaple/certbot/
Cela va réduire d'environ 250 Mo, y compris l'image de base. Je travaille à réduire cette empreinte maintenant. Ce n'était qu'une mise en œuvre approximative en quelques minutes. Les builds sont automatisés afin que vous puissiez voir exactement ce qui est en train de se construire, ce n'est pas drôle.

Je suis plus qu'heureux de soutenir cela sous la bannière Letsencrypt si vous le souhaitez.

:+1:

Pour ceux que cela intéresse, j'ai un petit rôle Ansible connecté pour automatiser l'installation des certificats pour mes sites Ubuntu. C'est très limité pour le moment, juste pour les fonctionnalités dont j'ai besoin, PR est le bienvenu si quelqu'un veut l'utiliser aussi.

Le rôle utilise le client officiel de git et effectue l'installation/le renouvellement du certificat en mode certonly .

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

La réaffectation d'Harlan après le transfert de pension l'a retiré. C'est toujours important, mais ce sera désormais une priorité moindre que de renommerletsencrypt -> certbot aux endroits où nous sommes déjà empaquetés.

??

+1

+1

+1

+1

Ce serait bien d'avoir le PPA mis à jour avec la dernière version. Il est à la traîne - toujours sur 0.4.1 il semble : https://launchpad.net/ubuntu/xenial/+package/letsencrypt

@larssn Ce n'est pas un PPA - c'est le package dans les référentiels Ubuntu. Deux considérations : tout d'abord, il y a un processus SRU [1] à suivre pour obtenir les mises à jour des packages dans une version Ubuntu. Deuxièmement, le package est dans 'universe' et n'est donc pas officiellement pris en charge par Ubuntu/Canonical.

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

(modifier : ajouter une URL)

J'ai compris.

Dans tous les cas; souhaitant toujours une mise à jour. :)

Mes amis, ce n'est pas un référentiel "officiel", mais je suis chez moi, j'ai une certaine crédibilité en tant que développeur Debian et membre Ubuntu (et mon PHP PPA est utilisé par des milliers de personnes), j'ai donc créé PPA pour certbot 0.8.x. Il a été construit à partir de Xenial uniquement pour le moment, mais je pourrais envisager de rétroporter une plus grande partie de la pile vers Trusty si je trouve un peu de temps.

Le PPA est ici : https://launchpad.net/~ondrej/+archive/ubuntu/letsencrypt

je viens de le tester sur ubuntu 16.04 fonctionne très bien, en utilisant déjà vos trucs pour php, apache et mysql

@oerdnj Vous venez de sauver ma journée encore une fois. Merci beaucoup pour votre travail!

@oerdnj pensez -vous que votre PPA est suffisamment fiable pour que nous puissions envisager de le pointer dans notre générateur d'instructions ?

wrt Trusty : Je crois qu'Harlan a eu un peu peur de l'ensemble de dépendances qui devait être construit pour Trusty afin de lancer un PPA fiable. Mais @jonathonf semble avoir fait des progrès sur ce front, il peut donc s'agir d'un problème résolu.

@pde C'est stable au fur et à mesure. Je suis occupé de temps en temps et quelqu'un peut me contacter ou répondre à un problème sur mon tracker gh ici : https://github.com/oerdnj/deb.sury.org/issues

Mais j'ai tendance à publier et à réparer des choses critiques en quelques heures-jours et des choses moins critiques en quelques semaines.

J'assisterai à des conférences en octobre et je remplis généralement le temps d'inactivité avec des emballages, je pourrais donc peut-être terminer l'emballage Trusty. Bien sûr, s'il existe déjà du travail sur ce front, je serais heureux de prendre des conseils/correctifs/aide.

Comme alternative, je serais heureux de créer un groupe de packaging "officiel" sur Launchpad et d'inviter plus de personnes et d'ajouter quelqu'un de LE en tant qu'administrateur.

L'équipe d'empaquetage Debian a fait un excellent travail, donc pour Xenial, il s'agissait principalement de rétroporter/remballer un paquet existant. Pour Trusty, cela peut nécessiter quelques modifications supplémentaires, mais je ne l'ai pas encore examiné.

Pour mémoire, j'utilise le PPA de Trusty et tout fonctionne bien, j'avais juste besoin de quelques packages python-* mis à jour.

@pde Il y a https://launchpad.net/~letsencrypt et il semble abandonné. Peut-être que LE pourrait demander à Canonical d'accorder à quelqu'un de LE un accès administrateur à cette équipe de lancement, puis de m'ajouter et @jonathonf , et nous créerons un référentiel officiel pour certbot sous cet espace de noms ? Cela semble être la meilleure approche pour combiner les efforts.

@oerdnj Un dépôt de certbot sousletsencrypt serait bien. Personnellement, je cherche toujours un package letsencrypt , et je serais confus si je ne pouvais pas trouver ti en recherchantletsencrypt.

J'ai accordé à @oerdnj la propriété de l'organisation ~letsencrypt.

Si quelqu'un de Letsencrypt souhaite être ajouté à l'organisation et devenir propriétaire, veuillez me contacter par ping.

J'ai maintenant copié mes packages certbot vers ppa:letsencrypt/letsencrypt ? Je vais regarder le référentiel de confiance @jonathonf pour vérifier quels packages doivent être rétroportés pour Ubuntu Trusty.

@floe Est-ce que https://launchpad.net/~jonathonf/+archive/ubuntu/letsencrypt est le bon référentiel Trusty que vous utilisez ?

Oui, c'est la bonne. De mon sources.list :

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

Si nous voulons créer un PPA Certbot officiel, je pense que nous devrions le configurer sous https://launchpad.net/~certbot au lieu de ~letsencrypt car Certbot n'est plus un projet Let's Encrypt ( source1 , source2 ). ~certbot appartient à @hlieberman qui est notre responsable du paquet Debian.

Est-ce que ppa:letsencrypt/certbot serait un meilleur match ? Je suis d' accord avec l'un ou l'autre ou avec

Je suis d'accord qu'avoir un PPA Certbot officiel serait un énorme avantage pour les utilisateurs. Comment exactement nous voulons faire cela est quelque chose dont les développeurs de certbot de base devraient parler cependant. Nous avons une réunion tous les mercredis. J'en parlerai alors et je vous recontacterai après la réunion.

@bmw @oerdnj @ArchimedesPi Je pense que la bonne chose à faire est probablement de réduire ppa:letsencrypt , idéalement en le redirigeant sur le Launchpad vers certbot , mais par d'autres moyens si nécessaire ?

@oerdnj Ravi de vous revoir ici :) En fait, je viens de tomber sur ce fil au cours du rétroportage vers Trusty. J'ai déjà rétroporté les packages Debian pour xenial en juillet, mais seuls les deux packages que nous exécutons actuellement en production (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 En plus du problème de nommage PPA, qui a déjà effectué un backport propre de Debian vers Trusty ? Et quel est le meilleur endroit pour synchroniser nos efforts là-dessus, car nos applications PHP5 veulent vraiment aussi LE ? ;)

Debian a rétroporté ses paquets 0.8.1 vers jessie-backports, il y a donc un rétroportage très propre de là vers xenial. Réduire les profondeurs des paquets Debian pour pyopenssl et python-cryptography signifiera que python-acme et python-certbot seront rétroportés sans rien d'autre nécessaire. Si vous faites cela, cependant, vous pouvez aussi simplement rétroporter le paquet yakkety.

Trusty a toujours besoin d'un correctif pour le package python-acme - tout le reste est compatible avec (principalement) les versions jessie-backport. Il existe encore un grand nombre de packages de bibliothèques de dépendances mis à jour qui pourraient avoir des effets d'entraînement.

@ -all using ppa:jonathonf/certbot basé sur les paquets Debian jessie-backport. Il se peut également que je réajuste légèrement ce nouveau PPA pour nettoyer le backport xenial comme ci-dessus.

Edit: mon certbot PPA apporte quelques bibliothèques Python supplémentaires de Jessie - cela rend le rétroportage direct depuis Sid beaucoup plus facile au prix de s'écarter de la pile Trusty Python. Ce n'est pas un gros problème si les bibliothèques sont dans universe toute façon.

@jonathonf Bon à entendre :) Pouvez-vous donner plus d'indices sur le patch pour "python-acme" sur trusty ? Pour les effets d'entraînement, j'aurai une phase de stabilisation tout en le mettant en production et bien sûr nous devons toujours casser les serveurs de développement ;) Comment puis-je vous aider avec les packages de confiance ou qui travaille dessus ?

@jonathonf Lorsque vous testez vos packages de confiance à partir de ppa:jonathonf/certbot, j'obtiens :
pkg_resources.DistributionNotFound: The 'python2-pythondialog>=3.2.2rc1' distribution was not found and is required by certbot
Mais avec un backport rapide sans modification de source pour cette dépendance, le client fonctionnait maintenant : https://launchpad.net/~trio-interactive/+archive/ubuntu/unstable/+sourcepub/7045266/+listing-archive-extra

@all : Pour un rétroportage propre, les dépendances python sont un gros problème, car nous devons mettre à niveau plusieurs packages Python fournis avec la version de distribution. Cela peut casser d'autres outils Python avec les mêmes dépendances et rend également le fardeau de la maintenance un petit cauchemar de sécurité, car le PPA devrait envoyer toutes les mises à jour de sécurité pour toutes les dépendances rétroportées. C'est un problème non trivial pour l'expédition de colis fidèles ! Même si vous construisez le pipeline de rétroportage à partir de xenial ou de jessie, nous aurions toujours besoin d'être synchronisés avec les équipes de sécurité ... pendant que nous jouons avec la pile Python dans la version ;) Qu'en pensez-vous ?

Hum. Pourriez-vous visiter les versions requises des dépendances localement dans le package certbot ?

@bhat3 : si vous cherchez python-acme dans debian.tar.gz, vous trouverez le patch quilt. Je suis presque sûr de l'avoir obtenu plus tôt dans ce fil, mais je ne l'ai pas vu après une analyse rapide à l'instant.

@jonathonf J'essaie de jeter un œil à l'emballage aujourd'hui, mais je ne peux pas encore promettre d'avoir le temps. À côté de votre correctif, que verriez-vous comme des dépendances minimales pour trusty, afin que nous n'ayons pas tellement besoin du désordre avec la pile Python de trusty ?
@oerdnj Sachant que vous êtes assez en phase avec les responsables de la sécurité, êtes-vous intéressé à fournir des packages fiables via le PPA ?

Cela dépend de la quantité d'emballage que vous voulez faire. Les deps dans mon letsencrypt PPA d'origine sont à peu près aussi minimes que possible, mais rendent les rétroportages ultérieurs à partir de Debian plus difficiles. Les deps rétroportés dans mon certbot PPA sont plus nombreux/plus étendus mais rendent les rétroportages directs beaucoup plus faciles.

Si les bibliothèques Python sont dans universe nous n'avons pas à nous inquiéter autant - rien dans la pile Ubuntu de base ne repose sur quoi que ce soit dans universe (et les packages dans universe ne le sont pas mis à jour comme une évidence de toute façon, même pour des problèmes de sécurité).

@jonathonf Bonne réflexion sur le cas du coin "univers" dans Ubuntu ;) En fait je n'ai pas pu continuer mes efforts hier et plus aucune chance pour cette semaine :( Mais j'espère le faire lundi ou après le 7 novembre. D'ici là :)

Nous sommes à presque un an de la création de ce numéro et nous ne sommes toujours pas d'accord sur quoi que ce soit ?

Pouvons-nous prendre de l'élan ici? D'une façon ou d'une autre.

https://launchpad.net/~jonathonf/+archive/ubuntu/certbot est-il aussi officiel que nous allons l'avoir ?

@jonathonf et tous - J'ai fait équipe avec @hlieberman dans ppa:certbot/certbot et je pense avoir la plupart des développements de construction pour trusty, xenial et yakkety. La seule chose qui manque est le sphinx récent et j'espère qu'il y aura une solution de contournement pour cela.

@oerdnj Est-il prêt à être utilisé ?
J'obtiens un message "Erreur : l'empreinte de la clé de signature n'existe pas" lorsque j'essaie de l'ajouter.

Désolé pas encore, mais il sera terminé dans ~semaine. Je pars pour l'IETF demain et j'aurai du temps libre là-bas pour le terminer.

Si c'est juste comme builddep, j'ai un PPA de backport Sphinx qui peut être ajouté
en tant que dépendance PPA. Vous pouvez l'utiliser, copier les packages sur un "support"
PPA, ou rétroportez le même ensemble de packages.

J

Le 9 novembre 2016 à 12h39, "Ondřej Surý" [email protected] a écrit :

@jonathonf https://github.com/jonathonf et tout - j'ai fait équipe avec
@hlieberman https://github.com/hlieberman dans ppa:certbot/certbot et moi
pense que j'ai la plupart des deps de construction pour trusty, xenial et yakkety. Les
il ne manque qu'un sphinx récent et j'espère qu'il y en aura
solution de contournement pour cela.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/certbot/certbot/issues/1706#issuecomment-259405442 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAiJCY1dmSHhspzOgNcT8tQu4XigyNJdks5q8b7ygaJpZM4Guho5
.

@oerdnj @jonathonf @hlieberman
Merci pour votre travail à ce sujet.

Je pense que nous pouvons tous attendre encore une semaine.

@oerdnj @jonathonf Y a-t-il quelque chose que je puisse vous aider sur les backports fiables pendant mes heures de travail ?

@bhat3 Ce serait génial si vous pouviez faire un test approfondi de ce qui est maintenant dans ppa:certbot/certbot . J'ai dû resserrer certains (Build-)Depends avant qu'il n'arrête de générer des erreurs d'exécution, mais tout semble bien maintenant.

JFTR le ppa:certbot/certbot contient maintenant des packages qui pourraient être utilisés avec une certaine prudence. Veuillez signaler toute casse ici pour le moment.

@oerdnj Okay le fera et remplacera mon propre emballage sur nos serveurs de développement par ppa:certbot/certbot . Mais à côté des outils standard Debian/Ubuntu, nous n'utilisons pas Python mais votre PHP là-bas, donc je ne pourrai pas insister sur ces casses ;)

Sur Ubuntu-16.04-xeinal, j'étais bloqué sur 0.4.1 qui ne se renouvelait pas avec l'erreur suivante :

AVERTISSEMENT :letsencrypt.cli : Tentative de renouvellement du certificat à partir de /etc/letsencrypt/renewal/gableroux.com.conf a produit une erreur inattendue : 'server'. Saut.

Après la mise à niveau, les renouvellements fonctionnent à nouveau, merci ! :RÉ

python -mplatform

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

letsencrypt --version

permet de chiffrer 0.4.1

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

permet de chiffrer 0.9.3

letsencrypt renew --agree-tos 

Félicitations, tous les renouvellements ont réussi.

:cœur:

@oerdnj Jusqu'à présent, cela a l'air bien sur le serveur de développement, j'ai utilisé les packages de confiance de

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]

J'ai renouvelé avec succès un certificat LE précréé avec 99 sous-domaines et cela fonctionne bien. D'autres tests suivront demain...

Comme dit, je suis un peu sceptique quant au rétroportage complet des dépendances, car LE travaillait déjà sur le même système sans mettre à niveau toute la chaîne de dépendances ;) Sinon, je suis heureux d'enfin "mainline" nos systèmes :)

BTW, si vous renommez le PPA certbot/certbot avec le nom par défaut (certbot/ppa), les utilisateurs pourraient alors utiliser la version abrégée du nom, c'est-à-dire :

sudo add-apt-repository ppa:certbot

@oerdnj Le prochain test de confiance était un renouvellement automatisé via cron et shell, mais en fait, j'ai trouvé des problèmes que je n'avais pas rencontrés auparavant :

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

Alors que j'enregistre chaque sortie de ce script de renouvellement et que je reçois une notification par courrier, je ne trouve pas le certbot.log et je ne peux pas vraiment le déboguer. Avez-vous des indices là-dessus ?

@bhat3, vous devriez utiliser --noninteractive ou --quiet (ce qui implique --noninteractive ) si vous invoquez certbot à partir d'un script cron.

(Je chercherais certbot.log dans /var/log/, peut-être dans /var/log/letsencrypt/? TBH, je n'ai que letsencrypt.log là-dedans ; certbot.log ressemble à quelque chose de nouveau.)

certbot ne renouvelle-t-il pas la tentative de tout renouveler ? je lance ça et ça fait ça

@ bhat3 est-ce une tâche cron par défaut fournie par le package ?

@oerdnj Non, c'est le propre et le commutateur --noninteractive n'était pas nécessaire auparavant avec le package de @jonathonf . La raison de cette propre tâche cron est que nous devons redémarrer Nginx si le renouvellement réussit et que de telles choses doivent se produire dans un délai fixe. La dernière exigence peut être effectuée dans /etc/cron.d/certbot mais pas sûr de l'interaction avec nginx -t && systemctl restart nginx .

@chrismccoy Et comment redémarrer votre serveur web après renouvellement ?

@mgedmin Thx, cela a fonctionné avec le commutateur. Mais je suis toujours curieux de savoir si le certbot.log n'est qu'un problème de marque et /var/log/letsencrypt/letsencrypt.log est signifié par cela, qui semble ne pas avoir été créé sans le commutateur.

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

Regardez le nouveau travail de recadrage, il a un répertoire de crochets

@oerdnj Vous voulez dire que je ne peux faire un crochet qu'après des renouvellements réussis qui s'occupe ensuite de Nginx?

L'appel certbot renew comprend désormais : /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/'

Et je viens d'envoyer à @hlieberman le correctif pour le bogue Debian n°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 , nous avons spécifiquement demandé à

La version packagée de certbot dans le PPA a-t-elle le plug-in de configuration Apache ? Je remarque qu'il n'a pas de package équivalent à python-letsencrypt-apache comme le fait Universe.

J'ai Certbot/Letsencrypt qui fonctionne avec la version d'Universe, mais lorsque je mets à niveau à l'aide du PPA, j'obtiens des erreurs concernant le plugin Apache. par exemple

$ 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)

et

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

J'ai essayé de supprimer le fichier de configuration (renommé /etc/letscrypt) mais aucune amélioration. Heureusement, il est simple de rétrograder à 0.4.1.

@bmw Pour être honnête, je salue en fait l'intégration de Debian ici et je souhaite la consolider à partir de notre propre script BASH cron'ed. Que voulez-vous faire en tant que solution en amont et agnostique de la distribution ... et combien de temps faut-il pour livrer ?

Il y a tellement de solutions horribles à l'air libre concernant le renouvellement et l'interaction nécessaire avec le service utilisant les certificats, que je préfère vraiment que fournissent une solution saine sur laquelle nous pouvons maintenant standardiser sur les distributions Debian :+1 :

@bmw Je

Je suis peut-être dans ce domaine depuis trop longtemps, mais attendre une solution parfaite n'est généralement que le chemin vers un désastre, car les gens vont commencer à être créatifs.

J'apprécierais vraiment que @hlieberman intégrait la solution run-parts dans le paquet Debian principal car il fournit une solution fonctionnelle pour Debian Stretch dès maintenant et s'intègre bien d'une manière dont le fonctionnement interne de Debian.

Salut @oerdnj , deux points :

1. Étant donné que nous contrôlons en amont et que nous avons un assez bon pipeline de nos versions vers unstable et testing , nous pensons qu'il est temps d'atterrir un correctif dans Certbot en amont qui fonctionne à la fois pour Debian et la plupart/toutes les autres distributions , et placez-le dans Debian. Cela peut très facilement arriver avant le gel de février si vous voulez ; envoyez-nous simplement un PR ou encouragez @hlieberman à le faire :)
2. Nous avons eu beaucoup de conversations sur la façon de faire face au gel des étirements. Nous ne pensons pas que Certbot soit suffisamment mature pour être épinglé sur une version donnée pendant les 5 ans et plus que les gens semblent essayer de faire respecter pour les versions stables de Debian. Nous essayons toujours de trouver quoi faire à ce sujet. Sur Ubuntu, nous suivons le processus SRU pour obtenir les nouvelles versions de Certbot dans Xenial LTS, mais nous ne sommes pas très optimistes quant au fait que Debian les considérera comme extensibles. Notre plan actuel est de demander à la liste debian-devel de choisir entre (1) s'engager à accepter une version de Certbot bien testée dans les mises à jour Stretch tous les ~6 mois ; (2) demander à Debian de ne pas livrer Certbot dans des versions stables, et de se fier à la place à donner à nos utilisateurs des instructions de rétroportage, ce que nous faisons avec Jessie en ce moment, et nous pensons que c'est assez raisonnable.
3. Vous pouvez participer à nos appels hebdomadaires aux développeurs Certbot pour discuter de ces problèmes avec nous si vous le souhaitez ! Je pense que Brad t'a envoyé une invitation, mais sinon, envoie-moi un message et on réglera ça.

@pde ok, c'est logique. Je vais essayer de réserver du temps libre pour concocter quelque chose de similaire à run-parts , mais en code python natif.

Oui, j'ai reçu l'invitation (je vérifierai avec vous sur Freenode pour l'heure exacte). Je ne peux rien promettre au-delà de ce problème particulier, car il n'y a qu'un temps limité en jour/semaine/mois/année :)

Edité : C'est peut-être l'expérience de l'IETF en moi, mais je préfère en fait un code en cours d'exécution à la conversation :). Si seulement j'ai plus de temps pour produire plus de code en cours d'exécution.

Ce serait bien si le plugin apache pouvait également être ajouté :)

Bonjour, je voulais juste vérifier quand nous pourrions voir un PPA ? Je suis sur le point d'installer certbot-auto à court terme pour nous aider à traverser notre premier renouvellement à venir depuis la première utilisation de Lets Encrypt. Bravo et merci pour le travail que vous faites pour mettre tout cela ensemble.

@jesseiqmi Vous pouvez déjà faire un tour :

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

Je l'utilise également en production, mais toujours sans intégration de renouvellement appropriée, mais ma production a testé le script home brewn. Mais je suggérerais au moins que vous testiez toujours les nouvelles versions sur les systèmes de développement et de mise en scène avant de toucher à la production. Vous pouvez rester léger avec KISS en utilisant simplement apt-mark hold PKGNAME , désactiver le PPA en production jusqu'à ce que les prochains tests soient passés sur la mise en scène ou utiliser vos propres PPA pour transférer les packages entre vos systèmes dans la chaîne d'assurance qualité.

Le PPA ne semble inclure aucun des plugins tels que certbot-apache. Quelle est la bonne procédure pour les installer ?

@oerdnj des mises à jour ou des choses pour

@pde Si vous avez une idée de la façon de réparer la documentation avec sphinx-build 1.2.2, cela peut aider : https://launchpadlibrarian.net/301768953/buildlog_ubuntu-trusty-i386.python-certbot-nginx_0.9.3-1+certbot ~trusty+2_BUILDING.txt.gz

Cela semble être un bogue de code dans certbot_nginx/nginxparser.py , rien à voir avec Sphinx (à part que Sphinx essaie d'importer le module à des fins d'autodoc, ce qui échoue à cause du bogue).

AFAICS pyparsing veut que vous utilisiez ... + restOfLine au lieu de ... + restOfLine() .

@mgedmin Merci, je vais essayer de corriger cela dans le package et soumis en tant que https://github.com/certbot/certbot/pull/3989

Ok, donc le PPA contient maintenant à la fois des plugins Apache et Nginx. Merci pour le coup.

Merci pour tout votre travail ici @oerdnj ! Pensez-vous que le PPA est à un point où nous pouvons commencer à le suggérer à l'utilisateur moyen de Certbot ?

@bmw je le crois. Eh bien, mis à part le problème que j'ai toujours le hack rundirs dans le référentiel, je ne veux pas lâcher prise - mais je serais heureux de préparer un chemin de migration stable une fois que la fonctionnalité aura atteint le certbot en amont.

@oerdnj Ouais ! J'adorerais enfin consolider le rundirs "hack" sans avoir besoin de forker le PPA plus tard :+1:
@bmw Je peux comprendre votre besoin d'une approche Python en amont, mais il s'agit de paquets Debian ici, n'est-ce pas ?! ;)

Désolé d'avoir posté ma question ici car il y a tellement d'abonnés à ce problème, mais je n'ai trouvé de bonne réponse nulle part ailleurs, alors voilà :

Ubuntu 16.04.2
Installer des packages avec apt install letsencrypt :
letsencrypt --version me donne 0.4.1 mais lors de l'installation à partir de git j'obtiens 0.12.0 - alors quand Ubuntu mettra-t-il à jour le paquet, ou la 0.4.1 est-elle juste la version Ubuntu pour 0.12.0 ?

Ubuntu ne met jamais à jour les packages dans les versions publiées (sauf lorsqu'ils doivent corriger des bogues graves - voir leur politique de mise à jour des versions

Ubuntu mettra à jour le package pour la 16.04 au fur et à mesure du processus SRU. Le package Ubuntu n'est pas lié au dépôt git.

Vous feriez mieux d'utiliser le PPA, alors un apt-get install letsencrypt installera la dernière version emballée.

À moins que vous ne vouliez la dernière version de git, auquel cas faites ce que vous avez fait.

@jonathonf J'ai installé le PPA dans ce problème, mais aucune différence. :/

Je ne pense pas que vous l'ayez fait. ;)

Essayez celui-ci : https://launchpad.net/~certbot/+archive/ubuntu/certbot

@jonathonf Génial ! J'ai raté ça.

Alors, est-ce que cela sera maintenu ? J'ai remarqué que c'était "semi-officiel". De plus, cela installera-t-il toutes les dépendances nécessaires ? Il me semble que la version Git installe plus de packages...

Salut à tous, puis-je utiliser le PPA cité https://launchpad.net/~certbot/+archive/ubuntu/certbot
?

Il est sécurisé, fiable et mis à jour ?

Comme pour tous les PPA, c'est votre appel.

Cependant, @oerdnj est un

Si vous lui faites confiance, vous pouvez faire confiance à ses PPA.

Il me semble que la version Git installe plus de packages...

La version git configure un virtualenv Python pour construire le logiciel et installe toutes les dépendances associées localement. Un PPA le fait en coulisses, il y a donc moins de packages de résultats finaux.

Ce PPA est prêt à l'emploi ! Nous mettrons à jour certbot.eff.org pour dire aux gens de l'utiliser sur certbot-auto ou sur les packages Ubuntu actuels (voir certbot/website#198). Nous pouvons enfin clore ce dossier.

@hlieberman , @oerdnj : pouvez-vous supprimer "(semi-officiel)" du titre du PPA ?

Une chance de faire renommer le PPA en ppa afin que les gens puissent exécuter sudo add-apt-repository ppa:certbot au lieu de sudo add-apt-repository ppa:certbot/certbot ? Cela a été mentionné dans ce commentaire : https://github.com/certbot/certbot/issues/1706#issuecomment -260585028

Quand le PPA sera-t-il mis à jour ? La version 12 est sortie depuis 13 jours.

Je suis presque sûr que vous avez besoin d'un préfixe pour un ppa afin qu'il sache à quel utilisateur et à quel référentiel il appartient, sinon il ne saura pas quel référentiel choisir dans ce nom d'utilisateur, je me trompe peut-être, quelqu'un d'autre peut intervenir, de tous les ppa je n'en utilisez aucun, ayez juste un préfixe.

Envoyé de mon iPhone

Le 15 mars 2017, à 17h18, Geoffrey Fairchild [email protected] a écrit :

J'aime la suggestion de @elyscape .

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub ou coupez le fil de discussion.

@elyscape Cela obligerait toutes les personnes qui utilisent déjà le ppa à changer leurs configurations juste pour l'esthétique, donc désolé, non, ce n'est pas une option à ce stade.

@chrismccoy , ppa est le dépôt supposé si vous spécifiez uniquement un utilisateur pour un 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)

Au moment où j'écrivais ceci, @oerdnj a répondu, donc le point est maintenant discutable de toute façon :)

Un PPA nommé simplement « ppa » peut être ajouté, comme le dit @elyscape , avec une commande raccourcie apt-add-repository , mais il ne s’agit en fait que d’une perte de vélo à ce stade. C'est le PPA certbot pour le projet certbot et les neuf caractères supplémentaires ne sont guère onéreux.

En termes de mises à jour, 0.12 n'a pas encore atterri dans Debian (même pas sid ou expérimental). Une fois qu'il l'a fait et qu'il a été convenablement disputé, il devrait se frayer un chemin dans le PPA :

Il s'agit du PPA pour les paquets préparés par l'équipe Debian Let's Encrypt et rétroportés pour Ubuntu(s).

Je suppose que vous souhaitez déployer un package fonctionnel testé ? :)

--Éditer
Deux autres mises à jour en tapant... meh, je poste quand même. :P

@enoch85 Y a-t-il quelque chose de cassé pour vous ? #4233 est troublant, mais c'est tout.

Je suis généralement le workflow @hlieberman et il n'a apparemment pas encore eu le temps de mettre à jour les packages Debian, et je ne veux pas lui marcher sur les pieds.

Je peux extraire un correctif de #4243 au-dessus de 0.11.1 si cela pose des problèmes à plus de personnes utilisant ce PPA, mais je ne suis pas vraiment cette vision du monde "nouvelle version juste pour la nouvelle version".

@bmw "(semi-officiel)" supprimé. Si vous avez d'autres suggestions pour le titre ou la description, je serais heureux de le modifier.

@oerdnj Non, pas encore mais peut-être bientôt, car je me suis converti à ce PPA à partir de la version git qui est de 12 et je reçois des avertissements sur les certificats générés avec 12. Ce serait génial avec une mise à jour. Et comme toujours, tu déchires !

combien de temps faut-il habituellement pour obtenir une mise à jour des responsables du tableau de bord, je vois que certbot/certbot sur le tableau de bord est à 0,11.1 et 0,12 est sur github.com

@chrismccoy Lisez le commentaire du mainteneur du PPA trois commentaires du vôtre, c'est-à-dire https://github.com/certbot/certbot/issues/1706#issuecomment -286890691.

@oerdnj Je

Obtenir ceci lorsque vous essayez d'installer un nouveau certificat avec Certbot 12 à partir du PPA dans ce problème. Je ne sais pas si c'est un bug de Let's Encrypt ou quelque chose avec le PPA. L'a également signalé ici : 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...

Mes certificats sont générés correctement, mais je pense que quelqu'un devrait examiner le message d'avertissement python.

@oerdnj Désolé de vous déranger, mais est-il possible de suivre l'emballage des nouvelles versions ? c'est-à-dire quand un nouveau paquet sera/pourrait être prêt.

J'attends de nouveaux packages (v0.14.x) pour pouvoir renouveler automatiquement les certificats à l'aide de Cloudflare et de l'authentification DNS.

@shaneog Il n'y a pas de plan car c'est sur la base du "temps libre en ce moment" (à moins qu'il n'y ait un bogue critique). Cependant, la mise à jour vers 0.14.1 semble être une simple mise à jour, je télécharge donc les versions en ce moment.

Merci!

Étant donné que la crontab créée lors de l'installation à partir du PPA n'inclut plus le bit /bin/run-parts, quelle est la méthode recommandée pour spécifier les hooks de renouvellement ?

Pour l'instant, je ne fais que remplacer mon script /etc/cron.d/certbot par ce que @oerdnj avait en place il y a quelques mois (je suis sur 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/'

... et mettre mes scripts de hook dans ces répertoires. Y a-t-il une meilleure façon de procéder?

Cela dépend de ce que vous souhaitez accomplir. Il existe deux options principales, mais assurez-vous de lire les avertissements que j'ai placés au bas de cet article .

Fichier de configuration globale

Vous pouvez obtenir un comportement similaire à celui de la solution run-parts en incluant des hooks dans le fichier de configuration de Certbot . Votre fichier à /etc/letsencrypt/cli.ini pourrait ressembler à :

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/

La seule différence de comportement entre celle-ci et la crontab précédente est que ces crochets s'exécutent parfois également lors de l'obtention d'un certificat avec d'autres sous-commandes Certbot telles que certbot certonly , certbot run , certbot (sans sous-commande ), etc. Les hooks avant et après s'exécuteront toujours si un certificat est obtenu, tandis que le hook de renouvellement n'est exécuté que si vous renouvelez un certificat sur un chemin existant.

Fichier de configuration du certificat

Une autre option consiste à définir des hooks par certificat. Cela vous permet d'exécuter différents hooks en fonction du certificat. Lorsque vous obtenez un certificat, les hooks que vous avez utilisés pour obtenir ce certificat sont stockés dans /etc/letsencrypt/renewal/domain.conf . Lorsque vous exécutez certbot renew , ces hooks seront automatiquement exécutés à nouveau lorsque le certificat sera renouvelé. Vous pouvez également modifier ces fichiers manuellement en plaçant des crochets sous l'en-tête de section [renewalparams] en utilisant la même syntaxe que celle que j'ai incluse ci-dessus.

Mises en garde

1. Ces deux options ne sont pas compatibles. Les hooks placés dans un fichier de configuration global sont traités de la même manière que s'ils étaient inclus dans la ligne de commande qui remplace les valeurs trouvées dans le fichier de configuration pour le certificat.
2. Quelle que soit la méthode que vous utilisez, assurez-vous d'exécuter certbot renew --dry-run après avoir modifié les fichiers pour vous assurer que tout fonctionne toujours correctement.

Parfait, le fichier de configuration global est exactement ce dont j'ai besoin, merci !

Alors, quel est le statut réel des crochets de renouvellement ? C'est étrange comme cela est devenu si désordonné. C'était d'abord une tâche cron appelant des pièces dans différents répertoires, puis un fichier cli, et maintenant tout ce que je vois avec une installation propre sont les répertoires, car le cli ne contient plus aucune information dessus.
Quelqu'un chez certbot dev lead pourrait-il simplement placer des commentaires clairs avec des instructions dans ses fichiers de configuration ? A quel point cela peut-il être difficile? Pour un exemple, veuillez vérifier comment ils l'ont fait pour CSF/LFD : https://gist.github.com/skt-bford/4987434

Je suis d'accord que c'est super déroutant et qu'il y a une tonne d'informations contradictoires ou obsolètes à ce sujet. D'après ce que je comprends, la meilleure pratique actuelle consiste à utiliser --deploy-hook (ce qui est mieux que --renew-hook ) à l'aide de la ligne de commande certbot, ce qui l'amène à enregistrer les informations de crochet sur le domaine dans /etc /letsencrypt/renewal, donc le hook sera exécuté à chaque fois automatiquement. Je pense que cela est considéré comme une solution préférée plutôt que d'éditer /etc/letsencrypt/cli.ini directement, et cela a également l'avantage de vous permettre d'avoir différents crochets pour différents certificats.

C'est la meilleure information que j'ai trouvée à ce sujet : https://community.letsencrypt.org/t/certbot-dovecot-postfix-certificate-renewal-issue/72226/11

Je suis d'accord que c'est super déroutant et qu'il y a une tonne d'informations contradictoires ou obsolètes à ce sujet.

oui, déroutant (!)... Mais votre lien est aussi déroutant et son contenu n'est pas fiable....

Salut à tous, certains des experts peuvent-ils nettoyer et résumer? Exprimez un « résumé fiable pour 2020 » .

Eh bien, à propos du titre de ce numéro, "PPA pour UBUNTU", le résumé est là, semble parfait !
https://certbot.eff.org/lets-encrypt/ubuntubionic-nginx

@oerdnj J'étais curieux de savoir ce qu'il faut pour obtenir un plugin certbot + dns mis à jour dans le référentiel de nos jours? Spécifiquement parce que certbot 1.2 ajoute la prise en charge des jetons Cloudflare DNS-01 à portée limitée, ce qui représente un grand renforcement de la sécurité par rapport à l'ancienne méthode qui nécessitait des clés API globales

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

Alors, quel est le statut réel des crochets de renouvellement ?

Je ne pense pas que ce soit la bonne question pour en discuter. Ce problème _fermé_ concerne un référentiel apt pour l'installation de l'outil certbot - qui semble être complètement sans rapport avec votre requête.

Alors, quel est le statut réel des crochets de renouvellement ?

Je ne pense pas que ce soit la bonne question pour en discuter. Ce problème _fermé_ concerne un référentiel apt pour l'installation de l'outil certbot - qui semble être complètement sans rapport avec votre requête.

Eh bien, je continuais simplement sur ce que drewcking a demandé, car la réponse à cela ne fonctionnait pas dans mon cas. Ce qui a à voir avec les packages Ubuntu LE (qui ne sont pas à jour).