Hardware: VPS bought online YunoHost version: 4.3.6.2 (stable) I have access to my server : Through SSH and through the webadmin Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : I think no If yes, please explain:
I created a subdomain (“yunohost.mydomain.tld”) and made it the default domain. As expected, I can now enter the Yunohost admin through yunohost.mydomain.tld.
I also uninstalled Wordpress from the Yunohost web admin, and reinstalled it, into the root domain (mydomain.tld/) and made it the default app for this domain.
Description of my issue
What you are trying to achieve: to have the Wordpress website show up when I navigate to my root domain (mydomain.tld/). What actually happens: when I navigate to mydomain.tld/ (even after deleting all cache, browser data, etc.), it redirects me to mydomain.tld/join, which used to be the old domain path of the previous Wordpress installation.
in which context What you tried: I logged in via ssh and tried the command sudo yunohost app map, which outputs
Then I tried sudo yunohost app change-url wordpress -d mydomain.tld -p /, which outputs Error: The old and new domain/url_path are identical ('mydomain.tld/'), nothing to do.
Detailed error messages and logs: the only error message I got was when clicking on Make default for Wordpress, and it said: Unable to make 'wordpress' the default app on the domain, 'mydomain.tld' is already in use by 'wordpress'.
Explain what really happens and how you interpret it: for some reason, the path of the previous installation of Wordpress has been kept, even if yunohost has it configured that it should be installed in the root domain.
I also just made sure that all the DNS settings are correct in my registrar (small issues remain, see below), and generated a certificate for yunohost.mydomain.tld, successfully.
sudo yunohost diagnosis run results in:
Success! Everything looks OK for Base system!
Success! Everything looks OK for Internet connectivity!
Success! Everything looks OK for DNS records! (+ 1 ignored issue(s))
Success! Everything looks OK for Ports exposure!
Success! Everything looks OK for Web!
Error: Found 2 significant issue(s) related to Email!
Success! Everything looks OK for Services status check!
Success! Everything looks OK for System resources!
Success! Everything looks OK for System configurations!
Success! Everything looks OK for Applications!
Warning: To see the issues found, you can go to the Diagnosis section of the webadmin, or run 'yunohost diagnosis show --issues --human-readable' from the command-line.
then sudo yunohost diagnosis show --issues --human-readable outputs
=================================
Email (mail)
=================================
[ERROR] The reverse DNS is not correctly configured in IPv4. Some emails may fail to get delivered or may get flagged as spam.
- Current reverse DNS: mydomain.tld
Expected value: yunohost.mydomain.tld
- You should first try to configure the reverse DNS with yunohost.mydomain.tld in your internet router interface or your hosting provider interface. (Some hosting provider may require you to send them a support ticket for this).
- Some providers won't let you configure your reverse DNS (or their feature might be broken...). If you are experiencing issues because of this, consider the following solutions:
- Some ISP provide the alternative of using a mail server relay though it implies that the relay will be able to spy on your email traffic.
- A privacy-friendly alternative is to use a VPN *with a dedicated public IP* to bypass this kind of limits. See https://yunohost.org/#/vpn_advantage
- Or it's possible to switch to a different provider
[ERROR] The reverse DNS is not correctly configured in IPv6. Some emails may fail to get delivered or may get flagged as spam.
- Current reverse DNS: mydomain.tld
Expected value: yunohost.mydomain.tld
- You should first try to configure the reverse DNS with yunohost.mydomain.tld in your internet router interface or your hosting provider interface. (Some hosting provider may require you to send them a support ticket for this).
- Some providers won't let you configure your reverse DNS (or their feature might be broken...). If your reverse DNS is correctly configured for IPv4, you can try disabling the use of IPv6 when sending emails by running 'yunohost settings set smtp.allow_ipv6 -v off'. Note: this last solution means that you won't be able to send or receive emails from the few IPv6-only servers out there.
However, nslookup 1.2.3.4 (my IP) returns 4.3.2.1.in-addr.arpa name = yunohost.mydomain.tld., and same if I check the ipv6 address.
Nice troubleshoot, I didn’t know about the yunohost app map-command
Apart from Titus’ suggestion, what about moving your current WP-installation to /join and (if successful) moving it back?
I’d expect an error (it already exists/occupied, or something like that), but you never know. If it works, you’ll also never know what went wrong but the problem would be solved
Good points, but I did try to change it to something else, then to ‘join’, then to move it to another domain altogether, then back… I tried lots of combinations
I suppose it’s a bug, though, given the solution above? In any case, thank you for your suggestions!
Hmmm, but actually, now I can’t log into WordPress admin anymore When I got to https://domain.tld/wp-login.php it redirects me to https://yunohost.domain.tld/yunohost/sso/?r=aHR0cHM6Ly8xMDFzLmNvbW11bml0eS93cC1sb2dpbi5waHA=, and, no matter which user I log in as, it just shows that same Yunohost login page again and again
Can you share the contents of /etc/ssowat/conf.json.persistent now? (sorry for the wrong filename above, I’ll fix it for later readers). If there are no settings in there, it should at least contain this : {}
Now I tried with just {}, as you suggest, and I see the same buggy behaviour I mentioned above (with the login screen that redirects to the same login screen).
Or do I need to restart anything for these changes to take effect?
Thanks. Yes, the two users I keep trying to log in as are, indeed, allowed to access WordPress admin.
Also, I have to say that I’m floored! I’d finally managed to log into sso on Microsoft Edge (it’s redirecting in a loop on Brave, as mentioned above, and in Firefox it’s telling me that I should “Please log in from the portal”, something I’ve seen before on this forum but didn’t manage to pin down to specific settings or anything). But, after logging out, it wouldn’t let me log back in (sent me in the login loop, like Brave).
However, upon restarting Edge, it’s now allowing me to log in again
All the while, though, the admin console (https://yunohost.domain.tld/yunohost/admin/#/) is usable in all browsers, thankfully.
I tried to look at all the logs I could think of to figure out what’s not going right. I did an ls -n and even a sudo find -printf "%TY-%Tm-%Td %TT %p\n" | sort -n on /var/log/ right after a redirected (looping) login attempt, to see which log files were the ones that had changed just then.
But nothing I read in either /var/log/nginx/yunohost.domain.tld-access.log, or in /var/log/debug or /var/log/daemon.log, etc. have helped me understand the issue… Please do direct me to which log file might record this behaviour, if any
PS: with Brave it used to work to log into sso. I think it was until I made those changes to /etc/ssowat/conf.json.persistent. While exploring these files, I also made some changes to /etc/ssowat/conf.json, but then I reverted them. Could it be related simply that that file was edited, even if the contents are the same as before?
Could be, but then the timing was very unfortunate.
Yes. In Brave, I switched the shield off and disabled the DuckDuckGo protection (I have no other relevant extensions), and in Firefox I turned off the enhanced tracking protection, all add-ons and downloaded the PrivacySettings add-on and put it on its most permissive (default) setting.
Here are the only messages that I can see in the Brave console, before and/or after trying to log in:
[WARNING] Error with Permissions-Policy header: Unrecognized feature: 'interest-cohort'.
yunohost.domain.tld/:1
[ERROR] Unchecked runtime.lastError: The message port closed before a response was received.
Ayy, it’s to do with the VPN! I’m writing a more detailed report now, but it’s definitely connected. So, this is just to let everyone know that the solution is getting closer.
Actually, after a bunch of tests, it seems to have nothing to do with the VPN, but with cookies or browser cache. After clearing them, it logs in correctly in all browsers (except for Firefox, which has another problem — “Please log in from the portal”) that I don’t have time to investigate now.
Marking the original solution as correct. Thanks to all!
I’m writing a more detailed report now, but it’s definitely connected. So, this is just to let everyone know that the solution is getting closer.