Pronounced "drupal-art", noun referring to Drupal code that is both beautiful and artistic.

We previously explored the idea that software is art, one of many creative disciplines. We examined art through the eyes of both the layman and the artisan, and meandered from traditional art to software art. We looked at pseudo code and glanced at PHP. I looked for beautiful code in Drupal core and concluded that Drupal's beauty is not in its code, but in its API's.

Relational Art

Without the relation the artist has with art (the time and attention that goes into the work), or without the relation the art lover has with art (the time viewing, collecting and enjoying the work), art would be nothing more than an object of clay, canvas, or cloth. We find value in objects, but appreciate beauty through connections.

I find the deepest beauty in relational art; paintings and sculptures that embed relations within the art object itself, mostly those that depict people in loving relationships with each other. Renoir’s Luncheon of the Boating Party is a great example, showing multiple interactions of people, pet, food, and drink.

Are You a Gazelle or a Bank?

When thinking about the security of a site based on a system like Drupal, it's valuable to decide if your site is a gazelle or a bank; that can help you prioritize your actions related to security, and determine a strategy for securing your site. This article starts by explaining the bank vs. gazelle categories, and then gives ideas for how to protect your site depending on which kind you have.

The Asymmetrical Nature of Security

The first thing to consider when running a site is that as the site owner you have to be proactive in keeping your site 100% secure. An attacker only needs to find one vulnerability. This asymmetry creates one of the biggest challenges in running a secure site and often leads developers and operations teams to take extreme measures to protect their sites. It's not uncommon to hear about combinations of preventive and detective protection in multiple layers. Just one example I'm aware of: a site that uses a Denial Of Service prevention tool at the DNS layer, a CDN with a built-in web application firewall (WAF), and a WAF on the read-only-publicly-accessible staging server, all of which are in front of the actual content entry server which is only accessible on a private VPN. Lots of protection, right?

Drupal 8 is Going Mobile

Drupal 8 is due for release in the far future: late 2013. The future is a scary place. I keep hearing about all these "handheld devices" that are capable of strange things like storing whole record collections, perfectly copying the face of a human being, and accessing the internet over a mobile or wireless connection. People are using these "handheld devices" to do all manner of things, one of which is building websites. Drupal needs to catch up fast.

"Who's going to want to use Drupal on a small screen?" is something I've been asked over and over. Perfectly understandable. It's really hard to imagine using Drupal in the palm of your hand now, because the experience typically ranges from painful to unusable.

I often ask clients if their mobile traffic is less than average because users don't want access on the go, or because the experience is so bad they're going somewhere else.

If we make the small- and touch-screen experience more acceptable, who wouldn't want the freedom of using Drupal from anywhere-but-a-desk?

Social Security

Using People (and a Little Tech) to Solve People Problems

"He convinced his employer that the company could double its profits by merely unlocking the front door and allowing customers to come in." — Woody Allen, from "The Diet," in the collection Side Effects

The cost of security is usually measured in milliseconds, developer hours, and gigabytes of storage. But what parts of the tale do those metrics ignore? Consider Allen's joke: the company avoided theft, but at the cost of half of its business. (How the other half shopped through a locked door is left as an exercise for the reader.)

Most "security" focuses on technical issues — how to lock the door, so to speak, and which kind of lock to buy. Drupal's security advisories and the security documentation on Drupal.org are good examples of that phenomenon. This makes sense: when you're good with a hammer, everything looks like a nail. (Credit where it's due: Drupal's security team is very good with a hammer, and there are a lot of nails out there that need pounding.)

Breaches of "security" are very troublesome. But breaches in the social contract — such as spam, trolling, and use of someone else's login — can be just as bad. The advisories don't address such social issues, which can have a bigger business effect than a cross-site scripting hole. (Few people trust an e-commerce site where all the comments are spam.)

Here's the thing: You can't fight a social problem with technology alone. Who hasn't been driven away from a site that was "too secure"? Mandatory membership, administrator approval, IP filters, rate limiting, (broken) CAPTCHAs... all effectively "lock the door." At issue isn't the tools per se, but their application.

Curing Social Disease

Social problems require social solutions. While not driven by technology, they are enabled through it. Here are a few examples:

You Will Be Hacked

Warning: this article is going to be practical -- bordering on cynical. Use common sense and apply cautiously. Also, this is a generic article. If you are tasked with safeguarding the personal data of thousands of policemen or a few million credit card numbers, this article alone is most definitely not enough. Still, every bit helps.

Know Thy Enemy and Other Basics

One kind of enemy is the guy who wants to build a botnet for sending spam, performing DDoS attacks, and other nefarious activities. For this type of person, it won't matter at all which computer he manages to take over (in short, "own"). If breaching your security takes more than the most minimal of efforts, these people are kept at bay because there are millions of easier targets out there. Keep your software up to date: most server OSes have simple ways to keep up with security updates in a fully automated, unattended way. Make sure your whole stack is up to date -- for example, if you installed something from source, then it's your responsibility to keep it fresh. Have a basic firewall going.

Another kind of enemy is the script kiddie who does it for the "lulz", bragging rights, or the thrill of it. These types of people are unpredictable, as they have no clear motive or goal. Nor do they have many skills.

Old Lessons for a New Problem

By now, you’ve no doubt been marinated in technical articles about security, to the point of being pickled in terminology and saucy advice. It’s too much! With all due respect to my fellow writers, most of what you need to know about security for your Drupal site you have already learned from your dad (or mom or granddad...) like I did, even though my dad never learned to use a computer, never heard of Drupal

Magic? No, not really; Dad wasn’t the least bit clairvoyant. What he had was a large body of advice, and that advice extends to the topic at hand, just as house construction is wonderfully analogous to web site building.

So, let me share some of those gems with you. I suspect you’ve heard them before, but we’ll breathe new life into them, like a movie version of "Hamlet."

Eliminate Headache Customers to Reduce Stress, Increase Morale, and Jumpstart Your Company's Growth

During a business strategy BOF at DrupalCon Denver, I suggested to the gathered freelance-types that they should fire bad customers. The reaction was immediate, visceral, and hostile! As I slowly backed toward the door I explained to 50 pairs of angry-eyes that firing ill-fitting, high-maintenance customers is a necessity advocated in many business books. They were having none of it and I slipped out just before I was hook_user_deleted on the spot. Clearly I'd hit a nerve; this is something that needs to be discussed more in our community.

I read an interesting blog post titled "Why Cheap Customers Cost More", in which web designer Sacha Greif explained why customers who buy lower-priced services have high support needs. The article postulates that low-price offers attract "dumb" customers (his word, not mine). Not dumb as in unintelligent but ignorant about the products being purchased so they make a decision based on the only thing they do understand: the price.

On the surface, this rings true, but ultimately I disagree. At Volacci, certain low-priced customers DO tend to have higher needs. However, it's not because of ignorance. We have "less informed" customers at all price points that are wonderful customers because we've earned their trust. In fact, some of our most successful, lowest-maintenance customers fall into this category. We call them "B" customers.

Common SELinux Configuration for Apache

SELinux is a powerful tool for controlling what applications are allowed to do on your system. SELinux is a labeling system where every process and every object (files, directories, devices, network ports, etc.) gets a label. Then a large rules database, called policy, is loaded into the kernel. The kernel, based on the policy, controls what each process can do based on its label, and the label of the object it is trying to access. For example SELinux allows a process with the Apache label (httpd_t) to share data labeled as "read/only Apache content" (httpd_sys_content_thttpd_sys_content_rw_t). SELinux will block Apache processes from reading data labeled as user's home content (user_home_t) or database data (mysql_db_t). Apache processes can listen on ports labeled as the Apache port (http_port_t) but can not connect to the ports labeled as the mail port (smtp_port_t).

SELinux provides confinement on an application if the application has been hacked, even if the application is running as root. If policy says the Apache process is only supposed to read Apache content, then even if a hacker gets uid = 0 (the root user), he will not be able to turn it into a spam bot; he will not be able to read credit card data in your home directory; and he will not be able to destroy log files. The hacked process will only be able to act as an Apache process.

"Well that is all fine and good Dan, but Apache can be configured in a hundred different ways. Can you give me some idea of how to stop SELinux from complaining?"

A while ago I wrote an article called: What is SELinux Trying to Tell Me? The Four Key Causes of SELinux Errors. In the article I explain that the four causes of SELinux messages are:

• You have a labeling issue.
• You changed the default configuration and you need to tell SELinux about it.
• An application or SELinux Policy has a bug.
• You've been hacked.

In the rest of this article, I will explain how to deal with each of these scenarios.

The Drupal starter theme Zen is known for its quality code and extensive documentation. But it does require copying many files, performing global replacements, and manually setting column widths.

The Zenophile module allows one to do all that within the Drupal user interface. At Appearance > "Create Zen subtheme", specify the settings of your new theme: the machine and human names, a description, and a target directory. Optionally, you can select an alternate base theme, change the layout type from fixed to liquid, and create a fresh CSS file. Your sub-theme is then built for you. (The Zen theme need not be enabled.)

The submodule Zenophile Midnight helps in building subthemes with a light-on-dark color scheme, by inverting or darkening the colors in the standard Zen Sub-theme Starter Kit. Zenophile Sidebars provides controls in the UI to set the placement and widths of the overall page wrapper and the sidebars.

There are many ways to create a Drupal theme, but probably the most common general approach is to modify an existing theme -- instead of building one from scratch. In the Drupal world, the phrase starter theme refers to any theme that is intended to be used as a starting point for developing a custom theme. Such starter themes tend to be simple and stripped-down, with no aesthetic styling.

Theoretically, any Drupal theme, even the most complex, could be used as a foundation upon which to build a new theme. But beginning with an existing complex theme would be counterproductive in most cases, because time and effort would be required to remove all of the complexity and styling not desired for the intended final theme -- which could be much of the HTML and CSS code, and would defeat the purpose of choosing that theme in the first place.

Sometimes the phrase base theme is conflated with the idea of a starter theme, but they are not synonymous. Instead, a base theme is one from which your new theme will inherit all properties simply by specifying, in the .info file of your new theme, the command: base = [base theme name]. Yet a starter theme does not have to be used as a base theme; it can be modified directly, to stand on its own. None of the starter themes examined here utilize base themes, but at least one was intentionally developed from another theme -- specifically, Basic is derived from Zen.

In either case, be sure to update the template files (.tpl.php), as well as any template.php, to replace the machine name of the starter theme with whatever you have chosen for your custom theme.

All the leading starter themes include the bare minimum of a .info file, as well as at least one stylesheet and screenshot. Most also add template files and a logo. Some are quite advanced, with capabilities that allow you to define your new theme through a graphical user interface with no need to edit any CSS files. Others are much more minimalist, such as Stark, which is intended to show Drupal output completely unstyled (mostly for debugging purposes).