Acme-dns on Nethserver (now with RPM-y goodness!)

Please see the new home of these instructions in the wiki.

4 Likes

On this point–it doesn’t look like it is working as it should, and I think the problem is the disagreement between the name of the service in systemd and the config database keys I’m using. The systemd service is called acme-dns, since that’s what the software is called. But hyphens aren’t valid characters in Perl variable names, so if I try to retrieve a config property of $acme-dns{foo} in a template, Perl complains. As a result, I’m using database keys of acmedns and acmednsapi, and the templates work fine with those.

So I’m probably missing something that’s already there, but I need to have the acme-dns systemd service enabled (and started) when $acmedns{status} = enabled.

${'acme-dns'}{'status'} eq 'enabled'
1 Like

Is it that simple? Wow. Well, that should be easy to fix, anyway.

1 Like

Tip

grep -srni 'acme\-dns' /etc/e-smith/templates

This should give back what you missed, grep is the better tools I know for a padawan developer, at least it helped me so much.

Install a nethserver with all modules and you will have an ultimate bank of example

3 Likes

That was it indeed. Fantastic. I’m sure it would benefit me to embark on a systematic study of Perl, but it just seems like that would take a lot of time. Though maybe not as much as trying random things I saw in a template somewhere…

1 Like

test, break, try, this is what I do most of time :stuck_out_tongue:

when you want to code something, try to figure what you could search, var name is a good start.

That got me to the point of knowing that hyphens weren’t legal in Perl variable names, but not to the point of knowing what to do about it–at least yet. Probably would have found something eventually, but you beat me to it.

I still think this is something Neth should consider providing themselves, perhaps as a subscription benefit–it would avoid the issue of access to port 80, as well as enable wildcard certificates, about as simply as possible for the users. The only thing the users would need to do is set up the CNAME records with their DNS host, once for each (sub)domain. The only thing that would need to be packaged with Neth itself is the hook script.

1 Like

Running into another issue, and I think this is due to how my config database keys are set up. In short, when installing software (including updates) through the software center, I get a red error message at the top of the screen indicating a problem with acme-dns. The problem appears to only be cosmetic–the software installs and runs without issues–but “big red warning banner” is a significant cosmetic issue. Looking in the log, I see

Jul  4 07:06:31 neth esmith::event[21173]: Failed to start acme-dns-api.service: Unit not found.

I use two config database keys, acme-dns and acme-dns-api. The main reason I do this is because the firewall settings will (or at least can) be different between the two–acme-dns itself must be accessible on the red interface (it must answer DNS queries from the outside world), while the API doesn’t need to be. However, there’s only one systemd service, and that’s acme-dns. Here’s how those keys are configured by default:

[root@neth ~]# config show acme-dns
acme-dns=service
    Debug=disabled
    TCPPort=53
    UDPPort=53
    access=red
    status=enabled
[root@neth ~]# config show acme-dns-api
acme-dns-api=service
    FullchainPath=/etc/letsencrypt/live/acme.familybrown.org/fullchain.pem
    KeyPath=/etc/letsencrypt/live/acme.familybrown.org/privkey.pem
    TCPPort=8675
    UseTLS=enabled
    access=red,green
    status=enabled

(OK, mostly by default–the fullchain, key, and UseTLS enabled aren’t there by default). How do I need to change this to avoid these errors?

You may try to change the acme-dns-api to a network service instead of a service:

http://docs.nethserver.org/projects/nethserver-devel/en/v7/services.html#add-a-new-service
http://docs.nethserver.org/projects/nethserver-devel/en/v7/services.html#add-a-new-network-service

I’d thought about that, but had somehow gotten the idea that the fw_ keys were only appropriate when all you were doing was setting the firewall (the fw_ prefix probably helped me reach that conclusion). If that’s not the case, that sounds like the easy answer.

The fw_ prefix is not mandatory, it’s just there to have an optical difference between NS controlled services and “firewall only” services.

I tested the acme-dns module and it works. :+1: I followed the instructions from the wiki.

Again I had to use another domain than my servers domain name so I edited /etc/e-smith/templates/etc/acme-dns/config.cfg/10general and did config setprop acme-dns Domain mydomain.com:

my $dmn = ${'acme-dns'}{'Domain'} || $DomainName;

my $domain = "acme.".$dmn;
my $nsname = "ns1.acme.".$dmn;
my $nsadmin = "admin.".$dmn;
my $domaindot = "acme.".$dmn.".";
my $nsnamedot = "ns1.acme.".$dmn.".";
my $ns2namedot = "ns2.acme.".$dmn.".";

HTTP worked without an error, I changed to HTTPS and after executing following command the cert is renewed but I got an error (I added the -v switch to get more output).

certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges --post-hook "/sbin/e-smith/signal-event certificate-update" -d mydomain.com -v

Error:

Hook command "/etc/letsencrypt/acme-dns-auth.py" returned error code 1
Error output from acme-dns-auth.py:
Traceback (most recent call last):
  File "/etc/letsencrypt/acme-dns-auth.py", line 154, in <module>
    client.update_txt_record(account, VALIDATION_TOKEN)
  File "/etc/letsencrypt/acme-dns-auth.py", line 65, in update_txt_record
    data=json.dumps(update))
  File "/usr/lib/python2.7/site-packages/requests/api.py", line 108, in post
    return request('post', url, data=data, json=json, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/api.py", line 50, in request
    response = session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 464, in req                                                                                                                                                                                               uest
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 576, in sen                                                                                                                                                                                               d
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 431, in sen                                                                                                                                                                                               d
    raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: UNKNOWN_PROTOCOL] unknown protocol (_ssl.c:5                                                                                                                                                                                               79)

It worked so maybe the error could be ignored?

2 Likes

…and in this case that’s completely fine; you can use any domain you want for this as long as you can control its DNS records. That seems like a worthwhile patch; I’ll try to incorporate that in the nethserver-acme-dns RPM.

Edit: Updated, should be in the repo in a few minutes.

This I haven’t seen before. For now (since it did work for you), I’d say keep an eye on it and see if it recurs.

3 Likes

Maybe I was too impatient but:

Package nethserver-acme-dns-0.0.1-7.ns7.noarch.rpm is not signed

Oops. Should be fixed now.

1 Like

Thanks. Working as expected! :clap:

hello @danb35 after postponing deploying acme dns for ages, i finally got around to deploying this fantastic tool.

I guess at the time i was not expereinced enough to understand it.

Now after deploying and testing, everything works great, but when i run this final command
curl -s -X POST https://acme.example.com:8675/register | python -m json.tool
i get this error

[root@monit ~]# curl -s -X POST https://acme.example.com:8675/register | python -m json.tool
No JSON object could be decoded

what could i be doing wrong, or where does the error come from

when running
curl -X POST https://acme.example.com:8675/register | python -m json.tool

the error i get is

[root@monit ~]# curl -X POST https://acme.example.com:8675/register |python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: acme.example.com; Unknown error
No JSON object could be decoded
[root@monit ~]# curl -X POST https://acme.example.com:8675/register | python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: acme.example.com; Unknown error
No JSON object could be decoded

I assume you’re using your actual domain rather than example.com? What do you get if you don’t pipe the output to python? IOW, what’s the output of curl -s -X POST https://acme.example.com:8675/register?

no error

EDIT: i had used get.

there is an error:

curl: (6) Could not resolve host: acme.example.com; Unknown error