[larkost]

The real problem is that the server admins should never have put any accounts in the 500 uid space. They probably had to play with things in order to get them there, and that should have been their first indication that this was a bad idea.

Anything you do to work around that initial mistake is going to involve a lot of work and a lot of potential gotchas that have to be avoided on a lot of computers. Get the server admins to change their userids. They are going to have to chase those ids though the system a bit, but that is a lot less hassle then modifying everything everywhere else.

[larkost]

Right now InstaDMG is not going to be able to handle that. I do have a couple of ideas about handling that in the future (you reminded me to create a ideas page on the development site, and put it there). Unfortunately for you I don’t need that at the moment because my multimedia image will use Radmind to put Final Cut Studio on the image, but eventually I want to move that into InstaDMG as well (it is not a priority since I only have 20 multimedia computers vs 500 of the other types).

[larkost]

You have found your problem. I don’t know how your LDAP users got uid’s in the 500 range, but that is what is causing the problem. Essentially DirectoryServices is synthesizing records for you by combining the two entries together. This is called “Augmented Records”, and is new in later versions of 10.5 (note: the name “Cylinder of Destiny” has been rejected…).

If you want to see what DirectoryServices is creating you can use dscl and go into the “Search” area. This will show you what the record looks like to DirectoryServices after all the combinations happen.

The solution is going to be to move one of the users so that the LDAP and local users don’t conflict.

[larkost]

I agree that it sounds like there is something messed up in dslocal, specifically I think you have somehow corrupted the dslocal store with something that you have put in there. The way that I would troubleshoot this is to go to the command line:

sudo -s
– this gets us to a point where we are “root” (so to speak)

cd /var/db/dslocal/nodes/Default/users/
– warning… we are playing with fire now

ls
– get a list of all the users, we are looking for things without under-scores

– you can view the contents of the files with:
cat

Get a feel for what should be in there. My feeling is that either one of the files is just-plain-wrong (and is messing up everything else), or there are two files in users that has a duplicate uid entries.

Edit: It just occurred to me that if your LDAP users are coming in with uid’s in the wrong range, then they could be overlapping with the local users. You can use dscl to explore the settings on the local and LDAP users, and compare the results.

[larkost]

Why do you need to enable root? I am going to STRONGLY encourage you not to enable root. There is nothing that you can’t do otherwise. Really…. I mean it.

And why can’t you simply create a launchd LaunchDaemon that would launch a script to do that for you? One that would then erase itself after running?

There is probably a better way of doing this (figure out all of the steps that dsenableroot takes), but this would work (you do have to replace a few things)
[code]


Label
org.sample.enableRoot
ProgramArguments

/path/to/script

[/code]
and
[code]
#!/bin/bash

/usr/sbin/dsenableroot -r anotherfakepass
/bin/rm -f /Library/LaunchDaemons/org.sample.enableRoot
/bin/rm -f $0
[/code]

[larkost]

I am missing something here. Are you creating the users with script after boot? Why not create the users and put the /prvat/var/db/shadow/hash file into place all as a pkg in your InstaDMG routine. Even if you are giving your pkg to others they can’t really reverse the password back out of the hash (well… no more than they could by having admin access to one of the imaged machines).

Since you are the one putting your user into place you already know what the UUID is going to be, so everything falls into place. This is what I do and it works out great.

[larkost]

Or you can use FileMerge. It is part of the Developer Tools, and is a pretty good front-end to diff.

[larkost]

Both the scolder and the technote are not reflecting the process in InstaDMG. Both of them are assuming that you are installing straight onto the computer, and in that case they are correct that you should not start with the 10.5.0 retail DVD. However, InstaDMG essentially synthesizes a 10.5.X retail DVD, and gets around all of these problems.

The people who are advocating that also don’t realize that that method is only really going to work for the exact hardware you are working on. It will usually work on other hardware, but you are going to be in for the occasional glitch (that are really hard to figure out).

So for InstaDMG it is a better path to use the retail DVD (less stick situations) and all of the combo updates.

Of course all of this is predicated on the idea that there is a Combo Update that is newer than the hardware you are installing on. At the moment 10.5.4 is newer than all the hardware out there, but when the next new piece of hardware ships there will be a window where that is not true, and people wanting an InstaDMG build for those computers will be out on a limb for a little while.

And the ASR issues can’t have anything to do with what DVD you used. An ASR restore just slaps the bits down on the disk, it does not try to evaluate them (not strictly true… but close enough in this case). And the “could not erase target error” has nothing to do with the source, that is a target error. Usually it means that something has some file on the disk open.

[larkost]

I would like to note that I would guess that the majority of the dev team are always using the retail 10.5.0 DVD to install from, and then using “Combo” updates downloaded over the web from Apple’s site (if you want the exact list I am using look at the vanilla catalog in InstaUp2Date).

Using a model-specific DVD should work in principal, but none of us are testing it.

The reasoning behind this is that the teams at Apple that put together the model-specific DVDs are completely different than the team that puts together the “retail” DVDs. The latter team is focused on making sure that things work on as many different models as possible, whereas the former teams are only responsible for making sure that that version works on one revision of a specific model of hardware. This can lead to things like missing kexts… things that would cause problems exactly like the things described here.

Can those who are experiencing the problem fill us in on the Base DVD that they are using?

And I am not going to lay any bets on things built on an XServe probably running MacOS X Server…. That is really far from what I am testing… and I am the one tossing code in at the moment.

[larkost]

Thanks Chris!

This explains nicely the reasons why some of us can see it and others can’t. I fell in the latter camp, and it seems the reason is because I have my own version of a user creation system (not yet ready for public consumption).

I have verified that the InstaUser in svn does indeed have this problem, and have put in the request to the other developers that this be fixed. I can’t do so because InstaUser uses PackageMaker, and the version I have on all my computers (the latest from Apple) is broken, and I would do more harm than good by touching it. So hopefully we will have that fixed soon in svn, and maybe Josh will decide to put out another beta to cover that.

[larkost]

This depends on an MCX group (that is how it is implemented in the background), and MCX groups are not cached on the client, only mobile users are (not a great solution in my opinion), so if you can’t see your directory service, you can’t resolve groups from your AD (or OD, or LDAP) servers.

There are a couple of ways around this: since your admin users are probably relatively static you could add a loginhook that would look to see if the user was in your admin group on your AD server (I assume this is how you are controlling it), and then add them to the local admin group. Actually, for ease of troubleshooting I would create another local admin group, then nest that one in regular admin group.

The code might look something like this (not tested… and off the top of my head just to give you a starting point):

[code]c
#!/bin/bash

AD_PATH=’/Active Directory/mydomain.here.com’
REMOTE_ADMIN_GROUP=’domain_admins’
LOCAL_ADMIN_GROUP=’admin’

for user in `/usr/bin/dscl “$AD_PATH” read Groups/$REMOTE_ADMIN_GROUP GroupMembership | /usr/bin/awk ‘sub(“GroupMembership: “, “”)’`; do
if [ “$user” -eq “$1” ]; then
/usr/bin/dscl . merge Groups/$LOCAL_ADMIN_GROUP GroupMembership “$1”
fi
done

exit 0
[/code]

This will make them a local admin every time they log in and are on the network, and that will remain even when off-network. Note that this will add them, but never remove them. If you ever want to remove someone you will have to do it manually (or add this to the script). You will also have to adjust the variables at the top of the script to your environment.

[larkost]

pteeter also posted on the dev list, and I answered him there. To sum up that response:

The xattrs problem is a cosmetic one on 10.4: xattrs does not exist so it complains, but the error message does not cause any other problems. I have checked in code to check for the existence (actually the excutablility) of xattrs before calling it.

And the long time on mount is probably hdiutil calling fsck on the target drive. On my machine this takes about 4-6 minutes. Since it is either that or about 50 minutes to an hour of install I thought it was a good trade when testing the code. I have a couple of ideas about how to get around this 6 minute pause, but don’t have time to do the cycles needed to test this for the next month (have to get my images out).

If anyone wants to pick up the challenge of working on that… I will be happy to look at it, and maybe even give it a whirl. And my ideas are up on the instadmg-dev@google mailing list.

[larkost]

I think to be useful to many people the catalog files are going to have to reference the online versions. The reasons that 10.4 versions are not up is that my organization is switching to 10.5 for all of the new images, so my only 10.4 images are the ones that are on life support until they get re-imaged.

[larkost]

pteeter: If you want to submit them to me, I will commit them into the SVN repository.

And I have gotten a few emails from people interested in the idea, but I don’t really know how may people might be using it. At this point for me it is all about getting my job done. I have a feeling that the popularity of InstaUp2Date is going to depend on whether the Apple SE’s like Josh Wisenbaker and Mike Bombich take to it and talk to their accounts about it.

[larkost]

[QUOTE][u]Quote by: pteeter[/u][p]
2. I’m a little fuzzy on dmgs vs. pkgs. I’ve always run checksum.py aganst pkg installers and only referred to pkg’s in my catalog files. Will that change now or not?
[/QUOTE]
Nope, you can continue to do exactly that. But take a look at the vanilla catalog file. One of the central ideas in this for me is that we can all share that file and it will take a vanilla retail disk (as in one you buy at the store) and bring it up to the latest version of everything that Software Update would add for you. When a change happens only one of us has to update the vanilla file and everyone else gets the benefits.

For the moment that person is me, but I will gladly accept submissions from others. And once we get out of the starting blocks I can see there being a collective that would contribute catalog files for things that are openly available (Firefox, AdiumX, etc). Part of the point of this is that if we can get a good structure that is widely applicable, then we have a lot of people all testing the same base image. If there is a problem someone will fix it, and we can all have more confidence in our base images, and concentrate on the things that make our installations unique.
[QUOTE]
4. Ok, this for me is the biggest change. The InstaDMG + InstatUp2Date dir structure now looks like this…

A few questions arise…

Can all .catalog files be stored in the CatalogFiles directory?
[/QUOTE]
Yep. InstaUp2Date will also search at a path you give it and I even a http: reference if you give it that.

I should also mention that I made a little change in how things work: If you give InstaUp2Date multiple catalog file it will assume that you want to setup for InstaDMG multiple times. So it will setup for one (presumably run InstaDMG), tear-down, then setup for the next run. Once for each file you give it. I am a little torn on whether I should put in logic that if it detects you have multiple files that would present an error if you don’t have the –process option selected.

I also think that there should be another option that would allow you to add a catalog file (or maybe a dmg/pkg or http reference) manually. The thought of taking in a catlog file on standard input has also gone through my head (think automated build systems). But I don’t need that yet, so it will be a while.

[QUOTE]
I assume the InstaUp2DateCache folder holds all DMGs and PKGs that will be linked into the BaseUpdates & CustomPKG folders?
[/QUOTE]
It is actually the place where InstaUp2Date will place pkg’s and dmg’s that it downloads. These should be considered disposable, as they will be re-downloaded when needed. InstaUp2Date will check here and the InstaUp2DatePackages folder to find things that will be linked in.
[QUOTE]
What’s the InstaUp2DatePackages directory for now?
[/QUOTE]
The InstallerFiles/InstaUp2DatePackages folder is intended as the place where you put the pkg’s or pkg-in-a-dmg’s that you download or create. If InstaUp2Date is the one to download the dmg then they go into Caches/InstaUp2DateCache. That way you know that you can get rid of anything in Caches without loosing data.

That reminds me.. I have to set the flag on the cache files to get them to be ignored by TimeMachine… ok… done in rev 96
[QUOTE]
Which tool – instadmg or instaUp2Date – leverages the BaseOS image caching?
[/QUOTE]
I added that to InstaDMG. It makes the 45 minutes or so of Base OS install into 6 minute process (after the first run with that image/installerchoices file). I got tired of the long wait through that while testing, so scratched that itch. There are a few other ideas like that might get implemented sometime.
[QUOTE]
Again, thanks. Your tool makes my build process far more elegant.
[/QUOTE]

I have selfish motivations in changing the code, but I am happy that others get to benefit as well.

[Author]

Posts