1st image made off of a System Restore disk

[thegooch49]

Hello, I started off creating my instaDMG image with a retail 10.5 install disk. I have all my packages tested and functioning with this 10.5 disk. I recently got a new iMac, which had 10.5 on the gray system restore disks, and I set off to test how instaDMG worked. I took my retail .dmg out of the BaseOS folder, and replaced it with a .dmg file I made from the Disk 1 that came with the new iMac. I ran the script, and an ASR image compiled without error.

When I imaged the target machine, it reached the login screen fine. But, I was unable to login. I have to packages that install 2 scripts to /Library/StartupItems. 1 script sets up the local administrator account (with the password hash), the other script sets up some basic preferences using the systemsetup command. After starting the iMac in FW disk mode, I confirmed that both of these scripts were in place with the proper permissions, but they did not execute.

These execute fine when I created the image with the 10.5 retail CD. Any idea why they wouldn’t run when compiled with 10.5 from Disk 1 on a System Restore disk?

[thegooch49]

Hello, the first script is a modified instauser script. It runs lots of dscl commands. It also enables root, sets the login screen to be username/password (instead of list). The second script is a post install script. It just sets some defualts. It modifies the postfix config file, adds about 10 users to the admin group, connects to our LDAP directory, sets a login hook, configures ARD with kickstart, sets NTP, turns on SSH, Configures energy settings, sleeep, etc.

These are the exact same scripts (put in place by a package) that are used successfully with the 10.5 retail DVD. I just can’t figure out why they don’t run at startup when I created the image off of the imac system restore disks.

Any ideas?

[thegooch49]

Hello, my previous problem can be ignored. I re-compiled my image a 2nd time, and things worked fine.

[thegooch49]

Hi, I had one more discovery along these lines. I got a new 8-core mac, which came with 10.5.1 on the grey system restore CDs. I imaged the disks, and ran my instaDMG script from my older, 4-core MacPro. The terminal output the following error:

installer: Error – This software cannot be installed on this computer.

The script eventually exited, and I was left with a 1GB image in the ASR_output folder. It’s basically all of my custom packages (applications), with a very bare /System folder. I’m going to re-run this on the 8-core mac, since it appears that the installer is hardware specific. Also note that I successfully compiled a good ASR image from a new iMac that had 10.5.0 on my MacPro.

[thegooch49]

I ran my instadmg script with all my custom packages from the 8-core mac, and it worked like a charm! Good to know that creating images w/ a system restore disk, might be best done on the class of machine that you are targeting.

[pteeter]

You mention ‘external drive’ specifically.

Does the InstaDMG environment *have* be connected to the intended system for imaging via external disk.

Is it possible for the InstaDMG environment to live on an AFP, SMB, WebDAV share? Mount the share on the system, run the instadmg script, etc.

Might that work?

[Patrick Fergus]

The earlier revision of InstaDMG (<1.3b) seemed to be intended to point at a mounted volume (partition, drive).

InstaDMG 1.3b actually makes a disk image inside the "Instadmg" directory (in "DMG_Scratch"). In _theory_ it would make it possible to run it off a server, but I'd worry about:

- Network bandwidth. It's going to install a full OS and then scan the image for ASR within the "Instadmg" directory. A local volume will provide much better performance.
- Permissions/rights on the installer packages. Thinking of the environment here, our old version of Helios doesn't understand UNIX permissions and just sets everything that you have rights to to 755 $USER: Default Group. That destroyed a few software distributions here until we started requiring everything to be compressed if permissions were important.

Josh might have other thoughts.

- Patrick

[pteeter]

Good points.

I’m still trying to plan in my head how I’ll maintain the build environment for images.

I tend to distinguish between images based on 3rd party software – who gets CS2, who gets FCS2, etc.

Based on Patrick’s comments, seems like shuttling different ‘build’ trees that hold the populated folders for each type of image to and from an external HDD would work. Keep the build trees on a RAID’d filesystem that gets backed up, copy to external HDD when ready to make images.

[pteeter]

I see what you are saying but maybe what I’m hoping for is a way to enable a flag within the instadmg script that will allow us to have 1, 2, 3 , etc. build options.

Each option denotes a different application group, etc.

So maybe to follow up on your comment, elaborate on what you mean by ‘client management system’? ARD / JAMF / etc.?

[akinspe]

The way I handle multiple bulid-trains is making a copy of the instadmg “environment” and have a master folder where ALL my packages are, and then just symlink the appropriate packages into each InstaDMG’s instance CustomPKG folder. That way I can maintain different versions of the image, but not duplicate packages. I also, of course, am symlinking the OS DVD image.

The client management system could work, but with some packages getting as large as they do, and our lab image approaching 30gb+, that’s not really an efficient option for us.

[akinspe]

I was just thinking…

Another way to handle this would be to allow an option to specifiy the name of the CustomPKG folder at runtime. Also perhaps allowing multiple CustomPKG folders. that way you could have a set of “basic” packages and then folders for your other groups of packages.

Then a clever person would just have a wrapper script that has the appropriate instadmg parameters in a script so they could chain them together and build all their images in serial. You’d have to have an option to allow the user to change the name/location of the DMG Scratch and resulting ASR image.

I didn’t get a chance to watch the webcast, so I didn’t see your “roadmap” I suppose it’s possible that you covered that.

[mdspidle]

[QUOTE][u]Quote by: thegooch49[/u][p]Hello, the first script is a modified instauser script. It runs lots of dscl commands. It also enables root, sets the login screen to be username/password (instead of list). The second script is a post install script. It just sets some defualts. It modifies the postfix config file, adds about 10 users to the admin group, connects to our LDAP directory, sets a login hook, configures ARD with kickstart, sets NTP, turns on SSH, Configures energy settings, sleeep, etc.

[/p][/QUOTE]

I’m curious to find out what commands you are using to set some of the items you mentioned. ie NTP, SSH, etc. I’ve captured the files and created a package for some things but other won’t stick. Looking for an alternative to set things like, Bluetooth prefs, Sharing prefs, Software Update prefs etc.

Thanks

[mdspidle]

[QUOTE][u]Quote by: macshome[/u][p]On 10.5 there is a lot you can do with MCX policy. If you don’t have directory service based policy you can take a look at our article on using localhost policy for another option.[/p][/QUOTE]

What article? I searched but couldn’t find one.

Thanks

Mark

[Patrick Fergus]

I think these are the articles you’d be interested in:

[url]https://www.afp548.com/article.php?story=using-mcx-in-the-dslocal-domain[/url]

[url]http://managingosx.wordpress.com/2008/02/07/mcx-dslocal-and-leopard/[/url]

and if you happen to have radmind:

[url]http://managingosx.wordpress.com/2008/02/08/mcx-dslocal-and-radmind/[/url]

– Patrick

[thegooch49]

[quote]
mdspidle wrote:

I’m curious to find out what commands you are using to set some of the items you mentioned. ie NTP, SSH, etc. I’ve captured the files and created a package for some things but other won’t stick. Looking for an alternative to set things like, Bluetooth prefs, Sharing prefs, Software Update prefs etc.

[/quote]

Response:

Have you run systemsetup? It’s new to 10.5 client. I believe that it was in 10.4 server, but I’m not exactly sure. These are the commands that I use, but there are many more. Run systemsetup -help for a full list. It’s pretty brilliant, and works perfectly with instaDMG.

systemsetup -setnetworktimeserver ntp1.mydomain.com
systemsetup -setusingnetworktime on
systemsetup -setremotelogin on
systemsetup -setcomputersleep Never
systemsetup -setdisplaysleep 30
systemsetup -setharddisksleep Never

[Author]

Posts