[larkost]

There is the techical side, and then there is the licensing side. The techical side of this conversation is not really difficult, and so you can use these methods very easily.

However, the licensing side is where things get a little less certain. So my advice is this:

1) Talk to your Apple representative about your licensing concerns. Ask them to put their solutions in writing for you (your leagal team will be happier).

2) Where you run into difficulties make sure you write to your Apple representatives, remember this is the written word not the spoken one, so that it can be passed along up the chain at Apple. Get most important person in your oganization’s name on it that you can. That is to say the person who makes the biggest money decisions. In your message make sure to mention how much you purchase from Apple, and how much of that might be in danger. By doing this you are giving your Apple representatives the ammuniton they need to go up their chain to get things changed where they need to be changed.

3) File radars describing how you are having trouble with the current licensing situation. Think of this as another front you are working on. #1 and #2 are all about gettting the sales side of Apple leaning in your direction. This one is about gettting the techical side leaning in your direction. Rememeber: if there is not a Radar about it, then it never happened.

[larkost]

That is not fixing the problem, that is (near litteraly) killing the messenger. The User Notification Center is used by a number of backgroun processes to… well… notify the user of things that they probably need to know. You have just killed that communication channel.

There is a reason you are getting this message, and you should figure it out, not ignore it.

[larkost]

InstaUp2Date is trying to get updates but not the same one as Software Update.app uses. Those are always machine-specific and for imaging you should (almost) never use them. Rather it is looking to go out and use the updates that you can get to throuh http://support.apple.com.

Proxys are a really tough thing to program for, since most of us don’t have them (including the programmers), and every one of them has its own quirks. If you can get the python urllib2 working with your proxy, then you can probably get InstaUp2Date to work there too. Otherwise, not so much.

[larkost]

Actualy, the installer works just fine in parallel in normal cases. The reason you can’t have multiple concurrent InstaDMG processes is that we have to cheat a bit to get more instlalers to work and so put one of the background daemons in a chroot jail that focuses on the location of one install.

But there really would be little-to-no advantage in having 2 simultanious installers unless you could set them up to use completely different disks. InstaDMG (as with most installers) is almost completly I/O bound. If you are looking to speed things up, then get faster disks, and use the ‘-t’ option to split the process between two disks (much faster, but must be seperate disks rather than partions).

[larkost]

Machine-specific builds are just that: specific to those machines. You have absolutely no way of knowing what bits they are missing that are required to safely operate other machines. Let me repeat that: you have absolutely no way of knowing. I understand that you want a universal image, and it is worth complaining to Apple that these machines were not “brought into the fold” with 10.7.1. But they were not, so you have to deal with that, at least until 10.7.2 (crossing fingers).

And people saying “it worked for me” means absolutely nothing in this conversation. They are not doing the work to validate the thermal controls, they have no regression testing systems in place to know where things go wrong, and they have no access to the list of changes between the builds.

[larkost]

There is no way of having dynamically changing messages at the loginwindow without constantly killing it. Besides, you might not want people logging in while your first-boot scripts are running.

The solution to both of these is to use iHook. It does take a little getting used to how it works, as you need to use a launchagent in the loginwindow context to run it, and then need to have your master script be called by it (unless you get really creative with things) so that it can get your stdout to display/change things. But there are a lot of people using it, so it is a workable tool.

Edit: Ok, this “spam post” thing has really got to stop. A couple more times and I will never post here again.

Sorry “punk” but you are going to have to google iHook yourself.

[larkost]

Two possible guesses:

1) That you are using the same package id for multiple packages. If the have the same value, then the installer will treat the second one to install as an upgrade of the first. If there are files in the first that are not in the second, it will helpfully delete those for you. While this is the right thing for the installer to do, it can be a bit surprising if you are not paying attention.

2) The relocatable bit gets set on a package. This was added by Apple some time ago in response to people moving applications out of /Applications, and then objecting when updaters would then fail to update the package in the new location and leave a broken shell in /Applications. Unfortunately the logic used to find where people have moved things can come up with very unexpected results. This often comes up when people are testing their packages on the same computer they created them on (a natural thing to do) and the package instead updates the copy in the folders they used to make the installer.

The second is not as likely in your case, since it requires a bundle with a bundle id (Applications, Frameworks, etc…), but it is a good thing to keep in mind.

[larkost]

The fastest is going to be between the internal bays in your MacPro (two RAID 0 sets would be the best), as those are full sized drives on internal connectors. But I would bet that the mini with internal and external RAID 0 is not going to be far behind.

Unless you are doing something I/O intensive on your computer, InstaDMG runs just fine in the background. That is how I always worked on it. The only things you have to remember:

1) Don’t open any of the .dmgs that are used by the process while things are in-flight. Things can get a bit confused if you do.

2) Don’t try and use the installer, especially not the GUI one. Because there is only a singel helper daemon, and I cadge it to only work on the target dmg, the installer will hang when used outside that cage.

3) Especially at the end of the process you will get occasional hangs when InstaDMG starts something intense. There is only one really bad point (when it is scanning for bad symlinks), otherwise you should be able to play videos on top of it (my regular practice while developing).

[larkost]

I can’t get through the spam wall, so I can’t give you the link to the page I created on this topic in June of 2009. Search for: reindex iLife loops, and you will get some results.

Will someone please put an end to the spam filter? It is preventing actual conversation. There is no excuse for the number of false positives it throws.

[larkost]

No, it doesn’t. I did put in the local http server where it can try and find the updates, but it requires that the updates have exactly the same names as the updates on support.apple.com, and because Software Update Server serves out the non-combo versions of things, I would bet you that at least the big files are not identical.

You can try it with Instaup2Date by adding a call to ‘–add-source-folder’ with the http url to a folder full of updates. It will try each item to see if it can match the name, and then download it to checksum it to see if it is the same. But I am not going to make a lot of bets there. I put it there more so that some organizations that have multiple image creation computers could centralize things.

My few experiments with trying to work with SUS left me with so many things that I could not automate between the two.

[larkost]

The problem is not calling from bash, it is that you are calling it from something other that the terminal, so cron or launchd. Try piping the output to a file, and you will probably get better results. That is untested, but in that code I did put in explicit checks to see if the output destination is a file.

[larkost]

When you select the “NetRestore” option in SIU you effectively have one of two tracks, based on what you use as the source:

1) NetRestore from volume. This grabs an ASR copy of whatever volume you give it, readies it to be restored, and wraps that in a .nbi set that will install it. Note that SIU does not check to see if you are giving it an already-ready-to-go .dmg, it instead reads out the files in the image. So basically it re-does some of the work InstaDMG is doing here.

2) NetRestore from Installer Disc. Here it does many of the same steps that InstaDMG does (or better put: InstaDMG does many of the same steps SIU does), and then wraps things in the same .nbi set.

So… backing up a step, there are two main tracks for installing systems in SIU:

A) NetInstall – This has a NetBoot image that then runs the installer through a single package targeting a single volume. They do some really nice work to bundle up any packages you provide into this single package, providing an easy way for you to add packages to “the one package”.

B) NetRestore – Takes the same NetBoot image, but swaps out “the one package” for a package-like thing that does the ASR restore. Since there is no regular package, there is no provision for you to add more packages. The reason #2 from above works is because they use the same trick from the NetInstall to merge your additional packages into “the one installer”, and then just run that on a target volume (like InstaDMG).

I have long argued that SIU’s interface was in need of a lot of re-thinking, and you have just run smack into one of the biggest problems: it will not tell you what works, and what does not. The only reason I can figure this out is because I have reverse engineered the output of SIU enough times.

A far better solution for you is going to be to switch from SIU + InstaDMG to InstaDMG + DeployStudio. With just a little bit of figuring things out the two work great together, and it is easy to achieve the sort of thing you are aiming for.

[larkost]

10.5 was what I wrote InstaUp2Date to target, so I don’t think that I ever wrote a catalog file for 10.4. I would have to scrub back through all of the revisions to be sure.

[larkost]

Last I remember, with a 10.5 host OS on Intel, I was able to get 10.4 Intel versions to work just fine (at least as far as my testing went). However there was no way of getting 10.4 PPC to work without modification. The main reason being I don’t own any PPC hardware, other than my mail server, so there was no way for me to test.

However, starting from a Golden Master image is only going to get you a list of things you want. The image itself is not useful for this exercise.

[larkost]

I have not yet had a chance to try out the new iLife in InstaDMG, but I did do a little work with it at work. So far here are my observations:

1) They are doing the same hide-the-real-installer-packages-in-folders trick that they have been doing for a while.

2) The outermost link to the real installer unfortunately is an alias file. This is really unfortunate because anything that uses the command line can’t use aliases… so you have to work around it (I replaced that file with a softlink and things work fine).

3) I have done a very little work with installing it to a non-booted volume, and when that volume is subsequently booted iPhoto started up fine. I have had no time at all to verify that everything is exactly as it should be with a normall install, but at least the first look went well. This bodes well for using it with InstaDMG… but I might have to do a little work to make some code to recognize aliases… *grr*

[Author]

Posts