I have searched the database dump with grep and vi as well and there was no moodle/moodle or mysite.com/moodle within the text file. I'm nonplussed.
Since then I copied the whole site to my home computer: moodle code, moodledata directory, database as is. I have only changed config.php, I did not use the search & replace tool. And lo and behold, the site works without a glitch on my home computer... I was wondering: could it be that there is some external program being called by moodle that might have a bug under Debian stretch (9.2) but not under Ububtu xenial?
Under Debian, I have
PHP 7.0.19-1 (cli) (built: May 11 2017 14:04:47) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.19-1, Copyright (c) 1999-2017, by Zend Technologies
Under Ubuntu, I have
PHP 7.0.22-0ubuntu0.16.04.1 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.22-0ubuntu0.16.04.1, Copyright (c) 1999-2017, by Zend Technologies
Is Selinux enabled? If so, try disabling it.
No, it's not even installed (only the runtime shared libraries are installed).
First ... think the recommendation is to 'move' what you have to the new host first (the 3.0.x) and make sure it works before upgrading in the new environment.
One reason ... environment check ... there have been some DB changes that one should implement with 3.3 and beyond. One had to have 3.0.1 or higher of Moodle for PHP 7.0 to work with Moodle code - if I re-call correctly.
To the best of my knowledge config.php is the only place where wwwroot is defined - where one might find http://site/moodle/moodle ... with no trailing 'slash' (ie, the double moodle)
The installation of the plugin ... was that done at the same time as the migration/upgrade prior to accessing the site for the first time (ie, manually)? Ownerships/permissions on the files for that addon/plugin?
Did you get the highest version of the plugin?
https://moodle.org/plugins/pluginversions.php?plugin=tool_inactive_user_cleanup
There's also the 'section' error you've mentioned ... and the link to the suggestion page that shows how one might fix that.
There was a major change to admin interface from 3.0 to 3.2 and higher. So when you copied moodledata you also copied the cache and localcache directory ... both of which could be manually removed and moodle wlll rebuild them as needed.
Move to local computer isn't same environment as server ... what else sits on top of or in front of the moodle code? Apache ... for one ... Emma has mentioned SELinux ... but there could be other web related apps like it on the hosted site not present on local that could come into play.
Have you checked apache config? Got any re-directs in .htaccess or any other config in production server that wouldn't be present in local?
'spirit of sharing', Ken
Yes, in retrospect I should have been way more careful with the whole migration/upgrade business... I'm just trying to find a way to fix what I have messed up.
The plugin issue was solved by manually removing the contents of the cache and localcache directories within moodledata (apparently the purge all caches command from the web interface doesn't remove as much?), thanks
The remaining issue seems that if there is a form to submit (as in the user filtering, or the creation of a new course, or searching), after pressing the submit button I get redirected to a site with an extra 'moodle' in the url, so a lot of 404-s.
What I have checked/tried so far:
* The wwwroot in config.php is fine: doesn't contain either an extra moodle or a trailing slash.
* The database doesn't contain the string mysite.com/moodle , I have searched the database dump.
* The apache2 conf had a trailing slash in the DocumentRoot (/var/www/html/ instead of /var/www/html) but removing said slash and restarting the apache2 service did not change the issue
* The server environment consists of a load balancer + sql server + 3 moodle servers. The nginx configuration on the load balancer seems ok to me, although I'm not sure I would notice what's wrong as I'm not an expert, the whole load balancing setup was done by someone else. If there were some problem with the setup it would make sense that the redirection issue should not be present on my home computer.
I guess I'll give it another go tomorrow and if all fails revert to the previous version at the cost of losing ~ 1 month of usage data. I really hope I'll find out what's wrong, it's been bugging me for a while.
Does this happen on any form, for any user?
You say an extra moodle - so it looks like yoursite.com/moodle or yoursite.com/moodle/moodle?
Well ... new information shared in last post ... nginx and load balancer.
Suggest that the 'extra' /moodle might be as a result of either of those or both of those config.
Maybe an nginx expert using load balancers will respond. ;)
'spirit of sharing', Ken
Follow up ...
What does the environment check in your server show?
https://site/admin/environment.php for direct URL.
Then there is apache config:
https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html
Some of the config of reverse proxies of apache does involve paths ... and not like Moodle where you are to put no trailing slash, those might have/require not only prefixed but trailing slashes.
Assume during the migration and upgrade you retained the original config.php file.
Have a gander at the config-dist.php file in the new code and especailly settings related to proxy and reverse proxy ... ssl also.
If site running ssl it's config might include an extra /moodle/.
That's about all I can think of! ;)
'spirit of sharing', Ken
It was that #&@! nginx.conf, thanks so much for pointing in the right direction
So, in the spirit of sharing (even though this is likely not the elegant way of doing this), my solution was the following:
Relevant part of nginx.conf before, that is, the settings that produced the error:
upstream foo{
hash $remote_addr;
server ip_of_server1;
server ip_of_server2;
server ip_of_server3;
}
location / {
proxy_pass http://foo/moodle/;
}
On the servers the documentroot in the apache config was /var/www/html.
Now:
I changed the documentroot on the servers to /var/www/html/moodle, and nginx.conf contains now:
location / {
proxy_pass http://foo;
}
Congrats! And thanks for sharing back! Doesn't have to be 'elegant' ... a 'nugget' is good ... just enough! ;)
'spirit of sharing', Ken