Convert Wordpress from Apache2 on Ubuntu to Caddy 2

Help
13

And here’s the output of netstat -tulpan | grep LISTEN | grep caddy

tcp        0      0 127.0.0.1:2019          0.0.0.0:*               LISTEN      3102/caddy
tcp6       0      0 :::80                   :::*                    LISTEN      3102/caddy
tcp6       0      0 :::443                  :::*                    LISTEN      3102/caddy

So, how do I make it listen to ipv4 requests?

14

Ok, adding:

bind bygden.nu

made it only listen to ipv4, but I still don’t get any response in my browser…
Neither Chrome nor Safari…

15

I don’t really see why a bind directive should be needed with the exact same information as in the server name…

16

Not sure – there’s probably something weird about your system’s dual stack config; it doesn’t seem to be properly configured for IPv4 + IPv6.

17

Well, I’ve gotten it to listen on the ipv4 interface now (almost 24 hours ago now, but I haven’t been allowed to post until now), but I still don’t get any response from any browser. I don’t even see the request from the browser with debug enabled…:confused:

I’ve changed my Caddyfile to this, for test:

{
    debug
}
bygden.nu {
	bind bygden.nu
	respond "Hello, privacy!"
	log {
		output file /var/log/caddy/access.log
		format logfmt
	}
}

But still only response from curl locally and nothing from a remote browser... :(
18

So, where do I go from here? Re-activate Apache (which I’ve done anyway now)?

19

I’ve found the problem it was UFW…

I needed to issue these commands:

sudo ufw allow 80
sudo ufw allow 443

20

But - I was running multiple wordpress instances, with different domains (FQDNs) before, which just works with ServerName in Apache 2.
As I added my second domain to my Caddyfile and restarted it complains when coming to the definition of the second domain:

run: loading initial config: loading new config: http app module: start: tcp: listening on erikersara.nu:443: listen tcp 97.107.138.194:443: bind: address already in use
21

Uhh, that’s odd.

Does that happen if you take it down and start it up again (without --resume, specifying the new config)?

There’s definitely nothing else clamoring for port 443?

22

I edited my Caddyfile and then ran systemctl restart caddy and I got the error in /var/log/syslog
I get the same if I try systemctl stop caddy followed by systemctl start caddy

23

What do you get from netstat -tulpn | grep 443 ?

24

Well, since I get an error starting it doesn’t start, so no output.
But when I start it with only one domain definition I get the expected:

tcp        0      0 97.107.138.194:443      0.0.0.0:*               LISTEN      17971/caddy
tcp        0      0 97.107.138.194:443      46.229.168.153:57902    TIME_WAIT   -
tcp        0      0 97.107.138.194:443      46.229.168.153:56176    TIME_WAIT   -
25

When Caddy outputs this error, it means that the OS told it that it can’t bind 443 because some other program is already using it.

I’m not sure why the OS would reject the bind attempt with this error if there’s not actually any program using it. A rejection based on permissions would be a different error entirely, for example.

26

I interpret that as “Hey, I just started another https server on that port - I can’t start another one, since I assigned it to that other server”

It’s the exact same message I would get if I tried starting a caddy https server when an apache https server was already running.

27

Can you give us the latest Caddyfile you’re using that causes this error?

28

Sure:

# Refer to the Caddy docs for more information:
# https://caddyserver.com/docs/caddyfile
bygden.nu {
	bind bygden.nu
	root * /var/www/bygden
	php_fastcgi unix//run/php/php7.4-fpm.sock
	file_server
	encode gzip
	log {
		output file /var/log/caddy/bygden.log
		format logfmt
	}
}

erikersara.nu {
	bind erikersara.nu
	root * /var/www/ersara
	php_fastcgi unix//run/php/php7.4-fpm.sock
	file_server
	encode gzip
	log {
		output file /var/log/caddy/ersara.log
		format logfmt
	}
}
29

Hmm. And if you try with both bind directives commented out? (Presumably they shouldn’t be / were never necessary if the earlier issue was with ufw and has since been resolved.)

30

Then it starts, but as before (see above) - only on ipv6 interface…

31

But - now, with the UFW-problem solved it actually answers on ipv4 interface as well…
So, that solved it - thanks!
Both domains running now!

1 Like
32

This topic was automatically closed after 30 days. New replies are no longer allowed.