Sugar 4.5.0d - permissions, role management and future upgrades

**curadebt** · 2006-10-09, 02:25 AM

Hi all

I've just done a clean install of the open source 4.5.0d, haven't had much time to look at it but there's a few points I'd be gratefull if someone could clarify (please note, I am fairly new to the whole website side of things therefore my apologies if they appear obvious to some).

Permissions - with the 4.5.0d install, all folders are now 777 and all files 666. According to my host, this is a security issue. At my host, folders are to be no higher than 755 and files no higher than 644. Is there a valid reason to have everything writable to the world?
Role management - as you can see from the attached, I seem to have something missing. Any ideas what and why?
Future upgrades - I was unable to upgrade from 4.5.0b to 4.5.0c or 4.5.0d (hence the clean install) as every time I tried to it hung on the first step eventually trying to download index.php. This also resulted 9 times out of 10 in being unable to move to another page without having to close and reopen and login again (kept trying to download index.php). I'm guessing that this was due to a timeout on the server as I couldn't see any errors in the logs (have it set for 6 minutes but being on a shared server, they kill scripts that run for more than 2 or 3 minutes). Is there any way to upgrade manually so I can get around this?

From what I've seen Sugar looks like it may well meet our requirements and although I have read a few posts re certain issues such as the email system, I also get a sense that it gets bigger and better every release. Kudos to the developers and all the people that contribute to this product

**kpit** · 2006-10-09, 03:23 PM

Originally Posted by curadebt

Hi all

I've just done a clean install of the open source 4.5.0d, haven't had much time to look at it but there's a few points I'd be gratefull if someone could clarify (please note, I am fairly new to the whole website side of things therefore my apologies if they appear obvious to some).

Permissions - with the 4.5.0d install, all folders are now 777 and all files 666. According to my host, this is a security issue. At my host, folders are to be no higher than 755 and files no higher than 644. Is there a valid reason to have everything writable to the world?
Role management - as you can see from the attached, I seem to have something missing. Any ideas what and why?
Future upgrades - I was unable to upgrade from 4.5.0b to 4.5.0c or 4.5.0d (hence the clean install) as every time I tried to it hung on the first step eventually trying to download index.php. This also resulted 9 times out of 10 in being unable to move to another page without having to close and reopen and login again (kept trying to download index.php). I'm guessing that this was due to a timeout on the server as I couldn't see any errors in the logs (have it set for 6 minutes but being on a shared server, they kill scripts that run for more than 2 or 3 minutes). Is there any way to upgrade manually so I can get around this?

From what I've seen Sugar looks like it may well meet our requirements and although I have read a few posts re certain issues such as the email system, I also get a sense that it gets bigger and better every release. Kudos to the developers and all the people that contribute to this product

1. The answer is not changing permissions it is changing ownership to the user that the webserver runs. (usually apache under Linux) The main reason for this is the web upgrade functionallity. On a shared host this is a real problem as any because any shared host can read and write to files that are owned by apache. Shared hosting is not the best solution for SugarCRM. It is better to have a virtual dedicated host or dedicated host for SugarCRM for security reasons.

2. Do you have any modules disabled? It might be a bug.

3. This may be related to how much memory PHP is allowed to consume on your shared host. This problem is with php running out of memory to run and is aborted because you exceeded the limit set in php. If you have access to a php.ini file you have to increase the memory limit to be 64M for sugar to work effectively. Not all shared hosts allow this to be changed by you. Another possability is your shared host overloads your server and has issues with timeouts.

SugarCRM is best run in virtual dedicated hosts and dedicated host for more thant 5 users.

**curadebt** · 2006-10-09, 09:45 PM

Hi Max

Thanks for the reply

I'll look into that when I get a chance, I believe the ownership is apache but I'll confirm it. At the moment I'm just having a play with Sugar externally, no real users or data as such, with the view to implementing on an internal server if the decision to go with it is made . . . had a sneaking suspicion that it would be too resource intensive for shared in a real world environment and not the sort of data you want in a shared environment
Nope, as far as I remember before the clean install no modules where disabled. Hmmmm, shouldn't RSS be in there? No sign of RSS, maybe that's what's missing.
Yep, increased memory limit to 64MB and max execution time to 360. Problem being I think is my host recently deployed Squire (some sort of resource use policing script), with a policy of killing scripts that run for more than a couple of minutes. Files can be whitelisted (had to have a backup file for the site I actually use the hosting for whitelisted) but haven't raised it with them for Sugar yet as I'm just getting a feel for it and not trying to deploy for real.

Thanks again for the reply, gives me a few more things to look at/think about

regards
Harry

PS For anyone else reading this wondering about an easy way to change the php.ini file, I found the scripts here to be invaluable (appends your changes to the server version, then run a cron to update it now and then therefore no worries if something changes in the main script).

**s.gnali** · 2006-10-25, 02:05 PM

In relationship to your question n° 2 (missing label in management table) I can tell you this is a bug.
Unfortunately Sugar developers forgot to add an appropriate value in the label array for that module; it doesn't affect functionalities but actually you are assigning user permission on an unknown thing!!!

Missing module label is "Merge Records" (can find source in modules/MergeRecors); I'm not sure to what it refers (I've just discovered the problem) but to correct the bug simply add the following line to your include/language/en_us.lang.php file:

'MergeRecords' => 'Merge Records'

before line 87 (i.e in moduleList array).

Hope this is useful!
SG