after image, first time run scripts

To make a script run once as you describe, I'd run the script via a policy,
once per computer, at login. Is it a requirement for it to run at login? If
not, I'd run it at reboot. If you don't have "Create Login/Logout Hooks"
checked in Management Preferences on your JSS, you should be able to set the
script up as a login script for your admin account. If you want it to
delete itself you could include the line "rm /path/to/this/script.bash" in
your script. If you run it as a policy, there's no need for self-delete.

The networksetup command will allow you to turn your ethernet interfaces and
Airport card on and off.

Recon:
I suggest the jamf binary. Type `jamf help recon` in Terminal. There are
several switches and parameters depending on exactly what you want. Then
again, with a policy, you could simply check the box in the Advanced tab.

If you want logs, you can include "echo `ifconfig -a`" to the "Run Command"
field in the Advanced tab of your policy (or, more simply `networksetup
-listallnetworkservices`).

Is this MAC-registering software running locally on the client machines? MAC addresses generally don't change, and if you're going to run the
software on these boxes, they're eventually going to register the MAC
address. Perhaps I don't understand what are you trying to accomplish or
avoid. Can you elaborate? In your workflows, when do you expect a local
admin to log on? After imaging, but before deployment?

It should go without saying that with both airport and ethernet disabled,
the only way you'll be able to interact with this machine, until the script
runs, is at the console.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

We actually do this in a few spots.

We have several packages and scripts that run after a machine is booted for the first time via LaunchDaemon (some after someone first logs in) - this does a number of things, including:

1) Renaming the system volume so our scripts actually work!
2) installing casper and creating a casper-only service account
3) creating a new hidden admin account (and removing the temporary one)
4) installing computrace
5) creating a loginhook for all users
6) naming the machine
7) setting ARD access
8) Installing certs and binding to our OD Server via SSL
9) Cleaning up caches
10) Fixing permissions
....etc

....then the script securely deletes each item, including the LaunchDaemon, while securely deleting itself last.
Works great!

-jeremy

Are you seeing any benefits to using a launchd task as opposed to "at
reboot" scripts in your configuration and/or creating Casper policies?

I ask because I'm wondering if your method is driven by function or
preference. As I look at your list, I think I can accomplish each item via
Casper directly or via a Casper-delivered script. Did you encounter any
situations that made launchd more desirable?

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

I'm not being helpful today, but I HAD to make a comment...

Some of you people really do some CRAZY things!

I'll echo along with Miles though on the launchd preference, and wonder why not using at reboot options for scripts with Casper?

Craig E

That is pretty much exactly what I want to do. I am familiar with all the commands since I already have scripts that do all of this. However, I am looking for a script that only runs for the local admin account and only runs at first log in. We image behind routers at times and these routers run NAT so it doesn't always hit the JSS since I don't have FQDN set up and all the forwarding, etc on each router. We also run CompuTrace which is MAC address sensitive which is why I have the NIC and Airport turned off in the master image.

I found really when mass imaging machines block copying performs faster than package based deployment and I never image one to 4 machines at a time. I always image over 10 at a time if I can, if not more than that even. So, I like to block copy and have all the basics in the main image.

So when someone from my department images a machine they just log in as local admin once, it runs all it needs to do, then it shuts down the machine. So they can log in and walk away and when they come back they can toss it in a laptop cart.

Overall, not a huge deal but it wold definitely make our lives like 1 or 2 percent easier.

thanks,

Well, I suppose a few reasons...

Firstly, some clients wanted these items to be done at first boot. At first boot these machines did not already have casper installed. Catch-22 there. Hard to run a Casper policy without casper being installed. Some wanted "fresh" machines at boot, with nothing but the core OS. Next step install X, then Y, then Z, etc.

Additionally, some clients in larger implementations have casper in some places, but not others. In other cases, there were other network issues or Technical/Administrative concerns. I can't go into this too much, but you can probably guess as to why.

Other than that, we wanted to be able to deploy using native technologies for some companies. Though Casper is definitely a preferable option, it does give our clients the ability to deploy a single package that includes all of this tech, will run at first boot (or next boot, depending on if you're already booted!), and does not require Casper to intervene, poll, make decisions, etc.

So, altogether now...

1) Use whatever distribution tech you want
2) Little (or no) reliance on networks or other services
3) Native methodology (Casper not required - some places use Casper, some don't, some mix and match)

-jeremy

Well, my main reason is everything is set up via FQDN and sometimes I
image on separate VLANs behind routers behind NAT so I can use higher
speed giga switches, and I don't have everything set up in the router
for it to work via FQDN.

I know I can do it by IP but I have set bind policies to run at reboot
and they don't always run. Would like to store a small little script
locally that as a log in item, when the hidden local admin logs in for
the very first time it runs, executes, then never again runs.

I also use non standard OS X permissions and want it to make sure every
package under /Applications has the following

owner: root group: admin rwx set to 775

/Applications/Utilities is

owner : root group: admin rwx set to 770

I toss everything I don't want people to have access to into
/Applications/Utilities. I currently have a policy that is set to on
going and it does work, but it spams my database with updates all the
time. I want this to be ongoing in case any one besides me builds
packages and deploys them, because I know some people won't fix
permissions on the package itself.

I am just exploring other ideas to keep it on the machine locally so the
JSS doesn't have to interact with it and it could be on a part of the
network that is not active and still get updated with the proper
settings.

Well,

I suppose running a script only once is not a problem, since you can have it issue a command to securely delete itself after complete.

You can create a user-specific launchd item, so you're covered there as well. Since I haven't tried to do using this method I suppose if you wanted to run something only at first login, you could create a loginhook which executes said scripts, and then create a logouthook which deletes the loginhook and the logout hook.

Would that work?

-j

Not to hijack the thread, but I just have a quick question about some of what you guys are talking about.

I do a lot of scripting and I'm not sure what you mean by "securely" delete. Is there something you run besides 'rm' to delete your files?

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

srm instead of `rm`
man page says it all.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com