Moodle in English: Site administration after upgrade to 3.7+ is not working

After upgrading my Moodle instance to 3.7+ (via git) Administrators can not use : -> Site administration.

For all normal accounts the Moodle 3.7+ is running smoothly - no problems.

BUT, no Administrator can log into the front end.

1.) After log in with the Administrator account you get an empty page:

https://.../moodle/admin/registration/index.php?returnurl=%2Findex.php

Now, you can go back one page in the browser and you see the login page with the message: "You are already logged in as xxxx(Admin), you need to log out before logging in as different user."

2.) Keep staying on that page you are able to click the Dashboard menu and get to Adminstration -> Site administration, clicking there nothing is happen, the icon is spinning.

System: Linux Server, OpenSuse Leap 15.0, I have full access to the Server, no error messages are coming up

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Wednesday, 3 July 2019, 4:01 AM

Upgraded to 3.7+ from what version of Moodle?

Themes have once again changed. Suggest a couple of things ... purge cache via command line ... code/admin/cli/purge_caches.php and using config.php file set the theme to one of 'boost' or 'classic' - themes that come with 'stock' moodle 3.7.x code.

$CFG->theme="oneofabove";

If you can, turn on debugging and/or use Console in FireFox browser to see what might happening.

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Wednesday, 3 July 2019, 5:37 AM

I upgraded from the latest stable version 3.6+ (our Moodle is running since 5 years and get always upgraded via git)

I purged the cache already via cli. My setup consists of themes: adaptable, boost and classic.

We are used the adaptable theme before with own css and style design - I tried already to delete the adaptable theme by simple removing it on server - the then active core theme showed the same behavior like described.

I tried your suggestion with the theme setting in the config.php - it did not work either! The returned empty web page:

https://.../moodle/admin/registration/index.php?returnurl=%2Findex.php

includes something with the return url - Do we have maybe a problem, when the moodle server sits behind a NAT? We are using a Proxy Server, so that the IP-Address of the Moodle server (10.x.x.x) is translated to the external official IP - Address (but this setup was working before with 3.6+).

The Error is 500 - internal Server Error

Here the Firefox-debug console message for the empty return page:

GEThttps://moodle.paes.eit.htwk-leipzig.de/moodle/admin/registration/index.php?returnurl=%2Findex.php[HTTP/1.1 500 Internal Server Error 417ms]
HeadersCookiesParamsResponseTimingsStack TraceRequest URL:Request method:Remote address:Status code:Edit and ResendRaw headersVersion:Response headers (324 B)Request headers (586 B)Accepttext/html,application/xhtml+xm…plication/xml;q=0.9,*/*;q=0.8Accept-Encodinggzip, deflate, brAccept-Languageen-US,en;q=0.7,de;q=0.3Connectionkeep-aliveCookieMoodleSession=ae7a1c80f2fff651…21ed0c8909476aa02b96333156bd3DNT1Hostmoodle.paes.eit.htwk-leipzig.deRefererhttps://moodle.paes.eit.htwk-l…pzig.de/moodle/login/index.phpUpgrade-Insecure-Requests1User-AgentMozilla/5.0 (X11; Linux x86_64…) Gecko/20100101 Firefox/60.0

Thanks for the fast answer!

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Wednesday, 3 July 2019, 6:34 AM

following a txt file with more detailed debug informations

Andreas

error-500-paes.txt

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Wednesday, 3 July 2019, 6:41 AM

Uhhh ... am getting a warning in FireFox ...

Warning: Potential Security Risk Ahead

Cert and issuer

Cert check with curl -I
curl: (60) Peer's Certificate issuer is not recognized.

That would surely mess up sites attempt to update registration info with moodle.org, me thinks.

Sorry ... can't help much more than that.

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Wednesday, 3 July 2019, 3:26 PM

Thanks again,

here additional explanation:

Our Moodle Server sits behind a Proxy Server with NAT (10.x.x.x), the Proxy serves for IP-mapping and Certificate handling to external IP (with IP-Tables rules).

In Firefox you can examine the Certificate for https://moodle.paes.eit.htwk-leipzig.de (CA is the German Research Network). How I sad - for normal users no problem - only the admin accounts are not working.

This set-up was running successfully with 3.6+ . What difference was made in 3.7+ with the admin registration?

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Wednesday, 3 July 2019, 6:01 PM

Above is what I see in Firefox. Have to make an exception before viewing or attempting to view cert info. Am assuming, of course, that is happening to everyone who tries your site via FireFox from the outside world. Wonder if anyone would confirm that.

https://support.mozilla.org/en-US/kb/what-does-your-connection-is-not-secure-mean?as=u&utm_source=inproduct

However, using curl -I with -vvv

* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=DE; ST=Sachsen; L=Leipzig; O=Hochschule fuer Technik, Wirtschaft und Kultur Leipzig; OU=Institut fuer Prozessautomation und eingebettete Systeme; CN=moodle.paes.eit.htwk-leipzig.de

Strange that Firefox would have issues and curl would not?

However, when I do make the exception, still see a broken lock ..

Original posting shows:

/moodle/admin/registration/index.php?returnurl=%2Findex.php

which is the form to register your site with moodle.net.

As far as I can see (using another server), no difference in the form.

See your running SuSE. From your server cli can you do a curl -I https://moodle.net to see if inside/out is working?

Not sure it's a factor, but why does that server have 2 outside IP addresses in DNS?

Check your cert using ssllabs https://www.ssllabs.com/

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Wednesday, 3 July 2019, 10:54 PM

Thank you again for your help!!!

This behavior is very strange - I added the security information with my Firefox browser is coming up.

curl -l https://moodle.net is working on my server (via IP-Tables all outgoing traffic is allowed, incoming traffic is only allowed on the http and https port - among few others)

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Wednesday, 3 July 2019, 11:20 PM

Thanks again for help!

Yes, that's a strange behavior:

1.) the server has only one IP-Address (10.x.x.x)

2.) ssllabs is showing two addresses, the first one is the correct proxy server address, the second address was used one year before we shifted the moodle server into our NAT-zone

3.) curl -I https://moodle.net works on the server (all outgoing traffic is allowed, only http and https ports and soem other are coming in through ip-tables)

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Wednesday, 3 July 2019, 11:53 PM

Agreed it is 'strange' ... for those outside your 10. we're at the 'mercy' of your net's outside DNS.

From my home network using dig for server FQDN it shows 2 public IP addresses.

First IP:

PORT STATE SERVICE
80/tcp filtered http
443/tcp filtered https

Second IP:

PORT STATE SERVICE
80/tcp open http
443/tcp open https

When you did the ssllabs check ... did you notice it tried both and finally decided on one?

DNS server for zone shows a serial of 2017011788 ... year 2017 jan 17.

Suggest you contact whoever admins the DNS server ... the one on the outside and ask.

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Thursday, 4 July 2019, 12:51 AM

Yes, I already started to look at our University DNS - Servers.

The IT-Service Desk gave us access to one of their servers at the time and we changed the IP address to the first one - obviously there exist a secondary server in our realm, what they did not mention to us.

I am only wondering why this problem came not up earlier - we had no problems, so we did not look for more.

Again - you did a great job and I can not stop to thank you for your prompt efforts!

PS.: During my last stay at the Abilene Christian University (ACU) in Texas this April, I also visited your beautiful home town San Antonio! The colleagues from ACU are coming next week to Leipzig for a joint student summer school

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Thursday, 4 July 2019, 9:11 PM

Sorry for making trouble again, but now we solved the DNS server issue.

The above described problem exists furthermore - admins can not log into moodle and get an empty page delivered, the apache2 server access.log shows:

"GET /moodle/admin/registration/index.php?returnurl=%2Findex.php HTTP/1.1" 500 -

what means an internal server error happened.

So, again my question - what was changed between 3.6+ (admins can log in) and 3.7+ (admins can not log in).

Attached you can see the page if you click "Go back one page". If you click "Cancel" you are redirected to the empty page.

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Friday, 5 July 2019, 2:00 AM

Can you go directly to:

https://yoursite/admin/registration/index.php using your browser?

All admins have the ability to submit the info on the form so it appears that during the upgrade or right after whatever admin person was doing the upgrade didn't get that form to renew it or to cancel, etc.

There is an 'un-register' link you can try directly using browser URL line:

yoursite/admin/registration/index.php?unregistration=1

Try that.

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 3:06 AM

trying

https://mysite/admin/registration/index.php

i get promptly redirected to

https://mysite/moodle/login/index.php

Using directly

https://mysite/admin/registration/index.php?unregistration=1

returns ERROR 404

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Grabs - Friday, 5 July 2019, 3:29 AM

Hi Andreas,

did you check your server logs? Maybe you can find there some answers or at least some information that leads to them.

Best regards
Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 4:32 AM

Yes, I'm getting this see attachment by trying to log in as admin

apache2-log.txt

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Friday, 5 July 2019, 5:09 AM

You need to share clips from the *error* logs ... not access logs.

error_log or ssl_error_log

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 5:50 AM

I did send a composite log via:

tail -f *_log

in the /var/log/apache2 folder - so you got all information, No error log was written

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Friday, 5 July 2019, 6:20 AM

No error_log file in /var/log/apache2/ ????!!!!

cd /var/log/apache2/

ls -l error*

tail error_log

And do that on both servers ... the proxy in front and the server where the moodle code resides.

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 7:00 AM

of course is there a error_log file !!!!!
BUT with tail -f *_log a combined file with ALL coming log info are written, please look for the section like
==> access_log <==
I do start the action in my browser in moodle and the the "tail" will filled up!
because no section ==> error_log <== is coming up, means, that no new error message came up!
Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Grabs - Friday, 5 July 2019, 5:18 AM

Hi Andreas,

thanks! But these logs look like they are from the proxy and not from the webserver itself. Maybe there the error rise up.

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Friday, 5 July 2019, 4:11 AM

Error 404 is a "not found" error - which would be strange cause you said you used git.

So using something to browse files on server, see if there is a 'registration' directory/folder in moodlecode/admin/

Also inspect the contents of 'registration'. See an index.php file there? as well as the following files:

confirmregistration.php
forms.php
lib.php
register.php
renewregistration.php

Also ... am still getting a 'broken lock' on https:// access to site and have to make an exception to view.

Getting only one IP address and looking at cert via --vvv and curl server cert reports "SSL certificate verify ok" and I get a cookie. Puzzling!

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 4:44 AM

Sorry, it was 303 (see attachment) and I checked on server the admin/registration folder, there are:

confirmregistration.php forms.php index.php lib.php register.php renewregistration.php

What is with the first file?

Explanation for the log: 10.0.26.101 is our reverse proxy server

apache2-log2.txt

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Friday, 5 July 2019, 4:57 AM

Please try to report accurately so those trying to help don't go down a rabbit hole! :|

The apache logs don't show an error.

303

https://www.checkupdown.com/status/E303.html

Manually remove **contents of** moodledata/cache/ and moodledata/sessions/

No need to restart apache.

Clear browser cache and cookies.

TIA - try it again!

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 3:56 PM

I did purge moodledata/cache and moodledata/localcache and moodledata/temp.
No change ....

But on my system no folder moodledata/sessions exists? I created for test this folder and logged in as normal user and tried again as admin - nothing was written into that folder, so that I deleted it again.

Yes, the certificate has grade B, but is valid! - I think the problem is not the ssl connection.
Yes we are using in our apache setup SSLCertificateChainFile , all certificates are coming from the German Reserach Association (DFN), maybe I made some error by concatenation in the chain file, but I did this a year ago and moodle 3.6+ was running accordingly!

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Friday, 5 July 2019, 5:05 AM

'What's with first file?" ... you mean the acess_log

==> access_log <== is just that access ... port 80.

==> ssl_request_log <== show you are using Mozilla/5.0 (X11; Linux x86_64 ...

Are you in server desktop .... on the server itself?

What about accessing with FireFox from a workstation?

Server is open to port 80 and 443 ... 443 is the port used for https:// access.

Do you have an autoforward for any port 80 traffic to auto to 443 ... and thus flipping http:// to https://

That would be in apache config me thinks.

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 5:47 AM

No, I was asking for the

confirmregistration.php

Is this file responsible for the registration?

The log files are coming from the server, I have direct access to the server via ssh (routed through our proxy server)

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Friday, 5 July 2019, 6:34 AM

Comments in file say:

* The administrator is redirect to this page from the hub to confirm that the
* site has been registered. It is an administration page. The administrator
* should be using the same browser during all the registration process.
* This page save the token that the hub gave us, in order to call the hub
* directory later by web service.
*/

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Friday, 5 July 2019, 5:20 AM

When going directly to

https://mysite/admin/registration/index.php?unregistration=1

even if it says 303 refresh with browser.

Comment: SuSE servers were supposed to be very compatible with Windows. Thus, you might need to treat it like a Windows server in this case ... reboot it! :|

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 6:02 AM

I have really nothing in mind with windows - I have a pure Linux environment

BUT, if it helps I'll do it!

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 6:54 AM

I did reboot - and like expected the same behavior.

I tried also another web browser - opera, the same is coming up - internal error 500.

The log files show the same (see my combined clip).

Attached for information the log file (combined clip) of my reverse proxy server - there also only is said <. internal error 500

(the 93.x.x.x is my home laptop's IP)

apache2-log3.txt

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Friday, 5 July 2019, 7:52 AM

When you use tail -f _log [(your log file (combined clip)] aren't you seeing the last 10 lines ONLY ... and not lines above the 10 last lines?

What, if anything, is in the error_log file just above the line that shows 500 error? Like at the top of the error_log.

What does git reset --hard do in code directory?

This will be my last idea ... remotely and trying to do a vulcan mind meld with server ... :|

cd /path/to/moodle/code/admin/cli/

php upgrade.php

'SoS'. Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 4:00 PM

Because I have both sides, the back end and the front end, under control I trigger on the server the idle status of system, start the tail -f ..... what opens a running combined log on the console AND then I start the actions in the front end (browser actions with moodle). So I can't miss any log entry!

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Friday, 5 July 2019, 6:30 AM

In what you named error-500-paes.txt file
This:
Host moodle.paes.eit.htwk-leipzig.de
Referer https://moodle.paes.eit.htwk-l…pzig.de/moodle/login/index.php

Referer has htwk-l…pzig
and in DNS it's htwk-leipzig

That chopped in the log file or is that's what's getting passed via proxy?

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 7:25 AM

This was the debug information of my firefox' s web console. The Refer field is there only shortened in the output.
This information are given in the web console, when the internal 500 error comes up during the admin login attempt.

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Friday, 5 July 2019, 8:12 AM

I lied! ;) One last suggestion ...

cd moodlecode/admin/cli/tool/task/cli/

php schedule_task.php --execute="\core\task\registration_cron_task"

Let's hope you see:

Site registration updated
... used 22 dbqueries
... used 3.4743680953979 seconds
Scheduled task complete: Site registration (core\task\registration_cron_task)

Ok, now am outta ideas!

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 4:13 PM

Here the output (one small difference - the tool folder is located on the admin folder level)
mymoodlecode/admin/tool/task/cli # php schedule_task.php --execute="\core\task\registration_cron_task"
Execute scheduled task: Website-Registrierung (core\task\registration_cron_task)
Die Registrierungsinformationen wurden geändert. Bestätigen Sie dies bitte durch Anklicken des Buttons 'Registrierung aktualisieren'.
... used 1 dbqueries
... used 0.027829170227051 seconds
Scheduled task complete: Website-Registrierung (core\task\registration_cron_task)

1.) I'm wondering why here the German locals are coming up - usually English is preferred.
2.) Translation: The registration information has been changed. Please confirm this by clicking the button 'Update registration'.

Questions:

1.) Is there a virtual or software way to push this button?

2.) I have full access to the sql-database, do you know in which table the update process is managed? can I set a field in that table as reaction of the virtual button click ?

Attached the content of the mdl_registration_hubs table.

What you can see there is obviously the secret linked with the old IP-Address 141.57.26.18. I have to look, what type the timemodified field has. Maybe that this is the registration we did long ago before we switched to our proxy?

Andreas

moodle-table.txt

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 4:52 PM

The timemodified field is "bigint" - so I'm not aware how the time stamp is stored in that field ....

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Tim Hunt - Friday, 5 July 2019, 6:33 PM

All times in Moodle are stored as Unix timestamps.

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Friday, 5 July 2019, 7:58 PM

Thanks,

then the timemodified field shows : 23.01.2019 - 23:09:37.

I think I updated a minor release at this time, BUT at this time the server was already part of our internal net and had the proxy's IP address.

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Friday, 5 July 2019, 9:13 PM

I lied again!!!! One last ...

Was wondering if you'd catch that ... Good! Means one is not just copying and pasting without thinking!!!

can you go to:
yoursite/admin/registration/index.php?unregistration=1

Try to un-register your site.

It's a form with 2 checkboxes. So not sure what one could do to pass those choices in a URL ... done via webservices back to moodle.net from what I gather.

Let's see if you can unregister your site now that DNS is correct. Still though ... wonder how strict moodle.net server is when talking https with your B rated site.

The 'Site registration' scheduled task keeps your registration up to date. You can also manually update your registration at any time.

Don't think the table can be manipulated ... token and secret probably generated on the fly and used to communicate with moodle.net.

So the IP in there is the old IP.
As a test, I truncated that table and that forced re-registration, but I can access /admin/.

"Your site is registered. Registration last updated 5 July 2019. The 'Site registration' scheduled task keeps your registration up to date. You can also manually update your registration at any time. "

And one last item about logs ...

Your first posting I see is: Wednesday, 3 July 2019, 5:37 AM - to me. And I assume you upgraded just prior to posting on the 3rd. Wonder if you'd do:

fgrep 'Jul 03' ssl_error_log
or
fgrep 'Jul 03' error_log

Do/Don't makes no diff to me as I don't seem to have a problem.

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Saturday, 6 July 2019, 12:50 AM

I can not use yoursite/admin/registration/index.php?unregistration=1 - I'm promptly redirected to the login page. So that form don't show up.

Next, I think moodle.net did accept until now our B-grade certificate - because it's valid! And with moodle 3.6+ were no problems - did they change their policies?

I attached the error.log and last zipped ssl-request.log - I did the update in the night from 2th to 3th of Juli.

In the error log are some [ENROL LDAP] errors to the LDAP Server uranos.paes.eit.htwk-leipzig.de (LDAP server of my institute) with unknown Resources ids #xx - That are artifacts from partly deleted enrollments - We changed our LDAP Server last year too to the University LDAP Server, unfortunately I did not care about that problem earlier.

I want to assure my understanding of your
1.) Do I right understand, that I can truncated the mdl_registration_hubs table? (I would of course copy the db before ! )?
2.) Are the admin user credentials locally stored in the db?
3.) What does it mean: ..... You can also manually update your registration at any time.

Andreas

error_log

ssl_request_log-20190703.xz

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Saturday, 6 July 2019, 2:36 AM

No offense, but ...

Really!!!???!!!! you are wanting me/we to sort through you logs looking for the date you did the upgrade? Wow! That's really asking for the 'extra mile' ... for free too! :\

As server admin or one who has that access level and as admin of the your moodle with issues, isn't that something you should do/learn?

Search for 'Jul 03' ...

First entry for Jul 03:

[Wed Jul 03 00:00:01.900190 2019] [mpm_prefork:notice] [pid 13258] AH00171: Graceful restart requested, doing restart
[Wed Jul 03 00:00:01.955997 2019] [mpm_prefork:notice] [pid 13258] AH00163: Apache/2.4.33 (Linux/SUSE) OpenSSL/1.1.0i-fips mod_jk/1.2.43 PHP/7.2.5 configured -- resuming normal operations

Others that you need to check into:

[Wed Jul 03 00:38:00.858578 2019] [core:notice] [pid 13472] AH00094: Command line: '/usr/sbin/httpd-prefork -D SYSCONFIG -D SSL -C PidFile /var/run/httpd.pid -C Include /etc/apache2/sysconfig.d//loadmodule.conf -C Include /etc/apache2/sysconfig.d//global.conf -f /etc/apache2/httpd.conf -c Include /etc/apache2/sysconfig.d//include.conf -D SYSTEMD -D FOREGROUND'
libpng warning: iCCP: known incorrect sRGB profile

libpng warning might be nothing but aren't you curious?

and I do see a few config files that have // in front? ... which I assume load anyway, even though I would think they should look like:

Include /etc/apache2/sysconfig.d/global.conf

with single / rather than doubles //.

Here's the first concerning LDAP user which you kinda explained:

[Wed Jul 03 00:39:10.827087 2019] [php7:notice] [pid 13483] [client 10.0.26.101:46190] [ENROL LDAP] Server: 'ldap://uranos.paes.eit.htwk-leipzig.de', Connection: 'Resource id #16', STARTTLS failed.\n, referer: https://moodle.paes.eit.htwk-leipzig.de/moodle/login/index.php

STARTTLS is certificate stuff (failed) and appears the user ID is 16 in mdl_user table?

So are all your admin level folks in your Moodle have LDAP as auth or manual?

Last line for Jul 03 and first line for Jul 04

[Wed Jul 03 22:54:32.937747 2019] [php7:notice] [pid 15588] [client 10.0.26.101:47538] [ENROL LDAP] Server: 'ldap://uranos.paes.eit.htwk-leipzig.de', Connection: 'Resource id #33', STARTTLS failed.\n, referer: https://moodle.paes.eit.htwk-leipzig.de/moodle/login/index.php
[Thu Jul 04 07:25:58.234511 2019] [php7:notice] [pid 14922] [client 10.0.26.101:47566] [ENROL LDAP] Server: 'ldap://uranos.paes.eit.htwk-leipzig.de', Connection: 'Resource id #15', STARTTLS failed.\n, referer: https://moodle.paes.eit.htwk-leipzig.de/moodle/login/index.php

In your ssl_request_log-20190703 log ... cannot find 03/Jul in entire log file!!!!

First line: [28/Jun/2019

*** last line ***

[02/Jul/2019:23:52:41 +0200] 10.0.26.101 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "POST /moodle/lib/ajax/service.php?sesskey=AX1iUV0DaP&info=core_fetch_notifications HTTP/1.1" 27 "https://moodle.paes.eit.htwk-leipzig.de/moodle/login/index.php" "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0"

Have already done way over what should be expected - free support. Suggest you review and search logs and IF you see something that looks like an error ... investigate!

Google is your friend!

I'll do below to the best of my ability ... as a community member ... even if I don't work for moodle.net nor admin that server. So can't say what their policies are in how strict registering a server is with them.

1.) Do I right understand, that I can truncated the mdl_registration_hubs table? (I would of course copy the db before ! )?

I said I did a test on a server that doesn't have the issue you have by truncating the table then renewed the registration without error.

And yes, would always be a good idea to make a backup of the database IF manipulating directly. That's SOP!

2.) Are the admin user credentials locally stored in the db?

If accounts are manual, which at least one admin level user should be (ie, no other auth like LDAP), then yes ... everything ... including password ... in the DB server pointed to ... localhost?

User ID's ... 1 is guest user ... 2 was/is the first user that installed them moodle.

mysql> select * from mdl_user where id = 2;

Password is not in clear text but has been hashed, etc.

You can change, however, using admin/cli/reset_password.php for maual accounts only.

3.) What does it mean: ..... You can also manually update your registration at any time.

That bit of info was seen after registering and renewing registration with Moodle.net. I assume it means one can, from the form, update registration info at any time ... but I've not found any CLI script that does that.

'SoS', Ken

Average of ratings: Useful (1)

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Saturday, 6 July 2019, 6:45 AM

Sorry about that, but you did asked for the log files.

What you are complaining about has nothing to do with the problem! That's why I gave you before only snippets from the log file.

Your remarks in the error log file are connected to the missing tomcat instance with mod_jk for the communication between tomcat and apache2 (for AJP). This server was used before for an wisemapping tomcat installation, but we stopped using it in that way. The jk worker was not removed from the apache2 config, so the module was started but could not work and echoed this by each apache2 restart.

You're mistaken about the assumption you made about the apache2 config constellation. Unfortunately I gave you too less information and I want to apologize for that.

I thought too, that you have more knowledge about the internals of the moodle upgrade process - because I think we did not dig into the real cause about that special upgrade process. Tho whole discussion we had is only a distraction - of course that is all my fault, I delivered no clear picture for you.

BUT please don't think that your communication partners are all blind - I know what I'm doing, again that what you are complaining for in the log file is not part of the solution. So, excuse me, I know very well what authentication method we are using. The problem here is only, that we changed a lot at the same time, internal IP with reverse proxy, switching the LDAP-Server, removing our tomcat installation and so on.

WHICH I'm not - I do not know too much about the Moodle internals - that knowledge I thought, I get from the forum! AND you did a great job!! Thanks again.

Because you think your communication partners in some sense are idiots .... you tend to do misinterpret their questions, that's a big failure! I know what I'm saying - I'm a teacher, I'm not a professional administrator, I'm a Professor for Process Automation and Embedded Systems. I have 20 years of experience with Linux systems, but Moodle runs on the side - we have no special administrator, some of my colleagues have admin rights too and so I do not know every detail of the installation, but that's not an apology, of course.

Our institutional Servers are not productive commercial servers - that are servers used for teaching and research issues, and you are right, they are not always optimal set up.

AND this was the first time I asked someone from the community, because I couldn't solve the problem alone.

So, in the end thanks again for yor work! Have a nice weekend and try to stay calm with next questionairs - there are situation, where you simply have too less information for judging.

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Saturday, 6 July 2019, 7:24 AM

PS: Yes, I know how to grepping files - but you asked for eventually errors before the upgrade process and 4 eyes see more than 2 eyes, but now I understand, that I stretched your nerves!

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Saturday, 6 July 2019, 7:53 AM

It is/was a very strange issue ... and difficult to solve/guess! And hard to share info related without disclosing too much as well.

Thanks for your polite response ... yes, guilty! At 71 years 'experience' now I have been told am becoming a 'grumpy old man'! Guilty!

It was Andreas Grabs - Friday, July 5, 2019, 5:18 AM that suggested looking at logs. I agreed ... even if I didn't say so in forum.

Just one more bit of 'discovery' ... for what it's worth ...

Here's something interesting ...

When one goes to your gaheris server, clicks the 'MOODLE' link (the link is in CAPS .... nothing wrong with that am just describing so you know I was there!)

the lock is green and stays green.

When I go directly to the moodle, I get a broken lock and have to make an exception in FireFox.

So, in the end, are you able to get site registration working and admins can now login?

Yes ... do plan to 'kick back' the remainder of the weekend, partake in one or two 'cold ones''!

So ... in the 'spirit of sharing' ... 'grumpy old man' Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Saturday, 6 July 2019, 4:44 PM

No, I did not get further in the process yet.

I will follow your recommendations you made earlier in the forum.

BUT before I'll do that I will check to have all backups of our moodle projects just in case I will "blow up" the whole installation.I have a full backup too, but that's 3 month old! - you see we are not professionals

My strategy is the following:

1.) Have weekend

2.) Put back the server for testing the certification problem into the 'real world' (changing the IP address and DNS back to the old state) - but I do not believe, that this solves the problem.

3.) When 2.) does not work , then going back behind the curtain (IP address, DNS) and then following your recommendation (truncating the mdl_repository_hubs database). By the way, the admin/cli -> php upgrade script gave back, that the system is already upgraded:

>php upgrade.php
Für die installierte Version 3.7+ (Build: 20190628) (2019052000.06) ist kein Upgrade notwendig. Danke für den Versuch!
Translation: For the installed version 3.7+ (Build: 20190628) (2019052000.06) no upgrade is necessary. Thanks for trying!

Again, I'm surprised why it's coming up in German - moodle by itself of course has English and German localization, but the installation was in English .... a lot of questions .... but maybe one of my colleagues changed it.

I will let you know what is happening next week! Hopefully I do not end up with a fresh installation ....

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Ken Task - Saturday, 6 July 2019, 9:11 PM

Heads up ... by the time you have time to do this, Moodle will be 3.7.1 (released just this week). Wonder if there is a fix for the issue.

And just thought of one other possible factor ... with a 10. network more than likely your net also has internal DNS servers. If outside DNS had 2 IP addresses, internal DNS might also have 2 IP addresses.

Plus ... worth checking /etc/host file for maps.

'SoS', Ken

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andrew Lyons - Monday, 8 July 2019, 8:19 AM

Hi Andreas,

I've been meaning to reply to this thread all of the last week but haven't had an opportunity so far.

For starters you need to turn on debugging as this will help to isolate where the issue is coming from. You can do this by adding the following to your config.php:

$CFG->debugdisplay = 1;
$CFG->debug = 32767;

You must add this before the line which requires setup.php.

The HTTPS errors, and DNS issues are unrelated to this issue. It is almost certainly due to a plugin which contains incompatible code so I'd recommend checking for issues with any of the third-party plugins you have installed.

I'm not sure whether the registration is actually your issue. I'd suggest that it probably isn't, but without having more information as to the cause of the issue we can't be certain. From my experience of these issues I would hazard a guess that you have a plugin issue.

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Tuesday, 9 July 2019, 8:23 PM

Thanks for information, I did it already today reading Moodle.doc "... how to debug", I inserted
//=========================================================================
// 7. SETTINGS FOR DEVELOPMENT SERVERS - not intended for production use!!!
//=========================================================================
//
// Force a debugging mode regardless the settings in the site administration
@error_reporting(E_ALL | E_STRICT); // NOT FOR PRODUCTION SERVERS!
@ini_set('display_errors', '1'); // NOT FOR PRODUCTION SERVERS!
$CFG->debug = (E_ALL | E_STRICT); // === DEBUG_DEVELOPER - NOT FOR PRODUCTION SERVERS!
$CFG->debugdisplay = 1; // NOT FOR PRODUCTION SERVERS!

The answer trying to login as admin I got was the following:
1.) the redirected url:
https://moodle.paes.eit.htwk-leipzig.de/moodle/admin/registration/index.php?returnurl=%2Findex.php
2.) the error mesage:
Fatal error: Class 'core_search\area\base_activity' not found in /usr/lib/moodle/mod/organizer/classes/search/activity.php on line 35
When I interpret it correctly, the module organizer makes trouble - can/ shall I uninstall this module on the cli ? (activity.php defines there the class extension to \core_search\area\base_activity).

Andreas

PS.: I updated today to 3.7.1 - the installation process did run without problem, but the admin login problem did not vanish.

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andrew Lyons - Wednesday, 10 July 2019, 7:56 AM

Hi Andreas,

Those classes were renamed in Moodle 3.2.0:

\core_search\area\base_activity has been renamed to \core_search\base_activity

This has actually already been fixed in latest versions of mod_organizer so all you need to do is update to the latest version of mod_organizer by downloading it from https://moodle.org/plugins/pluginversions.php?plugin=mod_organizer, removing the existing installation of it from /usr/lib/moodle/mod/organizer, and unzipping the new one in its place.

You'll be prompted to upgrade, but it should then work.

Best wishes,

Andrew

Average of ratings: Useful (1)

Re: Site administration after upgrade to 3.7+ is not working

by Andreas Pretschner - Wednesday, 10 July 2019, 3:38 PM

Hi Andrew,

Yes, this did the trick! Thank you!

One Question:
You're saying, that this class renaming issue was done in Moodle 3.2.0.
Our old installed organizer module CHANGELOG.txt tells me "3.5.0 (2018-08-10)" and I upgraded our Moodle to the latest stable release (the last was 3.6.+). So why this error happened? Did I something wrong in my update processes?

Finally our site is fully functioning again - the existing flaws discussed with Ken we will fix step by step.

Andreas

Average of ratings: -

Re: Site administration after upgrade to 3.7+ is not working

by Andrew Lyons - Thursday, 11 July 2019, 4:05 PM

When we rename the class we put in an alias as part of our deprecation policy.
That rename is removed after a period (4 releases) and it was removed in MDL-57244 for Moodle 3.6.0 of Moodle.

It was fixed in the plugin in version 3.5.3 onwards (https://github.com/academic-moodle-cooperation/moodle-mod_organizer/commit/34fc7b3d3db946a18e1a971d395991acf1ded896#diff-352a1931f83c36b7fbe56c2619ab244f).

It may be that Moodle 3.7 introduced a change which meant that the relevant file was included when it wasn't before.

Average of ratings: -