[larkost]

The specific answer to the question is that I think that this is set in:

/Library/Preferences/com.apple.keyboardtype

To the more general question, a lot of it is experience. After a while you get a feeling about where programmers are going to put things, and most of the time I can guess the plist that something is going to go in, or at least be able to guess the appropriate plist given the list of plists. As a case in point, I went to /Library/Preferences and looked for plists that had “key” in their name. Then I read out the plist, and decided that this was probably the one.

If that does not get the proper result, then another approach is to use fs_usage and then set the setting through the GUI. Then you filter through the files that got modified and then look in the files to find the likely changes. fs_usage is a bit of firehose, so I generally run it a few times first, each time I add a number of processes to a long list that I call with the “-e” flag to exclude them from the list. I still usually have a couple of pages of output, but a little experience will allow you to scan through this quickly for what you are looking for.

[larkost]

At this point InstaDMG is looking for exact names for the base image files. The two that it will accept as the “primary” disk are:

Mac OS X Install Disc 1.dmg
Mac OS X Install DVD.dmg

These happen to be the names that the disks automatically have. So if in creating your installer disks you changed this, it will not find them. The code will mount everything else in the “BaseOS” image as supporting disks, and that is what you are seeing happen. If you change the name to one of those names it should work fine.

I have plans to change this system a bit at some point, namely to have the location of the base image file and any supporting disks to come in through command line flags. I am still toying with ideas, and need to get consensus of the other people on the dev team (this is all new to them as well), but here is the idea that is rolling around in my head right now:

Do away with the automatic searching through the BaseOS folder, and force all users to provide either a name of an image (the name of the dmg file), the path to the dmg file, or a dmg checksum. An option on this one would be to default to the checksum of the 10.5 retail disk. Users could also provide multiple “supporting disks” with another command line switch (called as many times as you would like).

This would allow you to have multiple BaseOS disks and to choose between them. It would also be easy for InstaUp2Date to add this as another variable in the catalog files, and pass it along when it is used to call InstaDMG.

[larkost]

Create you own package with a postflight (it runs on installs, and upgrades) and use either “PlistBuddy -merge” (more easily available on 10.5.1+) or “defaults write”. Once you get over the initial hurdles of creating installers and scripts this should be easy.

[larkost]

Your DNS entries have to be correct for both forward and reverse queries. This is what trips up many people as Windows clients default back to NetBUI values and skip DNS altogether. MacOS X does not have the luxury.

[larkost]

This is definitely because the shell is seeing a ._ file that ends in .pkg. I just checked in a large change to the code around this yesterday that would partially get around this (it would attempt to run both name.pkg and ._name.pkg), but I will make it more explicit to handle this case. But I would not run InstaDMG off a remote volume, not even an XSan. Latency is going to kill you on this. InstaDMG is very dependent on IO speed, and it is very hard to have better IO through a network cable than a ribbon cable.

Update: ok… I have checked in code to exclude ._name.(m)pkg files. But I still don’t think you should be using InstaDMG from anything other than a HFS+ volume.

[larkost]

I assume by “MSX” you mean MCX. And if you have your AD server sending them out, then you have extended the schema in your AD server. Or you could be using a Golden-Triangle setup that you have not mentioned. In either case those are not GPO’s. GPO refers to Microsoft’s implementation of the same concept that Apple calls MCX.

[larkost]

You are getting a few things conflated:

With folder redirection you move aside and replace folders in the user’s home directory (presumably a network home directory) with local resources. This can have a huge impact with things like the Cache directory when you are using network home directories.

The second thing is Home Folder Syncing with “Mobile” users. This allows you to sync your local home folder with the folder designated as your network home folder, presumably by an OD or AD server.

Both of these are setup through MCX/WorkgroupManager. I think what you want is a Mobile user, but it is going to take a bit of work to get that crafted right (it is a complex thing).

Oh.. and GPO’s are not used on MacOS X.

[larkost]

[QUOTE][u]Quote by: pteeter[/u][p]I haven’t gone thru your script yet but I’d guess we’ll need to change references to AppleUpdates over to BaseUpdates with Josh’s change to the InstaDMG directory framework.

No?
[/p][/QUOTE]

That is probably the only change that needs to be made on the InstaUpToDate side, but there are a number of changes that I made to InstaDMG in the custom version that I put out that need to be brought into the latest InstaDMG. I was actually going to start work on that tomorrow, since I need to create an image in the next couple of weeks. Now that InstaDMG is in a repository I can submit changes to it in a better fashion.

[larkost]

I am referring to /Applications/Utilities/Java/Java Preferences.app. It allows you to choose what version of Java you would like to run by default (1.4.2, 1.5, 1.6). This is important in our environment because students are required to run different versions for different classes (no requirement for 64bit there though).

I would also not trust that this update when applied to 32bit computers does not break something else.

[larkost]

The Java update only applies to 64bit (Core 2 Duo and Xenon) machines, and can cause some problems (at least with the Java picker) on other machines.

[larkost]

This probably means that they are mixing-and-matching their connections. If you are connecting with AFP then everyone has to connect to AFP every single time. And if you are working with SMB then everyone has to connect via SMB every single time. Mixing the two is a recipe for files to get disassociated with their resource forks.

If you can afford it, ExtremeZ-IP has been getting a lot of great reviews as being an easy answer on both ends of the equation. But the cost is rather high.

[larkost]

I had the same thought, but I don’t think that there is any low-hanging fruit on the automation side. So I thought instead that if there was a way of easily sharing these lists of updates that it would at least ease things quite a bit (plus then we would all be testing on the same base image, so troubleshooting would be easier). So I created the InstaUpToDate script to go in front of it. So far it has not taken off, but once the big projects of the summer get done I will be back to hacking on it a bit.

[larkost]

Ok, another small release, and this one is just about bug-fixes (if memory serves… this was all pre-WWDC stuff):

[url]http://www.stanford.edu/~larkost/InstaUpToDate0.3a.zip[/url]

[larkost]

pteeter: At the moment most of my development time is in getting a 10.5 image ready, so working on “new” things for 10.4 has to take a back seat. I also am going away from 10.4 systems, so won’t really have an environement where it gets nearly the testing that 10.5 does. Mainly it is going to come down to whether the 10.4 python environment has everthing that I am using.

And thanks for helping me test!

And as to include fies: they are parsed just as they are encountered. So if you put them in the beginning of the file then they are edded before other things in that file. If you put them in at the end, then they are inserted after, and in between is in between. But all system updated come before all applicatinon, etc. If you look at the order of the sections in my sample catalog file, that is the order things come in, within a section they are then ordered by where they appeared.

And you can nest includes as deply as you want. It will throw an error if you include a file that has already been processed (poor mans looping detection).

And you can include as many sections as you want, and can even reverse the order of them, or put multiples of the same section in (they will still wind up in the same order)

[larkost]

I am now up to version 0.3. The big changes:

– A couple of bug fixes that prevented the script from working twice in a row in some cases

– For folders of installers (like XCode) where you only want a single installer to run you can put in a InstalThisOneOnly soft-link to the appropriate item

– ability to nest one .catalog file inside another (so you can create a base image, and then things based off that)

I have also included a heavily modified version of InstaDMG with this, and in fact my script should probably be run with this (definitely if you are using the InstalThisOneOnly bit). Here are some of the changes:

– Disk 1 of the OS mounts hidden, so there are less problems to run into if you are using your computer during the install. Next I will probably do the same for the target dmg.

– A lot of small changes in logging. And the ability to set how much of this should also go to the tty.

– Better ability to use folders of installers (such as XCode)

– quitting any process that has open files on the target volume before scanning

– correcting some soft-links that get mis-set by the iLifeSupport installer

– touchups in a lot of areas

I am putting the latest version in about the same place:

[url]http://www.stanford.edu/~larkost/InstaUpToDate0.3.zip[/url]

I have been using this code to successfully create images, so it should be in good working order (at least on 10.5), but there are absolutely no guarantees.

Oh, and this will probably be the last update for a couple of weeks, as I am going on vacation next week, and have to finish a presentation for SIGUCCS after that.

[Author]

Posts