No that didn’t work but I think it has something to do with the domains being different…the new subdomains, do I need to define them separately from the first I was using…with separate root paths?
Figured out my brackets which I think were causing the issue but now my domain lookups aren’t working when they were yesterday! Hmmpph!
mediacenterserver:caddy mediacenter$ sudo caddy Activating privacy features... 2019/04/04 09:20:14 [INFO] [sonarr.mainframe.rulinglife.com] acme: Obtaining bundled SAN certificate 2019/04/04 09:20:16 [INFO] [sonarr.mainframe.rulinglife.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/gGkfS4VJGExWQmLw1VFqXeszK0SLWmP5vnz2PwT5JkM 2019/04/04 09:20:16 [INFO] [sonarr.mainframe.rulinglife.com] acme: use tls-alpn-01 solver 2019/04/04 09:20:16 [INFO] [sonarr.mainframe.rulinglife.com] acme: Trying to solve TLS-ALPN-01 2019/04/04 09:20:22 [sonarr.mainframe.rulinglife.com] failed to obtain certificate: acme: Error -> One or more domains had a problem: [sonarr.mainframe.rulinglife.com] acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up A for sonarr.mainframe.rulinglife.com, url:
and I have this for my DNS settings still…
Got it! Google actually wanted *.mainframe and routing it to mainframe.ruling.life odd, but got it working…onward!
So I had things moving along, but can’t seem to get a tool called Tautulli working, I get a 502 bad gateway, do you have any experience with it? Here’s my current settings…
Sonarr however is working great from it’s HTTPS url
OK, so, you’re binding to
192.168.178.4 in the Tautulli interface, but you’re proxying to
192.168.178.5. Wrong host maybe?
Gosh, the simple things, kudos…another service working. This stuff is cooool.
I’m going to try and get caddy to launch on macOS startup this weekend.
Check this out if you haven’t already:
Thanks, I’ll give this a try!
Hmm getting a no such file after running the chown command…odd cause the folders do exists…
mediacenterserver:~ mediacenter$ sudo chown _www:_www -R /etc/caddy /etc/ssl/caddy /var/log/caddy
chown: -R: No such file or directory
and then understandably this error…
mediacenterserver:~ mediacenter$ sudo launchctl load -w /Library/LaunchDaemons/com.caddyserver.web.plist
/Library/LaunchDaemons/com.caddyserver.web.plist: Path had bad ownership/permissions
Can you explain to me a bit more what that chown command is doing?
chown -R changes the ownership of the folders and anything within, in this case to the
_www user and
It’s not strictly necessary to run Caddy. The
.plist actually specifies Caddy run as
root, so it shouldn’t care who owns those files. There was also an error in it… The
-R should come before the
user:group parameter. I just edited the guide to reflect that.
As for the
/Library/LaunchDaemons/com.caddyserver.web.plist: Path had bad ownership/permissions error… Can you check the ownership and permissions? (
ls -l /Library/LaunchDaemons/com.caddyserver.web.plist)
It should be
root:wheel with 644 permissions (
I re-ran the command with -R in front, and that was accepted.
The permisions are not root:wheel but staff 1143
~ mediacenter$ ls -l /Library/LaunchDaemons/com.caddyserver.web.plist
-rw-r–r--@ 1 mediacenter staff 1143 Apr 8 17:19 /Library/LaunchDaemons/com.caddyserver.web.plist
So I pushed through a ran a chown command to change permission and then for lack of knowledge a chmod command for the 644 which i wasn’t really sure made a difference but the lauchctl command ran successfully
Rebooted and success! Nice! Next weeks project will be getting homebridge working and it all worked over with SSL
I wonder if you used
sudo curl or instead just
curl by itself when downloading the
-rw-r–r--, so nothing would be different.
Here’s a great, concise explanation of how it works: https://ss64.com/bash/chmod.html
Basically, by setting the owner to
root and setting it to be writable by the owner, but not writable by group or world, you’ve made it so only
root can edit the
.plist. This is required for security reasons before macOS will let you load it, else someone might modify the
.plist file maliciously during startup to have macOS run bad code with root privileges.
Thanks once again for the great info and explanation, you’ve done me a service good sir, i imagine, or madame, who knows…no matter
Sorry to come back to this. It appears when I run this from the launch daemon i get this error.
2019/04/22 22:07:37 registration error: acme: error: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-acct :: urn:ietf:params:acme:error:rateLimited :: Error creating new account :: too many registrations for this IP: see https://letsencrypt.org/docs/rate-limits/, url:
But it doesn’t happen if I run it from terminal. Where should I look to troubleshoot this?
Looks like Caddy under
launchctl is trying to make a new account and being told that LetsEncrypt rate limited your IP address from creating any more accounts because you’ve registered too many already.
Pretty heavily implies that it’s not saving the ACME account data properly. Check
/etc/ssl/caddy for the
This was the fix, thanks for pointing me in the right direction…I ended up noticing the permissions got reset…I was doing some other work the other day and had to login as single user mode and repair permissions, I bet that did it.
Re-ran the other chown command as well with _www