[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