[luke]

I had the same problem in 10.5 and re-creating the key agent user didn’t work for me at first. Make sure to shut off the VPN service first, and delete any trace of any previous key agent users (from WGM, and also with mkpassdb if necessary). Then create a new keyagentuser per the instructions in this thread, and finally start up the VPN service again. YMMV

[luke]

I have exactly the reverse problem. I have an OD Master which is multihomed on two networks. That is, it has two interfaces with two IPs connected to two separate subnets. It publishes both of its IPs to clients so that they can apparently use either one to connect to it, but I only want it to publish one of them. Any ideas?

[luke]

I’ve noticed that if there is even a single record referencing the home share, it will continue to show up in the list in WGM. Go through all of your user records and group records and make sure none of their home (or group) folders are referencing the old share.

If that doesn’t work, you could check in the LDAP directory to see what entries are listed under “Mounts.” You can use WGM if you “Show all records tab” in its preferences. I also find the Apache Directory Studio to be a very nice LDAP editor for use with OD.

[luke]

We need more details. What do you need this server to do? If you want an exact clone on Mac OS X Server, you could (almost) do it with linux or bsd. The things you wouldn’t get are AFP server, Xgrid, WebObjects, Quicktime Streaming, and the GUI utils. Having said that, it will be no easy task to replicate anything but a small portion of the functionality.

Open Directory would be pretty tough to replicate, but if you install Kerberos 5, OpenLDAP, and use the schema extensions from OS X Server, you would be most of the way there. Keep in mind though that you will have to do everything manually using kadmin and an LDAP editor. Apache has a fantastic LDAP client that runs on the Mac which you can use for creating users, groups, automounts. MCX settings will be possible but difficult. They are plists encoded in base64 (I think) in LDAP.

Cyrus, Postfix, Jabber, Bind, NFS, Samba, etc… These are all open source and can be compiled on Linux. For the most part they will work in exactly the same way. You will have to manually get them working by configuring through the config files, and may have to do some work to get them all authenticating with Kerberos and authorizing through LDAP.

Good luck! Consider writing an article if you go down this route.

[luke]

1) One thing you could try is to use IMAP to do this. If you run both servers simultaneously, you can connect to both of them from Mail.app as the postuser, and then drag email across en mass. Of course, you would probably rather jab yourself with a fork than use Mail.app for this, so you could do the same with a perl script and Net::IMAP.

Connecting as the postuser will show all of your users as subfolders (although this isn’t the primary use for the postuser). I usually use the diradmin account as the postuser (just during an install though). To enable it, you have to enable mail for diradmin, plus edit /etc/imapd.conf to define it as the postuser.

[luke]

Magus255, could you elaborate on how you used this on drop boxes? Permissions issues on drop boxes drive me crazy!

[luke]

This just happened to us too. All of the maps are still located in the server’s local directory at /Local/Default/Computers/, but they don’t show up in Server Admin.

Is there another location that holds these maps? Or some sort of index file that got clobbered?

[luke]

See also: https://www.afp548.com/forum/viewtopic.php?showtopic=18732

[luke]

Ping!

I really need this functionality too. I suspect we can edit /etc/authorization somehow to allow regular users (or users of a specific “Printer Admins” group) to administer their own printers. My more immediate problem is that printers on my clients have become “paused” and users are not able to unpause them without an administrator password.

Does anyone have a solution?

[luke]

If a client is looking at an AD server for authentication and an OD server to get a few MCX policies, then if the OD server is down a user will likely still be able to log in (albeit with somewhat unpredictable results). The MCX settings will stay set in general. If some user or process is actively trying to change them to something else though, OD obviously won’t be able to enforce its policies.

If you can deploy Leopard server then you’re probably better off moving away from the magic triangle concept. Your macs can look solely at the OD infrastructure which will proxy (and augment) the records from AD.

[luke]

Those services almost definitely need to store extra stuff in the directory. You may be able to extend the schema of your existing LDAP server to support these new attributes, or you can use the “augmented users” feature of Leopard server.

There is quite a lot of documentation on these processes already I believe, and I would also recommend watching the Directory Service presentations from macworld at: [url]http://www.macworldencore.com/online/presentation.asp[/url] under “Mac OS X” and “Server.”

[luke]

Maybe you need to add the $, but have to escape it or else the shell will eat it instead of passing it as part of the argument. I believe a \$ will escape it in bash, so try dhcp57-145\$.

In dscl, are you able to use that same command if you go into the dscl shell first?

[luke]

Watch the 3 Directory Services presentations from Macworld, which are available from this site under “Mac OS X” and “Server”
[url]http://www.macworldencore.com/online/presentation.asp[/url]
Specifically, the second one talks a lot about what data is stored where in OD, and how one would go about exporting it, massaging it, and importing it into a new OD setup.

To quickly do what you want, you could try using “slapcat > mydirectoryback.ldif” as root on your server to get an LDIF-formatted export of your LDAP directory. Then you can use a text editor or your favorite scripting to parse out the pieces you need and modifying them to suit your needs. You will need to remove some attributes which will get recreated when you import it again. Then you can use ldapadd on your new server to import the entries. Read the man pages and test things out on a test server that doesn’t matter.

[luke]

Hmmm. This is on a test Leopard network with clean installs of both the client and server. None of the users or groups were even imported.

Do you think that maybe even though it can merge the MCX settings from all of the effective groups, it can’t actually merge dock tiles? Has anyone specifically tried this with dock tiles?

[luke]

Answer to #1

Use ditto with the -z option to create a compressed archive of the home directory. Move that over to the new server and unpack it. (See man ditto for exact details). Then go into workgroup manager, change the user’s home directory to ParisServer/Users. Change their group to ParisEmployee. This is approximately what I’ve done in the past (on Tiger), although I didn’t need to create a compressed archive because I was moving it between relatively close servers.

[Author]

Posts