M8 Hosting: Tech Support Deficient

I've been implementing SugarCRM in a hosted environment, and in contrast to my earlier post about great open-source customer service, this is a case where customer service is dragging down a product that would otherwise be quite good.

In fairness, I'll start with the good news.  Setup happened really quickly, with SugarCRM already loaded and running.  Mail worked, and I was able to set up ZuckerReports, which I'd been worried about, since I'd had trouble with that on a local test system.  Speed seems great, too.  There's no indication that the servers are taxed, no matter what time of day I check.

So what more could I want?

The problem is subtle, but really nagging.  The permission and ownership settings are all fouled up.

I'll try to describe the problem without dwelling too deeply into Unix / Linux tech-speak.  Linux files are owned by a combination of a user and a group, expressed as "user:group".  Permissions for these files are expressed in terms of who can do what, depending on whether you're (1) the owner of the file, (2) a member of the group that owns the file, or (3) anybody else.

Processes run as users in Linux, so I can log in to a Linux machine had have a set of permissions as "me", but when I do something via a web page hosted on that machine or an ftp session with that machine, I'm working through the web or ftp service, and I'm subject to the permissions granted to that service's user.  This is one of the ways Linux keeps itself secure (you may be able to compromise one account, but you wont be able run amok).

So here's where the trouble starts.

First problem: The web server is a different user than the user we are when we log in via ftp.  Different groups, too.  So when I ftp something up to the web site, it gets saved into the web file area, but the directories and files belong to "me", not the web server.  This isn't a problem unless it's a directory or file that SugarCRM wants to be able to change itself, and there are a surprisingly large number of those.

SugarCRM exacerbates the problem by (frequently) politely swallowing error messages, so what you see is a system that's happily puttering along while things frustratingly fail to save / update.

Next problem: Some SugarCRM customizations need to modify files on the server.  SugarCRM has a (generally) really nice feature called the "Studio" that lets you accomplish many customizations via meta-data and custom files right on the SugarCRM server, in near-real-time.  This makes short work of simple jobs like adding a field to a screen or customizing lists or drop down values.

When you make these changes, however, the web server has to be able to save them, and in some cases, this requires the web server to add one or more directories in order to maintain its structure.  Sadly, this also isn't working on our host.

I can frequently tell when I'm dealing with one of these problems, because they're goofy (something that should obviously be working just as obviously isn't) and because the exact same thing works on my test system.

Here are the two most recent cases where this setup has bitten me:

  • I needed to modify the Leads listview to include another column. Normally, this is a five-minute fix in SugarCRM's studio, so I went in and customized the listview to include the extra field.  I saved the view and went to test it, and no change had taken place. I went back into the Studio and found that my changes had reverted.  I did the same customizations on a local test system, and they worked just fine. I noted the most recently-modified files and saw that custommodulesLeadsmetadatalistviewdefs.php had been changed.  Back to M8 - I used file explorer to look at the directory structure on the production server, and found there was no "metadata" folder beneath "Leads". When Studio tried to create that directory so it could store the newly-customized file, the web server process had been unable to make the directory. If the directory had been created, I don't know if the web server would have been able to create a new file there, but I wouldn't be surprised if that failed, too.  I was able to get the changes to show up only by manually creating the folder and then uploading the file I modified on my test system.
  • I tried installing Ken Brill's advanced search module.  Now, I know that Ken knows how to package modules, and this one went in without a hitch on two separate test systems, but when I installed on the production system, I got an error complaining about permissions.  The workaround in this case was to CHMOD 777 for a couple of big chunks of the directory tree, and then set permissions back to "normal" after installation.

Now, I've begged and pleaded with M8 to get shell access so I could chown these files and directories properly, and they finally granted this to me, but my login didn't have permission to chown to the proper user and group so the web server would be happy again, so I'm still stuck!

This is driving me nuts, and I can't seem to get M8 to understand the problem.

Has anyone else experienced this with M8 or other providers? I'm afraid if this doesn't get resolved soon, I'm going to have to look for a new home for this site.  Needless to say, if anyone knows a good SugarCRM host, I'd be interested in that, as well.

6 Replies to “M8 Hosting: Tech Support Deficient”

  1. David –
    The issue you areDavid –

    The issue you are having is because your host is not using a program called PHPsuexec. This forces PHP to run as your username instead of as nobody. Most hosters love PHPsuexec for security. The result is that you no longer have to maintain permissions for two users for the same folder and will have fewer issues in the long run. We also no longer have to make files group and world readable, so no one can get into your stuff.

    Additionally, if you chmod 777 any sugar files, everyone with access to your server can edit your sugar source files.


  2. Mike –
    Thanks for the tip -Mike –

    Thanks for the tip – that helps a lot. I’ve used hosts that have done this right, so I knew that there was something wrong, but I was never able to penetrate the support infrastructure effectively enough to speak with someone who knew what they were doing. You’re right about the 777 permissions – I really wanted to find another way to do this, but I caved under time pressure.

  3. Your konw while doing this we had a problem.. Whatever your did the same customizations on a local test system i did the same thing and they worked just fine. Its very helpful for me in this situation and thanks for it..
    SFTP hosting

  4. Your konw while doing this we had a problem.. Whatever your did the same customizations on a local test system i did the same thing and they worked just fine. Its very helpful for me in this situation and thanks for it..
    SFTP hosting

Comments are closed.