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

[Daniel Beyer]

On Sat, 2016-05-21 at 12:33 +0000, Mattia Rizzolo wrote:
> Package: letsencrypt.sh
> Version: 0.1.0-2
> Severity: wishlist
> 
> As I wrote in #822493#45:
> 
> > +Providing a list of domains to letsencrypt.sh
> > +=============================================
> > +If the parameter --domains is not given to letsencrypt.sh, it tries to
> > get
> > +a list of domains from the file /var/lib/letsencrypt.sh/domains.txt.
> > 
> > I've never noticed this (as I use -d in my own script), but imho we
> > should put that file by default in /etc/letsencrypt.sh/domains.txt.
> > Really /var should not be the place for things like this, whilst is
> > totally fine for files like certs.
> > What do you think?

I agree with you: It should be /etc/letsencrypt.sh/domains.txt, as I
suspect this would be the place users would look for it. And it actually
is more like a configuration than a dataset.


> > 
> > IMHO the best way to accomplish this is to introduce a new conf entry
> > pointing just to the domains file, and defaulting to
> > "${BASEDIR}/domains.txt.  Just looking at the code and without trying
> > seems like ${DOMAINS_TXT} does that; if that's the case it just need
> > documenting in the example file.  This should be done upstream, of
> > course, and I couldn't figure why he wouldn't like it.
>
> Daniel: what are your thoughts on this?

It looks like ${DOMAINS_TXT} can not be set or overridden in config.sh.
But it should be rather easy to add this feature to letsencrypt.sh. I'll
work on a patch and propose it upstream. In past upstream was very nice
with accepting improvements to letsencrypt.sh. I'll let you know about
the progress of this.

Greetings
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/letsencrypt-devel/attachments/20160521/c83c7779/attachment.sig>