Drupal

Misinformation: A response to Chris Wilson's Whitehouse.gov article on Slate

in

Yesterday, I came across one of the most fabricated and agenda-laden articles I've ever seen in the world of software and open source, "Why running the White House Web site on Drupal is a political disaster waiting to happen". (no-followed)

Despite wishing "Drupal and the White House nothing but happiness" at the outset, Chris Wilson quickly moves to scare the beejezus out of you about Drupal and make sure everyone understands that the thousands of people coming together to provide really awesome free software are actually all user-hating Nazis and that Drupal is a REALLY. BAD. THING.

Unfortunately, the thing about misinformation is that it often does cause a stir. As one can see from this comment left on another article about Whitehouse.gov, a well known and curious Joomla developer is linking to the propaganda piece and referring to it as a "very different view". So misinformation success, it's now a 'point of view' whether Drupal folk are all user-hating nazis or not.

The software world is not generally the hack-political world where all one needs is an implication and a "reliable source" to start a false "debate" on whether something is true or not. But the slate article, and reactions to it, does demonstrate the point that the Drupal community needs to be prepared to address misinformation. This is a (large) annoyance, of course (more time fighting propaganda ='s less time coding or helping newcomers), but as a great person once said, "With great power comes great responsibility".

UPDATE: Informationweek.com weighs in with some sense on this issue:

"The news that WhiteHouse.gov relaunched this week running open source Drupal software raised eyebrows and hackles among knee-jerk anti-Obama types and a small cadre of ignorant bloggers."

Whitehouse.gov now powered by Drupal

Word is out that Whitehouse.gov is now powered by Drupal. The Washington Post has the details of this big win for Drupal and Open Source:

"The online-savvy administration on Saturday switched to open-source code for http://www.whitehouse.gov meaning the programming language is written in public view, available for public use and able for people to edit.

"We now have a technology platform to get more and more voices on the site," White House new media director Macon Phillips told The Associated Press hours before the new site went live on Saturday. "This is state-of-the-art technology and the government is a participant in it.

Under the open-source model, thousands of people pick it apart simultaneously and increase security. It comes more cheaply than computer coding designed for a single client, such as the Executive Office of the President. It gives programmers around the world a chance to offer upgrades, additions or tweaks to existing programs that the White House could - or could not - include in daily updates.

Yet the system - known as Drupal - alone won't make it more secure on its own, cautioned Ari Schwartz of the Center for Democracy and Technology.

"The platform that they're moving to is just something to hang other things on," he said. "They need to keep up-to-date with the latest security patches."

Improving your Drupal site's security: Cracking Drupal review

If you're a Drupal professional, you owe it to yourself and your clients to internalize the lessons and techniques inside Cracking Drupal: A Drop in the Bucket. This is true because, statistically, any insecurities in one's site are many times more likely to be introduced by one's own custom theming/modules than by Drupal core. The book mentions the audit of a high-profile Drupal site that uncovered 120 security issues, of which the vast majority were found in the customized theme layer! (much more than from contrib/custom modules even)

There are many good things to choose from, but for me the best thing about Cracking Drupal is that I finally have a definitive one-stop place to go for information about Drupal security: what to watch out for, how to test it, best practices, worst practices. It's all there.

Finally, keep in mind that just reading this book will not of itself make your site more secure. I've had to re-read certain things a few times before it sunk in all the way. A process helped along even more by downloading the vulnerable.module, the module the book uses for many of its examples, and testing out the examples inside of it for a few hours.

Many thanks to greggles for putting this together for the Drupal community. For another review of Cracking Drupal see Aaron's write up of it.

Provisioning and install script for a speedy Drupal workflow

I made this script and the database backup, dump, and SVN commit script because I was determined to spend as little time as possible doing sysadmin while setting up dev and staging sites, so that I could spend as much time as possible developing (e.g., the fun stuff). With one command the script can:

  • 'svn up' a version controlled database, and upload it to your database
  • Run queries against database to set preferred site defaults
  • 'svn up' site docroot
  • Copy over fresh "files" directory from another site (e.g., production). Note, not a good option if you have your "files" directory version controlled.
  • Set owner:group file permissions on all site files
Syndicate content