Hi Mattia, On Tue, 2016-04-05 at 21:15 +0000, Mattia Rizzolo wrote: > On Tue, Mar 29, 2016 at 05:45:44PM +0200, Daniel Beyer wrote: > > Hi Mattia, > > > > Am Montag, den 28.03.2016, 21:44 +0000 schrieb Mattia Rizzolo: > > > Hi Daniel :) > > > > > > On Sun, Mar 27, 2016 at 01:01:18PM +0200, Daniel Beyer wrote: > > > (...) > > > > > > > The infrastructure I needed letsencrypt.sh for enables the proxy module > > in a virtualhost, rather doing it the debian-"mods-enabled"-way. That's > > why it was a virtualhost (it had to be loaded at the very end to work). > > But this is a rather uncommon setup and providing a config snippet is > > definitely the way to go here. Thanks for changing it and switching to > > dh_apache2. > > Umh, now, I haven't checked as atm I don't have anything handy to check > this, and I'm not and apache2 master, but it really ought to work > anyway; unless you explicitly allow it again it should really work. >
I had the impression the order matters (at least with Apache 2.2), but actually this special case is no longer around for me. Anyhow, using conf.d is the better approach. > On the bright side, I've made changes to my little deployment and now > I'm using the -apache2 package too. Great. > I've made some changes to it, I think the most "difficult" change is > commit 365c3380ccab44b611d7a3edd6a9c4d6cf8ccabe please tell me what you > think of that. I wrote my reasons in the commit msg, but tell me :) > It looks reasonable to demote it to Recommends. The original (ProxyPass|Alias)Match in debian/letsencrypt.sh.conf might have been a bit paranoid. My intention was to make sure one really can load only the challenge responses. But I think dropping the *Match should not be a security issue at all. The rest of your changes are fine, thanks. > > > I've already installed the resulting .deb on one of my servers, but I > > > have to admit that I already have some infrastructure around LE, so I > > > won't use the packaged configuration, nor the apache snippet by myself > > > (at least not yet). > > > > > > > I have quite some infrastructure that I would like to use it for. I > > check if I can migrate one candidate to fully make use of the packaging > > later this week. > > How did it went? It works for me. > > > > (...) > > > > Yeah, you're right - pretty unhandy. I renamed it to simply > > letsencrypt.sh-apache2 in debian/master - but feel free to propose an > > other name. > > that name's cool for me! :) > Great. > > I would like to see the following features added to the packaging: > > - Ship some automatism, so the renews do not need to be done manually > > I don't know. I've yet to enable automatic renewals. Given that I'm > still doing stuff and playing with it I run so often anyway. > > Also, automatic renewals implies cron: that means deciding how often you > want to do that. And considering that letsencrypt.sh does not have a > silent mode really useful for cron (I wouldn't want to be "constantly" > emailed just to know that nothing has been done). > > And also means we need to install a letsencrypt.sh user or something to > run it with, and then IMHO it'll become a really complicated package for > a shell scrip... > Yes, it increases the complexity of the package. Let's not do this in the initial version, but keep it in mind for sometime in future. > > - Add ngnix support (similar to the apache2 one) > > I'm not a ngnix person, I wouldn't know how to do it. > What about leaving it for somebody else to supply a patch? > Agreed. > > Besides that, it would be wise to deny execution by user root per > > default, but this should better be implemented upstream. I'll try to > > work on this later this week - or more likely on the weekend. > > Yes, this should be done upstream. > > What do think is it needed after all of this? > I'm not sure we really need an '--allow-root'-switch. I think I draft an PR on upstream's GitHub repository and let them decide on this. I'll try to get this done as soon as possible. I think the version we now have is good for an initial release. If you agree, feel free to upload it to unstable. Greetings Daniel
signature.asc
Description: This is a digitally signed message part
