Clément Lassieur writes: > Marius Bakke writes: > >> Clément Lassieur writes: >> >>> * doc/guix.texi (Certificate Services): Add email field. >>> * gnu/services/certbot.scm (, certbot-command, >>> certbot-activation, certbot-nginx-server-configurations): Add email field. >>> (certbot-command): Add '-n' and '--agree-tos' options. >>> (certbot-service-type): Remove default-value. >> >> Since this effectively hides the ToS from the user, I think we should >> update documentation to link to it. Something along the lines of >> "By using this service, you agree to the Terms and Conditions laid out >> in URL...". >> >> I'm not a user of certbot currently and thus haven't tested it, but the >> other patches LGTM to me. Thanks a lot for working on this! > > Thank you very much for the review, Marius, I'll update the > documentation as you said. > > I won't push right now because I'm unconvinced by certbot-activation: > - it runs at every reconfigure, whereas I want it to run only when the > configuration changes > - it runs at system startup (with no internet access, I think) which I > obviously don't want > - it requires internet access I haven't studied the code, but perhaps certbot-activation could be made a "proper" Shepherd service (e.g. simple-service)? That way it can have a dependency on networking, at least. It also would not run on every reconfigure. > Assuming there is no way to get it to run only on reconfigure when the > configuration has changed, I could make a command that the user would > use manually (wich profile-service-type). They would use this command > if they add new certificates and if they don't want to wait for the cron > task to happen. WDYT? This sounds great, but don't know if it should block this series. Perhaps you can push it to a 'wip-certbot' branch on Savannah for easier access and testing? Also, hopefully some of our newfound Shepherd experts can chime in on this thread :)