Login scripts

[#1]

Hi All.

I just have a quick question about login triggers and running a script. Our goal is to allow all users to manage print queues. We currently use MCX and a group added to the lpadmin group. That works...most of the time. Instead - for a more robust solution and one that works off out network - I want to start running a simple script at login that adds the user logging in to the lpadmin group.

The bulk of the script is this:
dseditgroup -o edit -n /Local/Default -a $user -t user $group

Our JSS is not visible outside of our production network, but for various reasons I can't control, the JSS has a public DNS record. I don't want to cause significant delays when they aren't on the network and it's checking for policies at login. Is there anything that I can do/should be aware of? I think last time I looked at this, there could be a 2 minute delay at times. I think if I just created a policy with "Make Available Offline" I should be OK correct?

Thanks for the advice!
Aaron

[tlarkin]

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

[rockpapergoat]

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.

[#4]

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

[#5]

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...

[#6]

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.

[#7]

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

---------

[tlarkin]

$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

[#9]

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?

[sean]

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

[tlarkin]

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