Skip to end of metadata
Go to start of metadata

Drupal (COIS) Discussion notes from 2-24-2010

Present: Susan Tobes, Patrick McGrath, Brian Wood, Marilyn Graham

General Meeting Notes:

  • Current customers hosted using SliceHost
  • Need to bring them back on campus
  • Backlog of people inquiring after new sites to be setup
  • 4 live customers now
    • Summer Sessions - 2-5K plus consulting over a year.  Site Built by the department/consultant. Setup new environment and migrated their code.
    • Campus Life
    • CorWe (taken down--will become part of new HR Website to be launched on Drupal.)
    • Staff Org - Steve Lustig's group
  • Beta release June.
  • The initial offering for is 1 Drupal site per VM.  Not necessarily that cheap.
    • Possible for one client to run multiple sites on one VM
    • Problems with hosting multiple clients on one VM
  • Phase 2 will be a cluster of sites on the same VM, with much more standardization.
  • 3 days to provision a new site under the new model
    • Brian can bring up a new VM/site in 1hr or less
    • 3 days results from waiting on
      • TAM processing
      • VM provisioning (needs to be same day)
      • MySQL provisioning (might already be same day...)
      • UC Backup provisioning (3-4 days)
  • Ease of use with CMS is a driver.
  • UC Berkeley install profile creates new sites configured to use
    • CAS authentication
    • LDAP use attribute lookups
    • UCB Public Affairs Theme
    • Security update release notification
  • (Future) Install profile will be augmented by Drupal Feature Server which can push configuration updates/modifications to all hosted sites.
  • Manuals
  • Aegir product is used to provision sites and deploy updates thru the Drupal farm.  will be used to install, copy, clone, manage, etc. but only for drupal.
  • Puppet ( solution for centralized configuration of VMs
  • the choice of CMS driven by the nature of the site you're trying to get going.
  • Drupal is more complex - more enterprise level
  • high ramp-up on Drupal for tech configuration.  this managed service could make things a lot easier for a wider community in terms of helping to manage that level of complexity.
  • performance is a common issue for sites that have lesser levels of technical knowhow within their departments.
  • A real challenge in IST - how we're able to consume internal services and suppliers
    • No middleware team as an example. 
    • Brian interested in this space, and development work.
  • Looked at leveraging Sharepoint at one point.  usability, rampup issues. time consuming, but would be good to talk through further since it has some good features.
  • Definite performance issues with CalWebPro
  • UCSF Med School has an Aegir implementation going on.
    • Brian has talked to them.  They are in early planning stages
  • DrupalConSF 4/19-21/2010
    • Brian actively networking with higher ed Drupal users (Stanford, UCSF an ASU)
    • Brian initiated Aegir "birds of a feather" session:
  • Definite OE opportunity to consolidate managed Drupal Services
  • Price/Performance - an issue to look at with our internal infrastructure services


  • Ability to update web content without a web master
  • ability to manage roles
  • ability to customize workflows
  • Out of the box support for standards like a unversity theme / authentication.  
  • rolling cross-site updates
  • Brian's automation provides: reliable backups of content (and database)
    • Aegir provides restore with one click
  • good for general broadcast websites (majority of the use-case - just get content out there). brochure sites
  • does good collaboration - wiki, blog, etc.
  • Interactive content creation: course threads/townsend labs site, annotations, etc.
  • Leverage Drupal Simple Test module to configure drupal to test itself (in for functionality/use, etc.) regression testing...


  • Our infrastructure story
  • consuming our own products (UCB VMs, UC Backup...) is costly
  • 1 vm per site - time to provision, etc.   
  • Drupal has wiki capabilities, but they take configuration and fall short of what a focused wiki product like Confluence or MediaWiki offer.

Costs/Staffing -

  • Pretty much Brian at this point for this new service offering.  Plan is for Vahid and possibly one other AS person to head up IST Drupal consulting and to backup Brian on Drupal system administration.
  • Cost model in development.
  • Plenty of demand out there.
  • would be great to look at something like a center of excellence.
  • Brian organizes the Berkeley Drupal Users Group--campus drupal user group a great example of campus level leadership we should adopt further.

Subsequent Info/Thoughts from Brian

Costing Model

Tom Tsai (cc'd) probably needs to be involved in the actual pricing of the service. I've just posted an estimate which should allow Tom to get started on some preliminary pricing:

Service Roadmap

Here it is:

Other Recommendations

A "middleware" group should be created.

The current segregation of system administration tasks-specifically, OS package installation and server tuning-from application development is hurting our ability to rapidly deploy high quality solutions. IST should create a middleware team whose members are skilled system administrators with full root privileges AND experts in their technology areas. (Examples of "technology areas" might be: LAMP, Java/Tomcat…) The middleware team would be responsible for creating centrally managed server configurations yielding servers optimized for the technologies that they host.

Responsibilities of the middleware team would include:

  • Best practices configuration and tuning of servers hosting specific sets of technologies. This may include implementation of memory and byte-code caching for performance optimization.
    Support services for developers in Application Services.
    Some amount of application implementation and testing, i.e. eating their own dog food.
    Performance benchmarking of servers.
    Regression testing.

Speed to market of essential campus services must be improved.

Virtual Machines:

  • We have the ability to configure servers and deploy applications on then in less than 1 hour. We now need the ability to provision virtual machines just as quickly. In the outside market a VM a high performance VM can be requested and provisioned in 15 minutes. IST needs to improve billing workflow and technical procedure related to VM provisioning to approach this level of efficiency.

Campus standards solutions should be reviewed.

  • Shortcomings should be addressed.

Red Hat Enterprise Linux (RHEL):

  • Out of date software packages in the official repositories: RHEL provides only an outdated versions of popular software packages, such as subversion, PHP (version 5.1.6), and Ruby in the official rpm repositories. IST should maintain its own rpms of important packages in a local repository like Failure to provide up to date versions of important software will drive developers to unofficial 3rd party repositories for solutions. Creation and maintenance of RPMs could be a responsibility of the aforementioned middleware group. Note: Debian and Ubuntu maintain current PHP packages(version 5.2.4) in their repositories.


  • To what extent is IST's support contract with RHEL being utilized? How does the service and cost of support compare to other options, for example Canonical's support of Ubuntu?

Software updates:

  • How does RHEL's up2date solution for software updates compare to other options, for example Canonical's Landscape. Features: how easy is it for administrators to hold back a potentially sensitive upgrade to a production system? Price: is our selected standard still the best deal on the market?


  • To what extent is IST benefiting from RHEL-specific features like selinux? Is selinux required to be enabled in non-permissive mode on production systems? If not, how often is it disabled as a result of problems it can cause with applications.

UC Backup

  • File system backups of server are crucial to any system. The current turnaround for a UC Backup order is one week. IST needs to reduce this turnaround to a matter of hours.
  • Pricing of this service needs clarification. Presently a price of $0.25/GB is advertised. Depending on one's configuration the cost can actually be 10 times that much.
  • The installation procedure for the TSM client on RHEL should be improved. This standard solution should be installable as an rpm. Rpm installation is the best practice for use with centralized configuration management solutions. If no official RPM exists, IST should create and maintain one (as mentioned above).
  • No labels