Dear,
I am restore DB and mdl_user , and restore mdl_confing and update version from moodle after restore. but now is login problem, after change password , login is again problem, but admin user is in mdl_user
[root@ public_html]# php admin/cli/reset_password.php
== Password reset ==
Enter username (manual authentication only)
: admin
Can not find user 'admin'
[root@ns1 public_html]# ^C
You upgraded from what version of Moodle to what version of Moodle?
'problem again' indicates there was a problem before. What was that problem?
Above might be reason for issue.
Password reset script only works on accounts whose authentication are manual. When you query the mdl_user table for 'username' look for the 'auth' column info - see query below.
mysql> select username,auth from mdl_user where username='admin';
In your config.php file, is there a line for 'dbcollation'?
Does that match what one sees by executing:
php admin/cli/mysql_collation.php -l
At the end of above script, a table summary will display.
What does:
php mysql_compressed_rows.php -i
display?
Relates to the first question in this response.
'SoS', Ken
Uhhh ... "all is ok, but login is not. hosting is ok" - maybe not, other wise you'd be able to login!
Please answer questions ... what is your version of Moodle?
You said this:
"restore DB and mdl_user"
one only needs to restore the DB .. it includes mdl_user table. Did you restore something to the mdl_user table separately?
So ... again ... specific versions of Moodle would be helpful to know in order to help you - other wise may not be able to help at all.
Before issuing the following command:
mysql> select username,auth from mdl_user where username='admin';
At the mysql> prompt **you must select a database** ... the database you set up/created/imported or whatever for your moodle - found in config.php file.
mysql> use [DBNAME];
like mysql> use moodle; [ENTER] where DBNAME is the name of the DB you set up for moodle. Found in config.php file.
Then issue:
mysql> select username,auth from mdl_user where username='admin';
When reading directions for what to run, you have to adjust some times.
This:
[root@ns1 public_html]# php mysql_compressed_rows.php -i
Could not open input file: mysql_compressed_rows.php
shows you were in public_html ... you must have copied and pasted what I asked you to run which is probably not a good habit to make ...
The mysql_compressed_rows.php file is in moodlecode/admin/cli/ your moodlecode is in public_html ... I think.
and can be run via:
php mysql_compressed_rows.php
ONLY if one is in moodlecode/admin/cli/
Otherwise, at location public_html, have to provide the path to the script.
Linux 101 ... your prompt shows who you are logged in as and location:
This: [root@ns1 public_html]#
shows you were logged on as root user on the 'ns1' host and in 'public_html'.
If you do not change directories to issue moodle scripts, then ...
[root@ns1 public_html]# php admin/cli/mysql_compressed_rows.php
On a linux server, you can find out your location by using: pwd [ENTER]
'SoS', Ken
Strongly suggest finding a tutorial or something about basic command line for your distro/OS ... you could be a danger to yourself as root! and these forums are not for the purpose of teaching system admins how to admin their server. :\
Thank you ... finally ... an answer to a question!!!
Now let's try the DB query again to see if admin user is set to manual and if there is a password in the DB for your moodle.
From the config.php file in public_html you will find DBUSER, DBNAME, and DBPASSWORD. Use those values in the following and replace [DBWHATECER] in what you see below ... including the []'s:
mysql -u [DBUSER] -p'[DBPASSWORD]'
Then, at the mysql> prompt do:
use [DBNAME];
Still at mysql>
mysql> select id,username,auth from mdl_user where username='admin';
If the auth column in output above shows 'manual', then the reset_password.php script in your public_html/admin/cli/ should work. That script can change/reset passwords *ONLY* foer 'manual' accounts.
Reset the password. The password: use 1 cap, 1 non-ascii character, and at least 8 characters total in the password to make sure we are in compliance with password policies of a 3.4 Moodle.
Then try to login with browser as admin.
So that we don't get overloaded here ... let's try above and go from there.
'SoS', Ken
For Op as well as others who happen to find this thread ...
Op asked me to access ... provided necessary credentials to do so.
There was an admin user ... password has been changed and OP should now be able to login.
The moodle docs describing upgrading can't cover all situations ... a particular 'tricky' situation is when moodle code has been placed in 'public_html' of users account. One could adjust, but in some cases 'public_html' could include directories/etc. set up by provider ... in this case server is using LIghtSpeed. ... which is one off.
And just in case ... this was a one time freebie. Software might free, but moodle is DiY ... and when it comes to support ... one can use these community forums but Op *must* provide accurate information and be able to 'translate technical' situation/locations/etc. Those trying to help, can't without info ... don't have the ability to do 'Vulcan Mind Melds'.
'SoS', Ken
Recommendations for the Op ....
Create another account where you know login/pass and assign that account to admin levels. Site with only one admin level user could be in trouble.
Learn how to use command line ... just enough to admin the moodle.
Example: create a site backup ... code + minimal moodledata/filedir + DB dump. Guess what? check the bu script in your moodle code.
Another: backup courses to a directory outside of moodledata.
Guess what? check out scripts in code/admin/cli/ ... you have one!
And a biggy ... you, you lucky person, no longer have to struggle with moodle updates or upgrades ... IF you learn a little command line.
Your site is now under git and learning how to use git (the commands or scripts that could be created for you) to update as well as upgrade will save you time ... and errors.
https://docs.moodle.org/37/en/Git_for_Administrators
See the section on:
Updating your installation ... you can do this now.
See the section on:
Obtaining the code from Git
you only need to do line numbers #3,5, and 6 from your code directory
to upgrade from 3.4.highest (your sites current version) to 3.5.highest ... changing the numbers ... how hard is that?
Wow! All that for free! ... and not a word from Op!!!!
Oh, well ...
'SoS', Ken
Welcome! I'll probably not make what I did a habit! :|
You asked via PM 'what was wrong' ... will take this opportunity to share my 2 cent thoughts on shared hosting and the 'traditional' description of upgrading a site.
In typical shared hosting document root for web service is 'public_html' ... that's defined by web service config and as a shared user you cannot change that.
Traditional directions for upgrading say to 'move moodle code out of the way' ... well, catch 22 right off the bat ... moodle code is in public_html ... not a moodle directory.
In your situation you did have 2 moodle code directories inside the 3.4 code of you site ... both were higher versions of Moodle.
Your site uses cPanel and SoftTac for Moodle installs ... did you originally use SoftTac to install the moodle? That would put moodle code in public_html ... not in a 'moodle' directory.
What I think I would do if having to use cPanel/etc. ...
I'd use a 'moodle' directory and code in there ... just like 'tradtional' install/uprades would expect moodle to be located. Then one could move 'moodle' out of the way.
You say you want the moodle to be what folks see when hitting site ... fine ... use an autoforwarding index.html file with 0 seconds wait time (very old tech but still works) ... that forwards to /moodle/
Advantage ... you, the server admin, could install a tinker site in a directory called 'tinker'. You are the only one that knows it's there ... you make no links from other pages that a search engine could find and follow.
So now, when you want to tinker with something .... https://yoursite/tinker/
For directions on autoforwarding page:
https://www.w3docs.com/snippets/html/how-to-redirect-a-web-page-in-html.html
Now that you have your site like it is, I'd not recommend changing until you read up on search and replace tool in Moodle ... Moodle records every internal link and right now your DB has https://yoursite/ as where moodle is located.
The other thing I'd recommend to you, is do read Moodle docs. If you have a question ask!!! Found evidence in your site that you had exported mdl_user table and then imported that table into db for newer version of Moodle by a different prefix ... mdlXXX_user ... thinking one could transfer all users from old site to new higher version site. Same for the mdl_config table. Had to imagine what this meant ... 'restore DB and mdl_user , and restore mdl_confing' in your first post. Sure enough ... you tried a shortcut but ... In both cases, nope ... nada ... will never happen. 3.4 -> 3.7 there could have been a major change (and was) to DB character set/collations DB structure ... etc.
You won't see anything like the paragraph above, @
https://docs.moodle.org/37/en/Upgrading
If you use Moodle docs ... and something goes wrong ... that's one thing ... at least those trying to help you are 'on the same page', so to speak ... but doing what you did and then not really describing that ... exactly ... sent folks helping off into a very deep and dark rabbit hole. I hate going down rabbit holes! :\
'SoS', Ken
