[Letsencrypt-devel] Bug#824928: letsencrypt.sh: move the default position of the domains file to /etc/letsencrypt.sh/

Mattia Rizzolo mattia at debian.org
Thu Jun 2 11:14:37 UTC 2016


On Sat, May 21, 2016 at 06:07:34PM +0000, Mattia Rizzolo wrote:
> On Sat, May 21, 2016 at 07:14:05PM +0200, Daniel Beyer wrote:
> > I opened a PR for upstream [1], based on the initial work you gave me.
> > It might take a bit till upstream reacts to it, but I think chances are
> > good it will be accepted.
> > [1] https://github.com/lukas2511/letsencrypt.sh/pull/204
> 
> Great thanks!
> 
> > I started working on updating our packaging in a new branch
> > wip/dabe/domains.txt-in-etc.

In the meantime a new release happened, and our patch has been merged
the commit right after the release one, useful.

Anyway, I imported the new upstream release, and pulled your changes in
debian/master.

> > But I have the feeling, that mentioning the
> > change in d/NEWS is not enough.
> 
> I'd also keep in mind that this package is very young while considering
> this.
> 
> > So i came up with the following idea (not implemented, yet):
> > During upgrade we check if a /var/lib/letsencrypt.sh/domains.txt exists
> > and if so add an extra config file in /etc/letsencrypt.sh/conf.d/ to
> > automatically reconfigure letsencrypt.sh back to the old location. With
> > this we would not break things for our existing users.
> > Do you have an other idea or opinion how to deal with this?
> 
> That's a nice idea, even if I usually try to avoid having to deal with
> maintainer scripts.
> Anyway doing this also requires:
> * checking that /etc/letsencrypt.sh/config.sh actually has DOMAINS_TXT
>   set to the new location (if the user modified it, dpkg won't overwrite
>   it with our new copy with our new conf)
> * also adding a prerm to remove that file in case of purge
> 
> 
> Also, I'd like to not keep that thing forever, e.g. drop this
> transitional measure before stretch: I'm usually happier if my packages
> don't have maintainer scripts.

Are you willing to do this?
I'm now running current debian/master, after having moved files around.

With 0.2.0 there is also another incompatible change: the PRIVATE_KEY =>
ACCOUNT_KEY rename which actually bit me even if I was aware of it; do
we want to provide a backward compatible thing and carry on some kind of
deprecation procedure (like: using something like
ACCOUNT_KEY=${ACCOUNT_KEY:-${PRIVATE_KEY}} somewhere and keeping it for
a while)

> > An other question is whether or not we should start shipping
> > a /etc/letsencrypt.sh/domains.txt. I would prefer to do that, with a
> > small header (lines containing '#' are ignored) outlining the purpose
> > and the format of this domains.txt file. What do you think?
> 
> Yes :)
> Also notice the relative file in the new docs/ directory in the upstream
> repo (I'd like to ship all that documentation when a new release will
> happen).

In the new package there is a
/usr/share/doc/letsencrypt.sh/docs/domains_txt.md which imho contains
everything needed.

And if we provide an empty domains.txt, we should also first patch the
script to return a useful message instead of saying nothing and just
exit 0.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/letsencrypt-devel/attachments/20160602/f9c8ec40/attachment.sig>


More information about the Letsencrypt-devel mailing list