A tale of two clients

Loki · Been around the blocks Joined: 20 Nov 2008 Posts: 24

Hello-

last week I tried to add 2 new clients to my SAN, and I ran into a problem.
The first client installed perfectly- not so for the second.

MDCs and the new clients are on XSAN 2.2.2.
DNS is and has been working fine for over a year with the old clients.

So here's what happened when I went to add the second client:
In XSAN admin, I go to the computers tab, hit the big + button.
Dialog box opens, and I see the computer I want to add:

I authenticate to the client with credentials that I know are good, and I get this:

At this point, I'm pretty much done. There's no going forward.

I have looked at the logs on the client, and on the MDC, and I see nothing.
I've rebooted, reinstalled XSAN, rebuilt the client from scratch, same result.

One thing I will mention, that could be a red herring is that the new clients both came with 10.7 installed. We don't yet allow 10.7 in our environment, and the MDCs are 10.6, so I installed 10.6 on both client machines. I did this by booting each from a clean 10.6.8 install on an external hard drive, then performing a 'restore'. What I am wondering is if because both computers were imaged from the exact same source, are they somehow appearing as the same machine to XSAN? Again, this may have nothing to do with the problem.

Any ideas?

JSamuel · Xsan Master Joined: 05 Jan 2011 Posts: 169

I'm assuming that as newclient1 added fine, that you added the DNS (A and PTR) records for both subnets for the newclient2 machine too.

You would have to look at the Xsan config files to check machine IDs. I suspect this would be the issue, as everything else sounds clean (DNS; available Xsan licenses etc; network ability to ping etc etc).

Use another machine that boots 10.6.3* to deploy 10.6.3* onto that HDD, create the admin account and then combo update to 10.6.8. Take the HDD out and put it in the newer machine - then carry on with IPv4 config; software installation; Xsan deployment - etc etc.

If there is a lot of software I guess once the basic machine is done, you could attach the clone drive you have then Migration-Assistant the software over, assuming VLKs and what not.

* .. or whatever your latest OS X install image is.

singlemalt · Xsan Master Joined: 27 Feb 2009 Posts: 109

Back in the dim dark pass I remember running into something similar. This article
http://support.apple.com/kb/TS1245 used to explain how to remove the local
kdc but Apple later fixed-re-released system image utility which stripped out
the lkdc anyway. I think this
http://www.afp548.com/forum/viewtopic.php?showtopic=20036
( look for Stephen Buckley's comment "Follow up, for those who are interested. ..." has the original instructions.

As you say this maybe a red herring, but gotta start somewhere.

Loki · Been around the blocks Joined: 20 Nov 2008 Posts: 24

Well, I followed the steps for removing the KDC database and rebuilding it, and that all succeeded, but I am still unable to add the machine to the SAN.

I'm out of ideas at this point, I wonder if our support agreement is current...

JoelK · partially protected Joined: 08 Sep 2010 Posts: 8

Try deleting the UUID File in /Library/Filesystems/Xsan/config/
Then reboot, a new UUID file will be created.

I ran into some interesting issues using clone drives during xsan deployments, until I deleted that file my MDC's thought all my clients were the same.

Loki · Been around the blocks Joined: 20 Nov 2008 Posts: 24

Well folks, it's been many months since I hit this wall, and I ended up putting it on the back burner as I am trying to do two different jobs at the moment, and I couldn't really afford to devote any more time to this.

We ended up hiring a local guy who came well recommended, and he resolved the issue, with a little help from a sharp Apple technician.

We (and by we I mean he) also upgraded everything to 10.7, but the problem with this same client happened again.

Turned out it was a fiber problem. Oddly enough, the fibre applet in system preferences didn't indicate a problem, and prior to the installation of xsan, all the LUNs of the SAN were visible to Disk Utility. The problem was detected when the Apple tech ran cvlabel -c on the client and noted that the LUNs 'checked in' much more slowly than all the other clients. We eventually traced it down to a bad SFP.

Just wanted to share that for what it's worth. Again, I can't take credit for solving this, but at least I can tell you how we got there.