Be a part of the Great Commission, OneVerse at a time.
Popularity: 6% [?]
Be a part of the Great Commission, OneVerse at a time.
Popularity: 6% [?]
Popularity: 4% [?]
First, a big round of thanks and applause for the scores of folks who played a part in making Drupal 6 a reality and such an improvement to the design, architecture and usability.
Quick Reference Links
Drupal 6 Official Release Announcement
Drupal 6 Upgrade Instructions
Drupal 6 Upgrade Video Tutorial
Drupal 6 New Installation Instructions
Drupal 6 New Installation Video Tutorial
Converting Modules
One of the best additions is the Coder module. This little guy addresses primarily three areas of interest.
I have got to say it sure is nice to have a too that quickly can point a maintainer or contributor at key areas to look at for migrating a module to the next release. Really, the lack of 5.x modules available for 6.x is what will keep folks from upgrading existing sites straight away.
I am of the opinion that with this Coder module and a little elbow grease we can help users of Drupal to more quickly adopt 6.x once we get more modules ready for the upgrade.
Popularity: 5% [?]
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: 60% [?]
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:
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.
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% [?]