Menu
vinitjain75
By:
vinitjain75

Caddy not re-starting after changes in the Caddyfile

May 20, 2017 262 views
Let's Encrypt Miscellaneous Nginx Apache Security CentOS

Caddy Service is working fine when the Caddyfile is empty

The moment we update the Caddyfile with my domain and email address, caddy.service
sudo systemctl restart caddy fails

We have tried reset-failed and start combination and everything

/etc/caddy/Caddyfile

portexcel.com {
root /home/admin/web/portexcel.com/public_html
gzip
tls nc@tharlines.com
}

https://portexcel.com is not working

The moment we empty the Caddyfile, the caddy.service is Active, Enabled and working fine

This is where our files are and we have given access to caddy appropriately
/home/admin/web/portexcel.com/public_html

We have followed the steps from here
https://www.digitalocean.com/community/tutorials/how-to-host-a-website-with-caddy-on-centos-7

Only change is our root dir is different then what is given in the instructions

Please help!

Log In to Comment
8 Answers
thedude May 20, 2017

I'm wondering if https://www.digitalocean.com/community/questions/letsecrypt-failure is relevant. Did you try removing tls to see if Caddy works?

You can also use systemctl status caddy.service -l to see if there are some useful logs.

Reply
vinitjain75 May 20, 2017

Thanks for the response!

lets encrypt is now up and running

I tried removing one by one
1) tls
2) gzip
3) empty file

caddy is working perfectly fine only when the Caddyfile is empty

I am still not sure what is wrong in this configuration

portexcel.com {
root /home/admin/web/portexcel.com/public_html
gzip
tls nc@tharlines.com
}

Reply
vinitjain75 May 20, 2017

When I am using command line like
caddy -host portexcel.com

I am getting this error
2017/05/20 16:26:16 failed to get certificate: [portexcel.com] error presenting token: Could not start HTTP server for challenge -> listen tcp :80: bind: address already in use

How to fix this?

BTW my httpd is consuming too much of memory like 70% of 1GB RAM

Reply
vinitjain75 May 20, 2017

None of these are working

portexcel.com{

bind 139.58.69.238
proxy / [::1]:8081 { transparent }
tls
{ max_certs 100 }
}

OR

portexcel.com{

bind 139.58.69.238
proxy / [::1]:8081 { transparent }
}

OR

portexcel.com{

bind 139.58.69.238
proxy / [::1]:8080 { transparent }
tls
{ max_certs 100 }
}

OR

portexcel.com{

bind 139.58.69.238
proxy / [::1]:8080 { transparent }
}

Reply
jtittle1 May 21, 2017

@vinitjain75

I rand through the guide on a test 512MB Droplet to see if I could reproduce the issue and I didn't run in to any issues when using the defaults from the guide.

I then created a test directory much like yours:

/home/domain.com/htdocs/public

Opened up Caddyfile and made the changes:

domain.com {
    gzip
    root /home/domain.com/htdocs/public

    tls me@domain.com
}

Restarted caddy using:

systemctl restart caddy

It then failed and the reason it does is because of the service file configuration -- specifically this line:

ProtectHome=true

Above that line, you'll see:

; Hide /home, /root, and /run/user. Nobody will steal your SSH-keys.

What this does is hides /home -- and with it set as true, you won't be able to use /home as a root for your site -- or any directory below it -- as it prevents its use.

To remedy this, you need to either comment that line out with a ; so it looks like:

; ProtectHome=true

or define ProtectHome=read-only (this is implied if you don't define it, so commenting that line out is really all you need to do). Once that change has been made, you'll want to reload using:

systemctl daemon-reload

and then finally:

systemctl start caddy

or

systemctl restart caddy

...

Once that change was made, I was able to get 5 other domains working from /home without any issues.

Reply
vinitjain75 June 1, 2017

@jtittle

Based on your input, I have tried using this - but it did not work on 2 different droplets and domains
; ProtectHome=true

I have setup my website using Vesta Control Panel and this is why my website are under /home/admin/web/sitename.com/public_html

After following all the steps, now my Vesta CP login page is also not opening
https://139.59.58.199:8083/login/

Please help for both issues

Reply
  • jtittle1 June 1, 2017

    @vinitjain75

    If you're wanting to run Caddy, it'd be best to do it without a control panel and on a barebones VPS (Droplet). VestaCP, last I recall, only supports NGINX, so introducing a different web server to the mix may cause issues.

    Generally, with control panels, you're somewhat limited to running what they support. Adding in anything that isn't supported by the developers can cause issues. In your case, the conflict is most likely between NGINX and Caddy.

    They can't run on the same ports, so if you try to start NGINX and Caddy is already bound to port 80 and/or 443, then NGINX will fail. Likewise, if NGINX is running and already bound to ports 80 and 443, Caddy will fail.

    You could set them up to proxy requests from one to the other, though it'd be a bit redundant as they both support the same thing and you're only (from what I can tell) working with a single server setup.

vinitjain75 June 1, 2017

@jtittle
Yes Vesta CP uses NGINX and this is why I think caddy says port 80 already in use

can I uninstall vesta cp and nginx or will I have to start afresh?

I am planning multi server with a Load balancer (LB) model - Just wanted to first make it work on a single server and then wanted to replicate with one LB, one DB Server and atleast 2 Clients Server

Thereafter increase Client Servers with volume

Reply
  • jtittle1 June 1, 2017

    @vinitjain75

    If I were setting up a deployment for a potential cluster, I'd start fresh and use NGINX only. You don't need both. NGINX functions as a proxy and web server, and it can actually do both at the same time with very minimal configuration differences between the two.

    NGINX can also function as a load balancer, thus it makes it very much possible to use it across the entire cluster to manage the LB, Web Server, and any proxying that you may need to do.

    To take it a step further, with the stream module, NGINX can even function as a load balancer for MySQL and accept connections on port 3306/3307 or another of your choosing. I actually set this up for a client I was working with about a month ago and it works very well. There is some degree of configuration needed, but it works nicely.

    ...

    The issue with control panels is that all the above is rather difficult to implement as they don't provide support and you're likely to break functionality by introducing non-standard configs (at least when it comes to the CP). Most control panels are meant for single servers where you'll install the CP on each server you deploy.

    So if you need a control panel, whether it's VestaCP, Plesk, cPanel, or one of many others, you may find it hard to do some of the things you'd normally be able to do when just using the CLI.

vinitjain75 June 2, 2017

@jtittle

sounds complicated to me

Anyway you can help set this up for us or we can be your client in someway :-)

Reply
Have another answer? Share your knowledge.

Related Questions