Forum

I am building an Arch package specific to letsencrypt as there is not much traction to integrate it properly in the hiawatha official package https://bugs.archlinux.org/task/58343
my questions:
1- What is the best url for the latest version? should I take it within the latest Hiawatha source or independently from GitLab or another source?
2- The latest version is called v2.0 but there are some revisions of this v2.0 it seems, should I call it the version of the latest Hiawatha instead i.e. 10.8.3?

Thanks

3- Discussing with some Arch Trusted Users, 'letsencrypt' and '/etc/letsencrypt' are too generic and I will opt for 'hiawatha-letsencrypt' directory and naming as much as possible. Is it possible to also look in '/etc/hiawatha-letsencrypt' for the config or should I patch the script in the packaging (definitely not the best solution) or do you have a better option?

thanks again!

1: Best take the version that comes with Hiawatha. That one will work with the Hiawatha version it is shipped with.
2: Go with the one that comes with 10.8.3. That's the latest. I'll update the separate 2.0 package. It's just minor changes.
3: I prefer you patch the script according to your needs.

Thanks for your answers, to make sure the package update works efficiently: if there is a let say 10.8.4 version of Hiawatha released should the letsencrypt package update considering it’s a new version or should it wait for a let say 2.1 version of letsencrypt (by monitoring the letsencrypt page on this site for example)?
I understand currently it is rather the former (each time Hiawatha is updated I have to consider this is potentially a new letsencrypt version) but want to confirm with you this is the right way going forward.
Thanks !

By reading more carefully your answer to point 1. I think it answers to my latest question and I should adopt the Hiawatha versioning for letsencrypt. I will go this way, let me know otherwise.
I will send you the package link and update the Arch wiki page in the coming days.
Thanks again for this light, fast and secure web server you offer to the community

Just my wish list, to ease the packaging and system integration in Arch, would be:

a) To have letsencrypt follow its own version cycle (2.x) and have at https://www.hiawatha-webserver.org/files/letsencrypt-2.x.tar.gz the version compatible with the latest Hiawatha release, and not anymore in the Hiawatha tarball to avoid version consistency checks.

b) To also look for configuration in /etc/hiawatha-letsencrypt and ~/.config/hiawatha-letsencrypt to avoid clashing with other letsencrypt tools that could use /etc/letsencrypt.

Of course pickup what you agree with, I have adapted the packaging according to your comments above at the moment.

See the package here: https://aur.archlinux.org/packages/hiawatha-letsencrypt/
I have adopted the letsencrypt versioning (2.0) to make the distinction with Hiawatha and avoid systematic update even if the script does not change between 2 Hiawatha versions. However at the moment I download it from the Hiawatha tarball to get the latest version.
This is a bit circumvoluted but the best I could figure out. I will switch to the letsencrypt tarball once updated.

The best thing to do is to not see Hiawatha's Let's Encrypt as a separate script. See it as part of the Hiawatha software. I will make sure that that script will work with the Hiawatha version it is shipped with. So, don't make it a separate package. Include it in the Hiawatha package. There is no point in installing the Hiawatha Let's Encrypt package and not installing Hiawatha, as that script will only work with Hiawatha.

I will consider installing it via the source package CMake install script. That will make it easier for packagers to include it in the package.

Unfortunately we have not managed, with the maintainer of the Hiawatha package, to agree on a proper integration of letsencrypt: he last reacted in August with a negative remark about the php implementation of the script and hasn't responded since then to several messages. The tarball currently provided in the Hiawatha package requires manual installation while the package hiawatha-letsencrypt I have built is functional. hiawatha-letsencrypt package has dependency towards Hiawatha which ensures it is also present.

At the moment what I will do then is to adopt the Hiawatha version cycle (instead of the 2.0 I am using) and update it every time there's a new Hiawatha version.

If the installation is eased via the CMake script, I will need to see how this is adopted in the official package in the context I mentioned above.
I will also seek other Arch Trusted Users advice, the initial reaction was to recommend upstream a renaming to something less generic than letsencrypt to avoid confusion with other tools and integration of letsencrypt under a hiawatha directory structure /usr/share/hiawatha.

I have done the changes you can see here https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=hiawatha-letsencrypt
I've added a version watch of https://www.hiawatha-webserver.org/latest and now use the Hiawatha version for the letsencrypt script.
The package is available in https://aur.archlinux.org/packages/hiawatha-letsencrypt/
Not great but that should work until the official maintainer changes his mind about letsencrypt or that you enhance the CMake.
Thanks

I suppose the topic can be closed

- I will watch if there is future change in the hiawatha CMake
- and let you see if you want to reference the letsencrypt Arch package in your unsupported package list (https://aur.archlinux.org/packages/hiawatha-letsencrypt/)

Thanks for the best webserver around and your support for the last 15 years!