Login scripts

Yes, you are on the right track. Upload your script, create the policy, set the trigger for log in and then make available offline. This will cache the script locally and it will run even if it cannot hit the JSS.

One caveat though is that login hooks run as root, so you cannot use the $user variable. You must use another detection method to see who is the current user. I usually test for ownership of /dev/console

ls -l /dev/console | awk '{ print $3 }'

should do the trick

Tom

Or you could use a launch agent that runs as the user on login.

It may be easier to edit /etc/cupsd.conf to allow all staff access to print queues.

Some tips are here: http://themacadmin.com/?p=63

If you did it that way, you wouldn't have to run any login scripts, etc. regularly.

Running as the user means you can't make the needed change...

Unfrotunately console trick doesn't return the logging in user. That's what I initially tried. Perhaps because the user has not actually logged in completely yet? I even tried a "sleep 30" before getting console's owner and sure enough, it just waits 30 seconds before logging in the user with the same bad results for the console owner variable. Fortunately $3 does work and teh script seems to run just fine (IE it adds them to the lpadmin group), so no problems.

Easy so far. I'll have to test it on a laptop now...

As I mentioned the secret sauce is $3 to return the correct user. The script runs as a priv. user through casper so nothing else is needed.

Here you go. Like I said, I tested this (I added a bunch more logger lines
to check each line) and the $3 returned the correct user. I'm sure some
people would add some sort of log that the script would check and exit if it
has already run for that user, but I ran the script many times on an account
and didn't see anything adverse. After running the script, you can check to
see if the user has been added to the group.

dseditgroup -o read -n /Local/Default -t lpadmin

Pay attention to the users that follow dsAttrTypeStandard:GroupMembership

Hopefully this helps. This list has been very helpful to me!

---------
#!/bin/sh

# unlockprinters.sh
#
#
# Created by Aaron Robinson on 5/11/11.

# Get variables. $3 is logging in user.
user=$3
group='lpadmin'

# Exit if user is root
if [ $user = "root" ]; then
logger -i "No logged in users. Exiting."
exit 0
fi

# Add the logged in user to the lpadmin group.
dseditgroup -o edit -n /Local/Default -a $user -t user $group
logger -i "$0: Added user $user to printer group $group"

exit 0

---------

$3 only returns the current user if Casper is running the script as a login policy. Otherwise, if you port it to self service or use it with out a login policy then $3 won't return anything. That is why I use the console ownership detection so I can use the same script in self service or push it out as a policy.

It also works for me, so not sure why it won't work for you.

bash-3.2# ls -l /dev/console | awk '{ print $3 }' tlarkin

I'm not sure what I am doing differently. I logged 2 variables out to the system log to test.

consoleuser=ls -l /dev/console |awk '{print $3}'
user=$3

logger -i "Console is $consoleuser"
logger -i "Variable 3 is $user"

Now logging in as the Active Directory user "test", I get this in the system log:
May 12 08:24:11 2536-mp _mdnsresponder[53462]: Console is root
May 12 08:24:11 2536-mp _mdnsresponder[53463]: variable 3 is test

So it appears that console is still owned by root when that variable is set and would therefore not add the correct user to the lpadmin group. If I ran the script differently, the it does work fine, but as a login-trigger, it seems to not work. What's different between you and me?

Whilst a Mac is at the login screen, the only user running is root, so running /dev/console will return 'root'. This will only change, once a user has logged in. Thanks to the asynchronous way that Macs boot and login, the script will almost certainly run early in the login process, prior to the user actually being logged in and hence returns root.

/dev/console is arguably a better way to return a user, since it will always be correct, even with fast user switching. The problem here is successfully running the script so that it will return the user that is logging in at that point in time. However, jamf have supplied a way to do this for you with the $3 option.

I agree with Thomas that you don't want to be having different scripts depending on how the script is running. I can only guess that Thomas isn't using user detection at login or is forking to another script. An alternative way to get around this would be to include an 'if' statement.

Something like:

consoleuser= `ls -l /dev/console |awk '{print $3}'`

if [ "$consoleuser" == "root" ]
then

$consoleuser=$3

fi

Sean

Further more, if you have the login window run the script (which is the Apple way) I believe $1 will return the current user. I don't use a lot of login hooks that involve user stuff. I typically deploy user stuff as user agents if I need to do something as a user.

I also self service some of those things.

-Tom