Ad-hoc Render farm challenges

If you can use Casper Remote to kick off the app, then you should be able to
build a Self Service policy that does the same thing. I know you mentioned
trying Self Service, but have you tried to mimic what you do in Casper
Remote with a policy and use Self Service that way?

Steve Wood
Director of IT
swood at integer.com

The Integer Group | 1999 Bryan St. | Ste. 1700 | Dallas, TX 75201
T 214.758.6813 | F 214.758.6901 | C 940.312.2475

A simple Self Service policy with the "run" field filled in the Advanced tab of

sudo open /path/to/app

should do it. Depending on the app, you may need to grab the current owner of /dev/console and then do a

sudo -s <user> open /path/to/app

This basically does a sudo as the user.

j
---
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

Yes, but the challenge is how would I remove myself from the mix? I need an end user to be able to kick this off on other computers...not me. Since the end user is not able to unlock other end-user machines, there will have to be something that enables a particular end user to kick-off the app on other machines remotely. I don't plan on giving them access to ARD. It would have to be something that they can do without us giving away the keys. It appears there is an API for the JSS. Perhaps an answer lies there? Could a self service script interface with that? IF so, I would imagine that this could be possible. Otherwise any "solutions" seem to involve too many compromises. On Aug 17, 2011, at 11:45 AM, Nichols, Jared - 1170 - MITLL wrote:

I can do it myself quite easily using a variety of tools. The real question that I probably buried in details is "how do I avoid calls at 1am asking me to startup the render slaves".

Ah ok. I think I took it to mean that they were doing this on their own machine.

This one's a good ol' 'hrm'.

If they need admin rights directly, I don't see this happening from direct machine to machine. You'd need an authentication infrastructure similar to how the JSS knows if you're able to use the various parts of the Casper Suite on people's machines (remote control for instance).

I wonder if you could create a separate group on each user's machine and add users to that group. Then the app would have permissions such that the group had the execute flag on it. Is this a background command-line binary that runs or a full fledged GUI app? You'd then need to still craft a way to remote into the machines to trip off the app. Casper policies are only triggered when a machine checks in. Casper Remote is true "push."

Something that comes to mind is allowing the use of Casper Remote to run a script on a target set of machines. However, this is currently "keys to the kingdom" with the security model in the JSS. ("allow this user/group this function, but to all machines" as opposed to "allow this user/group this function to only this machine/group of machines") I know that particular issue is something that we all want and is something JAMF's working on.

j
---
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

The render app is a GUI app and will only work within a user context (unfortunately). No special rights are needed beyond a logged in user. Currently I could run a launchd that starts up the app on a schedule, or a saved task for ARD, etc. Neither of those models are "on demand" though would be annoying for users if it pops up frequently or inconvenient if the app doesn't launch for hours at a time. On demand and just in time is what's needed to make this work well.
On Aug 17, 2011, at 1:27 PM, Nichols, Jared - 1170 - MITLL wrote:

Hey all,

Just some thoughts on this…

Consistency in the environment and some clever scripting may get you there.

If we can assume that the appropriate computers will be powered on and that they have consistent hostnames, a script could…

- Contain all of the hostnames for the render farm computers
- make ssh connections to the render farm members via a for loop
- issue the command Jared mentioned. I would add the –g flag though, to avoid disturbing whoever may be using that computer. The –g flag on the open command keeps the app from coming to the foreground. See below.

sudo -s <user> open -g /path/to/app

Since this is a script on one client connecting to other clients, and not running directly on the target computers via a policy, the $3 variable won't be available, however, you can discover the current logged in console user with the following command…

/usr/bin/last -1 -t console | awk '{print $1}'

I think the big hitch is that the app requires a logged in user. Unless my memory is failing me, I don't believe there is a scriptomagic way to force a gui login. Perhaps having autologin enabled on these computers (maybe with a "render" account) along with automatic shutdown at the end of the business day and a pmset script telling them to power on in the evening well before typical render sessions would help. Of course, having the render app be a login item for the render account in this scenario would eliminate the need for the client to client scripting.

Another option using the client to client script might be to report to the user initiating this whole process when there isn't any response from, or logged in user on any of the render computers. If these computers aren't too far apart physically, the user could then go over to those computers and power them on or log in to the render account. This idea assumes that the reason the user isn't manually launching the app is because the other computers are generally in use rather than because the computers are significant distances away from one another.

I hope there are some useful nuggets here.

Thanks!

--

Miles Leacy

Technical Training Manager

Mobile +1 347 277 7321

miles at jamfsoftware.com<mailto:miles at jamfsoftware.com>

....................................................................

JAMF Software

1011 Washington Ave. S

Suite 350

Minneapolis, MN 55415

....................................................................

Office: (612) 605-6625

Facsimile: (612) 332-9054

....................................................................

US Support: (612) 216-1296

UK Support +44.(0)20.3002.3907

AU Support +61.(0)2.8014.7469

....................................................................

http://www.jamfsoftware.com<http://www.jamfsoftware.com/>

Hi Miles.

Thanks for the info. I'd actually thought of the connecting to a list of hosts via ssh, but the thought of having the hard-code credentials (or ssh keys) isn't all that desirable nor is maintaining a list of computers in a script. BUT, I think your thoughts do sound feasible. We have the consistent environment and I'm not overly concerned about logged out machines as the majority are always logged in. I might look into a quick-n-dirty way if it comes down to that.

IF the API allows one to change whether a policy is enabled/disabled, then the ability to toggle a policy which launches the client app by an end user using self-service might be less management overhead. Machines would check in, see a policy scoped to them, and do it. It's all easily managed on the familiar JSS. However the API is a big IF that I'm not familiar with.

I actually contacted jamf asking about the API (I have no experience with it and am not a developer) and here's what I got.

----
"I think I may have something for us to go off of. We're first going to want to create a policy which triggers the desired application to launch. We'll need this to be on the every15 trigger so that machines automatically launch this the next time they check in and see that the policy has been enabled. The policy should be disabled by default.

Now, we're going to want to create a policy that is scoped to the users we want to be able to launch this application via Self Service. The policy should utilize the API and the policy PUT to enable the initial policy that was created. This is slightly beyond the scope of items supported by the Casper Suite since the API isn't supported, but hopefully it gives you a good idea of the basic concept."
----

So, it does sound possible to use the API to do it, but beyond my current level of knowledge. I think I will go the route of finding someone to help me with the API approach first and if that doesn't work, fall back to the scripting method. If anyone familiar with the API wants to help, I'm all ears.

You could set up certificate-based authentication for SSH instead. That way there's no credentials in the script. It would be a little legwork, but even the certificate generation could be scripted a bit if it turns out to be a viable solution in the longterm.

j
---
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

Aaron,

Before you read any further can your users ssh to other machines?

Hi Sean.

No, ssh is locked to a single account. I do like your idea on only executing if screensavers are active. I'll have to play with determining that. Other than that, the only need is to somehow allow someone to turn the policy on/off without giving them access to the jss.

I'm sure I'll be able to play around a bit more next week.

A while back I asked a question on setting up a solution to allow for an
end-user to centrally launch a render client on a bunch of machines. I think
I have a method worked out. I'd love to hear any feedback on it. Much of it
is comprised of ideas already offered.

There are 2 parts. The policy, which is responsible for launching the render
client, and policy activation, which will be handled through self service
and the API

Policy activation isn't all done yet, but will be done with the API and Self
Service. I've created a user with rights only to API ---> Policies --->
change. Unfortunately I don't have further control as to which policies etc,
but it's a start and hopefully no too large of a security hole?!? A Self
service policy scoped to one user is used to modify (on or off) the
following policy.

THE POLICY
My policy, set to run "every 15" and "ongoing" is a script and some
preferences (since C4D requires user-level prefs to point to the netrender
server). The prefs are laid down every time, which I may change and
incorporate into the script.The script essentially ensures that a few
conditions are met and launches the render process. Conditions are:

1. There has to be a logged in user
2. The Process can't already be running
3. The machine has to be inactive for at least $4 time (900 seconds)

If those conditions are met, then the script alerts the user and launches
the netrender client. This is where I have one question. It launches the
process as the logged in user and works, except it will also bring up a
terminal command window. Is there a way to prevent that and just launch the
app?

Other than that, I would love to hear suggestions on script improvements.
One I can see already is to ensure that C4D is installed. It should be on
all machines, but there are always exceptions.

I'll post the complete solution - if I ever get there.

Thanks!
Aaron

----- SCRIPT------

#!/bin/sh

# Check idle time in seconds
idletime=`ioreg -c IOHIDSystem | awk '/HIDIdleTime/ {print
int($NF/1000000000); exit}'`

# get current user
currentuser=stat -f%Su /dev/console

##Set Variables

#Uncomment to test otherwise this gets set in the jss policy as $4 $5 and $6
#idletimeout=0
#alerttitle="RENDERING ALERT"
#alertmessage="Due to machine inactivity, your machine is now being used as
a render zombie. While this will assist the cinema4d team with renders it
may slow your machine down if doing demanding tasks. If you experience
slowness, you can easily opt-out at any time by finding ""NET Render
Client"" in your dock and choosing quit. It may launch again after a 15
minute period of inactivity on your machine but may be shut down at any
time. Thanks for your help."

# Variables passed from Jamf policy
# CHECK TO SEE IF A VALUE WAS PASSED IN PARAMETER 4 AND, IF SO, ASSIGN TO
"idletimeout"
if [ "$4" != "" ] && [ "$idletimeout" == "" ]; then idletimeout=$4
fi

# CHECK TO SEE IF A VALUE WAS PASSED IN PARAMETER 5 AND, IF SO, ASSIGN TO
"alerttitle"
if [ "$5" != "" ] && [ "$alerttitle" == "" ]; then alerttitle=$5
fi

# CHECK TO SEE IF A VALUE WAS PASSED IN PARAMETER 5 AND, IF SO, ASSIGN TO
"alerttitle"
if [ "$6" != "" ] && [ "$alertmessage" == "" ]; then alerttitle=$5
fi

#Check for existing netrender client running
netRenderPS=`ps -axl |grep "NET Render Client.app/Contents/MacOS/CINEMA 4D"
| grep -v grep | awk '{print $2}'`

if [ "$netRenderPS" == "" ]; then echo "Netrender is not running" netRenderPS=0
fi

echo "$1: Idletime: $idletime"
echo "$1: NetRender Process#: $netRenderPS"
echo "$1: CurrentUser: $currentuser"

## Do sanity checks then run cinema4D
# We need a logged in user. If user is not root, exit
if [ "$currentuser" == "root" ]; then
logger -i "$1: No user logged in. Exiting"
exit 99
elif [ "$idletime" -lt "$idletimeout" ]; then
# User inactive for less than 900 seconds logger -i "$1: Idle timeout not exceeded. Exiting" exit 98
elif [ "$netRenderPS" -ne "0" ]; then
# check for existing netrender process logger -i "$1: Netrender already running" #netrender is already running.
Exit now exit 97
else ## At this point they are logged in and inactive for 15+ minutes. Go
ahead and alert the user and launch app ### jamf displaymessage -message $alertmessage /Library/Application
Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType hud
-title "$alerttitle" -description "$alertmessage" & #launch the netrender
app as the current logged in user in the background ### Problem in that is launches a terminal window as well. How do I
change this? sudo -u $currentuser open -g "/Applications/MAXON/NET Render R12
Client/NET Render Client.app/Contents/MacOS/CINEMA 4D" & sleep 5 #now renice the application by grabbing the current PID and making it
nice renice +20 -p $(ps -axl |grep Render | grep -v grep | awk '{print $2;}') logger -i "$1: Render PID is $(ps -axl |grep "NET Render
Client.app/Contents/MacOS/CINEMA 4D" | grep -v grep | awk '{print $2;}')"
fi

exit 0

Sorry to keep replying to myself. Hopefully this is useful to someone. I'm done and it seems to work well.

Here's how it was put together:

We have a policy "RenderClients", which determines if a computer is ready to run the render client, and launches it when appropriate (logged in user with 15+ minutes of activity). The "RenderClients" policy is activated/deactivated by an end-user using Self Service. The self service policy simply contains a script which makes an API call, enabling/disabling the "RenderClients" policy via the API.

Here's the XML blob to enable <?xml version="1.0" encoding="utf-8"?>
<policy> <general> <enabled>true</enabled> <frequency>Ongoing</frequency>
</general>
</policy>

And here's the curl command:
curl -v -k -u username:password https://jss.example.com:8443/JSSResource/policies/id/179 -T "$pathToXMLFile" -X PUT

To disable the policy, we just use the same curl command pointed to an xml file to disable the policy. Now, an end user can enable/disable the policy that launches the C4D netrender client on all logged in machines (even with locked screens), effectively giving them the control to start and stop the "render farm".

Improvements:
• We had to create a user in the JSS with permission to update policies through the API and pass that username/pass in the curl command. Not sure if theres a better way.
• The API user could in theory enable/disable any policy. I don't see a way that could be locked down.
• There's really no feedback for the end-user. He just has to trust that it's working.
• Cleanup/quitting of the render process might be good. It could be as easy as a one-liner in disable Policy's "kill process if found".