Jeff Geerling's blog

Drupal 2014 - New Year's Resolutions

2014 is going to be a big year for Drupal. I spent a lot of 2013 sprucing up services like Hosted Apache Solr and Server Check.in (both running on Drupal 7 currently), and porting some of my Drupal projects to Drupal 8.

So far I've made great progress on Honeypot and Wysiwyg Linebreaks, which I started migrating a while back. Both modules work and pass all tests on Drupal's current dev/alpha release, and I plan on following through with the D8CX pledges I made months ago.

Some of the other modules I maintain, like Gallery Archive, Login as Other, Simple Mail, and themes like MM - Minimalist Theme, are due to be ported sooner rather than later. I'm really excited to start working with Twig in Drupal 8 (finally, a for-real front-end templating engine!), so I'll probably start working on themes in early 2014.

Drupal in 2014

Drupal 8 Logo

Quick logrotate example for Apache logs and some gotchas

On one server, where I have a custom directory where all the Apache (httpd) error and access logs are written, one set per virtualhost, I noticed the folder had grown to multiple gigabytes in size (found using du -h --max-depth=1)—in this situation, there's a handy utility on pretty much every Linux/UNIX system called logrotate that is made to help ensure log files don't grow too large. It periodically copies and optionally compresses the log files and deletes old logs, daily, monthly, or on other schedules.

For this server, to quickly fix the problem of growing-too-large log files, I added a file 'httpd-custom' at /etc/logrotate.d/httpd-custom, with the following contents:

/home/user/log/httpd/*log
/home/user/log/httpd/*err
{
rotate 5
size 25M
missingok
notifempty
sharedscripts
compress
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}

Some notes:

Responsive design > mobile sites

There are individuals and companies who still believe it would be in their best interest to maintain a 'desktop' version of their website, and a completely or mostly-separate 'mobile' version of their site, and this belief (especially in the corporate arena) was strengthened by a recent (2012) report by the Nielsen Norman Group, Mobile Site vs. Full Site, which recommended a separate mobile site with stripped-down features and different design. The idea of having a mobile-optimized design is good—but not with the cost of making it a stripped-down version of your 'full' site, as Nielsen seems to recommend.

Mobile PNC Website

There are many problems with having separate versions of the website, especially as we near a point where many sites are accessed more on mobile devices (tablets, smartphones), and less on traditional desktop computers:

reCAPTCHAs are easier to read—but they're still a bad idea

From the article reCAPTCHAs are finally readable by normal humans:

Google today announced that reCAPTCHAs served up to humans are finally readable without the need to squint your eyes or bang your keyboard in frustration after typing the wrong sequence of letters five times in a row. Who can even read those things, amirite?

I'm glad Google is making CAPTCHAs easier for humans to read. For the very, very rare times when they're necessary, that's a good thing.

However, I want to make an appeal to the thousands of developers who are thinking of implementing a CAPTCHA to deal with their site's form/registration spam: use CAPTCHAs only as a last resort.

CAPTCHAs - the Nuclear Form Spam Prevention Technique
CAPTCHAs: The nuclear option.

Kerberos authentication on a Mac OS X workstation with Chrome

Kerberos authentication allows your computer to log into certain services automatically without you having to enter (and re-enter) your password (it's a SSO—single sign-on—service). Kerberos v5 is baked into Windows and Internet Explorer and works great with many LDAP-enabled services (for example, Drupal's LDAP module allows includes a submodule for SSO support).

Kerberos is built into Mac OS X as well, but isn't as simple to use and configure with Chrome and FireFox as it is with Explorer on a Windows workstation. You need to do two things before you can use Kerberos for authentication in Chrome/FireFox:

Apache Kerberos Authentication and basic authentication fallback

Many businesses and organizations use Active Directory or other LDAP-based authentication systems, and many web applications (like Drupal) can easily integrate with them for authentication and user account provisioning.

The Kerberos Module for Apache allows users to be automatically logged into your web application, by passing through their credentials behind the scenes. This makes for a seamless user experience—the user never needs to log into your web application if the user is authenticated on his local machine.

A standard configuration for Kerberos authentication inside your Apache configuration file looks like:

<Directory "/path/to/site/root">
    # By default, allow access to anyone.
    Order allow,deny
    Allow from All

    # Enable Kerberos authentication using mod_auth_kerb.
    AuthType Kerberos
    AuthName "Your Web Application"
    KrbAuthRealm example.com
    Krb5KeyTab "/path/to/krb5.keytab"
    KrbMethodNegotiate on
    KrbSaveCredentials on
    KrbVerifyKDC on
    KrbServiceName Any
    Require valid-user
</Directory>

Pages

Subscribe to RSS - Jeff Geerling's blog