[gw1500se]

Never mind. The 2nd attempt worked. I guess the definition of insanity is no longer doing the same thing over and expecting different results. Sorry.

[gw1500se]

You don’t say what version of OS X server you are using but I know this is a problem on 10.4 because we encounter it a couple of times each week. I would hope it is fixed in 10.5 and 10.6 but maybe not if you are using one of those. The Apple password and Kerberos databases are out of sync. Anyway, the way we fix it on Tiger is simple but you’ll likely find it strange:

In Workgroup manager highlight the errant user and click the “Advanced” tab. Change the “User Password Type” to crypt password. Enter the password in the resulting dialog box and then save. Next, click off that user to any other (don’t ask me why, I just know it won’t work otherwise) then click back to the errant user. Now switch the “User Password Type” back to open directory then again enter the password in the dialog and save. That will sync the Apple password and Kerberos databases.

If that doesn’t fix it then you must have discovered something new and I’m afraid I won’t be much help.

[gw1500se]

After considerable testing, hair pulling and teeth gnashing, I have more information on this but it is creating an even greater puzzle. It seems that this issue is related to users being members of multiple groups. The reason I am not getting any members for this group is because all its members have this group as their primary. Apparently the query I am using, only returns the members of a group that do NOT have that group as their primary. Logically this makes no sense to me but that is how it seems to work.

Therefore, the question becomes, how do I structure a query to return all members of a group, including those that have the group as its primary.

Thanks.

[gw1500se]

Thanks for the reply. I’m afraid I’m not having much luck with your suggestion. First I need to state that at this time I am running 10.4.11 server, if that matters. I suspect that may be why I can’t find ‘dsmembersutil’. Second, your reply probably attributes more LDAP knowledge to me that I really have.

You mentioned 2 steps but I don’t understand that. Your suggestion seems to get all the groups and members rather than a specific group’s members. If an additional filter is not possible I guess I can deal with that using a brute force method with the result I do get. However, using your suggestion, there are a few groups that return no members even though they do have them. Unfortunately, one such group happens to be the group I really need (Murphy’s Law). Perhaps that is the crux of my original problem.

I suppose the first question is, why do some groups falsely appear to have no members? How do I fix that?

Thanks again.

[gw1500se]

Thanks for the reply. I’ll give that a try.

[gw1500se]

Nope, you’re not stupid, I am. This is a new “feature” that did not exist on the Tiger version. I did not know what that field really was. Putting it in the right format makes all the difference. I guess it might have helped if I had paid attention to that little example below the field. Thanks, I owe you one.

[gw1500se]

Thanks for the reply. I put our company name in the organization name and I leave the minimum target selection on the default (Tiger 10.4). However, I tried selecting other entries but none will enable the OK button.

[gw1500se]

Just to close this out, it turns out that by default, the Kerberos library use some virtual location that is not available when run in background. Using KRB5CCNAME is the solution but it requires more then just a path. It also requires the type of node specifically it needs to be told to use a file. My solution was KRB5CCNAME=’FILE:/somefilepath”.

[gw1500se]

[QUOTE][u]Quote by: MacTroll[/u][p]The user the script is running as not have a real home?

No home = no cache.[/p][/QUOTE]
I missed the ‘?’ on this. Why wouldn’t the user have a home just because its running as cron? That certainly doesn’t happen with other Unix flavors. I don’t think that can be the problem after all.

[gw1500se]

Thanks. Perhaps it is because I’m running a perl script, but fs_usage does not generate anything (at least the silly way I tried it). This is also the first time I tried to use it so I’m sure I didn’t do it right. It seems like the script must already be running for fs_usage to work but it does not seem to have a way to launch the script. It is not clear from the man page how I get fs_usage to launch the command its supposed to monitor.

[gw1500se]

Thanks for the reply. I figured that is where this was heading. The standard Unix location for the credentials cache file is /tmp (I guess you are implying OS X is non-standard) not /home. The standard environment variable, KRB5CCNAME, is used to change the location of the cache file and that seems to be ignored by OS X. Since OS X does not seem to use Kerberos standards, how do I fix it?

[gw1500se]

What version of Windows are you using? We have XP-Pro and Home and both have been working for years. Vista is a different matter, we don’t have any. I don’t recall why I have it set, since we don’t use it, but it might be that WINS needs to be set on the DHCP server anyway. I’m guessing the wireless works because it gets its address from the wireless router and not the Mac server.

[gw1500se]

It doesn’t matter as it fails with any user including root. Yes. Remember this is a working script when launched from the command line. In background it fails initializing the credentials cache. If I knew where it writes the cache file I might be able to figure out why it fails. The puzzle is that I thought Apple used the standard Kerberos libraries. That being the case why is KRB5CCNAME seemingly not used?

[gw1500se]

[QUOTE][u]Quote by: bschappel[/u][p]
FWIW: the upgrade Leo server was not bad. I think you can do an in-place upgrade. I remember there was no way to upgrade from PPC Tiger server to Universal Tiger server but that Leopard would allow for a PPC Tiger to Leopard upgrade.

In the worst case (and I tested this) archive your OD info in Server Manager. Install a clean Leopard server, promote it to a master, and import the old archive. As I said it worked for me.[/p][/QUOTE]
From what I read, it won’t import properly. Were all your passwords in tact too? If that really does work, it will save a lot of headaches.

[gw1500se]

[QUOTE][u]Quote by: macshome[/u][p]Take a look at our AFP tuning articles as they can help quite a bit. If you have one particular folder that is causing issues, try whacking the .DS_Store from it if it has one. I tend to turn them off on network shares now anyway.[/p][/QUOTE]
Interesting solution. How did you stop OS X from putting it back?

[Author]

Posts