/build/static/layout/Breadcrumb_cap_w.png

Issue pushing Shell Script to Mac

I am trying to push a small script to a test mac.  The script will make the current logged in user an admin of the Mac.  The script works when I pass the username over to the Mac.  But as soon as I try to use a variable to get the logged in current user, the script fails.

 

This works (the current username is user2)

dseditgroup -o edit -a user2 -u localadmin -P mm1007mm -t user admin

 

This fails with the following (using $USER to get the current logged in user)

dseditgroup -o edit -a $USER -u localadmin -P mm1007mm -t user admin

 

2014-04-22 10:03:46: Alert not enabled, moving to next phase....

2014-04-22 10:03:52: Sending script script.sh to client....

2014-04-22 10:03:57: Script sent

2014-04-22 10:03:57: Executing script....

2014-04-22 10:04:01: Error 64 received while executing script

 

Any help would be greatly appreciated.


1 Comment   [ + ] Show comment
  • Thanks for the info. When I run this from xcode, it works great, but when its pushed via Kace, I get the same error. - belliott@millennialmedia.com 10 years ago

Answers (3)

Answer Summary:
Posted by: AbhayR 10 years ago
Red Belt
0

Kace Agent runs under sudo context and unfortunately there is no $USER variable defined in it. Hence the error.

 

I would recommend using something like below command to get the active console user instead 

who | grep console | awk '{print $1}' 


Comments:
  • Thanks for the info. When I run this from xcode, it works great, but when its pushed via Kace, I get the same error. - See more at: http://www.itninja.com/question/issue-pushing-shell-script-to-mac#sthash.fv0FdUPi.dpuf - belliott@millennialmedia.com 10 years ago
    • When you run "who | grep console | awk '{print $1}' " you get the same error? - AbhayR 10 years ago
      • yes, it does return the user when I run it locally, but when I push it via Kace, I get the same error. But if I put the username in and remove the automated part, it works. - belliott@millennialmedia.com 10 years ago
      • This is what I have

        #!/bin/sh

        #  test.sh
        #  
        #
        #  Created by Brian Elliott on 4/21/14.
        #

        who | grep console | awk '{print $1}' 

        dseditgroup -o edit -a $1 -u localadmin -P mm1007mm -t user admin - belliott@millennialmedia.com 10 years ago
      • The first statement doesn't assign the username to $1 but rather it is telling awk to only print the first string passed to it (which happens to be the username). See AbhayR's answer for how to assign to a variable and then use the variable later in the script. - chucksteel 10 years ago
      • I tried that below and it still failed, but I got a different error this time

        Error 200 received while executing script

        Thanks for all the help! - belliott@millennialmedia.com 10 years ago
Posted by: AbhayR 10 years ago
Red Belt
0

I don't think you can use $1 like that as it is a awk variable.

Try this 

#!/bin/sh

#  test.sh
#  
#
#  Created by Brian Elliott on 4/21/14.
#

USER=`who | grep console | awk '{print $1}'`

dseditgroup -o edit -a $USER -u localadmin -P mm1007mm -t user admin

Comments:
  • The command I use to add a user to the admin group is a little different:
    dseditgroup -o edit -a $USER -t user admin

    Since I normally run this command as root there's no need to authenticate with the -u and -P flags. That might be causing part of the problem for belliott since KACE will run the script as root also. - chucksteel 10 years ago
Posted by: belliott@millennialmedia.com 10 years ago
Senior White Belt
0

I was able to get this working using the code that AbhayR gave me.  But Chucksteel was also correct. I did not need the -u or -P since it was running as root as well.  So now my code works and it optimized.  Thanks everyone.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

View more:

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ