New Pod Up, but having problems

My new pod is located at www.diaspsocial.com, and every time I try to edit my profile, it throws a generic 500 error. I can click on all other links in my site with no issue, but anything to do with my profile gets an error.

Additionally, I don’t think my site is ‘federalized’, here’s why: I have an account on www.diasp>org as well, and I wanted to test between the two to make sure that cross posting between the two instances worked. I could comment on each other’s posts, but following is quite different. On diasp>org, it registers that I have followed myself on diaspsocial>com, and that I have followed myself back, mutual following is confirmed. But on my new pod, diaspsocial>com, it only shows that I followed myself on diasp>org, but haven’t been followed back. When I search for tags, I don’t see tags from other pod servers either.

The following is what I see when I look at my “other_vhosts_access.log” for apache:

https://pastebin.com/8VJwYapB

Here’s my server specs as well:

-Linode with recommended resources
-Ubuntu 18.04
-Apache2 (newest version)
-Ruby on fails (newest version)
-Diaspora* (newest version)

I also have a wordpress site up on the same server, so I know apache is working. I am available for the next few hours to troubleshoot if someone wants to give me a little time to help me out personally, I’d really appreciate it. Thanks!!!

Please have a look in the log/production.log for errors.

It looks like you mixed www and non-www. So you tell your pod is www.diaspsocial.com, but your username there is shawneric@diaspsocial.com without www. When diaspora then tries to get the account info for that account, your pod then tells again it runs under www.diaspsocial.com for federation, which then doesn’t work because it redirects to the non-www domain. In addition to that, your pod responds with 404 on the route for incoming federation, I don’t know why.

I’m not sure if you can fix this fuckup. You can try to set everything to the non-www host, and see if it works then, but I think the accounts which exist now in that broken state stay broken. If you change everything to non-www (I don’t know where everywhere you mixed that) and the account’s still don’t receive stuff, then they are maybe broken forever. But new accounts should work if your pod is configured correctly.

If the accounts stay broken you can either just use other accounts with new usernames and use them. Or you can drop your database and re-create a new empty one, change everything to a new domain (neither diaspsocial.com nor www.diaspsocial.com because they are already broken on some pods), for example pod.diaspsocial.com would be an idea, and start fresh. On that new unused domain you can then use all usernames again. Just make sure to find the cause of your fuckup first and know where you need to configure the domain, otherwise you would break that new domain too with the first usernames you create there.

I messed up the www and non-www stuff when I set up cryptospora.net, years ago, and it was a pain to fix. I think it can actually cache in the databases of other pods with the wrong www prefix and then require like manual intervention from other podmins to fix, in the worst-case scenario, before federation can be restored to those pods. Hopefully that is not the case hare. The docs should make it really clear on this issue…

I think I may have ended up actually using a MOD_REWRITE within apache to forward requests internally from the non-www to the www prefix, to solve the issue at cryptospora…

yep:

I have this in my apache conf file (sites-available/cryptospora.net.conf), to fix any potential www, non-www issues, it seems to work.

RewriteEngine on
RewriteCond %{SERVER_NAME} =cryptospora.net [OR]
RewriteCond %{SERVER_NAME} =www.cryptospora.net
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Oh yes, rewrite (not redirect) for the federation routes could work, so pods which know the broken users under the wrong domain could just communicate with the wrong domain. It looks like the redirect which happens now confuse the federation.

Yep you need internal redirection like that if you messed it up when you set up the pod and they are trying to federate to www.yourpod.com when only yourpod.com without www works properly. I think I wanted to have no www at the beginning, but realized that broke the “convention” other pods were using, then I tried to switch it, and ran into this issue…

Would I be able to dm one of you guys my rewrite config and you let me know what to do exactly? I’ve already got it setup so I can do the reverse proxy in apache, so I don’t want to screw it up
Thankfully I’m the only one who’s made an account on my server so far

I tried your config Tectract, but now my site just redirects too many times. Here’s my redirect, mind you, I’m also running Mastodon on the same server, and now that I just installed that, I’m having a redirect issue with both sites. I don’t know why. www>diaspsocial>com is my diaspora site, and www>tootsocial>com is my mastodon site. without the www the diaspora site comes up, but still has the same issues with federation like we discussed earlier, but if you put www in front of it, it says too many redirects, and regardless what I do, any tootsocial url redirects to diaspora, even though there isn’t a redirect there. I’m incredibly confused.

Diaspora apache config: https://pastebin.com/irzjF1pw
Mastodon apache config: https://pastebin.com/GcXX7mgE

What’s in your apach config? You must have some redirect line in there. My mod_rewrite will make your server basically see all requests as coming to the NON-www site, even if they are coming to the www site, so either version works, you can include www prefix OR NOT when visiting or federating to cryptospora. This way, all foreign pods can have EITHER www or no www in their local entries for the pod and users and it still works.

You may have set it up so that the internal config wants all requests to have WWW, as opposed to mine which wants all requests to have NO WWW prefix. In that case the last line in that mod_rewrite would be:

RewriteRule ^ https://www.%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

So you could try that. I use certbot / letsencrypt for my SSH key management so I try to keep the apache config files as small as possible not to confuse it…

Looks like I have this in the top-level httpd.conf file also, may be redundant:

ServerSignature Off
ServerTokens Prod
LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so
RewriteEngine On
RewriteCond %{HTTPS_HOST} ^www.cryptospora.net$ [NC]
RewriteRule ^(.*)$ http://cryptospora.net/$1 [R=301,L]

I actually did use certbot for tootsocial, and then just used letsencrypt (no certbot) for diaspsocial. But I actually commented out what I had before and replaced it with your example above, as you can see in the two pastebin’s I posted above.

RedirectPermanent / https://www.diaspsocial.com/

Try removing that

Ok, did that for both of them. Now tootsocial.com says it’s down for maintenance or something like that, but diaspora doesn’t come up at all

I think I’m going to start over from scratch. Mastodon doesn’t officially support apache2, and it only supports nginx, and I can’t have both running, so I’m going to switch to nginx instead and just do everything from scratch. hopefully it works when it’s fresh.

Check here for my (OLD) and (NEW) config.

The (OLD) entries are from when I used reverse-proxy, like you are now. The (NEW) entries are from after I switched over to using Passenger to serve the content (recommended). This may help you along your way :wink:

https://pastebin.com/NRAQfKWE

1 Like

Just letting you guys know I created a new topic, but still need help, if you could head over here please.