« Node Ref Create & Node Import | Main | Shibboleth at UM »

February 17, 2011

Notes on ITS hosted Drupal Install - Common tweaks

You probably should start with ITS's guide for hosting drupal on their virtual servers.

Email via the www-sig email list from CC:

I wouldn't say hosting a Drupal site with ITS has no problems. It's entirely doable (I've installed three there now), but here's just a sampling of a few things that many prospective Drupal admins will have to do to make it work just right...

- ask them increase php upload limit
- ask them increase suhosin limits
- ask them increase php max filesize
- wrestle with drupal cosign module integration oddities (like the super user admin needing to be an a real u-m person with a kerberos login - but who wants the admin login to be specific to one person who could leave that post some day? makes no sense).
- the need to add fairly common php modules via the drupal config page (settings.php). For example (from my settings.php file):

/** * Custom settings, some specific to UM ITS servers */

# This should load the gd library needed for images:
dl( 'gd.so' );
# To make Insert module use relative URLs, insert this into your settings.php file:
# http://drupal.org/node/622964#comment-2451810
$conf['insert_absolute_paths'] = FALSE;

# Load unicode support if not already present
if (!extension_loaded('mbstring')) {
if (!dl('mbstring.so')) {
exit;
}
}

# For the XML Sitemap module
if (!extension_loaded('xmlwriter')) {
if (!dl('xmlwriter.so')) {
exit;
}
}


- default Drupal .htaccess requires changes for successful installation. Try commenting out all of the Options, for starters.
- and more. For example, to access the ITS error logs for a site. "Use a web browser to view /cgi-bin/logs on your host (http://your-web-site.umich.edu/cgi-bin/logs)." - http://www.itcs.umich.edu/web/log-viewer.php


Here is a Drupal 7 related note (with error):

PHP Fatal error: Call to undefined function json_encode() in ~/includes/common.inc on line 4807

Solution is to add the following to settings.php:


if (!extension_loaded('json')) {
if (!dl('json.so')) {
exit;
}
}


These aren't MASSIVE inconveniences (aside from the cosign issue). But they're annoying. And it means that you have to jump through extra hoops just to get your Drupal install to work with ITS hosting, whereas most commercial Drupal hosts make the installation and management of Drupal sites their core business. Therefore, it works better.

We chose U-M hosting mainly out of loyalty. But there are plenty of commercial Drupal hosts out there who offer incredible services (like one-click Drupal site creation, full access for managing the files, dev-to-production workflows, and more). I use a commercial service for my sandboxes and it costs less than $150 a year and I couldn't be happier. I know that's more expensive than ITS hosting. But the reasons are obvious.

Also, a quick note or two about the wasup Drupal service*: you have to send them modules, libraries, and themes to install for you (no FTP access to the "sites/all" directory) - a big inconvenience in my opinion. Also, I noticed a lag in updates to Drupal core. I don't find it a very useful service beyond the most simple site-building tasks. Some use it for their main site. They must not mind the extra steps.

* This statement appears to be <100% accurate, here's a reply from drupal-people:


This actually isn't true because they can now set up a spot in AFS for
you that will sync to the sites/yourdomain.com/ directory. Combine
that with your VCS hosted on Codeblue and you have a pretty good
deployment process - no FTP required, just SSH into your AFS spot and
pull updates in to be synced. Also I think your statement regarding
sites/all is a little misleading, since this isn't what you really
need access to in a multi-site setup like theirs. Your comment about
a lag in Drupal core updates is true though since their version is
about 2 years old now with many missing security updates and
incompatibilities with newer modules, something most would find
unacceptable in a cloud hosting platform.

Posted by kkwaiser at February 17, 2011 04:41 PM

Comments

I was the original author of most of the above (it was a reply to a question about issues hosting Drupal on IFS).

As for the accuracy of what I wrote about the Wasup service, those options for syncing to Wasup Drupal sites did not exist at the time I was exploring usage of Wasup.

I specifically asked if access to control contrib modules and themes would be possible and I was told 'no.' They obviously altered what was possible, which is great.

It is true that "sites/all" wouldn't be the destination for a person's account on such an installation - that was just a mistake of habit (in fact, if it's symbolic links, it could be almost anywhere on their system).

Lastly, the lack of automated security updates actually proved to be more of a deal breaker for us than the lack of direct FTP access to modules and themes. A lag in mods/themes is one thing. But vulnerability to cross-site scripting attacks is another.

Posted by: cacody at August 11, 2011 12:13 PM

Login to leave a comment. Create a new account.