Bug#812174: ITP: letsencrypt-sh -- ACME client implemented in Bash
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:
> (...)
>
> I think your apache snippet is cool, actually.
> I improved it a bit the thing, by moving it to be a config snippet,
> instead of being treated as a virtualhost, and by using dh_apache2
> instead of manually try (and fail, e.g. you forgot to remove the thing
> when removing the package) to get it right :)
>
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.
>> (...)
> > Let me know if you think we can base our work on what I've done so far,
> > or if we instead should make a fresh start.
>
> See this:
> https://anonscm.debian.org/git/letsencrypt/letsencrypt.sh.git/
> I updatd it to the released version. I kind of changed a bit the git
> repository layout (using debian/master instead of debian/experimental,
> and using master (following the upstream one) instead of
> upstream/experimental. README.source is not really the thing I followed
> to import the new source, but as I did a lot of stuff while updating the
> thing I think we'll need the next release to see what we actually need
> to do to import a new upstream (also, I'm not really a gbp master, I
> committed the pristine-tar info manually with `pristine-tar commit...`)
>
Great this is will be maintained within Debian's letsencrypt-devel. I
just closed the old packaging repository on GitHub in favor of the new
one at anonscm.d.o.
I'm fine with the changed repository layout, meaning the primary
packaging work will be done in debian/master. I updated d/gbp.conf
accordingly, as well as README.source. As already mentioned in private
to you, I implemented 'When upstream uses Git/No upstream tarballs' [1]
here.
>From my understanding we do not need to track upstream changes in a
branch at all, since gbp defaults to '--git-upstream-tree=TAG'. Thus we
most likely can drop the branch 'upstream/master' from the Debian
packaging repo - hence I'm not 100% sure about that.
[1] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM.GIT.NOTARBALL
> I did a buch of other changes, that you may agree or not, please have a
> look and comment on them; I'm quite open, if you don't like some commits
> I can happily accept to see them reverted (some/most of them, some other
> I definitely want to see them keep)
>
I'm fine with them ;)
> You should have commit access on it, so feel free to just push stuff and
> at most we can discuss it later.
>
I've pushed some commits to debian/master, you might want to have a look
at them.
> 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.
> Something I need help/suggestion for: I quite dislike the name
> letsencrypt.sh-challenge-response-apache2, I find it way too long :\
> Can we think of something more nice? :)
>
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.
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
- Add ngnix support (similar to the apache2 one)
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.
Greetings
Daniel
Reply to: