[cmcfarling]

What is the record called specifically? Here’s a screenshot of what cn=config looks like now with the ldapreplicas record hilighted:

[url]http://www.50amp.com/od/ldap.jpg[/url]

Is a record missing?

[cmcfarling]

In the meantime I’ve been trying every trick I can dig up. The general rule of thumb seems to be if you have problems with your replicas, just demote them to standalone and then re-promote to replica status. I have tried that in past troubleshooting attempts to solve this issue and I’ve tried it about 10 times in the last day again. This time I was more thorough. I tried the demote/promote process from both WGM and using slapconfig, each multiple times. Unfortunately the end result remains the same, new users can’t mount AFP shares until both servers are restarted. This time around I ran into some other issue along the way. After my first attempt at using slapconfig to create an OD replica on server02 somehow caused the local admin account to stop working. Before doing any of this, I would log into WGM using the address format of server02.domain.com. Now, if I do that, WGM can not access the LDAPv3/127.0.0.1 directory and gives an error of “Record type not mapped. The record with type “PrestUsers” is not mapped. …” If I log into WGM using the address format of server02.local however, all is well.

So anyway I’m back to square one. I have a functional, for the most part, OD but it seems that any minor change may be enough to blow it up. I’m giving up on it and I guess I’ll just plan to do a clean install of everything and upgrade at the same time (probably to 10.5 at this point).

[cmcfarling]

From what I can gather Ghost has the ability to backup open files. I assume it uses technology similar to Acronis Trueimage for which I dug up a whitepaper on the internet. Basically it incorporates a driver that sits above the disk driver and can intercept writes while the app is imaging.

Ideally I’d like to be able to backup an OSX server startup disk to a dmg file stored elsewhere on the network for disaster recover purposes. When needed I could simply use asr to restore the dmg to the server drive and be up & running quickly.

So far there are several caveats that I’m running into. The volume where the backups will go is an SMB volume on a Windows server. The machines I want to do this on are currently running 10.3.9. In all my testing, I can’t get hdiutil to store a -srcfolder dmg file on an SMB share. I’m beginning to think that the 10.3.9 hdiutil simply can’t accomplish this (it does work with 10.4 though).

Another option would be to forget the dmg and use rsyncx. Again the fact the the destination is an SMB share presents complications that I’d rather not mess with with regard to resouce forks. Even if I got this working, restoring to a new disk wouldn’t be as simple as the asr method.

A third option would be to use a combination of a dmg file and rsyncx. I realize upgrading to 10.4 (or even 10.5 when it’s available) would simplify matters and it may just be time to finally do that. For the initial backup, hdiutil could be used to image the startup disk and store it on a remote volume. Then, periodically rsyncx (or rsync if using 10.4 or later) could be used to syncronize changes between the startup disk and the dmg file. This would maintain an up-to-date dmg file while still allowing a fast restore with asr.

Is anyone running this type of backup operation? Is there any reason why this wouldn’t work well?

[cmcfarling]

Win2K IE 6.0.2800

Here are some screen shots

[img]http://www.50amp.com/images/screen1.jpg[/img]

[img]http://www.50amp.com/images/screen2.jpg[/img]

[cmcfarling]

This now bugged with Apple as ID 4422832.

[cmcfarling]

I contacted Apple support. The tech was able to reproduce this problem, so it looks like a bug. He’s escalating the issue. When I hear something back I’ll post it.

[cmcfarling]

We do indeed use Retrospect Workgroup, running on a server, to do daily incremental backups. We also use the Desktop version to do long term archiving. Been doing it this way for years with no problems.

[cmcfarling]

[QUOTE]I’ve backup up servers with the noNetworkUsers setting with Retrospect plenty of times. True it runs as root, but it’s a local client running as root and not over AFP so it shouldn’t make a difference.[/QUOTE]

To clearify, in my case Retrospect is not running on the server, it’s running on a desktop machine. This is the “archive” station. The desktop machine must mount a server volume in order to access the files that need to be archived to tape. In this case, Retrospect IS accessing files over AFP. Depending how the volume is mounted, Retrospect may or may not have permission to the files (as noted earlier) when noNetworkUsers = yes.

[cmcfarling]

iperf is good for testing raw network speed. It uses a client/server architecture and can do multiple connections.

To check AFP specifically, you can do:

client –> server
——————–
dd bs=1m count=1000 if=/dev/zero of=/Volumes/mounted_volume_name

server –> client
———————
dd bs=1m count=1000 if=/Volumes/mounted_volume_name/file_name of=/dev/null

This will take your client disk performance out of the equation

[cmcfarling]

Of course, an unexpected problem has now popped up. Apparently Retrospect cannot access files on a server volume when noNetworkUsers = yes. It’s something to do with the fact that Retrospect runs as root. You can use Retrospect’s “Configue Volume” feature to have Retrospect mount the volume under the root account, allowing it to access files. However, you are not able to view anything on the mounted volume from the Finder when it gets mounted this way.

[cmcfarling]

Apple’s suggestion at this point for me was to upgrade the servers to 10.3.9 and see if that fixed the problem. I did that today and it did not fix it. I then changed the noNetworkUsers setting to YES, restarted AFP and the problem was resolved. So, it appears that that is the fix. I’ll keep monitoring it to make sure there are no adverse side effects though.

Thanks for the help

[cmcfarling]

Open Directory is in place, configured with Kerberos, SSO, etc. The user accounts are set up as Managed Mobile accounts. That way I have directory based accounts with local home folders (I do not want server based home folders).

I’ve tried logging in using standard Appleshare authentication (i.e. I destroyed Kerberos ticket, logged into server, cancelled out of Kerberos authentication dialog box forcing the standard Appleshare auth dialog box) but I get the same results.

[cmcfarling]

Some dummy (me 🙂 ) did it.

Actually, I was attempting to mimick OS9’s ability to lock folders so that they can’t be moved or renamed. Occasionally someone inadvertantly moves the “Jobs” folder into the “To Archive” folder for example. I’d like to prevent this from happening. With OSX, when you Get Info on a folder, the Locked checkbox is grayed out. I was trying out the chflags command to see if I could accomplish it that way. Well, the folder (luckily I tried it on a test folder) can’t be moved or renamed now. Unfortunately nothing can be done to it really.

On a side note, the man page for chflags says the following flgas can be set:

archset the archived flag (super-user only)
opaque  set the opaque flag (owner or super-user only)
nodump  set the nodump flag (owner or super-user only)
sappnd  set the system append-only flag (super-user only)
schgset the system immutable flag (super-user only)
sunlnk  set the system undeletable flag (super-user only)
uappnd  set the user append-only flag (owner or super-user only)
uchgset the user immutable flag (owner or super-user only)
uunlnk  set the user undeletable flag (owner or super-user only)

archived, sappend, schange, simmutable, uappend, uchange,
uimmutable, sunlink, uunlink
aliases for the above

However, the uunlnk and sunlnk do not work (unrecognized command). Maybe if those worked then I could accomplish what I’m trying to do. Any idea why those flags can’t be set on OSX?

[cmcfarling]

It sounds like you’ve tried all of the usual suspects. I’ve determined that the OD architecture is quite unforgiving if things aren’t perfect. A couple things I’ve done to resolve problems:

1) Make sure the master and replica have FQDN’s. If you don’t get a FQDN with the ‘hostname’ command, you’ll have problems. (I know you mentioned that you have this setup but I thought I’d mention it anyway)

2) Repair permissions after getting things setup how you want them.

3) Destroy and rebuild. I’ve wiped out and recreated my replica 6 or 7 times and my master 3 or 4 times since initially setting this thing up a couple months ago. (usually at the suggestion of Apple tech support)

4) Delete the Managed Mobile account from the client, forcing the creation of a new one on the next login.

It seems like it’s been one problem after another with OD though. For a while, the DNS server on the master would not work immediately following a reboot, which caused the KDC to not work, which made the OD useless. Miraculously, it started working a while back and I haven’t had problems since.

To answer your last question, I would doubt that the hardware is causing your problem.

[cmcfarling]

I spoke with 2 Apple techs this week regarding a related OD issue and asked them about this. The first one told me it’s not supported. It was one of those “if it doesn’t work then it’s not supported” answers to get me off the phone. The second tech actually took about 10 minutes to look into it and then determined that it can’t be done.

So it looks like the bottom line is that auto-login for mobile users doesn’t work at this point.

[Author]

Posts