[Casper] run script as different user?

[Jeremy Matthews]

Thomas,

We used a wild card...or at last, what I thought was a wild card:
----
for i in $( ls /Users )
do
defaults write /Users/$i/Library/Preferences/com.panic.Transmit3  
SerialNumber 333-333-333-333
done
----

Unfortunately, this runs as root, so permissions get horked, etc. As  
soon as the users launches the app (Transmit, in this case), the "bad"  
file gets overwritten. So, we still need to run another script to  
repair permissions on said file.

I get the whole composer thing - right now we're tied to packagemaker  
- per policy for this environment everything has to be a package/ 
metapackage. Its messy, I know. Try reverse-engineering CS3  
installs...when Casper can nicely handle that for you. Plus, composer  
wants to diff the whole disk still...while something like LanRev can  
watch specific directories...a lot faster when you know where things  
will be installed.

Love to get OD finished - but until some issues are resolved its a no- 
go. We pushed out MCX stuff before...hopefully that will be our path  
in about 3 months. But not today, sadly.

Thanks,
j

On Aug 20, 2008, at 12:35 PM, Thomas Larkin wrote:

> Well,
>
> I still don't know what exactly you are trying to accomplish but I  
> can still give you a few pointers
>
> using a wild card in a script will apply to all users
>
> default write <insert bash commands, code, etc> /Users/*/path/to/plist
>
> the above is an out of syntax quick and dirty example.  The * is the  
> wild card
>
> Composer will capture any modifications you make to a file.  To just  
> give you an example, we have some old legacy netware file shares  
> that only support plain text passwords.  By default AFP does not  
> allow this.  So, I had to edit the AFP plist file to allow plain  
> text passwords.  Before I did, I took a snap shot, then edited the  
> file and took another snap shot and it picked up that I modified  
> that plist file.  I then created a policy that pushes that plist  
> out, and since composer took a snap shot of where that file goes as  
> well, it runs as a root process and overwrites the original file  
> with my new one that allows for plain text passwords.  This is  
> easier in my opinion that writing a script to add the settings,  
> especially when it comes to testing.  You can modify ownership and  
> everything and Composer will keep those settings you set, convert it  
> to a dmg file and then you can toss it in Casper Admin, and then set  
> a policy in the JSS and you are done.
>
> Then under /System/Library/UserTemplates/English.lproj, you can set  
> up templates so that whenever a user account is created it will use  
> that template as the default settings.  Place that plist file in the  
> template and it should replicate out to every user.
>
> I suggest you get your Open Directory running and enforce things by  
> group policy, it is a much nicer and easier way of managing the OS X  
> clients.
>
>>>> Jeremy Matthews <jeremymatthews at mac.com> 08/20/08 11:14 AM >>>
> Tried applying to all users - the file is created, but I then have to
> go in a muck around with ownership - or else it gets overwritten when
> certain apps are launched and cannot find a valid plist. If I try to
> return the session user during an installation, it is usually root.
>
> Our 10.5 server is working, but clients are not binding properly, so
> MCX attributes are out - unless I want to push those out as well, but
> pointless until it is set for production.
>
> It was my understanding that composer used packagemaker, and therefore
> during an "installation", runs as root - which brings me back to the
> issue - script needs to run as a different user - without me asking
> the user to authenticate.
>
> Tried the tilde - didn't work.
>
> Config file sounds interesting....what is that about?
>
> Thanks,
> j
>
> On Aug 20, 2008, at 11:54 AM, Thomas Larkin wrote:
>
>> You can do this many ways.
>>
>> use a wild card and apply to all users
>>
>> enforce it from MCX if you are running Open Directory
>>
>> Use composer and take a snap shot of the modification and assign it
>> to smart groups with in casper, then deploy
>>
>> set it up as a self service policy and use the ~/ for that users  
>> plist
>>
>> set it in the (forgot the file path) configuration file that pushes
>> out new user settings every time a user is created
>>
>> What exactly are you trying to do?
>>
>> Thomas Larkin
>> TIS Department
>> KCKPS USD500
>> tlarki at kckps.org
>> cell:  913-449-7589
>> office:  913-627-0351
>>>>> Jeremy Matthews <jeremymatthews at mac.com> 08/20/08 10:49 AM >>>
>> I want to write defaults to a plist for a user that won't get horked.
>> Needs to be pre-created...
>>
>> Thanks,
>> jeremy
>>
>> On Aug 20, 2008, at 11:42 AM, Thomas Larkin wrote:
>>
>>> May I ask why you would want to do this?
>>>
>>> If you can script it, Casper can and will run it.  If we know your
>>> higher goal perhaps we can better answer your question.
>>>
>>> Thomas Larkin
>>> TIS Department
>>> KCKPS USD500
>>> tlarki at kckps.org
>>> cell:  913-449-7589
>>> office:  913-627-0351
>>>>>> Jeremy Matthews <jeremymatthews at mac.com> 08/20/08 10:35 AM >>>
>>> Casper can run scripts against your box, but it does so as a root
>>> user
>>> - what if I want to run the script as a different user, such as the
>>> one who is logged in - without prompting for a password (like su-)?
>>>
>>> Thanks,
>>> j
>>> _______________________________________________
>>> Casper mailing list
>>> Casper at list.jamfsoftware.com
>>> http://list.jamfsoftware.com/mailman/listinfo/casper
>>>
>>
>>
>
>