These step-by-step install instructions show how to install Sugar SugarCRM, starting with a freshly installed Host Europe Linux Virtual Server 4.0 (XXL,but probably valid for any package size). For other webhosting providers, you might need to adapt these steps, but the general outline is the same, as long as you want or need mod_suphp (else, the installation is much simpler).

  1. Register and set up a domain, using Host Europe as the domain registrar.
  2. If you want, create a subdomain for the CRM installation, using Plesk.
  3. Change the Apache PHP handler from mod_php to mod_suphp.
    • By default, a Host Europe VPS runs PHP in “cli” mode (not in “cgi” mode via mod_suphp or mod_suexec). This however creates a bunch of file permission problems in a SugarCRM deployment: the SugarCRM install scripts create files with www-data:ww-data ownerhip, which cannot be accessed by the FTP or SSH user who installs the CRM. Together with PHP’s safe_mode it is even wore: the SugarCRM files are owned by a FTP or SSH user, so SugarCRM itself cannot access the files it created during the installation (which are owned by www-data).
    • Also, using mod_suphp allows more restrictive file permissions on the SugarCRM files. In the “cli” mode, they must be readable by the web server (running as www-data), which means world-readable. Many directories even have to be world-writable or the installation script complains. With mod_suphp, the webserver runs the PHP scripts with the permissions of the file owner, so they have to be readable and writable by the file owner only. Which will most probably be a SSH or FTP user.

    • Execute as root via SSH:

      apt-get install libapache2-mod-suphp

    • The APT post-install script will automatically configure the suPHP engine and switch it on (the steps detailed in ). The configuration added is located in /etc/apache2/conf.d/suphp.conf.

    • Check in the output of your phpinfo script that mod_suphp is listed in “apache2handler: Loaded Modules”.
    • Disable the mod_php5 module by removing the symbolic links to its config and LoadModule files:

      rm /etc/apache2/mods-enabled/php5.conf;
      rm /etc/apache2/mods-enabled/php5.load;

    • Probably remove “-ExecCGI” from /var/www/vhosts/ from the corresponding virtual host. That very file must not be edited or Plesk might stop to work, so you need to overwrite the setting by creating /var/www/vhosts/ and create the right VirtualHost tag there and a +ExecCGI option in it, like this (adapt your IP address and domain name):

      <Directory /var/www/vhosts/>
      Options +ExecCGI

    • Restart Apache:

      /etc/init.d/apache2 restart

    • Call a phpinfo script to check if the PHP handler is now mod_suphp and if that works. It does, if the regular phpinfo output appears and the “Server API” value is “CGI/FastCGI” instead of “Apache 2.0 Handler”.
      • A phpinfo script is a file containing “<?php phpinfo(); ?>”.

      • Note that the file owner of a script has to be a “non-system user” (UID > 10000, so not www-data for example) and no directory on a script’s root path must be group- or world-writable. Else, mod_suphp will not work and Apache outputs a “500 Internal Server Error” to the browser. In that case, look up the error message in /var/www/vhosts/
  4. Raise the PHP memory limit to at least 40 MiB.
    • Change the line in /etc/php5/cgi/php.ini that starts with “memory_limit” to this:

      memory_limit = 64M

  5. Raise the allowed PHP upload file size to at least 6 MiB.
    • Change the line in /etc/php5/cgi/php.ini that starts with “upload_max_filesize” to this:

      upload_max_filesize = 10M

  6. Check if your settings for upload file size and memory limit are in effect.
    • Restart Apache:

      /etc/init.d/apache2 restart

    • Call a phpinfo script (a file with “<?php phpinfo(); ?>” in it) and check the values. It must reflect your changes both in the columns for local and master value.

  7. Get over the session save path check in the installation.
    • According to this source, the code in installSystemCheck.php that checks the availabilit of the session directory is broken. So checking that oneself and commenting it out helps, as done here.

    • Check the “session.save_path” setting in the phpinfo output and ensure that this directory is writable by PHP CGI scripts.

    • If your PHP configuration uses the open_basedir setting (see the phpinfo() output), ensure that the session save path is covered by the open_basedir setting. If necessary, add it to /var/www/vhosts/ by making it now look something like this:

      <Directory /var/www/vhosts/domainname.tld/subdomains/crm/httpdocs>
      <IfModule mod_php4.c>
      php_admin_value open_basedir "/var/www/vhosts/"
      <IfModule mod_php5.c>
      php_admin_value open_basedir "/var/www/vhosts/"
      Options +ExecCGI

    • Comment out the whole “if” code block below “// session save dir” in install/installsystemCheck.php .

  8. Create a SSH user for managing the SugarCRM deployment.

    • Managing by SSH is much more comfortable than using FTP, and mostly also much more performant.

    • If you want, you can use the existing FTP user for the CRM’s domain or subdomain and allow SSH access to it. This makes it possible to manage the SugarCRM deployment by both SSH and FTP.

    • Create a new user in a Linux shell, and allow SSH access to it.
    • Add the new user to the psacln group.

      • “psacln” is “Plesk server administrator, client side” and usually the group of all httpdocs files.

    • Switch into the directory for the SugarCRM installation and grant the new user ownership of all files, like this:

      cd /var/www/vhosts/;
      chown -R exampleuser:psacln *;

  9. Create a MySQL database and a MySQL user with full rights to that.
  10. Put the SugarCRM 5.5.0 files in place.
    • SugarCRM 5.5.0 was the latest stable version at the time of deployment (2009-12).
    • Log in via SSH as the user for SugarCRM management (working as root is no longer necessary).
    • Get and install the files:

      cd /var/www/vhosts/; # Adapt with your domain name and perhaps subdomain name.
      chown :psacln SugarCE-Full-5.5.0/*;
      mv SugarCE-Full-5.5.0/* .;

  11. Call the install.php script you just unpacked from your web browser and follow the instructions.

    • Choose “Custom install” when your are asked.

  12. When asked, install the German language pack.
    • Download the German language pack (created for SugarCRM 5.2j) from . There is also the “official” German language pack (referred to on ), but it currently (2009-12-22) is only available for version 5.0: .

    • Upload it in the form that asks you for that.

  13. Cure permission problem with respect to mod_suphp.
    • mod_suphp means only that PHP scripts run with the permissions of its owner; regular HTML and JavaScript files are still served by Apache, using the www-data user. Now SugarCRM has the nasty attribute to create new directories in cache/ with the “drwxrws—” scheme and new files in cache/ with the “-rw-rw—-” scheme. Which is meaningful for mod_php5 handled hosting (if the files’ owner or probably group is www-data), but conflicts with mod_suphp.

    • It is no solution to use group “www-data” for all the files, as mod_suphp will then throw a “500 Internel Server Error” because the group must be set to a non-system group (GID > 10000).

    • So the solution must be to tell SugarCRM to create all files and directories world-readable (except perhaps .php files). This is no security problem, as these files are anyway served publicly by Apache as they are.

    • Edit /etc/suphp/suphp.conf and change “umask=0022” there instead of originally “umask=0077” and then restart apache. This does not help on its own, but is necessary because else umask will subtract permissions when SugarCRM has the right intentions with permissions.

    • Edit config.php in your SugarCRM httpdocs directory, and locate this section:

      'default_permissions' => array ('dir_mode' => 1528, 'file_mode' => 432, 'user' => '', 'group' => '',),

      These numbers are decimal. They mean directories are created with 2770 in octal notation (rwxrwx—) and files with 660 (rw-rw—-). This is exactly what SugarCRM was found to do. What we need however on a mod_suphp setup is 0755 for directories and 0644 for files ( ). Which leads to changing above line to this:

      'default_permissions' => array ('dir_mode' => 493, 'file_mode' => 420, 'user' => '', 'group' => '',),

    • Now, when logging into SugarCRM using a theme that one has not used up to now, should result in a page incuding CSS layout information. When it does, the problem is cured. What remains is to get the permissions right for those files that SugarCRM created before we applied this cure. To that end, execute the following as SSH user in the document root of the CRM’s domain / subdomain:

      chmod -R u=rwX,g=rX,o=rX *

      Or alternatively, to cure the defects in the SugarCRM default permissions:

      chmod -R a+r,o+X *

      This will cure the problems with cache/* files but also with files that belong to the language pack, like these: jscalendar/lang/calendar-ge.js.

  14. Create users.
    • Log out of SugarCRM.
    • Log in again, selecting “English (US)” in the login screen’s options. Creating users does not work in SugarCRM CE 5.5.0 when logging with the German language pack for SugarCRM 5.2j from . Then, clicking the button simply does nothing. Eliminating the error checks in the onClick action (using Firebug) does not help anything. Clicking the “Cancel” button works, however.

    • Click “Admin -> User management” and new users.

3 thoughts on “How to set up SugarCRM Community Edition 5.5RC4 with mod_suphp?

  1. Thank you Matthias for this excellent guide! I had big trouble with a sugarcrm instance running on a Hosteurope VPS. With your advice I could improve performance. Thanks again!

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> 

This site uses Akismet to reduce spam. Learn how your comment data is processed.