Rewrite for GNU Social

Help
1

Howdy,

I am trying to get a GNU Social instance running on Caddy with fancy urls enabled. In nginx there’s a command to cause it to stop redirecting after the first match, last. I have not been able to find such a command for Caddy. I think the same thing can be achieved with an if statement, but so far I have not been successful.

Here is my current attempt. I have removed my if statement because it didn’t work. It should take anything that doesn’t match, and redirect it to index.php?p=.

Caddyfile

example.com www.example.com {
errors /var/log/caddy/example.com.errors.log
fastcgi / 127.0.0.1:9000 php
    gzip
log /var/log/caddy/example.com.access.log
tls email
    rewrite {
        r .*
        to /index.php?p={1}
    }
    root /var/www/example.com
}
2

Caddy has this behaviour by default - it will stop processing a rewrite at the first available target. You’ve only got one rewrite, though, and only one target, so it will always perform only that rewrite.

Assuming you’re going off the nginx sample configuration here, what you’ve got looks right. I’d make one small change, though. Because using r .*, a regex matcher that simply matches all requests, is computationally expensive - contrast with simply excluding it, which has no extra cost, as the rewrite matches all requests by default unless limited:

rewrite {
  to /index.php?p={1}
}
3

Howdy,
Thanks so much for the help. You got me on the right track. Now the only problems, as far as I can tell, are those given by GS itself. For some reason it can’t write to the config file, even though it has full access to it lol. I even made the file 777 and still no go. It can sure read it though.

Here is the finished file. I’m still very new with Caddy, so suggestions are welcome. I figured out, in stead of {1} I should use {url}. The problem came when trying to access the install page, which didn’t need a redirect. I think I got it though:
example.com www.example.com {
errors /var/log/caddy/example.com.errors.log
fastcgi / 127.0.0.1:9000 php
gzip
log /var/log/caddy/example.com.access.log
tls email
rewrite {
to {uri} {uri}/ /index.php?p={uri}
}
root /var/www/example.com
}

4

Ahh, yeah :sweat: forgot about that one.

I’d use {path} instead, though. The query/anchor aren’t going to be useful when passed as a query.

Strange that chmod 777 didn’t fix the issue… It usually does, which is why it’s a dangerous option. Your FastCGI process is the one that will be trying to write the file. Does the containing folder also have the right permissions?

5

Howdy,
Sorry it took me so long to respond. I have had a very interesting experience with this permission error. No matter what I did, it would not write to that file. So, since this was my play around server, I just did a chmod -R 777 to /var. That has some very interesting results, not the least of which, is breaking sudo and ssh.

Because my play around server is on CloudAtCost, it sometimes takes a while to spin up a new on ethat will actually boot. I plan on trying this again. I’m debating putting web stuff in a different directory than /var/www. It works for the most part, but I did have some interesting troubles while using that method. I tend to create an html user and put things in /home/html/sites. I’ve never had trouble with that method, so far anyway.

I’m sure the latest version of the Caddyfile works, but I want to install and make absolutely 100% sure before submitting it to the sample git repo. Thanks for all the help :slight_smile:

1 Like