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).
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.
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
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]
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ā¦
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.
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.
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**
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
@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:
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.
Dear @maverickws and @pgr ā¦sorry for this but due to my lacking time I tried to run using sudo 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
Thank you for your effort to help everyone here in using in deep suiteCRM.