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.

osCmax svn and reporting which revision is in use

So I started this morning looking to download the latest svn version of osCmax. I am sure the elves have been grinding at the various parts of osCmax providing general users with an improved system for ecommerce.

So I go to http://code.google.com/p/oscmax2/source/checkout and grab the svn command line and use it on my dev linux server to get the latest version.

Start up a fresh site and run the Installer. Which politely informs me that I am using osCMax Power E-Commerce v2.0.25.

WTF? It is 2.5RC2 in the latest download release, why is it still displaying v2.0.25? Hummphhh! I’ve got multiple svn versions and I try to use the code and templates that I develop across the latest public release and more recent svn’s in order to get the best from my sites.

EDIT: The above 2.0.25 was correct because the oscmax2 svn source page gives the latest release version information resulting in that version being downloaded by svn. The more appropriate command line is for a linux testing svn download is
[text]
#svn checkout https://oscmax2.googlecode.com/svn/branches/dev/2.1/ oscmax2-read-only
[/text]

So is there a better way? How about getting the svn version number and publish it alongside the PROJECT_VERSION.

To keep this as a short post this was my way around this:

Create a new file in catalog/includes/svn.php and paste in the following code:

[php]
<?php
/*
$Id: svn.php

osCMax Power E-Commerce
http://howden.net.au/thowden/

Released under the GNU General Public License
*/
// A quick’n’dirty test of publishing to a developer the svn version that is being used

// svn numbering if .svn directory exists then assume that the developer would like to see
// the current version in addition to the PROJECT_VERSION which is consistently out of date
if (!defined(‘REVISION’)) {
if (file_exists(‘.svn/entries’)) {
$svn = file(‘.svn/entries’);
if (is_numeric(trim($svn[3]))) {
$version = $svn[3];
} else { // pre 1.4 svn used xml for this file
$version = explode(‘"’, $svn[4]);
$version = $version[1];
}
define (‘REVISION’, trim($version));
unset ($svn);
unset ($version);
} else {
define (‘REVISION’, 0); // default if no svn data avilable
}
}

?>
[/php]
Save the file and change to edit the install/includes/application.php:
At line 37 which shows

[php]
define(‘PROJECT_VERSION’, ‘osCmax v2.5.0’);
[/php]

and change or insert the following in place of line 37, noting that this is a if else wrap around for the line.

[php highlight=”3″]
require(‘../includes/svn.php’);
if (REVISION == 0) {
define(‘PROJECT_VERSION’, ‘osCmax v2.5.0’);
} else {
define(‘PROJECT_VERSION’, ‘osCmax v2.5.0 svn: ‘.REVISION);
}
[/php]

Then repeat for the main admin application catalog/admin_dir/includes/application_top.php at line 32.

Then repeat again for the main application edit catalog/includes/application_top.php at line 45 except that you removed the ../ from the require() so it is
[php]
require(‘includes/svn.php’);
[/php]

What this does is check for the .svn directory to exist. It will not(should not?) exist in a packaged install like 2.5RC2 but will exist in an svn download. Appending the REVISION to the PROJECT_VERSION constant means that it will appear in all the relevant places in the osCmax site.

Thanks to AD7six at the Bakery for the svn code snippet.

Edit: Thanks to Michael for correcting my understanding of the release version being available from the svn by default and not the latest dev version. However, since writing this post version 2.5 has been released !!

WordPress and Breadcrumbs

Some WordPress themes that I like don’t have a breadcrumb option. So the next best thing is a plug-in and the one I like is Breadcrumbs Plus.

The first thing to do to use this, after installation, is confirm which file you need to edit and I’ll guess it will be header.php for the theme but it could be somewhere else depending on your theme and where you want the breadcrumb to appear.

Once you know where, just add this section of code to the appropriate file, and magic will happen.

[php]
<?php if ( function_exists( ‘breadcrumbs_plus’ ) ) breadcrumbs_plus( array( ‘singular_post_taxonomy’ => ‘category’ ) ); ?>
[/php]