Posted on 08-20-2008 08:34 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
Posted on 08-20-2008 08:42 AM
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
Posted on 08-20-2008 08:48 AM
I want to write defaults to a plist for a user that won't get horked.
Needs to be pre-created...
Thanks,
jeremy
Posted on 08-20-2008 08:54 AM
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
Posted on 08-20-2008 09: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
Posted on 08-20-2008 10:04 AM
Is your OD binding problem solved with this tip?
http://support.apple.com/kb/TS1245
It's a common one when imaging 10.5, like the local SID in Windows if you have done MS imaging as well.
In fact if anyone from JAMF is on this list, this would be a great feature to add when a 10.5 machine is first imaged. The first thing a machine should do is change the local KDC hash so each one is unique per machine. It seems to me to be enough of a problem that the imaging tools should take care of it, not a custom script by us users.
Posted on 08-20-2008 10:13 AM
Criss,
We just got this working this morning...works pretty well - we're using a user-based LaunchAgent that runs on login.
We even have the script securely delete itself, as well as the LaunchAgent (writing defaults shouldn't take more than one time)....cool stuff!
Thanks,
jeremy
Posted on 08-20-2008 10:22 AM
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
Posted on 08-20-2008 10:24 AM
No - our issue occurs when you bind a machine, and it doesn't appear
in WGM.
It is one of our few remaining 10.5 server issues....of course 10.4.11
client/server works flawlessly.
-----
Is your OD binding problem solved with this tip?
http://support.apple.com/kb/TS1245
It's a common one when imaging 10.5, like the local SID in Windows if
you
have done MS imaging as well.
In fact if anyone from JAMF is on this list, this would be a great
feature
to add when a 10.5 machine is first imaged. The first thing a machine
should do is change the local KDC hash so each one is unique per
machine.
It seems to me to be enough of a problem that the imaging tools should
take care of it, not a custom script by us users.
Posted on 08-20-2008 10:27 AM
Add the line:
On Wed, Aug 20, 2008 at 1:22 PM, Jeremy Matthews <jeremymatthews at mac.com>wrote:
chown $i /Users/$i/Library/Preferences/com.panic.Transmit3.plist
before the "done" statement.
ta-daa! your users' plist now belongs to them.
Posted on 08-20-2008 10:31 AM
You know, the funny thing is that we tried that but our test machine wouldn't respect the command.
I'm guessing at this point that since the script has a lot more running inside of it, it needs further dissasembly....something must be silently failing or changing it back. I know at one point we had a pseudo-security daemon that looked for new files, and would change them in whatever way that consultant saw fit (before my time).
But, we have re-run ownership (standalone) and it does fix the issue. I think the set of setup scripts we "inherited" may need....further study.
Thanks,
j
Posted on 08-20-2008 10:31 AM
Well, what about this
#!/bin/sh
#write settings to plist
/usr/sbin/defaults wite /Users/*/Library/Preferences/com.panic.Transmit3 SerialNumber 333-333-333-333
#now set ownership and permission
/bin/chmod -777 /path/to/plist
#now set ownership
/usr/sbin/chown -R user:group /path/to/plist
For your OD issues I have a script that works for 10.4.11 and 10.5 and I use it in my environment to unbind and rebind servers in OD.
Yeah my website sucks, I am learning CMS so go easy, and yes that was a shameless plug
Thomas Larkin
TIS Department
KCKPS USD500
tlarki at kckps.org
cell: 913-449-7589
office: 913-627-0351
Posted on 08-20-2008 10:34 AM
Right, when you try to bind, it thinks all your machines are the same because they all have the same local KDC hash. The first one will bind and nothing else will.
Posted on 08-20-2008 10:36 AM
Yep - we have similar scripts and those work...I think something in the master_setup script is destroyed, and I'll have to check on the whole security daemon...it looks for and attempts to disable and files that are created within 1 minute of login (excepting LoginHooks and LaunchAgents).....weird, I know....
The problem isn't binding macs to OD - its that the 10.5 Server cannot
"see" them - nothing shows up in its list of computers.
At. All.
That is, except itself "$www.myserver.com"
If anyone has insight there....I'm open.
-j
Posted on 08-20-2008 10:39 AM
For a while I had a long post-imaging script that took care of things like
On 8/20/08 12:31 PM, "Jeremy Matthews" <jeremymatthews at mac.com> wrote:
network settings, antivirus updates, etc., then I adopted the modular
approach even with my scripts. Now I have several smaller scripts but
they're easier to maintain this way and I can apply them as part of the
imaging process or run them individually to correct minor problems.
If you've got one script doing several unrelated things then consider this
approach.
--
bill
William M. Smith, Technical Analyst
MCS IT
Merrill Communications, LLC
(651) 632-1492
Posted on 08-20-2008 10:40 AM
OD doesn't discover computers. You need to create the records in the
directory (using Workgroup Manager, typically) in order for them to appear
in Workgroup Manager.
Were the computer records created in OD, and now they're missing?
Posted on 08-20-2008 10:42 AM
Er....lemme back up.
We would bind a mac to OD, and then it would show up in WGM under computers. This is the way its worked since about 10.3 - works fine in 10.4. We don't create computer records - OD does that for us during the binding process.
No computer records evident...
Thanks,
j
Posted on 08-20-2008 10:42 AM
Absolutely.
Think of and approach scripts just like packaging. A big script requires a
lot of work to update and is more prone to problems. Small scripts, even
containing a single command, are easy to write, troubleshoot & update.
Posted on 08-20-2008 10:52 AM
Perhaps its procedural baggage, but I've always created the computer record
in WGM before binding the client via Directory Access/Directory Utility.
Posted on 08-20-2008 11:45 AM
Since these scripts are being run in the root context you should be able to run commands with su without being prompted. The trick is that you will not be able to just run 'su $user' and then list the commands after that, you will have to run 'su $user -c "command to run"' for every command you need to run. We currently do this with several scripts that we run, including one that chown's files (for roving profiles) just like you are trying to do. For us, the script would look like this:
for i in $( ls /Users )
do
su $i -c "defaults write /Users/$i/Library/Preferences/
com.panic.Transmit3 SerialNumber 333-333-333-333"
done
Like I said, we do similar things and, as long as we are running individual commands with the -c parameter, it works fine with no promts. Note that this is only the case if you are running this as root, an administrator account will not be able to su without prompts.
Hope it helps.
Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu
Posted on 08-20-2008 04:03 PM
Chris - I replied to the whole list, your message just made it to me.
I asked our Apple SE the same thing, he didn't know off the top of his head and we haven't tested it in house yet.
MS doesn't assume each domain machine has a local KDC and in Windows you don't, it uses a Windows domain SID to uniquely identify each machine on the domain. This SID is generated when you join the domain (but the local SID is used for other things, which can cause other problems when there are duplicates). I imagine the issue does not impact AD for that reason and you still have to reset the local KDC if it is bound to AD if you want OD to work as well. OD assumes the local KDC is a good identifier for a system and uses it. This is solid thinking unless you are mass deploying an image after that local KDC has been seeded, then they all appear to be the same machine in OD.
Again this is just a guess based on experience, but I have not tested yet.
Chris Lang <Chris.Lang at vu.edu.au> 08/20/08 06:48 PM
To
<r.wessen at neu.edu>
cc
Subject
Re: [Casper] run script as different user?
Hi All,
Just off topic would this OD issue also affect imaged machines bound to and AD domain that is using Kerberos?
I assume looking that the logic behind it it would can anyone confirm.
Regards,
Chris
Posted on 04-26-2019 11:23 AM
Stale thread - I needed to run a command as the logged in user from Self Service.
Thanks to tips here:
https://www.jamf.com/jamf-nation/discussions/2743/run-script-as-logged-in-user-not-as-root
https://www.jamf.com/jamf-nation/discussions/18627/running-a-script-as-a-login-user
I ended up using syntax below in a script called by users as a Self Service item:
sudo -u $3 -i /path/to/binary --parameter $3 --destination /Users/$3/Desktop/$3 --verbose
Posted on 11-06-2019 06:55 PM
This seems to work, for determining if current user has the box checked, if not check it for the user.
EA
#!/bin/bash
currentUser=$( python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");' )
currentSetting=$( sudo -u "$currentUser" defaults read NSGlobalDomain AppleShowAllExtensions 2>/dev/null )
if [[ "$currentSetting" -eq "1" ]]; then
echo "<result>PASS</result>"
else
echo "<result>FAIL</result>"
fi
exit 0
SCRIPT
#!/bin/bash
CURRENTUSER=$( python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");' )
sudo -u "$CURRENTUSER" defaults write NSGlobalDomain AppleShowAllExtensions -bool true
sudo -u "$CURRENTUSER" killall Finder
exit 0