Upgrading from 8.4.0 to 8.4.2

Hi there, I am going to upgrade my suiteCRM from 8.4.0 to 8.4.2.

Before action I want to check the right steps just because during the last upgrade I got problems with permissions (I was upgrading from 8.2.4 to 8.4.0).

I am following this steps: https://docs.suitecrm.com/8.x/admin/installation-guide/upgrading/ so I have the zip file (SuiteCRM-8.4.2.zip) on /var/www/html/suitecrm/tmp/package/upgrade folder but these are permissions/ownership info about the zip file:

-rw-rw-r--  1 ubuntu   ubuntu   82595606 Nov 20 10:26 SuiteCRM-8.4.2.zip
drwxr-sr-x  3 www-data www-data     4096 Sep 13 16:55 suitecrm-8-4-0-backup
drwxr-sr-x 10 www-data www-data     4096 Sep 13 16:55 suitecrm-8-4-0-extracted
-rw-r--r--  1 www-data www-data 83080453 Aug 29 08:18 suitecrm-8-4-0.zip
drwxr-sr-x  3 www-data www-data     4096 Sep 13 16:54 suitecrm-8-4-0.zip-backup

What I have to do before launching the following command ?
sudo ./bin/console suitecrm:app:upgrade -t SuiteCRM-8.4.2

Have I to change the ownership of SuiteCRM-8.4.2.zip file ?

Thanks in advance, Vincenzo

The ownerships and permissions on the zip file arenā€™t too relevant, as long as you have enough access in your console user to execute the unzipping operation.

I suggest that you donā€™t run the console command with sudo, that will just increase the odds that you get messed up ownerships afterwards.

After the process runs you can check if the ownerships and permissions are correct, or simply re-apply them.

1 Like

Ok, I run the command and got this output:

ubuntu@ip-172-31-42-117:/var/www/html/suitecrm$ ./bin/console suitecrm:app:upgrade -t SuiteCRM-8.4.2
PHP Deprecated:  Return type of Symfony\Component\HttpFoundation\Session\Attribute\AttributeBag::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/html/suitecrm/vendor/symfony/http-foundation/Session/Attribute/AttributeBag.php on line 134
PHP Deprecated:  Return type of Symfony\Component\HttpFoundation\Session\Attribute\AttributeBag::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/html/suitecrm/vendor/symfony/http-foundation/Session/Attribute/AttributeBag.php on line 144
PHP Deprecated:  Return type of Symfony\Component\HttpFoundation\Session\Session::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/html/suitecrm/vendor/symfony/http-foundation/Session/Session.php on line 131
PHP Deprecated:  Return type of Symfony\Component\HttpFoundation\Session\Session::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/html/suitecrm/vendor/symfony/http-foundation/Session/Session.php on line 141

SuiteCRM Upgrade
============

Running: backup-original-modules

In StreamHandler.php line 115:

  The stream or file "/var/www/html/suitecrm/logs/prod/prod.log" could not be opened in append mode: Failed to open stream: Permission denied


suitecrm:app:upgrade [-t|--target-version TARGET-VERSION]

Permission denied on /var/www/html/suitecrm/logs/prod/prod.log file.

If I ls -l it I got

ubuntu@ip-172-31-42-117:/var/www/html/suitecrm$ ls -l /var/www/html/suitecrm/logs/prod/prod.log
-rw-r--r-- 1 www-data www-data 14412853 Nov 14 17:52 /var/www/html/suitecrm/logs/prod/prod.log

What is the right thing to do ?

What I would do:

  • add ubuntu user into the www-data group
  • reset all ownerships and permissions correctly in the entire SuiteCRM directory
  • retry the upgrade
1 Like

Dear pgr, I really appreciate you help ā€¦ but same error, these are step taken:

sudo usermod -a -G www-data ubuntu

and if I checked if ubuntu is in the www-data goup running this command

ubuntu@ip-172-31-42-117:/var/www/html/suitecrm$ groups ubuntu
ubuntu : ubuntu adm dialout cdrom floppy sudo audio dip www-data video plugdev netdev lxd

After this I run this commands to set permissions

ubuntu@ip-172-31-42-117:/var/www/html/suitecrm$ sudo find . -type d -not -perm 2755 -exec chmod 2755 {} \;
ubuntu@ip-172-31-42-117:/var/www/html/suitecrm$ sudo find . -type f -not -perm 0644 -exec chmod 0644 {} \;
ubuntu@ip-172-31-42-117:/var/www/html/suitecrm$ sudo find . ! -user www-data -exec chown www-data:www-data {} \;
ubuntu@ip-172-31-42-117:/var/www/html/suitecrm$ sudo chmod +x bin/console

and run
ubuntu@ip-172-31-42-117:/var/www/html/suitecrm$ ./bin/console suitecrm:app:upgrade -t SuiteCRM-8.4.2

The error got is the same:

PHP Deprecated:  Return type of Symfony\Component\HttpFoundation\Session\Attribute\AttributeBag::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/html/suitecrm/vendor/symfony/http-foundation/Session/Attribute/AttributeBag.php on line 134
PHP Deprecated:  Return type of Symfony\Component\HttpFoundation\Session\Attribute\AttributeBag::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/html/suitecrm/vendor/symfony/http-foundation/Session/Attribute/AttributeBag.php on line 144
PHP Deprecated:  Return type of Symfony\Component\HttpFoundation\Session\Session::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/html/suitecrm/vendor/symfony/http-foundation/Session/Session.php on line 131
PHP Deprecated:  Return type of Symfony\Component\HttpFoundation\Session\Session::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/html/suitecrm/vendor/symfony/http-foundation/Session/Session.php on line 141

SuiteCRM Upgrade
============

Running: backup-original-modules

In StreamHandler.php line 115:

  The stream or file "/var/www/html/suitecrm/logs/prod/prod.log" could not be opened in append mode: Failed to open stream: Permission denied


suitecrm:app:upgrade [-t|--target-version TARGET-VERSION]

I think you took the correct steps.

You can ignore the ā€œDeprecated errorsā€, they are future errors, not present ones.

The real problem is permission denied on the log. You need to figure out why.

Maybe some process has the file locked. Maybe you have selinux or some anti-virus blocking it. Maybe you can try opening the file in a text editor, change it and save it, to see if you have accessā€¦

1 Like

@vincenzo

when on the SuiteCRM base dir, you can use the runuser command, like so:

runuser -uwww-data -- ./bin/console suitecrm:app:upgrade -t SuiteCRM-8.4.2

The deprecation warnings are just warnings, but regarding files permissions and everything else, running the update as the user that actually owns the stuff gets it through.

1 Like

@maverickws answer reminded me of something - when I add my user to the www-data group I also change the group digit in the permissions:

sudo find . -type d -not -perm 2755 -exec chmod 2770 {} \;
sudo find . -type f -not -perm 0644 -exec chmod 0660 {} \;
sudo find . ! -user www-data -exec chown www-data:www-data {} \;
sudo chmod +x bin/console

I also choose to lower the final (world) digit to 0, because, why would I want people accessing my CRM that way? Itā€™s safer with a 0 there.

This way the runuser is not needed and any logged in user that is part of www-data group gets the same access as the www-data user itself.

The runuser option is also a (different) valid way to approach it, of course.

Opening, using nano editor, /var/www/html/suitecrm/logs/prod/prod.log as ubuntu user the file is unwriteble

The same file, using sudo nano, is writeble

I am going to run upgrade using sudo :slight_smile: ā€¦just more study in the next hours

When applying permissions to the SuiteCRM folder, my choice is slightly different:

chown -R apache.apache . && \
find . -type d -exec chmod 2755 {} \; && \
find . -type f -exec chmod 644 {} \;

Ideally the settings are 644 in the event the web server should be able to read them despite the owner of the files. On a security point of view, the owner of the files shouldnā€™t be the web service user. But the web service needs read access. That is why we go for 644 and 755.
In my example the SuiteCRM is owned by the apache user, and that is the security issue right there. Actually in prod the user would be nobody.

# id nobody
uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)

In any way, 770 or 775 and 660 or 664 are not permissions I recommend in a production setup.

I tried to use runser but ā€¦


ubuntu@ip-172-31-42-117:/var/www/html/suitecrm$ runuser -uwww-data -- ./bin/console suitecrm:app:upgrade -t SuiteCRM-8.4.2
runuser: **may not be used by non-root users**

@vincenzo

You need to understand and work permissions, owners, groups and users, because it seems youā€™re kinda clueless about what youā€™re doing.

Obviously using sudo you are able to edit, you are using elevated user permissions to edit the file.

to use the runner command, put sudo before runuser
sudo runuser -uwww-data -- etc

This is also something you need to learn first, what is sudo and when to use it. Not very complicated once youā€™ll learn it youā€™ll know it for life, get some understanding on that

1 Like

@vincenzo please post the results of

ls -al /var/www/html/suitecrm/logs/prod/

@maverickws regarding your preferred settings - how does your production web server user write to the files? SuiteCRM is not your average application - it is an app that writes itself. Thatā€™s why I give write access to the web server userā€¦

Identifying all the files that will be written (usually thatā€™s a cache, tmp, logs folder) and setting appropriate permissions for those folders or files alone.
(itā€™s more or less comparing the same work as one needs to do to apply SELinux policies).
An application properly built should write logs to /var/log and use /tmp but well thereā€™s all kinds.

Ok, this makes sense - but then the production system you describe above was not something you have tested (including the use of Studio, Module Builder, etc, things that write out new PHP code).

I agree that if extra access is limited for some dirs, it should be limited to those dirs and not others. That was kind of the approach for v7, where this was recommended:

  sudo chown -R www-data:www-data .
  sudo chmod -R 755 .
  sudo chmod -R 775 cache custom modules themes data upload
  sudo chmod 775 config_override.php 2>/dev/null

There you see the extra permissions for some directories. Although the advice is not very consistent unless more things are explained regarding owners and group memberships.

For v8 I guess they gave up on this level of detail. Those dirs still exist (although under public/legacy) and they still need write access.

So I still prefer to give my accesses through the Group digit, and add my user to the www-data group, and leave the world digit at 0. But I do agree with you that it would make sense to set things differently for only some dirs.

It would actually be a good idea to jointly come up with some sort of ā€œbest practicesā€ recommendations for this. Hopefully, something that is straight-forward for clueless sysadmins, since SuiteCRM has a lot of those (comes with the territory of being a powerful free software).

This SuiteCRM is installed on a test web server and itā€™s me using it throughout the day as support for my activities, in order to identify its caveats and if it can be considered a viable solution both for ourselves as for others as something worth pursuing and invest on.

I am also hoping that the ā€œlegacy dirā€ will disappear in a couple of versions as things get migrated to the ā€˜non-legacyā€™.

I just wanted to address - in regarding the permissions - that the web server admin should always be aware of the implications of the users and permissions being used to run the services, and why I donā€™t usually go for the ###0 permissions. Then I find it interesting the debate on each setup and why. (I understand you, you understand me, and our friend here gets different little insights).
Also a good way to push @vincenzo to get aware of these subtleties of owner/group/users and running users.

My estimate for the disappearance of the legacy dir would be somewhere between 5 years andā€¦ never.

Thereā€™s just too much stuff in there. This app is huge.

I do think it will become residual in a couple of years, but there will be a ā€œlong tailā€ where it never really finishes walking out the doorā€¦ this is because of the ā€œlaw of diminishing returnsā€, some things will be too much work to get rid of, and not bring much improvement. So the scarce resources will force us to keep having that.

2 Likes

Which brings us back to the old tale of the wasted community resources.

Anyway, letā€™s make room for @vincenzo

2 Likes

Dear @maverickws and @pgr ā€¦sorry for this but due to my lacking time I tried to run using sudo :sob:
ubuntu@ip-172-31-42-117:/var/www/html/suitecrm$ sudo ./bin/console suitecrm:app:upgrade -t SuiteCRM-8.4.2

ā€¦ everything is ok now, I have suiteCRM 8.4.1 up and running :slight_smile:

Thank you for your effort to help everyone here in using in deep suiteCRM.

Vincenzo