Overview
Advanced Configuration options enable you to exercise tighter control over user actions in your Sugar instances.
Locking Down Upgrade Wizard, Module Builder, and Backups
If you are managing multiple instances of the Sugar application, you can maintain complete control over the Sugar instances by preventing users with administrative privileges from making any changes. To do this, you can lock down the Upgrade Wizard, Module Builder, and Backups.
To lock down the Upgrade Wizard, Module Builder, and Backups
1.
|
Navigate to the config.php file in the Sugar root directory.
|
2.
|
Set the following parameter as shown below:
|
$sugar_config[’admin_access_control’]=true
3.
|
Save the file.
|
Restricting the Module Loader
To ensure that users with administrative privileges do not load sub-standard modules into Sugar, you can restrict the Module Loader to a specific directory that you control. This allows you to check modules before they are loaded into Sugar.
To restrict the Module Loader
1.
|
Navigate to the config.php file in the Sugar root directory.
|
2.
|
Set the following parameters as shown below:
|
$use_common_ml_dir=true
$common_ml_dir=’ml directory’
where ml directory is the name of the directory from which module will be loaded into Sugar.
3.
|
Save the file.
|
Limiting System Resources
By default, Sugar terminates any request or post that runs more than 1000 queries. For reports,export, import, administration, and synchronization, the maximum number of queries allowed is 50,000 per request. This prevents user-initiated processes from taking up too many system resources. You can change these settings as desired in the config.php file.
Configuring Default Permissions for Sugar Files on Linux
If you are running Sugar on Linux platform, you can control ownership and accessibility to all Sugar files and folders by configuring default user and group permissions.
The following is an example of setting Read, Write, and Execute permissions for the Apache user and the Apache group on Centos operating system:
’default_permissions’ => array(
’dir_mode’ => 02770,
’file_mode’ => 0660,
’chown’ => ‘apache’,
’chgrp’ => ‘apache’,),
For dir_mode, you may see a value of 1528, which is the decimal equivalent of the octal value 02770. For file_mode you may see a value of 432 which is the decimal equivalent of octal value 0660.
Cache upload enhancements
Changing upload directory
To enhance performance of the Reports module, you can configure a slave database to share the load with the master Sugar database.
The upload directory is set by the upload_dir configuration variable. The default value is upload/, which is the upload directory inside the Sugar installation directory. You can set it to any path in the filesystem by putting the absolute path of the new upload directory into this variable.
Note: Remember to copy files from the old upload directory into the new upload directory for accessibility.
The upload directory should be writable by the user running the webserver.
Changing cache directory
Sugar uses a cache directory to store files (such as compiled templates, aggregated variable definitions, remote mailbox data, various cache files) produced by the system to optimize functionality and enhance system performance. These files can take considerable space, especially in larger systems. Administrators can move the cache directory to a location outside the Sugar install directory to ensure space availability. The location of the cache directory is stored in the configuration variable cache_dir and the default value is cache/ - i.e. cache directory inside the Sugar installation directory. It can be set to the absolute filesystem path of the new cache directory.
Some of the cache files can be accessed by direct URLs. So if you move the cache directory, you should also ensure that the URL/cache/ (relative to the main SugarCRM site URL) on your webserver is configured to refer to the new cache location. For more information on how to configure mappings between URLs and filesystem directories, refer to your webserver documentation.
The cache directory should be writable by the user running the webserver.
