createUser.pkg & ARD

[sgstuart]

Hi all,
In the postflight portion of the createUser.pkg at the very bottom there is a section for using kickstart and having Remote Management (ARD) activated for it after that. I am having problems with this portion. Here is what that command does for me.

It activates Remote Management (this is good)
It adds the admin account that was created with createUser (this is good)
It gives the admin account all the privs. (this is good)

It does not select the Allow access for “Only these users” (THIS IS VERY BAD)

So it keeps the Allow access for “All users” selected, and “All users” has no privs. So when this computer comes up, there is no way to access it remotely.

I am sure others have done this. What are you changing the command too, to allow it to work?

Thanks,
Steven Stuart

[Rusty Myers]

Hey Steven,

This seems to still work:

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -specifiedUsers
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -on -users “admin” -privs -all -restart -agent

However, didn’t respect my wishes the first time I ran it. I ran:

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -specifiedUsers

A couple more times and eventually it took…strange for sure!

Rusty

[sgstuart]

Hi Rusty,
Thank you very much for your response. Based on you saying the first couple of times it did not take, are you doing this in the build with the createUser script or are you doing this manually at the terminal? When I do certain things at the terminal I have got a 100% success rate, but I will not be able to run these at the terminal if I do not have access to them thru ARD.

Also based on your suggestions, if they are in the createUser script does that mean I should add the sudo to the front? I have put a sleep 5 in between the two I have decided to use in the script, but not sure if that is long enough or needed. I do have the 2nd command first though, and the 1st command 2nd in mine, but I have the restart command on both as well.

Thanks,
Steven Stuart

[Rusty Myers]

Sorry, should have been more clear on that. I was trying these on my laptop, already running 10.6.4. From the terminal, when I ran the commands, it didn’t take the first few times I ran it. Although, I had the system prefs window open the second time I ran it, so It probably worked but didn’t show me the changes. When I was running this command in InstaDMG, I was doing it with a separate package that ran after createUser.

Not sure what the ordering of the scripts changes. I suggest experimenting with that. Good luck.

[bdawg20000]

Has anyone had any success with creating the custom setup in ARD and putting that in the build train.

[sgstuart]

Hi Rusty,
Thank you again. Based on how you said it I assumed that you were just running them from the terminal. I had been testing things that way myself, and had problems as well. I found out thru those testings that if you have System Preferences open the items for whatever reason do not take. So when the command lines are run the system prefs need to be closed. I will keep trying.

I had tried one other variation last night on my way out, and just tested that, it did not work either. So I am going to try your suggestion now.

I am placing the first line of yours without the sudo (as I do not think it is needed in the createUser.pkg). Then putting a sleep 5 and then keeping the line I had in their to begin with. In about 75 minutes that should be done, then I need about another 20 min to push it to an external firewire device and then boot to that. device.
I am feeling good about it, I did manually test that sequence successfully as well, but apparently scripting it appears to be slightly different at times, in this case I do not think there will be a difference, and I will recommend a change to those lines. They are commented out by default.

Thanks,
Steven Stuart

[sgstuart]

Hi all,
That try failed as well. I will try to set it so that all Users have access, and then thru ARD run a command to do the specifiedUsers.

Thanks,
Steven Stuart

[Rusty Myers]

Hey Steven

I would create a launchd item and script that would run your ARD settings during first boot of your machines. That way you would know its being set right. You can do as you suggest as well and just use ARD to set the clients prefs, but I personally don’t like having to trust ARD for that kinda thing. I’d rather do it once and let it fix itself. Sorry we couldn’t get it to work via InstaDMG build train, perhaps someone else has a fix for it?

[sgstuart]

Hey Rusty,
I am going the LaunchDaemon way. I believe I have created a valid one, and tested it on one of the bad builds, restarted it, and it came back properly. So I will hope that takes care of it. I am adding it to build now, and hope all goes well.

Thanks,
Steven Stuart

[sgstuart]

Hi Rusty and all,

I was able to get the ARD portion working by creating a .sh with 2 kickstart lines, pretty much the two lines that Rusty said above, and in that order. That way it only needs to activate and restart once. I did not put in a sleep command.

Then I placed a .plist into /Library/LaunchDaemons that has two parameters, “sudo” & the full path to the script. It is set to RunAtLoad.

I should probably put a rm of the .plist at the end of the .sh, but I did not do that at least yet. I will probably add those deletions to my ARD script that is for post Build anyways. Which will be pushed thru NetBoot (not a OSX server).

Thanks,
Steven Stuart

[bdawg20000]

Hey Steven, any chance you could send those files over so that i can give them a shot. I haven’t had any luck getting ARD configured after the InstaDMG build. are you just using the lanchdaemon to call the .sh script to configure ARD?

Thanks

Brian

[sgstuart]

Hi Brain,
Yes that is what I am doing.

Here is the .plist code which is put into /Library/LaunchDaemons. Change the XXXX to your company, and the /path/to/file to the correct path for where you put your .sh, if you have a different name for your .sh, change that as well.

[code]

Disabled

Label
com.XXXX.ARDSettings
ProgramArguments

sudo
/path/to/file/ARDSettings.sh

RunAtLoad
[/code]

The meat of the .sh is this. Change the XXXXX to the user that you want. This will run every boot, so you may want to write a rm -f command to delete the LaunchDaemon after it runs the first time.

[code]# Set the Access to only be for specifiedUsers.
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -specifiedUsers

# Activate Remote Management, configure user XXXXX to have all privs and to restart the ARD agent.
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -users XXXXX -privs -all -access -on -restart -agent

[/code]

Thanks,
Steven Stuart

[Allister Banks]

So I feel responsible for this, and will be sending a patchfile of enhancements to larkost when I’ve tested more thoroughly. I actually have noticed this poor behavior with kickstart since at least early Leopard, but am just annoyed I can’t tell where this is exactly specified per-user. (All users is obviously /Library/Preferences/com.apple.RemoteManagement.plist)

Steven, your launchd is great, and I’ve been using daemons for a bunch of things, so the patchfile mentioned above will include a thoroughly tested launchd.plist+script template to accomplish this and other goals. I’ll have a download link on this thread soon.

Allister

[sgstuart]

Hi Allister,
That sounds great.

Thanks,
Steven Stuart

[Allister Banks]

There’s still hope! You do still need one extra file pushed into the image, but I think I gotit!

First, an update, here’s the slightly more correct syntax for the bottom of createUser:
[code]KICKSTRT=”/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart”
$KICKSTRT -configure -allowAccessFor -specifiedUsers -targetdisk “$3”
sleep 1
$KICKSTRT -activate -configure -users $shortname -privs -all -access -on -restart -agent -targetdisk “$3″[/code]

The sleep is just so I have time to check for it in the debug log, really, and I got a little variable-happy with the path. I’m not sure when they changed -target to -targetdisk, but that’s what the man page says now, so I thought ‘why not'(the old -target probably works fine too).
And then here’s the trick, drop the plist I mentioned earlier(/Library/Preferences/com.apple.RemoteManagement.plist) in place with this content:

[code]

ARD_AllLocalUsers

ARD_AllLocalUsersPrivs
0
[/code]

And bob’s your uncle!
Try it out and let me know, please,

Allister

[Author]

Posts