Bug 237349 - New port: security/lego Let's Encrypt client written in Go
Summary: New port: security/lego Let's Encrypt client written in Go
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Rodrigo Osorio
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-17 19:44 UTC by Matthew Horan
Modified: 2019-07-24 14:51 UTC (History)
1 user (show)

See Also:


Attachments
Add security/lego and associated UIDs/GIDs (9.49 KB, patch)
2019-04-17 19:44 UTC, Matthew Horan
no flags Details | Diff
security/lego port patch v2 (10.10 KB, patch)
2019-06-17 00:03 UTC, Matthew Horan
no flags Details | Diff
security/lego port patch v3 (10.10 KB, patch)
2019-06-22 12:29 UTC, Matthew Horan
no flags Details | Diff
security/lego port patch v4 (10.10 KB, patch)
2019-07-23 22:59 UTC, Matthew Horan
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Horan 2019-04-17 19:44:05 UTC
Created attachment 203753 [details]
Add security/lego and associated UIDs/GIDs

Create new port for lego, a Let's Encrypt client written in Go.

Runs via periodic on a weekly basis to check if certificates need to be renewed. lego does not currently support a config file, so I've implemented a similar approach to acme-client via a lego.sh script in /usr/local/etc.

Also supports restarting any services associated with new certificates when they are renewed.
Comment 1 Rodrigo Osorio freebsd_committer 2019-05-03 15:00:48 UTC
Hi Matthew,

Thanks for your submission and the work done to package this port,
nevertheless the porting is not finish and some extra work has to
be done before a final commit:

* The Uids patch is not correct and breaks the package generation,
  the correct syntax should be 
  "_lego:*:604:604::0:0:lego client user:/nonexistent:/usr/sbin/nologin".
* There is a missing running dependency :
  RUN_DEPENDS= ca_root_nss>=0:security/ca_root_nss
* Try to make a better separation between parameters and scripts,
  and move the scripts to ${PREFIX}share/lego/ as much as possible.
  You can look at the security/dehydrated port as an example to see
  how they handle the configuration parameters
  

Extra remarks:

There is no clear pah about how to run lego for the first time, even in the
lego github page. In my first attempt, the lego.sh script stops requesting
a 'run' command.
So clearly something has to be done to help the newcomers by
adapting your script and by providing a better guidance in the pkg-message.in
file.

If you want to work in a more interactive way create an account and submit your changes through the review tool Phabricator  (reviews/freebsd.org) all the details about how to create an account or submit a patch are here: https://wiki.freebsd.org/Phabricator. After that just add the review URL to your bug request.

An of course test your port before submission using poudriere and portlint.
Comment 2 Matthew Horan 2019-06-02 13:24:03 UTC
(In reply to Rodrigo Osorio from comment #1)
> * Try to make a better separation between parameters and scripts,
Could you elaborate on this point? I seem to be doing the same thing that both security/dehydrated and security/acme-client (which I based this port off of) are doing. I have weekly_lego_renewscript and weekly_lego_deployscript parameters. The only other parameter is weekly_lego_enable.

Also, security/dehydrated and security/acme-cleint have their renew and deploy scripts in ${PREFIX}etc/, which is why I put them there. If it's appropriate to have example files and user-editable scripts in ${PREFIX}share/, I'm happy to move them there, but I just want to make sure that's the right thing to do.

Happy to improve the pkg-message.in. The upstream maintainer is also working to improve the first run experience, so I was holding off on building up too much tooling around that. However, I agree that a good first run experience is important.
Comment 3 Rodrigo Osorio freebsd_committer 2019-06-04 13:55:59 UTC
(In reply to Matthew Horan from comment #2)

> > * Try to make a better separation between parameters and scripts,
> 

> Could you elaborate on this point?

This remark is not a showstopper for your port commit, and comes when I was trying to configure and start lego  :)

What I was saying is you can make a better separation between the variables
the user has to configure and the helper lego.sh. That way lego.sh can be moved to /usr/local/bin and a 
/usr/local/etc/lego/config with all the variables can be source.

( BTW the %%WWWWDIR%% should be configurable)



> I seem to be doing the same thing that both security/dehydrated and security/acme-client (which I based this port off of) are doing. I have weekly_lego_renewscript and weekly_lego_deployscript parameters. The only other parameter is weekly_lego_enable.
> 

No objection.

> Also, security/dehydrated and security/acme-client have their renew and deploy scripts in ${PREFIX}etc/, which is why I put them there. If it's appropriate to have example files and user-editable scripts in ${PREFIX}share/, I'm happy to move them there, but I just want to make sure that's the right thing to do

Again no objection.

> 
> Happy to improve the pkg-message.in. The upstream maintainer is also working to improve the first run experience, so I was holding off on building up too much tooling around that. However, I agree that a good first run experience is important.

Agree, specially when you have more than one tool available for the same usage. users tend to try them one by one and discard when configuration is actually a headache.


Feel free to resubmit a new diff/tgz anytime, and of course you can ask as many question as you want.

Cheers
-- rodrigo
Comment 4 Matthew Horan 2019-06-17 00:03:25 UTC
Created attachment 205153 [details]
security/lego port patch v2

v2 patch for security/lego.

Addresses feedback about first run experience. lego.sh can now be run with an argument, run, which will set everything up. pkg-message contains additional documentation.

Fixed UIDs.
Added runtime dependency on security/ca_root_nss.
Make WWWDIR configurable.
Use ETCDIR and WWWDIR consistently.
Fix lego.sh permissions.
Set GO_BUILDFLAGS so lego version works.
Bump to lego version 2.6.0.
Comment 5 Matthew Horan 2019-06-22 12:29:54 UTC
Created attachment 205281 [details]
security/lego port patch v3

Fix permissions on lego.sh.
Comment 6 Rodrigo Osorio freebsd_committer 2019-07-23 15:52:06 UTC
Dear Matthew,

Thank for the re-submission, except from a minor fix* the patch looks fine, I just gonna perform a few more test in the next days then commit it.
Sorry for this late response but I was a little busy the last weeks.

Cheers
-- rodrigo

* space vs tab Makefile issue, see portlint output.
Comment 7 Matthew Horan 2019-07-23 22:59:51 UTC
Created attachment 206022 [details]
security/lego port patch v4

> Sorry for this late response but I was a little busy the last weeks.
No worries! I have been busy as well.

> * space vs tab Makefile issue, see portlint output.
Whoops, I was unaware of the -A flag, which I'll use from now on.

I've attached a new patch which bumps lego to 2.7.1, released yesterday.
Comment 8 commit-hook freebsd_committer 2019-07-24 07:50:26 UTC
A commit references this bug:

Author: rodrigo
Date: Wed Jul 24 07:50:17 UTC 2019
New revision: 507266
URL: https://svnweb.freebsd.org/changeset/ports/507266

Log:
  Add new port security/lego

  Lego is a new let's encrypt client write in Go with
  support for number of ACME challenges and no external
  dependencies.

  PR:		237349
  Submitted by:	Matthew Horan <matt@matthoran.com>

Changes:
  head/GIDs
  head/UIDs
  head/security/Makefile
  head/security/lego/
  head/security/lego/Makefile
  head/security/lego/distinfo
  head/security/lego/files/
  head/security/lego/files/604.lego.in
  head/security/lego/files/deploy.sh.sample.in
  head/security/lego/files/lego.sh.sample.in
  head/security/lego/files/pkg-message.in
  head/security/lego/pkg-descr
  head/security/lego/pkg-plist
Comment 9 Rodrigo Osorio freebsd_committer 2019-07-24 07:51:19 UTC
Commited with minor changes, thanks
Comment 10 Matthew Horan 2019-07-24 11:44:47 UTC
(In reply to Rodrigo Osorio from comment #9)
Fantastic, thank you! Shall I submit a new diff for the 2.7.1 bump or can you use the one attached?

Thanks again.
Comment 11 Rodrigo Osorio freebsd_committer 2019-07-24 14:51:12 UTC
(In reply to Matthew Horan from comment #10)

Sure but the new diff should be based on the current version of the port.