Bug 1438181

Looking at the RPM content, this would be my suggestion for the packages (Some paths could, of course, differ):

acme-tiny:
/usr/sbin/acme-tiny
/usr/sbin/acme_tiny
/usr/share/doc/acme-tiny-0.1
/usr/share/doc/acme-tiny-0.1/README.md
/usr/share/licenses/acme-tiny-0.1
/usr/share/licenses/acme-tiny-0.1/LICENSE

acme-tiny-wrapper:
/usr/lib/systemd/system/acme-tiny.service
/usr/lib/systemd/system/acme-tiny.timer
/usr/libexec/acme-tiny
/usr/libexec/acme-tiny/sign
/usr/sbin/acme-tiny-sign
/usr/sbin/cert-check
/usr/share/doc/acme-tiny-0.1/README-fedora.md
/var/lib/acme
/var/lib/acme/certs
/var/lib/acme/csr
/var/lib/acme/lets-encrypt-x3-cross-signed.pem
/var/lib/acme/private
/var/www/challenges

acme-tiny-wrapper-httpd:
/etc/httpd/conf.d/acme.conf

Moving the top level to an option subpackage would break dozens of systems that I run.  In my case, I would just need to go around and install acme-tiny-wrapper on dozen or so systems.  But what if someone else was actually using the package?  There is not an mechanism that I know of to provide a heads up to admins with an incompatible change.

What if we move acme-tiny.py proper to an acme-tiny-core subpackage?  That would facilitate other wrappers like you need - but wouldn't match debian naming.

BTW, the version of acme-tiny.py that I ship includes the certificate chain via the ACME protocol.  Upstream hasn't accepted the patch - but then they haven't done anything for a long time.  

The wrapper does not assume apache.  The only apache specific config is the /etc/httpd/conf.d/acme.conf drop-in - which causes no issues if not using apache.   Many other package include drop-in convenience configs that are unused if you don't have the relevant package installed.  

You don't even have to run *any* web server on the same machine as acme-tiny.  As the README points out, you just have to arrange for a web server somewhere to serve the files written to the magic directory.  The only thing the acme-tiny timer/cron script does is sign and renew the certs.  All the other configuration is left to the admin.

Hi Stuart,
sorry, I missed that you patched acme-tiny. I only found this:

 usr/libexec/acme-tiny/sign
 37   # append intermediate certs
 38   #cat *.pem >>"$crt"

which hinted at it not containing the intermediate cert and that package telling that it is git commit 5a7b4e7 (which I find a bit confusing since it's actually not that commit but a modified version of it).


About the sub-package, while I still find it confusing that a package named acme-tiny does not contain the actual project but (to a large part) something else. I get your point in possibly creating problems and agree that an acme-tiny-core package would probably be the best way forward. At least for current versions. That should ensure a painless upgrade process while allowing to install acme-tiny only.


About the apache httpd, the wrapper does not assume apache, but the package more or less does ;) The documentation could be much shorter if all the httpd stuff is being dropped which would emphasize the important bits (where to put requests, which dir to serve and where do certificates end up). And I think that not cluttering the system with unnecessary stuff is a good way to go. As an example for a package with separated httpd configuration, I could name nextcloud-httpd.

Please do not get me wrong, I am not saying that what you are doing is harmful. Most users will probably not care. But I do not think it is a good practice. In the same manner, you could include a configuration for nginx, lighttpd, a stand-alone web server, … and while it will not directly break anything, we will throw tons of unnecessary stuff into the system. I hope, you get my point.

In the end, the beauty of acme-tiny vs the we-do-everything solutions out there is that it does exactly the acme part and nothing more. That is, what makes it harder to use, but also what it makes it more flexible. It would be great for the package to reflect that.


In any case: Thanks for taking up the job of packaging it. I think it's a good addition to Fedora.

I agree the acme.conf is breaking my own rule, but I appreciate it when a Fedora package (other than a *-lib) does *something* visible and useful out of the box without nothing more than enabling something.  That is the motivation for including the (very minimal) timer/cron machinery needed to sign and keep certificates renewed. Having the acme-tiny-core package is in keeping the expectation that like other *-core packages it won't do anything out of the box.  Sometimes these are called *-common as well.

What tempted me to include acme.conf as well is that you do have to have a web server mapping the token dir.  Including some example web server configs in an example directory might be better.  Can you supply a nginx config?  (I like thttpd, but the package has been dropped, and I've been building it myself.  It's on my todo list to offer the package again.)

I like the idea of having acme-tiny-httpd, acme-tiny-nginx, etc.  I wonder if we can move acme.conf without breaking existing installations.  It is marked config(noreplace), so there is a good chance.  I think the replacement should just have a comment that says something to the effect "Moved to acme-tiny-httpd." A later release can remove altogether.  

acme.conf breaks my own rule in that it actually *could* conflict with a custom config affecting the same Location.  (But highly unlikely.)

Sorry for the late reply. I had to check how a default nginx config looks like and works since I usually have them replaced automatically. Going with the default, it's actually very easy to extend. This should already do the trick for acme-tiny-nginx:

% cat /etc/nginx/default.d/acme-tiny.conf
  # Deliver ACME challanges for Let's Encrypt
  location /.well-known/acme-challenge {
      alias /var/www/challenges;
      add_header Content-Type application/jose+json;
  }

The add_header is not really required but I think it's nice to actually deliver the correct content type.

This file is then included in the default configuration and will become part of the default vhost configuration shipped with Fedora/EPEL.

Do you think acme-tiny-nginx and acme-tiny-httpd should require nginx, httpd respectively?  I'm thinking probably not.

I would probably add a “Requires” since the files do not make much sense without the web servers. If you want to avoid “Requires”, you could use weak dependencies instead and use “Recommends” or “Suggests” instead. Again, I would prefer stronger dependencies but I will not complain about weak ones ;-)

Hi Stuart,
any updates on this or anything I can help you with?

acme-tiny-4.0.4-1 released on rawhide creates an acme-tiny-core subpackage with just:

$ rpm -ql acme-tiny-core
/usr/sbin/acme_tiny
/usr/share/doc/acme-tiny-core-4.0.4
/usr/share/doc/acme-tiny-core-4.0.4/README.md
/usr/share/licenses/acme-tiny-core-4.0.4
/usr/share/licenses/acme-tiny-core-4.0.4/LICENSE

I am holding off on modularizing the httpd support, as this change was pretty simple and needs to get out.  Hopefully, nothing breaks.

I've tested on 2 epel7 production systems, and will put a release in epel7-testing.

acme-tiny-4.0.4-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-65660d9490

acme-tiny-4.0.4-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0eee178912

acme-tiny-4.0.4-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-295464ca66

acme-tiny-4.0.4-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-0eee178912

acme-tiny-4.0.4-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-65660d9490

acme-tiny-4.0.4-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-295464ca66

(In reply to Lars Kiesow from comment #10)
> Hi Stuart,
> any updates on this or anything I can help you with?

Please test the new release!

acme-tiny-4.0.4-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

acme-tiny-4.0.4-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

acme-tiny-4.0.4-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.