Monthly Archives: March 2012

cPanel and 451 Temporary local problem

This was a new cPanel server and I was setting up the first account for email but tests via the webmail client were not being sent. The error was similar to the title of the post with a ‘Try again later’ message.

So I went trawling through the account settings and came up with nothing. So I read somewhere the the /etc/localdomains may be the issue, so I checked that file and the appropriate domain was there in all its glory so that was not the issue.

More Google searching and I wind up at the appropriate cpanel forum with a post that appeared relevant.

http://forums.cpanel.net/f5/451-temporary-local-problem-14251.html

The post that caught my eye was the one that suggested to run script to fix /etc/localdomains

You can run /scripts/mailperm and it will add all domains to the /etc/localdomains

So I ran this and despite the being no apparent change to /etc/localdomains the email is now working. My guess without looking at the mailperm script, is that it does something more than just set the localdomains list. No time to investigate further and its working.

SugarCRM, IIS7, PHP and configuring php.ini

Seems that every time I look at a SugarCRM on Windows installation it is a case of the devil being in the details.

Windows 2008 server can be painful at times. Granted it is locked down by default to protect us from the more informed black hats that may get into our systems, but sometimes it just makes it hard to do work.

This time the Sugar install was done by others and it worked except that the Sugar pages were blank. That is the login page worked and the headers and menu bars in the pages were ok, but the Home page, Accounts, etc did not display anything, i.e blank pages.

So I started at the basics and checked the PHP configuration:

  • Set post_max_size to at least 60MB
  • Set upload_max_filesize settings to at least 60MB
  • Set max_input_time to a large number
  • Set memory_limit to 256MB

Then check for PHP in the path environment variable and the PHPRC variable set. I have written up the details of that in another post on IIS7 and PHP 5.3.x

The Sugar installer can be re-run to use it’s System Check to confirm the write permissions without losing anything. Change the sugar config.php file setting ‘installer_locked’ => true to ‘installer_locked’ => false and run the install.php file. This will prompt for some settings but the system check comes before anything else.

In this case the System Check page identified that most directories were not writeable. So I made some changes as per below and clicked the ReCheck option on the System Check page to confirm that the directory was fixed.

Setting write permissions to the various directories within a Sugar install on a linux server is pretty straight forward with assigning Apache or the account that Apache runs as the write permissions. Windows is similar except that it can be obscured depending on how detailed the sysadmin was when configuring the server accounts.

By default granting permissions to the local machine IUSR account should get it working. Start by adding the IUSR account as default Read type permissions to the entire Sugar directory. Access this from the directory Properties -> Security tab.

Then add specific Modify (Full control is not needed) access to the cache, custom, modules, and upload directories level which should automatically include the subdirectories and files by default.

Check each of the directories that the Read-Only flag is unchecked on the General Tab of the properties window.

Once you have the write permissions correct and the systemcheck gives the go ahead, just edit the config.php and set ‘installer_locked’ => true again. Close the install script without proceeding and run Sugar again. In this case I had been successful and Sugar was doing exactly as it should.