I've run into the same issue and it's a real bugger. The CPU usage on my OD
master is nearly always at 90-100%. It seems like Password Server is choking
on the extra authserveroverflow files when trying to add a new slot to the
database. Switching back to crypt is not an option since I need the OD
passwords for windows services. I've taken to running a cron job that removes
the extra authserveroverflow files ever hour on my master and replicas. A
"nice" side effect was that my replicas and master were no longer syncing
their password server databases with each other. And when they are syncing,
it's happening every few minutes even though I have replication set for every
30 minutes (my guess is that this is for the LDAP directory replication and
not Password Server). However, removing the authserveroverflow files has
helped remedy the situation. But it feels like putting a band aid over a
gushing wound.
I don't know if deleting the authserveroverflow files has resulted in users
passwords getting lost but it's a lot more usable than having them in there.
Does anyone know if this is strictly a 10.4.2 issue?
Patrick Lee
Academic Computing Technician
California College of the Arts
On Wed, 28 Sep 2005 07:26:26 -0400
email@hidden wrote:
I don't think the problem is a simple one or I hope Apple would have issued
a fix or workaround weeks ago. All of my customers who have moved to 10.4.2
Server are having problems like those described on this list (and the
macos-x-server list).... Cannot add new users due to password errors,
cannot access their home directory after being forced to reset the password
at login, the authserver folder filling up with 100's or 1000's of files,
etc. On the surface a quick fix is to set the users password to crypt, but
that is a poor solution in any environment and does not solve the problem.
Recently one of my customers contacted Apple tech support and the tech did
not even bother to open a case (because apparently this is such a common
issue) and instead sent him a canned email on how to reset the Open
Directory on the master and the replica. There are some minor changes
(hardcoding the FQDN into the hostconfig file), but I do not know if this is
a permanent fix or merely a way to rule out DNS at the install site as a
problem. I include the direction below in hopes they can be of use to
others. I would import my users from a known good file instead of exporting
them from your broken LDAP server though...
Hello,
Thanks for calling Apple. Here is the list of steps I mentioned during our
phone conversation. Please let me know if these steps do not correct the
issues you are experiencing.
Master
1. Log into the server as the root user.
2. Export users, groups, computer records by selecting them in Workgroup
Manager and choosing "export".
3. Demote ODMaster to standalone using Server Admin
4. From Go menu, select Go To Folder, enter "/etc". Find hostconfig file
and replace hostname=-AUTOMATIC- with FQDN.
5. From Go menu, select Go To Folder, enter "/var/db". Delete the folder
called "authserver".
6. Restart server.
7. Log into the server as your admin account, and use Server Admin to
promote to ODMaster.
8. Use Workgroup Manager to view LDAP domain, then Import computer records,
groups, and users.
9. Change user passwords to Open Directory type.
10. Use options button to 'require user to change password at first login'.
Replica
11. Re-establish replica by changing Server admin, open directory settings
to standalone.
12. From Go menu, select Go To Folder, enter "/var/db". Delete the folder
called "authserver".
13. Log into the replica as your admin account, and use Server Admin to
promote to ODMaster.
In a perverse way it's good to know that I am not the only one losing sleep
over this mess.
Regards,
Todd
On Sep 17, 2005, at 2:14 AM, Chris wrote:
but my solution came tonight when I received a case# from the
Server Team I spoke with under my maintenance contract. As soon as
I began to describe my situations, I was told all my problems were
related and this is a "not so subtle problem in automatic hosting"
that they are becoming aware of. While my issue will not be
worked on until next week,
