Diagnostics Robo Task

[connorshea]

We should have a task for printing diagnostics: ./vendor/bin/robo diagnostics

It'd be useful for debugging problems people have on the forums and on GitHub issues.

It should:

• Print versions of the OS, SuiteCRM, Composer, Apache, PHP, and the database
• Run diagnostics checks, like:
  • Valid SuiteCRM config
  • PHP is on the recommended version or higher
  • PHP is on a supported version
  • Necessary PHP extensions are installed
  • composer validate doesn't return errors
  • composer diagnose doesn't return errors
  • composer check-platform-reqs doesn't return errors
  • File permissions are correct
  • Database exists and tables exists
• Print locations of important files (the CRM itself, the PHP binary, error logs, etc.)
• Maybe also print the PHP INI settings and the SuiteCRM config.php settings?

I'm guessing it'd look similar to this:

Versions

- Operating System: Debian Linux
- SuiteCRM: 7.10.18
- Composer: 1.9.0
- Apache: 2.6.2
- PHP: 7.2.18
- Database: MySQL 5.7.2

Diagnostics

- SuiteCRM Config: [OK]
- Recommended PHP Version (>=7.1): [OK]
- PHP Extensions: [OK]
- File Permissions: [OK]
- Composer Validate: [OK] (Valid with a few warnings)
- Composer Diagnose: [WARN]

Checking composer.json: WARNING
License "GPL-3.0" is a deprecated SPDX license identifier, use "GPL-3.0-only" or "GPL-3.0-or-later" instead
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys: FAIL
Missing pubkey for tags verification
Missing pubkey for dev verification
Run composer self-update --update-keys to set them up
Checking composer version: OK
Composer version: 1.8.6
PHP version: 5.5.9 - Package overridden via config.platform (actual: 7.2.20)
PHP binary path: /usr/local/Cellar/php@7.2/7.2.20/bin/php

- Composer Check Platform Requirements: [OK]
- Database Name: foobar_suitecrm_db_name
- Database: [OK]

PHP/SuiteCRM Files

- SuiteCRM Directory: /www/suitecrm/html/
- SuiteCRM Config:
  - /www/suitecrm/html/config.php
  - /www/suitecrm/html/config_override.php
- SuiteCRM Log: /www/suitecrm/html/suitecrm.log
- PHP INI: /usr/local/etc/php/7.2/php.ini
- PHP Errors: /www/suitecrm/html/php_errors.log
- PHP Binary: /usr/local/Cellar/php@7.2/7.2.20/bin/php

It might help to use the code in this comment (or find a package that does this for us) to determine some of this info: https://www.php.net/manual/en/function.phpinfo.php#117961

We could also have a --debug flag that'd display the diagnostic command output even if the command was successful (we can't use --verbose because Robo already has that).

We should just get a working Robo task developed first, we don't need to cover all of these from the start. Most of these are aspirational :P

cc: @pgorod

[pgorod]

A few comments on things you asked on Gitter, and some additional considerations...

1. Before using any permissions code, please tell me about which code you want to use; much of it is not good code at all, and I'd like to avoid the bad parts.

2. About the phpinfo - I am interested in making sure the Diagnostics have a good sense of whether they're running from CLI or from web server, and it would be great if they could give us information about the other side also (not the one where they're running).

   2a. To get web server info from CLI, you could make an entry-point that you can call with curl and gives you the phpinfo output, but it would require some security mechanism to ensure it's not being called by some anonymous hacker from somewhere. (For example: generate a random Key and write it to tmp dir or database; send it as a parameter into the web entry-point; wait 20 seconds and delete the key. This way the entry-point can check it has a valid code before replying).

   2b. In the opposite direction, diagnostics running from web server could call exec to run a PHP CLI script (could be the Robo task directly), in the servers where that is allowed.

3. Have you used PHP's ini_get function? With it you could retrieve specific php.ini items witouth any screen-scraping.

4. It would be important to retrieve date.timezone information.

5. We should keep stuff that identifies the installation in a separate section, so that users can remove it when pasting stuff online to get help in Forums. Things like site_url and host_name from config.php

6. As the information collected grows, I'm thinking we might want two separate versions of Diagnostics: short and long. I plan to use this task to ask people for reliable information when answering Forum threads, and I don't think I will always need a huge endless list of stuff.

[pgorod]

Oh, and a vital piece of information: which Linux/Windows user name the web server is running under. Same for CLI. There is code for this in a function called getRunningUser, an example of usage is here