[dblack]

We experienced the exact same thing at our site and finally punted with a second cable back to the inside because of the same issue. The downside to using a second cable is that you end up with screwy behavior in terms of listeners and you will have to put a script into your startup items to set the route to the secondary card. Even in these situations, I’ve noticed that replication gets goofy.

When we tried this, we wanted a server in the DMZ to be a OD replica to provide authentication services to a blog server, webmail and others. We configured the PIX to do a route between the DMZ and the Inside so that our inside ldap server would “appear” to be inside the DMZ.

Quite a few authentication protocols seemed to work fine such as plaintext but the OSX ones for Blosjom, Jabber, AFP, etc. would fail. I don’t know what the mechanism is doing this…is it a lookup or verification of the sender IP address packet, is it doing a checksum of the whole packet? Which authentication service is this?

I’d still be interested to see if we could change this behavior.

[dblack]

Cheers to the ambiguous error messages!

It had nothing to do with SSH and everything to do with the fact that I hadn’t reset the local root password of my OD master in netinfo.

Doh!

[dblack]

Thanks…we used Passenger…all is good.

[dblack]

After changing our DNS names, and realm last week in OpenDirectory, I failed to overlook that our mail server, that get’s it’s OD info as a replica, needed to be redone – swtiched to standalone, then back to replica.

[dblack]

It looks like the export users from WM, destroy the ODMaster by making it standalone, recreate it, reimport users and groups…

Any problems with this idea?

[dblack]

Sorry, I just saw that this information exists elsewhere on this site. It said…

slapcat, change datafile, slapadd

Is this still it in a nutshell?

[Author]

Posts