Monthly Archives: August 2008

Looking up .local DNS names under OSX

My workplace uses a .local DNS suffix for all internal DNS, which of course causes problems when you’re running a system which uses any form of mdns – such as OSX or Ubuntu (or probably any modern Linux distro, I know SuSE had this problem about 6 years ago). The .local lookups fail, because mdns takes over. (Thanks John and Phil for reminding me of this). This shows up as resolution via host or dig working fine, as they make calls direct to your nameservers, but commands like ping failing, as it uses the NSS to do the lookup.

A quick bit of googling, and I found this gem on Apple’s website, and also this one on www.multicastdns.org. Apple’s suggested fix didn’t seem to work, but I suspect a reboot is required. I’ve applied the second one, and rebooted, and one of them is definitely working.

As an aside, this started with me wishing that it was possible to do per-domain resolver configuration. I initially gave up and set up dnsmasq which forward on requests to specific domains to specific servers, but then hit the mdns issue. This method looks very much like a per-domain resolver configuration however – it’s saying to use my local DNS server for .local lookups. I haven’t tested it, but it looks like it should support setting an arbitrary resolver for an arbitrary domain.

Why I love dmidecode

I was asked to provide more ram for a server today, specified only by name. I have login details, but it’s in a datacentre in Auckland, and I’m in Hamilton, so I can’t wander over to check details.

Enter dmidecode:


System Information
Manufacturer: Dell Computer Corporation
Product Name: PowerEdge 860

That’s basically all I need right there. Having a namebrand machine helps, of course – getting the same sort of information from a generic motherboard isn’t as easy or useful. However, while checking which ram banks are populated I can also (typically) get the type of ram as well:

Handle 0x1100, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x1000
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 1024 MB
Form Factor: DIMM
Set: 1
Locator: DIMM1_A
Bank Locator: Not Specified
Type: DDR2
Type Detail: Synchronous
Speed: 533 MHz (1.9 ns)
Manufacturer: 7F7F7F0B00000000
Serial Number: 7A947291
Asset Tag: 0D0718
Part Number: NT1GT72U8PB0BY-37B

In this case, the other “Memory Device” entries had “No module installed” in the Size: section, so I know that this machine has one (1) 1GB DDR2-533 DIMM installed.

Of course, that output doesn’t seem to tell me that the Dell PowerEdge 860 wants ECC ram (although I know that anyway). And the output from dmidecode on a newer machine:

Handle 0x1100, DMI type 17, 23 bytes.
Memory Device
Array Handle: 0x1000
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor:
Set: 1
Locator: DIMM 1A
Bank Locator: Not Specified
Type:

Type Detail: Synchronous
Speed: 667 MHz (1.5 ns)

That’s from a brand new HP DL360 with FB-DIMMs, so I guess my version of dmidecode on this machine isn’t new enough to handle that.

In general though, it’s more than good enough :)

Further bugs in switches

Further to my {{post id=”opennms-and-bugg-switches” text=”previous post”}} on the topic of uncovering bugs in switches with network monitoring systems, I have two more bits of news:

The first is that the vendor has given me a new firmware for one of the switch models which fixes the bug. Apparently it was a known but undocumented bug. Still waiting on a firmware for the other switches.

The second is that I have found another bug in the switches – this time with HTTPS. It’s not triggering during autodiscovery this time, and the bug takes a bit longer to manifest (2-4 weeks, it seems), so it’s slightly harder to track down. I’ve got to set up a test rig to hammer some of the switches with HTTPS connection attempts and see what shakes loose.