So the obvious thing here is just to look at the code.
This doesn’t appear to have anything to do with permissions but rather that ./vendor/bin/robo is not looking in the right place for autoload.php. I hadn’t modified these files so this is either a bug that no one else is running into (no one using command line upgrade?) or something weird about my OS/php install in terms of how __DIR__ is defined.
./vendor/bin/robo
…has at the top:
// Non-phar autoloader paths
$candidates = [
__DIR__.'/vendor/autoload.php',
__DIR__.'/../../autoload.php',
];
I don’t know what phar is…but since I am running robo from command line I guess it shouldn’t apply.
So a simple thing to do is check what __DIR__ is so I added echo '__DIR__: '.__DIR__; after the $candidates declaration and tried to run the robo upgrade again…
root@suitecrm:/opt/apps/suitecrm# sudo -u www-data php ./vendor/bin/robo upgrade:suite /tmp/SuiteCRM-Upgrade-7.11.x-to-7.11.20.zip ./upgrade.log . mattp
__DIR__: /opt/apps/suitecrm/vendor/binCould not find autoloader. Run 'composer install'.root@suitecrm:/opt/apps/suitecrm#
The output: __DIR__: /opt/apps/suitecrm/vendor/bin
implies that the $candidates are resolving to:
/opt/apps/suitecrm/vendor/bin/vendor/autoload.php-
/opt/apps/suitecrm/vendor/bin/../../autoload.php (/opt/apps/suitecrm/autoload.php after resolving /../../)
Neither of these paths are correct.
Updating $candidates to add the correct search path for autoload.php (the third entry)…
$candidates = [
__DIR__.'/vendor/autoload.php',
__DIR__.'/../../autoload.php',
__DIR__.'/../autoload.php',
];
and running again…
root@suitecrm:/opt/apps/suitecrm# sudo -u www-data php ./vendor/bin/robo upgrade:suite /tmp/SuiteCRM-Upgrade-7.11.x-to-7.11.20.zip ./upgrade.log . mattp
➜ Upgrade SuiteCRM
[Exec] Running php modules/UpgradeWizard/silentUpgrade.php /tmp/SuiteCRM-Upgrade-7.11.x-to-7.11.20.zip ./upgrade.log . mattp
********************************************************************
***************This Upgrade process may take sometime***************
********************************************************************
PHP Notice: Array to string conversion in /opt/apps/suitecrm/include/database/DBManager.php on line 887
...
********************************************************************
*************************** SUCCESS*********************************
********************************************************************
******** If your pre-upgrade Leads data is not showing ************
******** Or you see errors in detailview subpanels ****************
************* In order to resolve them ****************************
******** Log into application as Administrator ********************
******** Go to Admin panel ****************************************
******** Run Repair -> Rebuild Relationships **********************
********************************************************************
[Exec] Done in 30.202s
➜ Upgrade Complete!
root@suitecrm:/opt/apps/suitecrm#
So is this a bug in robo? If so is no one else upgrading their SuiteCRM installs via command line in order to get security patches?
Or is this some artifact of my OS/install/config. As I mentioned earlier my install is pretty basic. Unzip. Set owner/group. Set folder perms, set file perms.
root@suitecrm:/opt/apps/suitecrm# uname -a
Linux suitecrm.<redacted> 5.4.0-74-generic #83-Ubuntu SMP Sat May 8 02:35:39 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
root@suitecrm:/opt/apps/suitecrm# cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
root@suitecrm:/opt/apps/suitecrm#
