[akinspe]

What particular settings are you looking to change?

Depending on what you’re trying to accomplish, you could either do it using DSLocal policies, or yes, you could replace /S/L/User Templates. But before you go down that route, let’s find out what you’re trying to manage. Also if it this is going to be a one user system, you could get creative and have a script that takes a variable for the shortname (like createUser) and auto populate the home folder with some settings. I’ve already gotten a request for something like that. I have some ideas to make it work.

But MCX is generally the better choice if you have a central server.

[akinspe]

[QUOTE][u]Quote by: knowmad[/u][p]and now let the fun begin.
Item one, thank you again for this, everything I say here is meant to help, not nit-pick or complain.
[/QUOTE]

Your welcome. I absolutely welcome comments and criticism, even if its nit-picky. it’s how we all get better.

2) I actually don’t think it’s necessary in this case because we are just assigning the contents of a shell variable. When we actually need to use that variable in an exec, it is enclosed in quotes, but I’ll do it anyway to be consistent.

3) I really don’t want to do any hard coded exclusions and i do want to allow them to add an existing uid if they are mindful of the consequences. Are you suggesting that I allow any uid from 0 on? I could certainly add that and make it more permissive if someone wants to be brave and used uids less than 100. But if I remember correctly that’s explicity a no-no from apple’s perspective.

4) I believe that A belongs in another package since it is secondary to creating the user. I can add B into it since technically it’s part of creating that user.

5) Again, I personally think that global options belong in another package.

6) That IS another package, and I have submitted it to AFP548 and it’s awaiting approval .

7) I will add an option to place the home folder in another location. I think I have that hard coded in now. Great suggestion

8) Are you talking about user profiles? That really needs to be another package. I really want to separate user creation from everything else. If it’s not obvious by now, I’m a unix guy and so we make things that do one thing and one thing only. It’s much more flexible. Especially since many people will be building multiple build trains to adjust to different management needs (labs vs. faculty/staff vs. other. etc), so simply being able to add the right packages is, in my opinion, a better option than having a super package that requires fine tuning for every deployment.

As far as defaults, you were actually right on, except you’d just have to use “$3/Library/Preferences/…” defaults can run on any plist file no matter where it is so using it to set plist files on the target volume is absolutely a valid option. But as I said (and you suggested), those are probably the realm of different scripts. I plan on submitting all of this stuff. Just not part of the same package.

Thanks for you feedback. Keep it coming!

[akinspe]

I had to remove files that had tilde’s (~) in them. There were two folders, one for Dreamweaver, one for Pshop that had them. Once I removed them (or the tildes) all was good.

[akinspe]

[QUOTE][u]Quote by: mgb123[/u][p] 😛

This is awesome! I very much appreciate you putting the time and effort in on this!

I have one question- would it be possible to add something to this script to skip the intro movie and setup?

Thanks![/p][/QUOTE]

In the Unix spirit of keeping things separate, I have another package for that. It’s really simple since it just creates 2 files. I’ll post it today.

[akinspe]

I’m not sure if this is your issue, but I have seen this happen on a CS3 package where there were some files (folders actually) that had tilde’s ~ in them. I.e. check for some files with questionable file names. It could be something else, but that caused some issues with me.

[akinspe]

Well I think you can make an argument that it’s security agnostic. The reason being that all those files and their folders are root readable only, and so if someone’s rooted you already then all the UUID changing in the world won’t matter.

I can see merits in both methods. But you could just as easily write a script that quickly looks up the UUID on your box and the writes the hash to the appropriate file. It’s not as dumb plumb easy as simply copying a file, but once created it’s just as easy to deploy.

I can’t think of any significant drawbacks. Part of the flexible add user package I’m creating will allow the ability to either specify the UUID or let it auto generate one. So it’ll be your choice.

[akinspe]

[QUOTE][u]Quote by: dano[/u][p]I’ve also determined that one can take any hash file and attach it to any user account as long as the name is changed to the UUID of the account it is being attached to. I haven’t figured out how to generate a password hash but do check out the sample script specified by the initial post of this thread (posted by akinspe )[/p][/QUOTE]

This is precisely what this script is for. It simply generates the bits and you pipe the output to the appropriate file which is the UUID of the user you need.

In fact I am thisclose to finishing a package that will assist in automating the creating of a user and their password in package format for both 10.4 and 10.5. and is flexible to adjust to any particular policy you might have (same UUIDS, different, auto UIDs, specific, etc. Plus it won’t use clear text passwords if you pre-gen a hash so it’s slightly more “secure”

Anyway, I hope to have it cleaned up and up next week.

[akinspe]

The script is currently written that it requires you to be in the base InstaDMG folder before executing.

So just type:

cd /InstaDMG_Resources/Instadmg
then
./instadmg.bash

I think that’ll get you going

[akinspe]

We have a volume license that already has the serial number built into the installer. So it’s really no big deal. Aside from the damn setup assistant.

[akinspe]

I don’t have an answer, but it’s clear there’s some craziness in their packages that basically copy stuff to a tmp place and then install. You probably won’t be able to deploy this using instadmg as is.It’ll probably need to be repackaged or go into a “install this on first boot” type of process.

[akinspe]

[QUOTE][u]Quote by: Patrick+Fergus[/u][p]Setting the GUID for a local admin would be a really good idea–that way you can easily change the password of your local admin by distributing a single file (the password hash). But otherwise this would remove one of the packages we’re currently installing on first boot of a freshly imaged machine. Very slick.

You could future-proof yourself further by using the installation shell variables:

dscl /usr/bin/dscl -f $3/var/db/dslocal/nodes/Default localonly -create /Local/Target/Users/admin

– Patrick[/p][/QUOTE]

Yeah I wrote that real quick, I didn’t even notice that I had two “dscl”s in front. Using the $3 var is the way to go in scripts. If you want the same GUID, then you can just replace it with a known one. That does make pushing out the shadow hash change much easier, but I suppose one could write a package the grep’s out the GUID based on the shortname and writes the file as necessary.

FWIW: I did some testing and simply replacing the shadow hash seems to instantly change the password. Tested via su in terminal at least.

Long live dslocal. It really makes this type of stuff much more flexible.

[akinspe]

No I think you just have to remove group writable from instauser

chmod g-w /Library/StartupItems/instauser/instauser

the plist should NOT have execution rights

[akinspe]

This target refers to the Volume you wish to restore your freshly cooked ASR image to. This is completely optional and is actually commented out if you use an unaltered version of the script. Basically this would allow you to start the instadmg process, go to sleep (or whatever), and wake up with not only a made ASR image, but a volume that you can immediately test on. In fact, there are also methods to bless the volume (thus making it the startup disk) and rebooting so you return to the new volume all ready to go.

Very astutely, the authors made all of these discrete functions so they can be easily commented out to suit your particular need. As the comment for this item mentioned, soon we’ll have getopts parameters so you could use switches like “-t /Volumes/foo”, etc instead of having to alter the script source

[akinspe]

There’s a known issue the iTunes launches iTunesHelper app after its install and that would prevent the volume from unmounting. I simply removed the postinstall scripts from the itunes.mpkg that does that.

I don’t know of any issues with FrontRowUpdate though.

[akinspe]

[quote]But I need to generate the hash code for the password, so how do I do that?[quote]

It’s like I heard the question coming.

Check out the script I posted today. I created it for that very reason. You simply run it:

./shadowHash password>$VOLUME/var/db/shadow/hash/AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA

the file name is the GUID of the user you want to save the password to.

This will generate a hash file with the appropriate password. Obviously you’ll want to protect this if it’s in a script since it’ll have the cleartext of the password in it. So maybe just use it to generate the hash initially.

Because it uses a random salt, you’ll get a different hash everytime, but it’s the same password.

What’s nice about this also is that you can SET a password on a volume you have root access to, even if it’s not booted.

[Author]

Posts