Dave's Blog

I've never been happy with how Drupal handles updates to the main Drupal package. There's something kind of kludgy about just unpacking the .tar.gz file, copying over all of the custom themes and modules and then doing the old switcheroo by moving the older installation to some other name and the new install to my blog's name and then hoping I got everything right and didn't forget some critical piece (like settings.php). I was happy to find Drupal in the EPEL repo and thought my problems with Drupal updates were over. It turns out that getting Drupal to work the way my original .tar.gz installation worked was easier said than done.

This article is a list of the steps I stumbled through getting the Drupal6 rpm to provide the same functionality as I had with my .tar.gz installation. The possibility also exists that some of the changes I made that apparently had no effect were required in order for what I eventually tried to work. These may or may not apply to someone else's installation but are the things I tripped over in setting up the Drupal rpm on an internal system.

So, it's been a year and a half since I last did anything with IPv6. Lots of life has happened since then but technology marches on. After upgrading my gateway/DNS/firewall/router to Scientific Linux 6.3, I have been deluged with DNS errors because IPv6 addresses aren't resolvable on my system. I guess that's an indication that I really should pick back up on getting IPv6 working.

My plan is to do a phased roll-out of IPv6 with the first phase being to just get it working alongside my existing IPv4 network. That means setting up DHCP6 and DNS for internal systems and then getting local services like amanda, NTP and NFS to work with either protocol. Once I get to that point, I'll see if I can get an IPv6 tunnel working again but this time as a gateway.

Update 31 May 2013: Here's a hint at how things are going...

Lots of progress so lots of updates to come but it's basically working. Still can't get reverse DNS to work for DHCP assigned addresses and dhcp6d and dhcpd seem to not be able to coordinate updates to files like /etc/resolv.conf but those are details for future postings. The body of this post (from the summary break, on) has not yet been updated.

The old Athlon 64x2 I had been using as my VMware server was having more than a little trouble running a virtual server and several virtual clients for my IPv6 tests and experiments. Although the hardware was not on the VMware compatibility list, the only thing I had to do to make it compatible was to install an Intel gigabit ethernet card and VMware installed and worked well. I decide that something with more cores and more RAM would probably "greatly enhance" my VMware experience so I bought an AMD Phenom II x6 CPU and supplied it with 16GB of RAM on a Gigabyte motherboard. Big mistake.

Morning: A time of mental anguish, emotional pain and suffering, and sorrow. Not to be mistaken with mourning which is when you have similar feelings because someone has died as opposed to just having to get out of bed.

W00t!!!!

Yes, you can take that as it's sort of working. It took finding one more level of the systems doing something that wasn't quite what I had in mind. This time it was the "memory" built into the DHCP implementation that meant that changes made by me weren't taking effect. It seems that DHCP lease information is cached on both the client and the server as a means for either to just put things back into place after a reboot. This is great except the check for "is the last set up still good?" failed to take into account the possibility that the configuration had changed. Once I started clearing the client and server leases before testing things became a lot clearer.

CentOS 5.6 has been released. The updates have been downloaded but I will need to reboot the server at some point. Dave's Blog will be unavailable for at least long enough for my server to reboot. Based on past experience, there will probably be some issues that I will need to fix before the server will be fully "back to life."

Update as of 23:25 9 April 2011:

Up and running again. This time I used find to find all of the .rpmnew files and brought forward my old settings to the new file. I probably missed something but at least httpd, named and sendmail seem to be working.

I ended Part 5 of this saga with the observation that I needed to do more investigating to find out why I could get IPv4 DDNS entries and I was somehow able to force some IPv6 DDNS entries but these entries weren't apparently getting created by the network initialization scripts. My suspicion soon fell on NetworkManager (a.k.a. network-manager). I attempted to force Network Manager to use the dhclient.conf file that worked for me from the command line only to find out the NetworkManager dynamically creates its own dhclinet configuration file (in /var/run/nm-dhclient-ethX.conf). So what was happening was dhclient was sort of doing the right thing when I ran it from the command line but was not doing the right thing when run by NetworkManager. This mean that NetworkManager had to go at least until I found a working configuration for dhclient.

Success (sort of)!!!!!

As I mentioned in Part 4, I pulled down an evaluation copy of Red Hat Enterprise Linux (RHEL) 6 and made that my new server. That was an interesting adventure but all I had to show for my efforts was DHCP dynamically creating the DNS forward entry for my Ubuntu Natty Narwhal test system. I attempted to debug the problem (no reverse DNS entry) using nsupdate which at least let me know that there was some sort of "authorization" problem. The interesting quirk of the problem was that IPv4 DHCP was working flawlessly for both forward and reverse DDNS and was also successfully updating resolv.conf.

I ended Part 3 of this series stating that I would look into "building my own" version of the Internet Software Consortium (ISC) client for my Ubuntu 10.10 system or just moving to an early version of the next Ubuntu release. Let's just say that building my own DHCP client and integrating it into the Ubuntu network start-up scripts was a bigger undertaking than I had imagined. Instead I pulled down an alpha version of Ubuntu "Natty Narwhal". The Natty release is surprisingly stable for an alpha but, unfortunately, had the same problem as 10.10: I still got the message, "client6_recvreply: unexpected reply."

My ultimate goal in this endeavor is to have my real home network running on IPv6 with no loss of functionality as compared to how I have things working now with IPv4. In particular, I want to be able to configure tools like amanda or use ssh using host names; not IPv6 addresses. Since I currently accomplish this functionality with tools like DHCP and dynamic DNS updates, I wasn't expecting to encounter any problems. It turns out that this functionality is still somewhat in flux when it comes to IPv6.