- This topic has 4 replies, 3 voices, and was last updated 15 years, 2 months ago by
nessts.
-
AuthorPosts
-
November 30, 2009 at 12:40 pm #377579sipatechnicalParticipant
Hello,
I’m using instaDMG to create and deploy images over a network of Macs which will be making the transition from OS 10.5.x to 10.6.
Is there a way, other than having two discrete instances of the program folder, to run multiple operating system images in tandem?
Also, is there a way for one to redirect the program to get the InstaUp2DatePackages from a remote server?
Thanks
December 1, 2009 at 2:34 am #377588larkostParticipantRight now you are going to run into two problems:
1) Even using InstaUp2Date there is no way of specifying the installer dvd image to use. I have always wanted to change this, but felt that I needed to wait until 2.0 to make this change. I have a clear idea of how to do this, and it is a solid goal for 2.0 (no news on that… just not enough free time).
2) Right now you should not install 10.5.x while running on 10.6. I have not figured out how to get the installer to run properly with chroot jails from 10.6, and it is virtually required from 10.6. Similarly the 10.5 installer does not know how to handle everything in the 10.6 install packages, so that will not work either. I am aiming to get chroot jails working in 10.6, but it is going to take some time, and will probably wind up slipping to 2.0
And in all likelihood the first serios time I will have to really work on 2.0 is going to be durring the holiday break. I have about a week of forced down time, and since I am not traveling for the holiday (and my girlfriend will be working) I will have time for that and some work on my part of a Macworld presentation. Hopefully I am not distracted durring that period, and can get some stuff done.
And on your InstaUp2Date question currently the only ways is to make all of your catalog file references be http:// links, and share the packages (wrapped in dmgs) on a http server. It will then create local copies of these files. Unfortunately the base image is not included in this.
I do have some ideas to allow for share points in the future, but have to think that through some more.
January 23, 2010 at 3:24 pm #377869nesstsParticipantWe build images for multiple customers and multiple OS levels, some 10.5.8 some 10.6.X
So, we wrote a wrapper for instadmg, it is a perl script and it needs the following directory structure as a default all your data lives in
/Volumes/WIP
in Volumes/WIP you have the following subdirectories (as you can see some of them can be links to other areas for space reasons.) instadmg must be a link to InstaDMG_1.4b4 or whatever version you are running.
BaseOS@ -> ../WIP2/BaseOS
BaseUpdates@ -> ../WIP2/BaseUpdates
InstaDMG_1.4b4/
Packages/
images@ -> ../WIP2/images
instadmg@ -> InstaDMG_1.4b4I never took the time to understand the instaup2date stuff as we had this written before its existence.
Anyhow inside BaseOS you have different install media directories with the Mac OS X Install DVD.dmg inside
10.5.2-3A142/
10.5.6-3A164/
10.5.7-3A174/
10.6/BaseUpdates contains downloaded updates in pkg format
images contains directories that match customer names or customer department names for each image you wish to create and inside those there are 2 important dot files a .build and a .version
the .build file contains a letter specifying the build type you can designate any you wish i use B for beta builds and P for production builds and a number usually start it with 0 and it will increment so you can differentiate what build is what, your final DMG will wind up here with the name of the Customer-Version-BuildTypeBuildNumber.dmg as well.Packages contains directories that match customer names or customer department names for each image you wish to create and inside those are any customer specific pkgs that have licensing information etc as well as the all important customer configuration file pkglist.csv, and a Generic directory for pkgs that can be used in any build Firefox for example.
ABC/Office2008-12.2.3.pkg
ABC/SystemSetup-2.0.0.pkg
Generic/Firefox-3.5.7.pkg
Generic/Flip4Mac-2.3.1.2.pkg
etc…then in instadmg I add the all important t1.pl not a very flashy name but not the point.
you cd to the instadmg directory and run this script and if you have everything in the default locations with justsudo perl ./t1.pl ABC
at this point t1.pl will look to make sure the all the necessary directories exist, and it will link all the packages, baseos, baseupdate etc into the proper locations in the instadmg directory in the order specified in the config file. it will also look for packages that have an installer choices file and link those into the proper directory if they exist, I wrote a special handler for iLife, where I copied those files somewhere into the Packages structure so that I did not have to build ilife packages all the time
and you change customers just by changing the last argument of the line above. you can also run this whole process from a place other than /Volumes/WIP by giving a -t /path/to/files argument.
here is a sample of the config file for a current build
o,10.6
u,MacOSXUpdCombo10.6.2.pkg
u,RemoteDesktopClient-3.3.2.pkg
u,iTunes-9.0.2.mpkg
u,PerformanceUpdateSL-1.0.pkg
u,AirPortClientUpdate2009002.pkg
u,JavaForMacOSX10.6Update1.pkg
u,CanonPrinterDrivers-SL2.2.pkg
u,RicohPrinterDrivers-SL2.0.pkg
u,Safari4.0.4SnowLeopard.pkgs,Install Bundled Software.mpkg
g,iDVD_704.pkg
g,iMovie_803.pkg
g,iMovie_804.pkg
g,iMovie_805.pkg
g,iPhoto_804.pkg
g,iPhoto_81.pkg
g,iPhoto_811.pkg
g,GarageBand51.pkg
g,iLifeSupport903.pkgc,ABCUserTemplate-1.0.pkg
c,ABCSystemSetup-2.0.0.mpkg
c,ABCBuildVersion-2.0.0.pkg
g,HPadmin-1.0.1.pkg
g,LocalAdmin-1.0.pkg
g,FireFox-3.5.7.pkg
c,ABCFirefox3Defaults-1.0.pkg
c,ABCSafariDefaults-1.0.pkg
g,Flip4MacWMV-2.3.1.2.mpkg
g,MicrosoftMessenger-7.0.2.pkg
c,ABCFlip4MacProLicense.pkgo = OS type of thing to use
g = generic package to use
c = customer specific package to use
s = the all important iLife packages, I had to link those updates from the BaseUpdates directory into Generic packages because this all happens after updates in the instadmg script or you could just store them in Generic but I wanted it clear what was an update.If anybody is interested in the actual script I can post it or make it available for download somewhere, but I figure this might be confusing as I am not the best documentation person when it comes to writing step by step directions and assuming anybody knows what I know.
if this helps or is interesting for anybody let me know…
January 23, 2010 at 7:08 pm #377870larkostParticipantI would really recommend that you take the little bit of time to look over InstaUp2Date. It basically does the same thing, but allows for nested lists of updaters, and will even download those updaters from the Apple sites for you.
It is really simple to use. Go and get the latest version from the development site, clear out the InstallerFiles/BaseUpdates and InstallerFiles/CustomPKG folders, and then run the instaUp2Date.py command (it is in AddOns/InstaUp2Date) with “10.6_vanilla” as the argument. It will then go and download the latest list of updates for you, and setup the two folders for you. And it is even easy to create your own catalog files, and have them reference the vanilla ones, so when the vanilla files get updated, yours come along for the ride. And since everyone shares the vanilla catalog files, we all share the same base image. So when something goes wrong you have more eyes looking at it. You can even have InstaUp2Date drive InstaDMG, so it will process multiple images in a row. Here are some sample calls:
[code]/path/to/instaUp2Date/py 10.6_vanilla[/code] download anything that is not cached for a vanilla image, and setup for a InstaDMG run, but will not run it
[code]/path/to/instaUp2Date/py –process 10.6_vanilla[/code] same as above, but then run InstaDMG (note: need to call this with root privileges)
[code]/path/to/instaUp2Date/py –process 10.6_vanilla myImage[/code] same as above, but then will setup and run InstaDMG a second time using the setting from the ‘myImage’ catalog file that you created. This will probably produce 2 images (depending on your settings)
The only thing that it lacks at the moment is the ability to choose BaseOS disks, but that is not actually important at the moment, and I think you might have a large problem that you are missing: if you are installing 10.5.8 then you need to be using chroot jails, but they only work with the 10.5 installer (so you need to be running 10.5 as the host OS), and if you are installing the 10.6.2 update you need to be running the 10.6 installer, and that only works under the 10.6 installer (so you need to be running 10.6 as the host OS). And it is sort of silly to have 10.5.2, 10.5.6, and 10.5.7 base os’s. Just pick one and mix in the latest combo updater and you have something that will work everywhere.
January 24, 2010 at 7:57 am #377871nesstsParticipantI run the build off a machine that can boot either 10.6 or 10.5 it works fine.
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed