[pteeter]

Here’s a question or two.

If InstaUpToDate.py parses include-file directives first in a catalog file, and the included catalog file points to another catalog file…will the python script still work?

Also, if a pointer to an included catalog file references a catalog that only has ‘Third Party Software’…will the python script still parse through the different sections of the original catalog file?

Again, haven’t tried it yet…just curious.

[pteeter]

So, am setting up my catalog files now.

I work with 4-5 different image ‘classes’ and for me InstaUpToDate makes perfect sense.

I have not run the instaUpToDate.py script just yet but should be ready to give it a try within a day or so.

It really all depends on how perversely modular one wants to be in their imaging process.

I plan to rely heavily on the use of the ‘include file’ option. Hopefully that doesn’t prove to be foolish.

I’m managing 100 or so packages to perfect my image. About half will be included on every class of image, the rest vary.

larkhost – do you have the resources to test a bit with Tiger? I’m planning to test with Tiger, I’ll be sure to update you on what I find.

Agree with Joel/Josh – great work, powerful stuff.

Josh – will you make time soon to look at larhost’s mods to your instadmg.bash script?

[pteeter]

Hopefully this isn’t beating a dead horse.

Agree with Joel that enabling the plug-in is necessary. But as for adding the Custom Search Path.

I found that a killall DirectoryService followed by dscl / -list / seems to right the DirectoryService ship for proper appending of CSPSearchPath items.

I found that Tiger especially likes to have the service bounced and ‘primed’, Leopard isn’t as picky about it.

Thank a few people at AES for this knowledge. And check out the Release Notes…

[url]http://developer.apple.com/releasenotes/MacOSXServer/RN-DirectoryServices/index.html[/url]

[pteeter]

Correct me if I’m wrong but I’m pretty sure you need a running Tiger OS to create a Tiger InstaDMG.

Using a Tiger BaseOS image on a running Leopard machine won’t work?

[pteeter]

My preference is logGen -> pkgGen -> PackageMaker.

I find that I prefer Xcode 2’s PackageMaker as opposed to the latest greatest, though I’m building for Tiger primarily now.

I also, at times, use Composer and InstallEase by LanRev.

At this point I’ve built numerous packages from various types of installers, I have *never* seen a machine crash.

What kind of hardware are you using for building your packages?
How clean/vanilla is your OS install?

[pteeter]

Went with Patrick’s suggestion re. grep -m 1 Ethernet. Works great from Terminal and even as loginhook.

Cannot get it to work via Launch Daemon – Leopard, Tiger (PPC nor x86).

Looks like, in the interest of expediency, I’m going to enable AppleTalk via loginhook and be done with it.

[pteeter]

Yeah, I don’t have a later PMG5 or MacPro handy with Leopard running to check.

Yup, rtfm on grep.

It’s been a ‘free day’ today due to Friday.

Good info either way.

[pteeter]

I worry that the ‘grep -m 1 Ethernet’ will fail on machines that have only 1 ethernet port…in Leopard.

Nope, know how to write the lpadmin command.

I’ll try not enabling AppleTalk and configuring the printers.

We’ll see how it goes.

[pteeter]

I am also trying to get this working.

I’d like to enable AppleTalk for a wired (ethernet) interface that has an IP assigned.

This shell script works on a booted system:

[code]
#!/bin/sh

PATH=/bin:/sbin:/usr/sbin:/usr/bin:/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support
launchdaemon=”/Library/LaunchDaemons/com.companyname.enableAppleTalk.plist”

### loop through all Ethernet network interfaces
for eth in “`networksetup -listallnetworkservices | grep Ethernet`”
do
#echo “$eth”
ip=`networksetup -getinfo “$eth” | grep ‘IP\ address’ | grep -v ‘IPv6’`
#echo “$ip”
### if Ethernet interface has IP assigned, enable AppleTalk on it
if [ “$ip” ]; then
networksetup -setappletalk “$eth” on
#networksetup -getappletalk “$eth”
fi
done

### delete launchdaemon file after first boot
rm -rf $launchdaemon

exit 0
[/code]

Obviously, ignore the commented debugging lines and note that I’m trying to do this with a LaunchDaemon.

It appears that Leopard refers to wired network interfaces on things like MB, MBP, MM as simply ‘Ethernet’ and not ‘Built-in Ethernet’ as Tiger does.

I’m curious about Joel’s assertion that AppleTalk will enable automatically, for printing, if needed.

Here’s what I’d like to accomplish…

1. enable AppleTalk for ethernet interface that has IP assigned
2. configure printers, some over AppleTalk, with lpadmin

If #2 can be done without explicitly doing #1, fine.

What’s ‘best practice’ persay?

[pteeter]

I was doing this:

1. create image with InstaDMG, admin uid as 499, user added with akinspe’s createUser.pkg
2. ARD kickstarting and privileges being set by 1st boot LaunchDaemon shell script
3. sub 500 uid’s hid with launchdaemon that runs the same defaults command you mention
4. after image is delivered to machine, on first boot am unable to ARD in…get permission denied

If I login to the freshly imaged machine with kbrd/mouse, am able to login with local admin/uid 499.

Both in Leo & Tiger, ARD/Remote Management is enabled *but* no user has privileges configured.

I am doing this now:

1. create image with InstaDMG, admin uid as 501, user added with akinspe’s createUser.pkg
2. ARD kickstarting and privileges being set by 1st boot LaunchDaemon shell script
3. specific user, the local admin, is hidden with launchdaemon that runs the a similar defaults command – HiddenUsersList -arry “shortname of account to hide”
4. after image is delivered to machine, on first boot am able to ARD in

I think the 2nd process works for me just fine.

Not sure if pros/cons exist between former and latter method.

[pteeter]

Packaged and ready to go.

Tested on Tiger.

Will test on Leopard shortly.

I think the method I’m using is somewhat more in-line with what Joel suggested earlier in the thread.

[pteeter]

No worries, thanks for the suggestions.

I think I have identified that I can set the GeneratedUID to a value of my choosing…perhaps the same value Leopard uses?

Then add the AuthenticationAuthority entry.

Then copy in the hash file to /var/db/shadow/hash.

I think it works…will test more.

[pteeter]

Anyone care to comment on a strategy for enabling root in Tiger?

It appears that an entry for root exists in /NetInfo/Users from first boot, but the entry has no GeneratedUID.

If dsenableroot is run, the GeneratedUID is *not* standard as in Leopard, thus making it challenging to create the hash file with the correct name.

Is there a way to pre-determine what the GenUID will be?

I suppose one could run dsenableroot with a dummy password, then copy in the ‘real’ hash file. Problem there is that the local admin user password would have to be hardcoded into the script. Kind of bad.

[pteeter]

Compulsively, a while back I mapped out the integers for the -mask option in kickstart…which correspond directly to the naprivs values of course.

Of course this value is already set in dsattrTypeNative:naprivs for this user, as my kickstart script intended.

Shoot, looks like I’m un-hiding this user with a higher UID.

[pteeter]

It’s called a payload free package.

Look all over this forum for discussion, step by step, etc.

Basically – have your script act in a postflight capacity, install a dummy file with the PKG installer, then have the postflight script’s last action be deleting that dummy file.

[url]http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_4.html[/url]

There may be more elegant ways of doing it.

But that’s the basic concept.

HTH.

[Author]

Posts