Tech4Him – Technology with Integrity

Ran across this one today. Upgrading a site with some custom work from 4.7 to 5.6. Obviously the testing of the upgrade is going on is a development environment but we ran into a problem with anonymous users being denied access.

Well, a quick check of the access control records proved that anonymous users did in fact have the Access Content permission. Hmmmm…. what else could it be.

As a side note, originally on pages where the user was denied access all you got in the content body was a “2″. No access denied message, just the numeral “2″. Thanks to the good folks on irc #drupal-support it was found this this is typical of an access denied issue. Atleast that led us down the right path.

Long story short, the tac_lite module had been previously installed on this site but was no longer being used. Apparently the disabling of the module did not properly clean up the node access data.

Again, thanks to the great folks on #irc, this time BDragon, and a quick search on drupal.org, the solution was easy. The default access row was missing. Adding the following to the table resolved the issue:

INSERT INTO node_access VALUES (0, 0, 'all', 1, 0, 0);

Yeah Drupal community! Yet another great reason to love Drupal.

Popularity: 62% [?]

Popularity: 5% [?]

Popularity: 5% [?]

Funny, isn’t it. The way things may have been setup on a network years ago and everyone thought were running fine. Then one day, small little niggly, nuisance things start happening. That is exactly what we were dealing with yesterday.

At a particular site, users had reported periodically being unable to browse to internal/LAN websites. A reboot or an ipconfig /release then ipconfig /renew would resolve it. Periodic, non-reproducible issues I don’t like but they happen all the time.

So, a quick rundown of the environment:

• Microsoft Active Directory environment
• 6 Windows 2003 Servers
• 4 Ubuntu 6.06 Linux servers
• 30 network drops in the local office
• 2 PTP VPN’s for remote offices

We were finally able to see the behaviour first hand. As we worked throughout the day we noticed that the failures were only being seen for sites residing on the Linux servers. So we threw Wireshark onto one of our laptops and began capturing packets. We cycled through lots of release/renew cycles and finally got the behavior to take place. Bingo!

Eagerly we looked through the packet trace filtering for the DNS queries. Lo and behold, the first requested went to the domain controller but then (2) two seconds later the client sends the dns query to one of the external isp dns servers. Aha! That’s it.

A quick ipconfig /all on a Windows XP desktop revealed that the clients DHCP lease included three dns servers.

1. Domain controller
2. ISP DNS server
3. ISP DNS server

Well there’s your problem. I was always taight that in an active directory environment, your clients should only use the active directory domain controllers for dns resolution. Those active directory domain controllers then are configured to forward unknown zone requests to external dns servers.

What was happening was that the domain controller, also serving as the dns service host was taxed from a system perspective, yet another issue. It failed to respond timely to the client’s dns request. The client then went to the next dns server in its list, the external ISP dns server. Well the external dns server has no idea about the internal servers and sites and therefore fails on the lookup and tells the client.

Thanks to our wonderful folks at Microsoft, Windows XP caches the failed lookup for a period of time. Thus the client can no longer browse to the internal site.

The story ends well we think. We simply changed the DHCP server to have the clients look only at the two internal dns servers.

Problem solved. Isn’t it fun to work with technology. ;o)

Popularity: 8% [?]

Now that we have had our server working well following our previous instructions, it is now time to tweak some more. Actually, many folks probably thinks this is more thank a tweak and really a necessity. I’d agree with that. Why? Well you just purchased a dual, quad core Xeon server to be fast. Fast is alot of things but certainly processing power is one of those key pieces.

Go to the shell prompt on your server and run the following command:

cat /proc/cpuinfo | grep ‘^processor’ | wc -l

Now, what number did you get back. Was it 1? Well the number you get back from that command is the number or processors the system currently sees. Yes, that’s right. In our example here, our server was only seeing a single core out of a possibility of 8 (dual, quad core, xeon processors). So you’re telling me that we are wasting 7/8 of our processing power? Essentially, YES!

Well don’t fear. There is a relatively simple way to fix this. Now, there are a few caveats but we’ll show you how we did it.

NOTE: If you compiled any source for any applications since your initial installation of Ubuntu, be prepared to re-compile. We are about to change the kernel and therefore your going to need to recompile against that new kernel.

From a shell prompt we need to be sure our repository information is up to date so…:

sudo apt-get update

Next, let’s get the 686 package which will allow our system to see more than the single processor as it does in the 386 version.

sudo apt-get install linux-686

Great! That was easy. You may have noticed that the installation made changes to the /boot/grub/menu.lst file. If you recalled from our previous article, this is the file that defines how grub will boot your system. With Ubuntu 6.06Server LTS and the PERC5/i controller in our box we had to make some modifications to that menu.lst file before. Well, unfortunately our work was just overwritten by the installation of the linux-686 package.

No problem, we’ll just update it again.

sudo vi /boot/grub/menu.lst

Now in this file towards the bottom are the boot menu options just like before. Change to "root" entries from something like hd(4,0) to hd(0,0). You are just changing that 4 to a 0 in each of the 4-6 menu option entries.

Next, the 686 kernel seems to correct the issue of how the raid array is detected and therefore named. Still in the menu.lst file, find the "kernel" entries for each menu option. Notice that there is something like root=/dev/sde1 in the line. Well, now the array is seen as sda not sde. So change all the sde1 pieces to sda1.

/boot/vmlinuz-2.6.15-29-686 root=/dev/sde1 ro quiet splash

is changed to

/boot/vmlinuz-2.6.15-29-686 root=/dev/sda1 ro quiet splash

Be sure you make those changes to all the entrie and then save your work.

Now all you have to do is reboot the server, but, be sure to do it form the console because you won’t have network connectivity when you reboot if you are on a Dell Poweredge 2950 like we are.

sudo shutdown -r now

Okay, after the reboot, log into your server at the console.

sudo /etc/init.d/networking restart

This should get your networking going again. There is an issue with the bnx2 / Broadcom driver in the 686 kernel that is odd but a simple restart of networking resolves the issue. This is how we came up with this temporary workaround until we find the real solution.

sudo vi /etc/init.d/rc

Now in this rc file, near the end add the following line which will force the networking restart after reboot.

# temporary resolution to networking issue under 686 kernel
/etc/init.d/networking restart

Then save your file.

That’s it. Now try that processor count again. Hmmmm…. we actually see 8 processors now. Now we are being good stewards of what has been provided.

Popularity: 5% [?]

Yesterday we finished the installation of a new server. There has
been alot of discussion about how to install Ubuntu 6.06 onto a Dell
PowerEdge 2950 server with a PERC 5 RAID controller. Really the
discussion has been about support for the PERC 5 controller and linux
kernel’s earlier than 2.6.17. The megaraid_sas driver is needed but not properly handled in Ubuntu 6.06 LTS. Read the rest of this entry »

Popularity: 5% [?]