On 15 September 2009, I downloaded and installed the Drupal 7.0, Unstable 9 development snapshot of the upcoming Drupal 7.x release.  I did two installs: one on my desktop and one on the Linux server used for testing here on my home network. 

The desktop runs Vista Ultimate 64-bit, SP1 and uses WampServer as its LAMP environment.  The configuration includes:

• Apache 2.2.11
• PHP 5.3 or PHP 5.2.8
• Mysql 5.1.30.

The server runs Ubuntu Linux 9.04.  The LAMP configuration includes:

• Apache 2.2.11
• PHP 5.2.6
• Mysql 5.0.75.

Installation

I did not notice much of a change between the Drupal 6 and Drupal 7 installation procedures.  One thing I did notice was the changes in the terminology to create a more user friendly experience. 

Other than the usual Linux file ownership and permission inconsistencies I encounter when installing applications on the Ubuntu Linux server, installation in both environments was uneventful.  PHP did run of of memory during the install on the server, but that was not really a Drupal 7 problem.  I upped the PHP memory allocation from the default 16M to 128M and that fixed the problem.  I need to check this later and determine what the real PHP memory requirement for a Drupal 7 install is.  I'm sure it's much less than 128M.

Administration

Drupal 7 introduces a number of changes in the administrative backend.  The most obvious change is that if you are logged in as the administrator, a menu appears at the top of each page that contains links to the various administrative functional areas. 

If you have ever inadvertently destroyed your public theme as I have, you really learn to appreciate Drupal's option of having a separate administrative theme.  Prior to Drupal 7, I typically used the Garland theme for administration.  I was happy to see that Drupal 7 includes a one-column, fluid width theme called Seven that is tailored for use with the administrative backend. 

 

One often heard criticism of Drupal is that its administrative backend navigation is less than straightforward and the terminology is too abstract and/or contains too much technical jargon. 

Drupal 7 has made a number of terminology changes and reallocation of functions to categories to make the administrative backend.  The changes are too numerous to delineate here, but comparing the new administrative backend view to that of Drupal 6 shown below, it's obvious that a lot of time and effort has been put in to make the Drupal 7 administration a bit more user friendly, more intuitive and easier to navigate.  To really appreciate all the changes, one must really install Drupal 7 and work their way through the administrative backend.  It is still far from perfect, but it is a big step forward. 

Core Modules

A list of the Drupal 7 optional core modules are shown on the right.  Modules that are new in Drupal 7 are outlined in green.  The Drupal 6 optional core modules are shown on the left.  Those which are not present in Drupal 7 are outlined in red.

What's New in Drupal 7 Core

I guess the biggest news for Drupal 7  is the incorporation of basic Content Construction Kit (CCK) functions in the core (Field, Field UI and File modules).

The Image module incorporates a more sophisticated image manipulation function than previous releases. 

The SimpleTest module provides a framework for unit and functional testing.

The Toolbar module provides the UI for the new top horizontal administration menu.

What's Gone in Drupal 7 Core

The BlogAPI module is gone.   I was initially a  bit disappointed to see it go as I use Windows Live Writer (WLW) quite a bit.  However, it will still be available as a  3rd-party module.

The same goes for the Ping module.  The growth of social networking has resulted in a number of 3rd-party modules that provide this capability plus more.

The Throttle module is also gone in Drupal 7. 

One other thing I noticed is that there is no longer a distinction between "Core - required" and "Core - Optional" modules.   In Drupal 6 and earlier, the Block, Filter, Node, System and User modules were classified as "Core-Required." 

Theme Development

I haven't quite digested all the changes in the theme system; however, at first glance there appears to be a number of  changes needed to upgrade a Drupal 6 theme to one that is compatible with Drupal 7.  You can read about the changes here. 

The goal of these changes is to make Drupal easier to theme.  I guess I'll find out about that soon enough.

Conclusions

From a user point of view, the big change is in the Administration UI, which is a good thing.  I know there there are numerous changes under the hood that make Drupal 7 faster and more reliable than its predecessors.  However, I feel that Drupal still has a bit more work to do in the UI and ease of use areas.  

Disclaimer

Any errors or inconsistencies in the above are no doubt due to oversights and/or technical ignorance on my part.  The authoritative source for information regarding Drupal 7 is Drupal.org.

• View September 2009 Pictures of the Month
• View September 2009 pictures at Snapfish
• View Uncle Brian's Birthday pictures

(note: you may have to create an account at Snapfish to view pictures stored there).

World Trade Center, Pentagon, Shanksville...This month's page is dedicated to the victims and the heroes of September 11, 2001.

We went back to school the Tuesday after Labor Day.  When we left the house to get on the school buses that day, our dog Cappy was really sad.  Now we have to get used to getting up early, doing homework, going to bed early, and that other stuff that we have to do until next spring.

During the last week of our summer vacation, we went on a field trip to see the Natural Bridge of Virginia.  It was really impressive.  Check out the Snapfish pictures to see what we saw there.

See you next month...

Ross & Owen

I recently completed a major update of my oldest internal Linux Server here at hrpr.com.  The server, whose name is Doofus,  is hosted on a Dell Dimension XPS T500 that has been in service here since April 1999. 

For the last eight years, Doofus has been running Slackware, which is a hard-core, no-frills, very stable Linux distribution that has been around since dirt was new.  If you aren't on speaking terms with command line shells such as Bash and are not familiar with the Linux Directory Structure and its contents, then Slackware is probably not for you. 

Back to the update stuff...

I was getting ready to download the latest, greatest version of Slackware and install it on Doofus when it suddenly occurred to me that I had recently downloaded the latest version of Ubuntu Linux and had made an installation CD-ROM for it.  It was the Desktop Edition, but as a local test server, it would do just fine.  I was also curious to see how GNOME would perform on a Pentium III with 256M of RAM.  After all, I was essentially starting with a blank slate and could revert back to Slackware if I really wasn't satisfied with Ubuntu.

I did the Ubuntu install and, as usual, it was fast and uneventful.  Doofus rebooted and up came the GNOME GUI.  And surprise, surprise!   It was quite responsive.  The mouse was responsive and GUI applications ran fast enough to meet my "wait-time" expectations.  Which really didn't matter much anyway since Doofus would be running 99.99999% of the time as a server with remote administrative access via SSH and/or Webmin.

I installed the LAMP stuff and a BOINC Client for running SETI at home tasks.  And that was it - Doofus was back online doing its thing.

I am still a Slackware fan and highly recommend it to anyone who enjoys tinkering at the command line level and/or wants to learn Linux from the ground up.  However, Ubuntu brings added value such as automatic notification of security updates, a more feature rich software package manager and other administrative tools that make life a bit easier.

And who knows, next week I may change my mind again and install Slackware Linux on Doofus yet one more time.

• View August 2009 Pictures of the Month.
• View August 2009 Snapfish Pictures
  (note: you may have to create an account at Snapfish to view these pictures)

On the first Saturday of the month, we attended the annual family reunion at the Mon Valley YMCA in Carroll Township, PA.  We enjoyed seeing all of our aunts and uncles, and our cousin Austin, who lives near St. Louis, MO.

Summer is almost over so Mom and Dad will be closing down the pool next month and we will be heading back to school next month.  I will be in seventh grade this year and Owen will be in fourth grade.

See you next month...

Ross & Owen

Back in the day, when the TCP/IP protocol suite was the new kid on the block, one of the classic issues was how to deal with half-open connections:

A TCP connection is considered “half-open” when one party thinks the connection has been closed and the other party thinks the connection is still open.

One solution to the half-open connection is the old "When in Doubt, Time Out" rule.  That is, if no packets have been sent/received on an existing connection for some preset period of time, unilaterally close the connection.  Not elegant, but works great. 

The Internet has grown exponentially over time and TCP/IP has become one of those things that are just there and works the way it is supposed to 999.999999 percent of the time.  Today's average PC user really doesn't think or care about half-open connections as defined above anymore, or even how TCP/IP does what it does!

Why am I writing about this?  Well, over the past week or so connections to two of my web sites has been bouncing, i.e., the monitoring service I use has been reporting intermittent loss of connectivity:

Alert Type: Site Not Available

Result: Failed

Time: August 11, 2009 10:39:23

HostName/URL: portal.hrpr.com

Monitor Name: hrpr.com

Service: http

Alert Type: Site is Available

Result: Ok

Time: August 11, 2009 11:09:24

HostName/URL: portal.hrpr.com

Monitor Name: hrpr.com

Service: http

I opened up a trouble ticket with my host provider and after a few back and forth conversions with them, ended up with this more or less "final" answer to the root cause of my problem.  Although not mentioned below, the implication was that the PHP scripts used by my sites were exceeding the server's PHP memory usage and/or processing time limit.  And I knew this wasn't the case:

Well, unfortunately, I have to maintain that the problem lies elsewhere at this time. Your server is rock solid stable, your apache instance is unwavering, and the ONLY reason I've found, other than an external connection issue, somewhere between yourself (or your monitoring service) and our servers, is the process watcher entries. If this were our issue, I'd be very quick to point it out. We're not really about shifting blame here...check out http://... for shining examples of our "we screwed up, we'll fix it" mentality.

However, in this case, the two possible issues are a bad connection between yourself and our servers, and the process watcher/resource issues. Again, if you want a useful diagnosis, we'll need to see a traceroute taken at the time that the problem is occurring. I never suggested you had networking issues anywhere else...but incorrect routing, or network issues along the specific path that your connection takes can cause a perceived interruption in service. You may also try checking your site via proxy such as http://... the next time it appears to be down.

Let me know if you have any other questions!

After reading this response, please consider visiting the URL below to comment on its quality.

Thanks!

http://...

To which I replied:

OK, I give up, you win. I'll continue trying to isolate it on my own.  And a few other choice words I will not repeat here. 

As suggested, I did visit the "URL below" and sent a comment on the quality of the response.  As you might suspect, my comment was somewhat negative.

A few hours later, I got this in an email from the host provider's support team:

I think I found your issue. I apologize that this was over-looked but this actually isn't supposed to happen as on our newer servers we have implemented FTP connection limits to stop them from piling up. Basically I saw your user had a huge number of stale FTP connections.

There was about 100 of them. Our process watcher will kill your processes if you have too many processes running and that's why your processes were being killed (99% of the time they are killed for memory usage not process count). Our process watcher won't kill FTP or shell connections as its hard to tell if the connections are legit or not but they are still counted towards your total process limit.

I killed all your stale FTP connections so I think you won't be getting killed by our process watcher anymore (or not nearly as much). It looks like all your processes that were killed were due to the process count limit (not memory).

I apologize that this was over-looked by ... but I can understand why as this isn't even possible on our newer servers because we limit the FTP connections to 7 total by IP or account and again 99% of the time processes are killed for memory usage not process count. Please feel free to email me at ... if you are still running into these issues and think this issue might have popped back up.

In 25 words or less, the intermittent connectivity problems were being caused by half-open (stale) connections. 

The host's FTP server thought the connections were still open and as far as my FTP client was concerned, they had long since been closed.  The nasty side effect of this was that other processes such as those spawned by the HTTP server were getting killed off because of this.

What's the moral to this story?  Well, there really isn't one.  I just wanted to write this down somewhere as it brought back memories to me of days gone by.