MI-80 De Oppresso Liber

Unfortunately the web server died last weekend, and most this week was spent finalizing repairs and restoring things. This means it's been awhile since part two of this series, so some of the more minor details have been forgotten. Because of this I'll be making part three more about customization and debating the licensing for the site. But I will talk about some interesting issues new admins might want to know of in advance, such as issues with Apache, PHP, and Drupal's default .htaccess file.

So to begin, going into day three of the overhaul I started noticing some critical issues. Certain features weren't working and I couldn't track down the source. Apache and Drupal's error logs alike weren't showing anything going wrong, however when I did certain things, like run cron or try making a blog entry, it'd silently fail. This actually ended up requiring a few adjustments to the server.

Initially it hit me that my websites configuration file was pretty tight by default. Here's how it was out of the box:

<VirtualHost <IP Address>>
DocumentRoot <Path>
ServerName mi80.com
ScriptAlias /cgi-bin/ /srv/www/cgi-bin
<Directory /srv/www/cgi-bin>
AllowOverride None
Options +ExecCGI -Includes
Order allow,deny
Allow from all
</Directory>
<Directory "<Path>">
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

Unfortunately this setup disabled many features. To solve many of my issues, like the lack of running SHTML, I started with the first segment. Changing AllowOverride to All from None, and changing Options to have +Includes from -Includes helped. Proceeding to the second segment I changed Options None to Options All and AllowOverride None to AllowOverride All. Note that for security reasons these aren't good longterm settings. These are great for testing however. After initially fixing things, it's a good idea to tighten them up to only what you need, for example Options FollowSymLinks, etc.

So with my /etc/apache2/vhosts.d/vhosts.conf in order, I continued to get some strange scripts failing silently. I eventually, thanks to Google and the Drupal forums, figured out that the 8MB memory limit PHP defaults to per script is way, way too low. So I opened up /etc/php5/apache2/php.ini and searched for MEMORY, and guess what I found?

memory_limit = 8MB

Tada! I changed that to 128MB and boom, suddenly everything started lighting up. Other scripts, such as ones running on other websites using phpBB, started to fly performance wise.

So now with the website at least up and running mostly, I felt like I had to do some customizing beyond the theme and colors. Layout's important after all.

Luck would have it on a recent trip to Ohio with my company's CEO and head web designer we'd thoroughly discussed a bunch of topics regarding web design, including “how most peoples eyes flow across a page.” We actually paid quite a bit for research regarding this – and I get to reap the benefits here. Apparently it's common for readers to scan in an inverted “L” shape, going from upper right to left then down.

Thankfully I have plenty of friends to get feedback from on this subject. Simplistic seems to be by far more popular than “busy” pages, so I kept everything to a minimum. Main navigation across the top right, user options along the left side, and the “just right” number of news feeds along the right side and enough articles on the home page to scroll a bit without looking overly long. I know it's all confusing – it confuses me as well. But adding a few too many links, or taking away a few made the difference between “too busy” and “amateur looking” for most people. That said, while a sites layout is important to attract viewers, I believe it's more about your personal preference. If I hated looking at my site day in and day out does it matter if I'm attracting lots of hits?

After working on the layout I spent some time looking the server over security wise. Because of my work I have access to some very “interesting” tools, namely NeXpose. I ran a thorough scan and sure enough came up with 119 issues, and certainly I wasn't going to take a site live like that.

The issues were all easily and quickly remedied. First of all SSH was set to allow both the SSH1 and SSH2 protocols. Because SSH2 has been around so long, and because of inherent flaws in SSH1, disabling SSH1 entirely is a common practice. This part couldn't be easier, it was just a matter of opening up /etc/ssh/sshd_config, finding the line that says #Protocol 2,1 and changing it to :

Protocol 2

That's it. Uncommenting the line and removing the 1, followed by restarting the SSH daemon, fixed that.

After that most of the complaints NeXpose gave me involved two default Apache items being indexed, icons and the Apache manual. I really don't mind if these are available, but I sure don't want them indexed and easy to navigate. After poking around I found this was actually incredibly easy to disable, it just requires knowing where to look. There's a file called by the main httpd.conf, /etc/apache2/conf.d/apache2-manual.conf which specifies the actions and permissions for the manual. A few lines from the top is the line Options Indexes. Well commenting that out as follows solved that problem:

# Options Indexes

So all that remained was getting rid of the indexing of the Apache icons. Just as with the manual this wound up being very easy to disable once I knew where to look. Opening up /etc/apache2/default-server.conf revealed the following:

<Directory "/usr/share/apache2/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>

I quickly changed Options Indexes MultiViews to Options MultiViews, restarted Apache so these changes could take effect, and suddenly I'd knocked out 119 security issues in a little under an hour. Not bad. Then again had I known from the get go what files to edit this would have taken a matter of minutes!

As a matter of timing another item I took into consideration while doing the overhaul was my licensing. The Creative Commons released version three of their license while I was working on the overhaul. Overall it appeared to be more of a clarification than anything else, not drastically changing anything meaningful. For a couple of days I did debate whether to allow derivative works of everything here. As a small site with a lot to say I tend to be overly protective of my work, figuring it'd be nice if people came to the source rather than taking my work and calling it their own. But after some thought I figured I'd put some trust in humanity. Plus, I take advantage of open source software every day of my life, so it's the least I can do to give back to the technical community.

Finally to wrap it all up I was slightly annoyed that you could access the page both without and with www. before the address. I just like consistency, if for no other reason than I don't trust myself to be constant in its future use, so I wanted the server to take care of that for me. This is easily done via the sites .htaccess file – and it ends up Drupal even ships with the lines required:

# If you want the site to be accessed WITH the www. only, adapt and
# uncomment the following:
# RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
# RewriteRule .* http://www.example.com/ [L,R=301]

Could it really get any easier? I quickly changed the last two lines to:

RewriteCond %{HTTP_HOST} ^mi80\.com$ [NC]
RewriteRule .* http://www.mi80.com/ [L,R=301]

and that was it. The site itself now enforces only accessing it through http://www.mi80.com, automatically redirecting people who typed things like mi80.com or http://mi80.com. Now I can rely on it always being accessed that way, no matter if I remembered to code the www. into a page or not.

That finishes up day three. The site was running, performing well, starting to take final shape, and I was confident about its security. Going live was right around the corner. A few issues remained, namely remote database management, webmail, and tying up loose ends. But you'll have to wait for the next exciting installment to read about all that!