Bug 237349
| Summary: | New port: security/lego Let's Encrypt client written in Go | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Matthew Horan <matt> | ||||||||||
| Component: | Individual Port(s) | Assignee: | Rodrigo Osorio <rodrigo> | ||||||||||
| Status: | Closed FIXED | ||||||||||||
| Severity: | Affects Some People | CC: | rodrigo | ||||||||||
| Priority: | --- | ||||||||||||
| Version: | Latest | ||||||||||||
| Hardware: | Any | ||||||||||||
| OS: | Any | ||||||||||||
| Attachments: |
|
||||||||||||
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.
(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. (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 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.
Created attachment 205281 [details]
security/lego port patch v3
Fix permissions on lego.sh.
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. 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. 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 Commited with minor changes, thanks (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. (In reply to Matthew Horan from comment #10) Sure but the new diff should be based on the current version of the port. |
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.