[JonThompson]

Do you have a bugreporter number that you can share so we can report it as well? Mine is 8156439

[JonThompson]

Same problem here. Fresh server install, fresh OD user. Pure OD. The fun bit is that the com.apple.iChat.managed preference file is even created. It just doesn’t get loaded by iChat.

I have the same issue with iCal MCX as well.

[JonThompson]

I know this is an old one, but it deserves an answer…

Promise RAIDs require OSXS 10.5 and XSan 2 to work properly. This is due to the redundant FC connections that are made.

As for the actual question. You should be able to configure your FC switch so that the Promise RAID is in a zone by itself with the XServe.

[JonThompson]

Any word?

[JonThompson]

I can’t help without actually playing with your setup as Kerberos setup is often picky at different parts of the process for different reasons. Anyhow, what I can do is point you to the information that allowed me to troubleshoot my Kerberos issues when I had them:

https://www.afp548.com/Articles/Panther/kerberos1.html
https://www.afp548.com/Articles/Panther/kerberos2.html

We’re still waiting on part three 😛

Anyhow, while they may seem dated; they aren’t. They are as valid in Leopard as in Panther.

as for directions in troubleshooting…

Since this is a new box, there is little harm in blowing out Kerberos (I’ve never really seen any harm in blowing it out on a production server, really, except that kerberos users can’t login during the blowout.) Follow these steps:

1) Use Launchctl to unload Kerberos related LaunchAgents (kdcmond)
2) Blow it out using the instructions in the kerberos 2 document linked above.
3) Re-create it using the instructions in the kerberos 2 document linked above.
4) Use Launchctl to load Kerberos related LaunchAgents if they are not loaded in step 3.

[JonThompson]

Hmm, that’s interesting. Since creating this thread, I’ve update my servers without incident. Still didn’t fix my problems with homesync, though.

[JonThompson]

Any thought as to what is causing the MDSChannelPeerCreate errors? I get them constantly in my logs, although I don’t see any performance issues that would suggest a problem.

[JonThompson]

PHD is a way to get everything a user has onto the server, where the server can be properly backed up. Or at least that’s what it _should_ be.

What I would really like to figure out is how I can have both a PHD and a OSXS Time Machine solution where they work in harmony with each other, but I don’t think that is possible until Apple makes it possible.

[JonThompson]

So I guess no one will help me. No matter. It seems on the next sync that it took care of my problem, as my stuff is now correct in both places.

[JonThompson]

Yes, you can allocate LUNs to different servers on the same fabric. You will not be able to access the same space on both servers, but you should be able to consolidate storage. As for XSan, it probably is good you don’t want to do it, as you would need two more servers (MDC and backup MDC)to get started. Especially with XSan 2 and spotlight indexing.

[JonThompson]

DHCP Options are unsupported in 10.4, and essentially broken in 10.5. Install ISC dhcpd and be happy.

[JonThompson]

One thing that gets people on the vpnaddkeyagent user over and over is that it does two things…

1) adds a user to the ldap database.
2) adds a keychain item to the system keychain. (ras is in the name of the item)

If you have ever run it multiple times, you need to clear out _both_ before you run it again. Otherwise, you will have problems.

[JonThompson]

OK, I think I have put this one to bed, thanks to a non-working Leopard Server VPN.

My guess is that everyone in this list used vpnaddkeyagentuser multiple times. (blush)

Here is what I did to fix it…

1) Delete _all_ the VPN users from your directory… There are most likely several with the UID 57, so keep deleting until they all disappear.
2) Delete _all_ of the com.apple.ras keychain items from the system keychain.
3) Run vpnaddkeyagentuser _once_

What I think is happening now is that if you have multiple keychain items, VPN gets confused and hangs up the authentication system for a period of time. Eventually, all of the keys are tried (and timed out), and the proper one is found. However, the authentication system doesn’t like this and locks out all other authentication for a period of time.

In Leopard, this problem goes away because VPN will pseudo fail to work at all with multiple keychain items.

[JonThompson]

Just got a bit closer to solving this one. Killing coreservicesd caused the system to immediately resolve itself. Now, what is going on there?

OK, that wasn’t it. By the way, how many of you have their HDs Software RAIDed?

I think I got it. If I turn off the firewall, the problem goes away. Allowing access to the password server ports through the public IP then appears to eliminate the problem. Question now is what can of worms am I opening up by allowing public access to the password service ports and/or how am I and other misconfigured so that we need this port open?

[JonThompson]

Has anyone resolved this yet on their boxes, without splitting vpn? My Xserve, after working without issue for months, has suddenly come down with this issue. I think that a restart took care of it for the moment, but I am not sure how long that will last.

[Author]

Posts