After new installaton of server/moodle, create and run this script.
DB may undergo tweaks in config and this could help in seeing changes
over longer periods of time and where one forgot to comment the config file for DB server changes.

Replace [user][password] below to yours.

mysql -u [user] -p'[password]’ -e “show variables;” > dbvariables-$(date +%Y%m%d%-H%M%S).txt;cat dbvariables-.txt; echo ‘———————————————————-‘; echo ‘Search dbvariables-datetime.txt file via grep for variable.’; echo ‘Files to search ….’; ls -1 dbvariables.txt

To see socket info:

grep socket dbvariables-20190904104601.txt

renders only:

performance_schema_max_socket_classes 10
performance_schema_max_socket_instances -1
socket /var/lib/mysql/mysql.sock

Using the DB for the site, run this query:

mysql> select id,filename,filesize,contenthash from mdl_files where filename like ‘%.mbz’;

Example of short output

id filename filesize contenthash
30142 backup-moodle2-course-98-certification_dl_7.5-20190418-0934.mbz 132098673 29276404a04217e4132df5bd84c62f58bc48e8c1
above made with zip

31079 backup-moodle2-course-98-certification_dl_7.5-20190815-0933.mbz 488311474 67558034a8e1e18136589366ded294c28132cacd
above made as .tar.gz

The last column is the contenthash and it will be used to find file by that name in moodledata/filedir/

cd /path/to/moodledata/filedir/
find ./ -name 29276404a04217e4132df5bd84c62f58bc48e8c1
shows
./29/27/29276404a04217e4132df5bd84c62f58bc48e8c1

To check file type:
file -b ./29/27/29276404a04217e4132df5bd84c62f58bc48e8c1
if above returns
Zip archive data, at least v2.0 to extract
The backup file was made at a time when Moodle was using zip for archiving courses and
there were issues with backing up courses whose backup file size 4 Gig or larger.

The second example given above:

file -b ./67/55/67558034a8e1e18136589366ded294c28132cacd

shows
gzip compressed data, from Unix
and is a backup made with archiving set to .tar.gz … which is the default now
for vr 3’s of Moodle. Reason file sizes are larger in this info, course has been used for a number
of years.

Copy those files out of moodledata/filedir/ and rename them using .mbz extensions so they can be used
to restore to other moodles.

From /path/to/moodledata/filedir/

mkdir /root/moodlebackups/

cp ./29/27/29276404a04217e4132df5bd84c62f58bc48e8c1 /root/moodlebackups/cid98-20190418.mbz

cp ./67/55/67558034a8e1e18136589366ded294c28132cacd /root/moodlebackups/cid98-20190815.mbz

[root@staging filedir]

# ls -l /root/moodlebackups/

-rw-r–r– 1 root root 132098673 Aug 15 09:47 cid98-20190418.mbz
-rw-r–r– 1 root root 488311474 Aug 15 09:48 cid98-20190815.mbz

php cfg.php –help

Displays the current value of the given site setting. Allows to set it to the given value, too.

Usage:
# php cfg.php [–component=] [–json] [–shell-arg]
# php cfg.php –name= [–component=] [–shell-arg] [–no-eol]
# php cfg.php –name= [–component=] –set=
# php cfg.php –name= [–component=] –unset
# php cfg.php [–help|-h]

Options:
-h –help Print this help.
–component= Name of the component the variable is part of. Defaults to core.
–name= Name of the configuration variable to get/set. If missing, print all
configuration variables of the given component.
–set= Set the given variable to this value.
–unset Unset the given variable.
–shell-arg Escape output values so that they can be directly used as shell script arguments.
–json Encode output list of values using JSON notation.
–no-eol Do not include the trailing new line character when printing the value.

The list of all variables of the given component can be printed as
tab-separated list (default) or JSON object (–json). Particular values are
printed as raw text values, optionally escaped so that they can be directly
used as shell script arguments (–shell-arg). Single values are displayed with trailing new line by default, unless explicitly disabled (–no-eol).

In the read mode, the script exits with success status 0 if the requested value is found. If the requested variable is not set, the script exits with status 3.
When listing all variables of the component, the exit status is always 0 even
if no variables for the given component are found. When setting/unsetting a value, the exit status is 0. When attempting to set/unset a value that has
already been hard-set in config.php, the script exits with error status 4. In
case of unexpected error, the script exits with error status 1.

Examples:

# php cfg.php
    Prints tab-separated list of all core configuration variables and their values.

# php cfg.php --json
    Prints list of all core configuration variables and their values as a JSON object.

# php cfg.php --name=release
    Prints the given configuration variable - e.g. $CFG->release in this case.

# php cfg.php --component=tool_recyclebin
#   Prints tab-separated list of the plugin's configuration variables.

# export DATAROOT=$(php cfg.php --name=dataroot --shell-arg --no-eol)
    Stores the given configuration variable in the shell variable, escaped
    so that it can be safely used as a shell argument.

# php cfg.php --name=theme --set=classic
    Sets the given configuration variable to the given value.

# php cfg.php --name=noemailever --unset
    Unsets the previously configured variable.

Handy when upgrading and there is an incompatible theme from old version of Moodle upgraded.

php cfg.php --name=allowthemechangeonurl --set=1

Would then allow browser /?theme=boost or whatever was upgraded code theme default.

Let’s say you have several individual task you’d like to run … but
not one at a time … too time consuming.

Example … several ‘cleanup’ task.
Create a file called ‘cleanup’ in admin/cli/tool/cli/
It consist of one liners that are the commands one would have keyed in
one at a time.

Looks like:

php schedule_task.php –execute=”\logstore_legacy\task\cleanup_task”
php schedule_task.php –execute=”\logstore_standard\task\cleanup_task”
php schedule_task.php –execute=”\core\task\file_trash_cleanup_task”
php schedule_task.php –execute=”\core\task\messaging_cleanup_task”
php schedule_task.php –execute=”\core\task\password_reset_cleanup_task”
php schedule_task.php –execute=”\core\task\session_cleanup_task”
php schedule_task.php –execute=”\core_files\task\conversion_cleanup_task”
php schedule_task.php –execute=”\tool_recyclebin\task\cleanup_category_bin”
php schedule_task.php –execute=”\tool_recyclebin\task\cleanup_course_bin”

make the ‘cleanup’ file executable.

To execute use ‘source cleanup’

Each task will be executed and it’s output displayed … example:

Execute scheduled task: Cleanup of temporary records for file conversions. (core_files\task\conversion_cleanup_task)
… used 2 dbqueries
… used 0.0052680969238281 seconds
Scheduled task complete: Cleanup of temporary records for file conversions. (core_files\task\conversion_cleanup_task)
Execute scheduled task: Cleanup category recycle bin (tool_recyclebin\task\cleanup_category_bin)
… used 1 dbqueries
… used 0.0043408870697021 seconds
Scheduled task complete: Cleanup category recycle bin (tool_recyclebin\task\cleanup_category_bin)
Execute scheduled task: Cleanup course recycle bin (tool_recyclebin\task\cleanup_course_bin)
… used 1 dbqueries
… used 0.0046000480651855 seconds
Scheduled task complete: Cleanup course recycle bin (tool_recyclebin\task\cleanup_course_bin)

In moodle 3.6 there is now a config for path to php.
Look in Moodle Admin. Search for System Paths – Path for php-cli

Typically the path to php-cli is found via:

whereis php

from the command line.

But to see if the one found is php-cli, issue the following command with the
full path as seen in whereis php above.

/path/seen/php -v

If you see anything other than (cli) in the first line,
that’s the wrong one for command line scripts in moodle/code/admin/cli/

Once the path to php-cli is found, one needs to decide how to make that
environment setting for the shell the default.

In home directory of a user using bash shell, there is or should be a .bashrc file (settings for that user in bash).

Add the following line to the end of the document (without quotes):

“alias php=/path/to/bin/php”

(change the PHP path to the one found for php-cli)

nano .bashrc

Juat below the #User specfic aliases and functions comment
which says:

User specific aliases and functions

add the alias.
The example below is not for all systems but an example.

alias php=/opt/cpanel/ea-php70/root/usr/bin/php

Save the .bashrc file. Logout. Log back in.

Test by exeuting php -v

This is what one wants to see **

customerlogin@vmxxx [~]# php -v
PHP 7.0.33 **(cli)** (built: Feb 5 2019 02:28:35) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.33, Copyright (c) 1999-2017, by Zend Technologies

The. ‘cli’ above emphsized here with ** in front and ** behind.
You will/should see just (cli).

Perfect! Now all the php scripts in moodlecode/admin/cli/ can be executed
with just php in front … not the path shown in help.

Example:

customerlogin@vmxxx [~/public_html/moodle/admin/cli]# php cron.php

Instead of what is shown to help:

/usr/bin/php admin/cli/cron.php

** if you execute what is shown in help you might get the php meant for the web service.

Some Moodle servers seem to have a hard time communicating with the repo for Moodle from time to time … CloudFlare ray issues. When one has a script built which is pretty much ‘brain dead’ … e.g. not ‘smart’ and a simple 1-2-3 thing, if Moodle HQ’s git repo can’t be contacted, all of the rest of the script is pretty much useless.

Wanted a way to check to see if the git repo was available. Here’s how:

git ls-remote git://git.moodle.org/moodle.git

Doesn’t have to be executed inside a code directory installed with git.

Side benefit … not only checks access but shows

9ab6e6b20acad01f35134036e55d21ac5d835cd2 refs/tags/v3.5.4

The first column of info is handy for going after a particular branch.

A quickie …

LiquidWeb moodle server allocated from WHM. PHP set to place error logs in
directories where the error occurs.

Problem … PHP/Moodle errors may not tell you whare it errored accurately.
How to find those error_log files.

Bash shell script at the root of the moodle code:

Called: finderrorlog
Contents of above script a one liner: find ./* -name error_log

Run with source finderrorlog

would kick out as an example something like:

./admin/tool/task/cli/error_log

Now one can cat the error log via
cat ./admin/tool/task/cli/error_log

to see what’s up.

No GUI to the moodle and need to check the environment to see if the server meets specs?   No problem now … with a shared .php file in admin/cli/ one can check the environment and it will tell what needs updating etc.

Since the cli script is not in official Moodle releases
a git pull for an update or even an upgrade to moodle
should cause a git error … complaining about a file it doesn’t know about.
That’s a good thing … but how to get around it?

Now to figure out how to tell git to ingnore.
https://help.github.com/articles/ignoring-files/

Me thinks .gitignore best ..

https://github.com/github/gitignore

at the root of the moodle code diretory.
There should already be a .gitignore so just add a line ** see below

If there isn’t a .gitignore create one:

touch .gitignore

Then edit .gitignore with a text editor … nano used in example:

nano .gitignore

add one line:

./admin/cli/envcheck.php

Save the .gitignore file

Now when doing git pulls or upgrades git won’t complain! 🙂

The code .. contributed by Howard in Moodle forums
https://moodle.org/mod/forum/discuss.php?d=379601#p1530402