I am stepping through the migration from 7.14.5 to 8.7.
Files have been copied, legacy folder added, vendor/include folders moved and whatnot. I have run the setup command from the command line and have no response:
./bin/console suitecrm:app:setup-legacy-migration
The migration walk through suggests that I should be prompted with a manual setup of session-dir and site_url. Neither of these things are being requested.
I know that the command is running as the first time I ran it I was prompted to upgrade my PHP to version 8.1 which I have done. This is a test instance so I can start over if need be but would rather see how I can dig out of this.
session_dir=“”
site_url is set to my installation/public directory, more specifically I have a domain pointing to “public” as the document root.
1 - On your SuiteCRM 8 instance root (For example: /var/www/<SuiteCRM8> ) run: ./bin/console suitecrm:app:setup-legacy-migration
2 - You should be prompted to do the manual step for checking and updating values on legacy config
Looking at my server PHP modules I have all the dependent modules listed with the exception of these 2:
cli
common
My understanding is that as I can SSH into the server and call a PHP script the cli module is installed. running php -v from a terminal returns:
PHP 8.1.28 (cli) (built: Apr 16 2024 22:03:04) (NTS) …
Well I have gone through the server setup a number of times to validate that everything is setup correctly and was unable to execute the legacy-migration command.
In an effort to verify that my server is setup correctly to run Suite8 I actually did fresh installation of 8.7.0. I had a LBL_ACTION_ERROR come up but did a permissions reset and it fixed the layout issues as has almost always been the case with SuiteCRM permissions matter!
Anyway, my plan is to attempt another clean unzip of the migration files, then attempt the process again and see what happens.
Not sure exactly what I did different this go but I’m up. The migration when swimmingly on my test instance.
Repeat of previous statement: Permissions Make a HUGE difference, make sure to set them correctly. This is the only thing I can think of that may have tanked my original attempt.
This is not true and it is a pity that these things are perpetuated. If your ownerships and permissions schemes is correctly designed, and you know what you’re doing, you only have to set ownerships and permissions once for the lifetime of SuiteCRM.
What you’re all doing is running commands (such as the upgrade scripts) under a different user and “stealing” the files from web-server-user ownership. No wonder it breaks.
These are Linux (well, Unix, actually) issues and they are notoriously hard to grasp unless you really study how things work. But it’s also not black magic…
Understood, I am sorry for perpetuating the myth. However, once I did get the install scripts to run, the last line of ALL THREE migration scripts suggested to once again set the permissions.
I would agree that once set correctly the permission’s stability is not an issue. I have been running versions of Sugar/Suite CRM for a long time and once the system is set up correctly, permissions are not an issue.
Again, I am sorry if I implied that permissions just randomly change, that was not my intent.
Yes. Except that user www-data usually is configured in a way that you can’t login with it.
Basically there’s a best-practice saying it’s better if your web-server-user is just that and nothing else; so that if you get hacked from the web server process (which has a lot of exposure), the hacker’s access to the rest of your server is limited.
So what I do for dev machines is drop www-data altogether and set the web server to run as my normal user. Everything is always owned by my normal user.
For production machines, I would leave the www-data user in place, but take extra care so that maintenance commands don’t break things. There are several schemes to achieve this, like giving access by the group, and making your personal user part of www-data group. Or using commands like sudo to run maintenance tasks on behalf of www-data.
@QuarterPint I think the tutorials have given up on educating people and just anticipate that people will break their permissions, and things will need constant fixing…
