[chops]

Well, duh… 😳
I failed to consider the brute force method:

1. Create custom packages containing the complete directories for the desired users (I used Iceberg for this);
2. Place them in the catalog file before the other custom packages (which can then throw whatever you want into them);
3. Set appropriate ownerships in the firstboot script.

Beam me up, Scotty!

[chops]

So it’s Saturday and here I am. I decided to try to create my image differently, the InstaUp2Date way. Tried to checksum my custom pkgs (three createUser and the ClearReg) and got this in the terminal:
[code]sltools:InstaUp2Date chop$ ./checksum.py /instaDMG/InstallerFiles/InstaUp2DatePackages/* > checksums.txt
Traceback (most recent call last):
File “./checksum.py”, line 71, in
progressReporter.update(taskMessage=dataLine)
File “/instaDMG/AddOns/InstaUp2Date/Resources/displayTools.py”, line 105, in update
self.outputChannel.seek(lengthToOverwrite * -1, 1)
IOError: [Errno 22] Invalid argument[/code]
I’m using instadmg 384 in SL 10.6.4 on an iMac Intel Core 2 Duo.

Neglecting the home and family for yet another weekend… 😕

[chops]

Sheesh, looks like I double-posted last night’s post. I don’t know how that happened…

Anyway, I figured out what “svn” is and used it to update my InstaDMG binary. It’s chugging away as I type and appears to have gotten past the missing com.apple.installd.plist file. Fingers crossed.

[chops]

I am having major problems baking an updated 10.5.8 image for my LAST remaining PPC lab (gawd I wish it would just go away!). What is “svn” in this command and where does one type it?

[code]svn checkout http://instadmg.googlecode.com/svn/trunk/ instadmg-read-only[/code]
It looks like something one must run inside the InstaDMG script but I am clueless and I need a fix. Here are the last lines from a fail that has happened several times today:
[code] Mounting the shadow file (/private/tmp/InstaDMG_temp_folder.bVAtG4/BB589DA2-EBA6-47BF-9F37-2F92B39F0094.shadowfile) onto the cached image (./Caches/BaseImageCache/E0799E5A.dmg)
Target OS: Mac OS X 10.5.6 (9G2141)
Encasing installd daemon in a chroot jail
cp: /System/Library/LaunchDaemons/com.apple.installd.plist: No such file or directory
launchctl: Couldn’t stat(“/System/Library/LaunchDaemons/com.apple.installd.plist”): No such file or directory
nothing found to unload
###### Unable to unload system installd daemon ######
19:25:37 ###### Cleaning up ######
Restoring normal installd daemon
launchctl: Error unloading: com.apple.installd.modified
launchctl: Couldn’t stat(“/System/Library/LaunchDaemons/com.apple.installd.plist”): No such file or directory
nothing found to load
Ejecting images
Deleting scratch DMG
dhcp110-141:instaDMG admin$
[/code]

[chops]

I am having major problems baking an updated 10.5.8 image for my LAST remaining PPC lab (gawd I wish it would just go away!). What is “svn” in this command and where does one type it?

[code]svn checkout http://instadmg.googlecode.com/svn/trunk/ instadmg-read-only[/code]
It looks like something one must run inside the InstaDMG script but I am clueless and I need a fix. Here are the last lines from a fail that has happened several times today:
[code] Mounting the shadow file (/private/tmp/InstaDMG_temp_folder.bVAtG4/BB589DA2-EBA6-47BF-9F37-2F92B39F0094.shadowfile) onto the cached image (./Caches/BaseImageCache/E0799E5A.dmg)
Target OS: Mac OS X 10.5.6 (9G2141)
Encasing installd daemon in a chroot jail
cp: /System/Library/LaunchDaemons/com.apple.installd.plist: No such file or directory
launchctl: Couldn’t stat(“/System/Library/LaunchDaemons/com.apple.installd.plist”): No such file or directory
nothing found to unload
###### Unable to unload system installd daemon ######
19:25:37 ###### Cleaning up ######
Restoring normal installd daemon
launchctl: Error unloading: com.apple.installd.modified
launchctl: Couldn’t stat(“/System/Library/LaunchDaemons/com.apple.installd.plist”): No such file or directory
nothing found to load
Ejecting images
Deleting scratch DMG
dhcp110-141:instaDMG admin$
[/code]

[chops]

[QUOTE][u]Quote by: walt[/u][p]FYI by default Composer doesn’t include files in /Library/Application Support/Adobe PCD/ which are required for licensing to work. I built my CS4 packages with Composer after changing the preferences in composer to include these files and it worked fine. They do this by default in case you are deploying an update and not the initial install.[/p][/QUOTE]

Hmmm. Well, the packages I made with both Composer and logGen/PkgGen do have this folder and its contents in them, so there must be something else.involved as well. 😐

[chops]

This is a follow-up post to report the results of more experimentation.

First I tried it Adobe’s way, but as described a few posts back: Package up the uber installer and the repository directories and dump them to the client, then run them after the Mac boots. It didn’t work for me. I had exactly the same broken licensing as before, but worse because I would have had to run all the updates as well, plus the package weighed in at 5.5GB vs 3.8GB for my DIY package. Fuhgetit!

My last attempt used logGen and PkgGen to do what I had done before with Composer. No change. Licensing is always broken. What I did discover, however, is that it is important NOT to run Acrobat Pro or Distiller first. Running Photoshop first cut the number of steps down. I still have to touch every dang Mac to finish the config process, but it doesn’t take 10 minutes per Mac any more. FWIW, here is the sequence:

1. Deploy as normal
2. Log into the lab user account
3. Launch Photoshop (or any CS4 app, but NOT Acrobat Pro or Distiller). Result: “Licensing for this product has stopped working.”
4. Install AdobeLicenseFix.pkg via ARD (this pkg came from Adobe)

And that’s it. Everything works now.

Note to Adobe: We shouldn’t have to deal with this! 👿

[chops]

[QUOTE][u]Quote by: shownde[/u][p]The real question is, why do we put up with major software developers putting us through the agony of their BS custom installers. It would be one thing if they actually made our lives easier, or if there wasn’t a standard installer package format with lots of free tools and no licensing costs to use. It’s another entirely when they just make unnecessary work for us. Adobe (and Mathworks, and a few others) should build .pkg installers, especially if they are building a .msi for Windows.

Grumble grumble grumble.[/p][/QUOTE]

I with you on that, shownde. Problem is my boss and users have neither clue how hard this is nor do they care. THAT is why we have to put up with Adobe’s foolish installers from hell. I have spent waaaay too much time on this!

I have tried several snapshot and packaging methods and still get licensing issues in the lab (non-admin) user accounts. Acrobat Pro and Distiller have given me the most troubles, and I can solve them but at a high price in time:
1. log into the lab user account
2. launch Acrobat Pro (succeeds)
3. launch Distiller (fails with the “licensing is no longer working” alert and takes Acrobat Pro down with it)
4. Apply AdobeLicenseFix.pkg using ARD.
5. Launch Acrobat Pro again and supply the requested admin user ID and PW

After this CS4 seems to work fine in the lab user account. But this is a BIG DEAL when I have to deploy to 200 Macs by myself. My solution includes the usual tweaks: the SelfHeal fixes; the Application.xml fix; futzing with permissions, etc. I’ve even tried watching file system activity with Sonar to get ideas. Zilch results.

So today I thought I’d give the Adobe Deployment Toolkit another try. Now that it is finished building I remember why I shied away from it before: It doesn’t create a package. I can only run the installer from the client, which has to install off the server where the resources live. This means a whole lot of hits on the server while the whole gang tries to install from it at once. I guess Adobe assumes we’re just installing to a couple of computers so bandwidth is no problem. WRONG! I make my base image with InstaDMG, but for everything else use Deploy Studio because it gives be multicast style speed with a train of packages.

So here’s what I’m going to try next: Package up the Adobe installer set, complete with uber installer etc, and create a package that dumps it on the client Mac then runs the uber installer on the second boot (first boot is already taken with other config stuff). It means a package about twice the size of those I’ve been creating with snapshots and Iceberg, but it _is_ playing by Adobe’s own rules. I’ll post my notes on the process back here.

Thanks for reading my rant, wish me luck, and stay tuned…

Patrick Mullen

[chops]

Thanks, larkost. I tried it and it worked, so now I want to understand it better. I’m obviously not familiar with much of this. Bear with me:

I can conceptualize that the script runs from the target image (volume) even though the machine doing the building of the image is booted from another volume. I’m not understanding how the image being built can have a running OS on it. Is it “running” because the shell command (like mkdir for example) is being run from the image instead of the boot volume? To me that implies that ${TARGET_DIR} or $3 could be placed in front of either the command or the path, as long as one of them has it. Am I on the right track?

[chops]

Okay, I’ll try it. I’m a little confused though. I saw the ${TARGET_DIR} variable, but in the lines of the original script that create the user there is this one:
[code]$serviceCmd $prefix “$dsNode” $suffix -create $userPath home “/Users/${shortname}”[/code]
which doesn’t have the ${TARGET_DIR} variable or $3 in front of “/Users/${shortname}”. Is this because the $dsNode variable does the pointing?

Thanks for your guidance…

[chops]

Thanks, gentlemen. I’ll play with the different ways of stringing things together. Right now I’m toying with a modification of the first-boot script thespider posted on another thread here. I’m still thinking cuz I’m still building my application packages. Once I have them done I’ll start putting this into practice. A bunch of new CPUs should arrive next week so I’ll have a mix of Macs to play with.

Anyway, here’s what I’m considering:

First-boot script
–Time Zone Setup
–Set up Network Time Server
–Enable ARD for admin user
–Start Remote ssh login
–turn off .ds-store on network shares
–turn off time machine
–disable time machine in general
–disable time machine new disk requests
–Set hard drive name
–Hide sub 500UID users
–Disable Autmotic Software Updaters
–disable itunes update checking
–remove itunes store links (bandwith)
–Disable WINS so your Mac won’t show up as a windows SMB share
no reboot, then this hands off to

set hostname script
–set-names.sh
–replace previous launchd with the cleanup script
–reboot

cleanup script
–enable root account
–make it so root cannot ssh in remotely (edit or replace /etc/sshd_config for “PermitRootLogin no”)
–turn off Airport if present
–allow printer selection by non-admin users
–remove launchd item
–Make sure the permissons are correct
–reboot
–Self Destruct

Am I missing anything?

[chops]

Sort of a n00b question here I guess: Is it better to have one script call another in order to chain them together, or can I just list them in the order I want them to run in the lauchd item?

I’ve been using the set-names.sh script for a few years and I’d like to call it during the first-boot process.

Seems like it may be useful to have a selection of scripts that could be used in different combinations depending on the desired configuration.

[chops]

[QUOTE][u]Quote by: knowmad[/u][p]
Now, for what Chops was saying…… um….. I got no good answer. I can tell you that all I am doing to the create user script is making a password hash and editing the userdata section. It works for me (though you have made me curious and I will be making new image tomorrow night to check). None of that helps you and is not what you wanted to hear. BUT going back to what I always tell my team/friends/family/clients/etc… start from the basic and go from there. Rebuild once more, but keep only one instance of the createuser and see what you get.[/p][/QUOTE]

Thanks, knowmad. I did indeed cut the creatuser scripts down to one only (I can always create the other users in the first-run startupitem). In addition, I had been trying to create a user that already existed on the Mac I was using to create the image. This is apparently a no-no, so I invented a completely new user for the createuser script and built my image again. Success!

Thanks again for your help and patience. Next step is to play with that first-run startupitem…

[chops]

This morning I altered things a little (moved the createuser pkgs (for three users) into separate numbered folders in CustomPKG) and ran the thing again. Figured I’d just set up admin, faculty, and student users in one go. I checked the image before writing it to my test Mac and found no user directories at all. Imaged and booted test Mac anyway, just to see what would happen. The startup sequence skipped the registration (per clearReg.pkg) and gave me a login screen with my three users on it. Right user names, wrong icons, and I couldn’t log in with any of them.

I am at the “let’s see how this works” stage with instaDMG, so the only CustomPKGs I have are three createuser and clearReg. I only changed the USERDATA file inside the createuser package. Was there something else I was supposed to do? Do I need another package to insert the directories?

I’m afraid I don’t understand what you’re saying, knowmad, as I have things pretty simplified already, AFAIK. Am I supposed to go through the createuser script itself?

[chops]

I too am getting incomplete user directories with creatuser. So how does one go about creating completed user directories, or completing the ones created by createuser? Surely I am missing something here?

[Author]

Posts