Missing relationship definition after upgrade 7.8 ==> 7.9

šŸ“¦ Install & Upgrade Help
1

Hi, Iā€™m using SuiteCRM, on Ubuntu 16.04 with Virtualmin, quite some time and am happy, but after the upgrade things went wrong:

  • Almost all subpanels are empty and suitecrm.log states: "Missing relationship definitionā€™;
  • I found the file/owner permissions on cache/ Relationsships/relationship.cache.php was www-data / 755 instead of crm_user crm-group 775;
  • If I change that and open a screen e.g. ā€˜Accountsā€™ the file is changed back to www-data and 755.
  • config.php did had a line with www-data, I changed that to crm_user but that didnā€™t alter anything.

As SuiteCRM is running as crm_user the file can be read but not written and I think that thatā€™s the problem.
Cannot find any else wrong or changed on the system.

What is the solution to get the subpanels back as before?
Kind regards Rob

2

Ok, a couple of things:

  • for the relationship problems (subpanels), wait for version 7.9.1, that should fix it. This release was due Monday, itā€™s a bit delayed, but should be out tomorrow.

  • for the permissions thing:

  1. Exactly which v 7.8 were you running? There were some changes in 7.8.3 that are very relevant for this.

  2. How are you launching your cron jobs? We need to make sure this is using the same user as the web server.

  3. Did you change anything else regarding users, for example, upgrade Apache? Is it possible that your Web server is now running as www-data? If you go in Admin/Schedulers, there are some lines on the bottom with instructions for setting up crontab. Here you can see the username that SuiteCRM recognizes as your Apache server user name.

  4. Is there anything in your logs mentioning ā€œcronā€?

3

Hi, Thanks for the quick reply.

  • I will wait for 7.9.1 then and hope it will be fixed in that release;
  • About the permission thing:
  • I was running 7.8.2;
  • You are write by the cron jobs although I donā€™t understand
  • At the bottom of Admin/Schedule: sudo crontab -e -u www-data
          • cd /home/crm_user/public_html; php -f cron.php > /dev/null 2>&1
  • thought crontab -e -u www-data is empty and crontab -e -u crm_user ==> cd /home/crm_user/public_html; /usr/bin/php7.0 cron.php > /home/crm_user/public_html/cron_error.log 2>&1
  • the log file had ā€˜cronā€™ entryā€™s: cron.php: running as crm_user is not allowed in allowed_cron_users in config.php. But thatś since the update 12 june and no more after I changed the config.php accordingly
  • the webserver hasnā€™t changed, non of the other virtual servers are running as www-date, but I did had some php updates.
  • Iā€™ve set the +i attr on the file, so it cannot be changed. I see no process complaining.
  • the permission change was executed the moment I opent e.g. an account tab, so no relation with cron crossed my mind

Thanks sofar and I hope this sheds some more light.

Kind regards, Rob

4

Ok, so running the cron jobs as a different user than your web-server user is a bad practice, and since 7.8.3 there is a new mechanism in place to control that.

But it seems your problem is that you changed your web-server user to www-data without knowing it or intending it.

So SuiteCRM is ā€œpullingā€ in the direction of a configuration with www-data as the user, and you are still pulling in the opposite direction.

So you need to reconcile that:

  1. Either leave the web-server as www-data, use www-data in config.php (allowed_cron_users), and reset ownerships on all files as www-data

  2. Or alternatively get your web-server back to crm_user, and keep crm_user in config.php, and in the file ownerships.

You can read a full explanation here:
https://pgorod.github.io/Scheduler-Jobs/

5

Hi pgr,

Running only virtual servers, though Apache envar\s = www-data for user and document root, non of the servers are running as such or using that document rootā€¦
The problem seems to lie in php 5.6 and/or 7.0 both on the system. And Iā€™ll look into that, but has nothing to do with SuiteCRM.
And, refering to the other post ā€œUpdate ruined everythingā€ , I"m also running FastCGI. And I also see a chown + chmod issues opening e.g. account page.
The crontab on the system is correct as crontab - e -u www-data is empty. The data Admin/Schedulers provides is incorrect IMModestO.
The way the entry is written correspondents with a system global cron which is not the case in Ubuntu 16.04 and, as said, crontab for user www-data is empty, so nothing runs as that user. The relevant cron runs is as user crm_user which is the correct user that also runs the application.

It seems that in 7.9 (7.8.4 ?) Apache envar or phpinfo is used to collect this data but in virtualmin the virtual servers arenā€™t running as such.

Hope that 7.9.1 comes quickly, as thatā€™s the main point for now.
Thanks for the help of course,
Rob

6

This is the code used to fill ā€œallowed_cron_usersā€ array in config.php:

/**
 * Gets the username of the user under which the PHP script is currently running
 * Notes:
 * - works on Windows and Linux, tries a variety of methods to accommodate different systems and hosting restrictions
 * - on Windows, return full username in form DOMAIN\USER
 * - returns empty string if failed
 */
function getRunningUser()
{
    // works on Windows and Linux, but might return null on systems that include exec in
    // disabled_functions in php.ini (typical in shared hosting)
    $runningUser = exec('whoami');
    if ($runningUser == null) {  // matches null, false and ""
        if (is_windows()) {
            $runningUser = getenv('USERDOMAIN').'\\'.getenv('USERNAME');
        }
        else {
            $usr = posix_getpwuid(posix_geteuid());
            $runningUser = $usr['name'];
        }
    }
    return ($runningUser == null) ? '' : $runningUser;
}

This code is new, introduced in 7.8.3, and I wrote it. I would love to know if this is returning an incorrect web-server user in your system, and try to understand exactly why.

7

Hi Pgr,

I also had that problem on fresh install. My config.php shows:

'allowed_cron_users' => 
array (
  0 => 'apache',
),

Since Iā€™m on shared hosting and installed the 7.9.4 using Softaculous I had to manually go into config.php and chnage the user ā€˜apacheā€™ to my account username to execute CRON using:

          • /opt/php71/bin/php -q /home/my_username/my_suitecrm_dir/cron.php > /dev/null 2>&1

as it wouldnā€™t execute for some reason using suiteCRM suggested:

          • cd /home/my_username/my_suitecrm_dir; php -f cron.php > /dev/null 2>&1

Hope this helps and hope I am also executing CRON correctly.

8

Softaculous uses one user when installing SuiteCRM (apache), then another one when running it (specific to your user area).

So when the SuiteCRM installer registers the user and uses it to fill allowed_cron_users automatically in config.php, it ends up adding a useless value.

This is already difficult enough without Softaculous pulling these stunts on usā€¦ :frowning:

9

Hi,

Thank you for a quick answer. I can only imagine the complexities the developers are facing caused by a multitude of suiteCRM installation techniques and different hosting environments.

Maybe when rebuilding a config.php from admin > repair > Rebuild Config File, it could do some additional check on the current user?

Anyways, as long as this method or running CRON is fine, then I will move on to debugging other problems. :slight_smile: Thanks again for your reply and for your hard work on suiteCRM. It great now, and it will get only better! :wink:

Best,