Tiger Lab Migration Part 2: Client/Server Interaction
As foretold, I've rebuilt my admin machine with fresh-from-the-factory Tiger. Nice. Things are going well.
I'm testing right now. Partly, I'm testing how Tiger does from a clean install. I'm also testing its interaction with my Panther Server. So far I have hit one, minor snag here, and it appears to be a bug in Tiger's Directory Access application.
In Panther Client's version of DA, the LDAPv3 configuration panel was set up by double-clicking the "LDAPv3" entry under "Services," then clicking "New..." at the bottom of the drop-down panel, and entering your server info in the available fields of the new entry. The Tiger version is slightly different: In Tiger, pressing "New..." brings up a dialogue box called "New LDAP Connection." Here you can enter information about how you want your client to use LDAP (i.e. for contact, or authentication, and whether or not to use SSL encryption). At the bottom of this dialogue is a "Manual" button which allows you to set up the panel the old, Panther-style way. Being old-school, I chose "Manual."
Silly me.
Turns out, setting up the server binding with the "Manual" button works, but the settings don't survive a restart. I tried this numerous times, and it would initially work, immediately binding to the server (which, by the way, is still Panther, and this may be part of the problem, but I seriously doubt it). But after restarting, though the entry would still exist in DA, the binding would be broken. No authentication, no computer management, nothing. The way to get it to work is to use the new, and supposedly improved, dialogue that pops up when you press "New..." in the LDAPv3 configuration panel -- the aforementioned "New LDAP Connection" window. Using this method to set up binding to my Mac Server worked. The new entry, once created in this manner, can be edited after the fact if need be. And best of all, the binding survives a reboot of the client.
Actually, the new dialogue does have one really nice thing going for it: It sets up the server paths in "Authentication" and, if you tell it to, in "Contacts." You used to have to set these up manually, in a separate steps, under the "Authentication" and "Contacts" panes, but now, if you check the appropriate checkboxes, DA does it all for you from the "New LDAP Connection" panel. Nice.
Well, it would be nice, if the "Manual" method worked. Still, it's better than a kick in the teeth.
So, with authentication working between Tiger client and Panther Server, I'm over halfway there. In addition to authentication, preference management (things like Login Items and such) appear to be working. The last thing on the client/server relationship checklist is services, mainly printing services. I'll be kicking this around for a bit, and then I'll be starting my Radmind work.
Just a preview of that: To start, I will install Radmind on my admin box and set it up a a Radmind server. Once that's all up and running (and I should really do some checking up to make sure Radmind is Tiger compatible), the odious task of setting up the master client from scratch will begin. To reiterate, this will be a machine that has everything that I plan to install on the various workstations on the floor. From this, sets will be made for each hardware/software configuration. Each change to the master client will have to be tracked by the server, starting with the base install, and building loadsets (overloads?) as software is added. This will take some time and patience, but it should be worth it in the end.
Let's hope.
So, when next we meet, I will be setting up Radmind. I will do my best to be as detailed and comprehensive in the documentation of this process as I possibly can be.
Oh yeah, and one other thing before I install Radmnd: I'm cloning my working Tiger install. 'Cause you never know.
UPDATE 1:
I have begun building my Master Client machine. The problem of server/client binding failing after reboot is now occuring on this machine, and using the "New LDAP Connection" window to set it up does not seem to work in this case. Thus far, I have been unable to bind my Master Client to the Macserver in a way that the binding survives a restart. This would seem to be the salient error in the system log:
Jun 27 19:43:45 systemsBoyMac /System/Library/CoreServices/mcxd.app/Contents/MacOS/mcxd: DSOpenNode(): dsOpenDirNode("/LDAPv3/192.168.1.10") == -14002
Simply opening the Directory Access application, authenticating, and opening the LDAPv3 configuration panel will bind the client to the server. The message that gets written to the log in this case is:
Jun 27 19:50:02 systemsBoyMac /System/Library/CoreServices/mcxd.app/Contents/Resources/MCXCacher: CacheUser(0, systemsboy) == -14136
I don't get it. I'll post when I find the solution.
UPDATE 2:
Deleted the /Library/Preferences/Directory Access directory -- which contains the preferences for, obviously, Directory Access -- rebooted (twice) and was able to login as a network user both times. I'd done this before. The differnce this time was that I logged in as a network user first, before logging in as a local user. I'm making a third attempt this very moment. The computer is rebooting... Now logging in as a local user... Good... Now as a network user... No luck! The login screen shakes it head at me. It would appear that setting up binding, rebooting, then logging in as a local user will break the binding. Man. That's fucked up.
More to come...
UPDATE 3:
So now I've trashed the DA prefs again. But when I launch the DA application, it's still set up with the old binding config. So apparently, there's some pretty nasty caching going on. I'm trashing all prefs in /Library now, and clearing the mcx_cache from NetInfo. Rebooting. Setting up the Network. Setting up DA. Rebooting. Now I'm bound, and network logins work. What a blast. I hate this shit. Trying again -- rebooting, logging in as a network user, success. One more time, this time local user logs in first -- reboot, wait... Binding is broken... WTF!? I must admit, I'm stumped.
Will keep you posted...
UPDATE 4:
Okay, now this is too bizarre. There are telltale signs that the client is not bound. One of them is that the "Other..." button does not appear in the list of users at the login window; there are only local users in the list. The other is that the server does not appear in /Network/Servers. When the client is bound, you will see a network mount (or actually, a symlink to the network mount) in this directory. So I'm poking around in the Terminal on my client, with the /Network/Servers window open, and I'm looking at logs and whatnot, and all of a sudden I see the server mount point show up. Out of nowhere. And it occurs to me, maybe the binding is just slow. So I reboot the client and just leave it at the login screen. After about three minutes, the "Other..." button shows up. Just pops right up. Client is bound.
I can reproduce this on two machines now, but I can't explain why it takes so long, and why this behavior is so inconsistent. My server is at 10.3.8 and has some strangeness about it. I will be looking at it to see if these problems are perhaps now manifesting themselves more obviously with Tiger clients. I will also consider upgrading the server to 10.3.9, as there are apparently changes to the LDAP schema that were made with that update that were in preparation for Tiger.
I'll let you know what I find...
UPDATE 5:
Another anomaly: Logging in to a bound client and navigating to /Network/Servers and selecting the server automount (we have a home account automount) causes the Finder to beachball indefinitely. Relaunching the Finder kills the beachball, but the network mount is broken (i.e. there is an empty mount point), and lots of automount errors in the system log. Oy! Time to fix/update the server.
I am now cloning my Macserver in preparation for moving to 10.3.9. Hopefully this will at least resolve the automount issues, and maybe even the slow binding issues. Of course, the ultimate solution will be to migrate to Tiger server. Still no idea when I'll be getting my disks, but when I do, there's a great article on the migration process at AFP548.
UPDATE 6:
I have updated my Panther Server to 10.3.9. Though the upgrade went smoothly, and I have experienced no problems with it, it has not solved my Tiger client problems, which are, to reiterate:
1. Binding to the server from a Tiger client takes approximately three minutes after reboot to occur. So there is a three minute period after a reboot during which a network user on a Tiger client cannot login. Suddenly, after three minutes or so, he/she can.
2. Network home account mounts from the Panther server do not automatically mount on the Tiger client. They should, and they do in Panther client. Here's the error message from the Tiger client system log:
Jun 30 16:42:18 systemsBoyMac automount[241]: Can't mount pantherServer:/Volumes/FlashDeveloper on /private/Network/Servers/pantherServer/Volumes/FlashDeveloper: Authentication error (80)
It's looking more and more like I'm going to have to install Tiger server before I can proceed much further.
Shit...
UPDATE 7:
Well, this is turning out to be more fun than a barrel of monkeys.
Finally got the network home account mounting and the user authenticating. It is not an automount problem, but rather an authentication problem. Apparenly, Tiger client cannot login to Panther server if the user's password is of type "Open Directory." Crypt passwords work fine. (I knew there was a reason I wanted to stay with crypt, but nooo, Apple said "Use Open Directory passwords. They're better." Yeah right.
I'm on my way to the Apple Discussions to see what I can dig up.
I'll let you know...
UPDATE 8:
(Hey, that rhymes.)
So I changed the password type of my network user to "Crypt" and could suddenly log in, right? Now here's something weird: I changed that same user's password back to "Open Directory," and guess what? It worked.
This would seem to indicate something screwy with the password server, but I'm hard pressed to say what it is. In any case, this presents a real problem for me, as I have about 50+ users with Open Directory passwords, and the way things are right now, they're not going to work in Tiger. The only way for me to change them is to get all 50 users to come in and change their passwords in Workgroup Manager, and that's just unacceptable to me.
This is why I long for a utility that lets OD admins change user password types without having to reset the password. This doesn't seem like a stretch to me, nor does it seem unreasonable, particularly if you have a lot of users, which I do. Because now I'm stuck with 50 or so users with Open Directory passwords that just won't work, and the only way to fix this is to reset their passwords, when really, all I want to do is change the password type to "Crypt," and all the data I would need to do that (i.e. the passwords) is there on the server. It's just inaccessible by the admin. So fine, give me a utility that lets me change the password type without resetting the password. I don't need to see the password to do this; the utility can do it. I just want to make the change, and I can't, and that's Bad. (And, BTW, the reverse could be true as well: What if you have 300 crypt-style users and you want to change them to Open Directory passwords? As it stands, I guess you're going to have a mightly long line outside your door.)
Anyway, from what I've read at the Apple Discussions, this sounds like it might be a problem not just with Panther servers, but with Tiger servers as well. I'm betting these are all upgraded or migrated servers, and that fresh Tiger (and maybe even Panther) server installs work just dandy, which is why only some people are experiencing problems.
Anyway, this is endlessly annoying. I'm done for the night...
I'm testing right now. Partly, I'm testing how Tiger does from a clean install. I'm also testing its interaction with my Panther Server. So far I have hit one, minor snag here, and it appears to be a bug in Tiger's Directory Access application.
In Panther Client's version of DA, the LDAPv3 configuration panel was set up by double-clicking the "LDAPv3" entry under "Services," then clicking "New..." at the bottom of the drop-down panel, and entering your server info in the available fields of the new entry. The Tiger version is slightly different: In Tiger, pressing "New..." brings up a dialogue box called "New LDAP Connection." Here you can enter information about how you want your client to use LDAP (i.e. for contact, or authentication, and whether or not to use SSL encryption). At the bottom of this dialogue is a "Manual" button which allows you to set up the panel the old, Panther-style way. Being old-school, I chose "Manual."
Silly me.
Turns out, setting up the server binding with the "Manual" button works, but the settings don't survive a restart. I tried this numerous times, and it would initially work, immediately binding to the server (which, by the way, is still Panther, and this may be part of the problem, but I seriously doubt it). But after restarting, though the entry would still exist in DA, the binding would be broken. No authentication, no computer management, nothing. The way to get it to work is to use the new, and supposedly improved, dialogue that pops up when you press "New..." in the LDAPv3 configuration panel -- the aforementioned "New LDAP Connection" window. Using this method to set up binding to my Mac Server worked. The new entry, once created in this manner, can be edited after the fact if need be. And best of all, the binding survives a reboot of the client.
Actually, the new dialogue does have one really nice thing going for it: It sets up the server paths in "Authentication" and, if you tell it to, in "Contacts." You used to have to set these up manually, in a separate steps, under the "Authentication" and "Contacts" panes, but now, if you check the appropriate checkboxes, DA does it all for you from the "New LDAP Connection" panel. Nice.
Well, it would be nice, if the "Manual" method worked. Still, it's better than a kick in the teeth.
So, with authentication working between Tiger client and Panther Server, I'm over halfway there. In addition to authentication, preference management (things like Login Items and such) appear to be working. The last thing on the client/server relationship checklist is services, mainly printing services. I'll be kicking this around for a bit, and then I'll be starting my Radmind work.
Just a preview of that: To start, I will install Radmind on my admin box and set it up a a Radmind server. Once that's all up and running (and I should really do some checking up to make sure Radmind is Tiger compatible), the odious task of setting up the master client from scratch will begin. To reiterate, this will be a machine that has everything that I plan to install on the various workstations on the floor. From this, sets will be made for each hardware/software configuration. Each change to the master client will have to be tracked by the server, starting with the base install, and building loadsets (overloads?) as software is added. This will take some time and patience, but it should be worth it in the end.
Let's hope.
So, when next we meet, I will be setting up Radmind. I will do my best to be as detailed and comprehensive in the documentation of this process as I possibly can be.
Oh yeah, and one other thing before I install Radmnd: I'm cloning my working Tiger install. 'Cause you never know.
UPDATE 1:
I have begun building my Master Client machine. The problem of server/client binding failing after reboot is now occuring on this machine, and using the "New LDAP Connection" window to set it up does not seem to work in this case. Thus far, I have been unable to bind my Master Client to the Macserver in a way that the binding survives a restart. This would seem to be the salient error in the system log:
Jun 27 19:43:45 systemsBoyMac /System/Library/CoreServices/mcxd.app/Contents/MacOS/mcxd: DSOpenNode(): dsOpenDirNode("/LDAPv3/192.168.1.10") == -14002
Simply opening the Directory Access application, authenticating, and opening the LDAPv3 configuration panel will bind the client to the server. The message that gets written to the log in this case is:
Jun 27 19:50:02 systemsBoyMac /System/Library/CoreServices/mcxd.app/Contents/Resources/MCXCacher: CacheUser(0, systemsboy) == -14136
I don't get it. I'll post when I find the solution.
UPDATE 2:
Deleted the /Library/Preferences/Directory Access directory -- which contains the preferences for, obviously, Directory Access -- rebooted (twice) and was able to login as a network user both times. I'd done this before. The differnce this time was that I logged in as a network user first, before logging in as a local user. I'm making a third attempt this very moment. The computer is rebooting... Now logging in as a local user... Good... Now as a network user... No luck! The login screen shakes it head at me. It would appear that setting up binding, rebooting, then logging in as a local user will break the binding. Man. That's fucked up.
More to come...
UPDATE 3:
So now I've trashed the DA prefs again. But when I launch the DA application, it's still set up with the old binding config. So apparently, there's some pretty nasty caching going on. I'm trashing all prefs in /Library now, and clearing the mcx_cache from NetInfo. Rebooting. Setting up the Network. Setting up DA. Rebooting. Now I'm bound, and network logins work. What a blast. I hate this shit. Trying again -- rebooting, logging in as a network user, success. One more time, this time local user logs in first -- reboot, wait... Binding is broken... WTF!? I must admit, I'm stumped.
Will keep you posted...
UPDATE 4:
Okay, now this is too bizarre. There are telltale signs that the client is not bound. One of them is that the "Other..." button does not appear in the list of users at the login window; there are only local users in the list. The other is that the server does not appear in /Network/Servers. When the client is bound, you will see a network mount (or actually, a symlink to the network mount) in this directory. So I'm poking around in the Terminal on my client, with the /Network/Servers window open, and I'm looking at logs and whatnot, and all of a sudden I see the server mount point show up. Out of nowhere. And it occurs to me, maybe the binding is just slow. So I reboot the client and just leave it at the login screen. After about three minutes, the "Other..." button shows up. Just pops right up. Client is bound.
I can reproduce this on two machines now, but I can't explain why it takes so long, and why this behavior is so inconsistent. My server is at 10.3.8 and has some strangeness about it. I will be looking at it to see if these problems are perhaps now manifesting themselves more obviously with Tiger clients. I will also consider upgrading the server to 10.3.9, as there are apparently changes to the LDAP schema that were made with that update that were in preparation for Tiger.
I'll let you know what I find...
UPDATE 5:
Another anomaly: Logging in to a bound client and navigating to /Network/Servers and selecting the server automount (we have a home account automount) causes the Finder to beachball indefinitely. Relaunching the Finder kills the beachball, but the network mount is broken (i.e. there is an empty mount point), and lots of automount errors in the system log. Oy! Time to fix/update the server.
I am now cloning my Macserver in preparation for moving to 10.3.9. Hopefully this will at least resolve the automount issues, and maybe even the slow binding issues. Of course, the ultimate solution will be to migrate to Tiger server. Still no idea when I'll be getting my disks, but when I do, there's a great article on the migration process at AFP548.
UPDATE 6:
I have updated my Panther Server to 10.3.9. Though the upgrade went smoothly, and I have experienced no problems with it, it has not solved my Tiger client problems, which are, to reiterate:
1. Binding to the server from a Tiger client takes approximately three minutes after reboot to occur. So there is a three minute period after a reboot during which a network user on a Tiger client cannot login. Suddenly, after three minutes or so, he/she can.
2. Network home account mounts from the Panther server do not automatically mount on the Tiger client. They should, and they do in Panther client. Here's the error message from the Tiger client system log:
Jun 30 16:42:18 systemsBoyMac automount[241]: Can't mount pantherServer:/Volumes/FlashDeveloper on /private/Network/Servers/pantherServer/Volumes/FlashDeveloper: Authentication error (80)
It's looking more and more like I'm going to have to install Tiger server before I can proceed much further.
Shit...
UPDATE 7:
Well, this is turning out to be more fun than a barrel of monkeys.
Finally got the network home account mounting and the user authenticating. It is not an automount problem, but rather an authentication problem. Apparenly, Tiger client cannot login to Panther server if the user's password is of type "Open Directory." Crypt passwords work fine. (I knew there was a reason I wanted to stay with crypt, but nooo, Apple said "Use Open Directory passwords. They're better." Yeah right.
I'm on my way to the Apple Discussions to see what I can dig up.
I'll let you know...
UPDATE 8:
(Hey, that rhymes.)
So I changed the password type of my network user to "Crypt" and could suddenly log in, right? Now here's something weird: I changed that same user's password back to "Open Directory," and guess what? It worked.
This would seem to indicate something screwy with the password server, but I'm hard pressed to say what it is. In any case, this presents a real problem for me, as I have about 50+ users with Open Directory passwords, and the way things are right now, they're not going to work in Tiger. The only way for me to change them is to get all 50 users to come in and change their passwords in Workgroup Manager, and that's just unacceptable to me.
This is why I long for a utility that lets OD admins change user password types without having to reset the password. This doesn't seem like a stretch to me, nor does it seem unreasonable, particularly if you have a lot of users, which I do. Because now I'm stuck with 50 or so users with Open Directory passwords that just won't work, and the only way to fix this is to reset their passwords, when really, all I want to do is change the password type to "Crypt," and all the data I would need to do that (i.e. the passwords) is there on the server. It's just inaccessible by the admin. So fine, give me a utility that lets me change the password type without resetting the password. I don't need to see the password to do this; the utility can do it. I just want to make the change, and I can't, and that's Bad. (And, BTW, the reverse could be true as well: What if you have 300 crypt-style users and you want to change them to Open Directory passwords? As it stands, I guess you're going to have a mightly long line outside your door.)
Anyway, from what I've read at the Apple Discussions, this sounds like it might be a problem not just with Panther servers, but with Tiger servers as well. I'm betting these are all upgraded or migrated servers, and that fresh Tiger (and maybe even Panther) server installs work just dandy, which is why only some people are experiencing problems.
Anyway, this is endlessly annoying. I'm done for the night...
Labels: Lab, Systems, Tiger, TigerLabMigration
This entry was posted
on Thursday, June 23, 2005 at 8:08 PM.
You can skip to the end and leave a response.
6:20 PMI had a very similar problem. In my configuration, the authentication server is OpenLDAP running on Debian GNU/Linux 3.1 using the RFC 2307 schema. Mac OS 10.4.2 clients would use the server if I configure it manually using the Directory Access utility but as soon as I reboot the client it stops finding the accounts in the LDAP directory. Reconfigure manually and everything works again until the next reboot.
Finally, I found a solution that works. First, I configured the server manually with RFC 2307 mappings in the Directory Access utility on the client. Then I wrote those mappings to the server (still using the Directory Access utility). This creates an ou=macosxodconfig directory entry with a big blob o' XML in its description attribute. Future OS X clients that bind to the server will automagically use that blob o' XML to figure out which objectclasses/attributes to use when looking up account information. This is how you get the Mappings: From Server bit in Directory Access to work.
Next, I configured my DHCP server (ISC) to provide the URL for the LDAP server in its DHCP replies, and I configure the client to use the DHCP-provided LDAP servers.
Finally, for both "Authentication" and "Contacts" in Directory Access I configure the path to be automatic.
So, now the client boots up, DHCPs an IP address and gets the LDAP server URL in the DHCP reply. Then it contacts the LDAP server, gets the Directory Access mappings from the big blob o' XML in "ou=macosxodconfig", and since the authentication path is "automatic", adds the LDAP directory to the list of authentication sources.
I believe this works because it essentially causes the client to do a full manual reconfiguration (automatically!) every time it boots up.
BTW, it takes about 10 seconds after the login widget appears before network accounts can log in successfully.
Chip Coldwell
coldwell (at) physics (dot) harvard (dot) edu
10:38 AM
Quick hints for this one having just lived your agony...
Make sure your DNS records are set properly. If your local hostname doesn't match the DNS name, it will never work reliably.
Set your hostname with hostname -s to match the DNS name and you should be OK... except that often times, Bonjour will reset it with the .local suffix instead of your local DNS suffix which causes it some problems.
9:15 PM
Hey, wow. I didn't realize anyone was reading this site. Thanks, Chip and Erik, for your comments. The bit about running the LDAP authentication from a Linux server may come in very handy for me in the near future, as we'd like to try doing this in order to host authentication data for our entire network -- Macs, Linux and Windows machines -- from one server, and we've agreed that that machine should ultimately be running Linux (though I've suggested repeatedly, and only in partial jest, that we host everything from a Mac server, but I'm somewhat biased, and not always for the wiser).
When I begin that process, I will surely post all about it here. But I have no idea when that might be.
Anyway, thanks again.
systemsboy
» Post a Comment