Flushing User Caches

Gene,

What you can do is have a policy set for log in via JSS web front end and have it execute the script. Can you post your script? I assume removing the temp and cache files the application will create new ones upon next launch, and they are stored in that user's home directory. So you can wild card or loop it for user's that are located in /Users and exclude shared if need be.

Thanks,

"Thomas Larkin" <tlarki at kckps.org> writes: What you can do is have a policy set for log in via JSS web front end and have it execute the script. Can you post your script?

rm -Rf ~/Library/Caches/Safari/*

I assume removing the temp and cache files the application will create new ones upon next launch, and they are stored in that user's home directory.

yes. I'm mostly interested in the Safari cache.

So you can wild card or loop it for user's that are located in /Users and exclude shared if need be.

Casper policy is set to execute on login, frequency ongoing, scope for all desired machines, and the script is specified in the Scripts tab.

Do I have to specify any of the extra paramter options?

Gene Anderson
Systems Analyst, ACTC, MCP
Pembina Hills Regional Division No.7
Phone: (780) 674-8535 ext 6860
email: ganderson at phrd.ab.ca

"Passwords are like bubble gum, strongest when fresh, should never be
used by groups and create a sticky mess when left laying around"

-anon

I see two problems with your script...

1. I don't believe "~" will work in your script since it's run by root. I use the Casper variables to indicate "the home folder of the account logged in (or being logged in). See my commands below.
2. If your clients are Leopard clients, you won't find anything at ~/Library/Caches/Safari/. See below for the locations to be concerned with.

If you want to emulate the "Reset Safari" menu item put this in your script
instead:

m -Rf /Users/$3/Library/Cookies/*
m -Rf /Users/$3/Library/Safari/*
rm -Rf /Users/$3/Library/Caches/Metadata/Safari/*
rm -f /Users/$3/Library/Preferences/com.apple.Safari.plist
rm -f /Users/$3/Library/Preferences/com.apple.Safari.RSS.plist

You will, of course, need to reset any preferences you did want in there
such as a default home page. You can do this with "defaults write" or
"PlistBuddy" at the end of your script.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

Yeah, the tidal can be a weird thing when it comes to syntax which I
have found out the hard way. You can create a variable and that seems
to do it.

I would write the script like this personally:

#!/bin/sh

#go through user's home folder and get rid of cache files

home=~
file=" $home/Library/Cookies/* $home/Library/Safari/* $home/Library/Caches/Metadata/Safari/* $home/Library/Preferences/com.apple.Safari.plist $home/Library/Preferences/com.apple.Safari.RSS.plist "

for file in $file

do

if [[ -e $file ]]

then

rm -rf $file

else 0

echo "no file found"

done
exit

Of course I haven't quite tested it and you may need to tweak it, but
that is a quick and non tested version of what I would attempt at
doing.

Forgot to mention, this is written as a log in hook, so the it will pull
the current user's home directory. If you run it otherwise it won't
work as it will look for root's home since it will be running most
likely as root.

When you run a script via a Casper policy, $3 = the user's shortname. This
is why I structure my commands to target /Users/$3/
This may be a matter of preference, but I would skip the $file variable and
the for loop in this case. We're operating on known values. To me, at
least, it seems unnecessary to declare $file and then set up a for/if
structure when we can just operate on each item and save lines.

The script below accomplishes the goal with just a few lines and is set up
to be run as part of a Casper policy triggered by login.

## Start script
#!/bin/bash

m -Rf /Users/$3/Library/Cookies/*
m -Rf /Users/$3/Library/Safari/*
rm -Rf /Users/$3/Library/Caches/Metadata/Safari/*
rm -f /Users/$3/Library/Preferences/com.apple.Safari.plist
rm -f /Users/$3/Library/Preferences/com.apple.Safari.RSS.plist

## End script

I save "for" loops for situations where you need to discover the item to act
upon, i.e.
for i in $( dscl . -read /Groups/admin| grep GroupMembership:| awk '{for (j=3;
j<=NF; j++) printf " %s", $j; printf " " }' )
to get a list of all members of the admin group, other than root.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

I just like using loops because I can change the rm -rf command to ls
-al for testing purposes and I don't have to rewrite a bunch of lines of
code, and I can use a large list of file paths. That way nothing is
harmed. Also, when working in home directories users can change things
around, so sometimes I use if and the touch command so if they rename
the file, then I create it, if the file exists then I delete it.

I have had users rename files for only god knows why in their home
directory. Luckily none of my users by default have terminal access.

Your method works out fine as well, it is purely a preference thing. I
sometimes also like to add a bit of chatting to my scripts so logs tell
me what they do, also a preference.

Miles Leacy <miles.leacy at themacadmin.com> writes: When you run a script via a Casper policy, $3 = the user's shortname. This is why I structure my commands to target /Users/$3/ This may be a matter of preference, but I would skip the $file variable and the for loop in this case. We're operating on known values. To me, at least, it seems unnecessary to declare $file and then set up a for/if structure when we can just operate on each item and save lines. The script below accomplishes the goal with just a few lines and is set up to be run as part of a Casper policy triggered by login.

Okay, I must be missing something here because I can't get this to work. Script is:

rm -Rf /Users/$3/Library/Caches/*

being executed on Tiger clients. Policy is set to execute on all Tiger workstations, trigger on login and frequency ongoing. The policy reports no errors. Should this command work from the Terminal? How does the $3 value in the script get assigned? If I manually execute the script from the Terminal the full path comes back as "/Users//Library/Caches". Does Casper somehow fill in the value for the script?

Gene Anderson
Systems Analyst, ACTC, MCP
Pembina Hills Regional Division No.7
Phone: (780) 674-8535 ext 6860
email: ganderson at phrd.ab.ca

"Passwords are like bubble gum, strongest when fresh, should never be
used by groups and create a sticky mess when left laying around"

-anon

Hi,

Could you not just redirect the cache folder to the local HD on login and then delete at logout,

i use WGM to redirect the Cache and fonts folder on login from a network Home folder, to /tmp/ they then get deleted at logout,

A login hook could do the same,

Criss

Criss Myers
Senior Customer Support Analyst (Mac Services)
Apple Certified Technical Coordinator v10.5
LIS Business Support Team
Library 301
University of Central Lancashire
Preston PR1 2HE
Ex 5054
01772 895054

I believe for $3 and login policies in general to work, you need to check
"Create Login/Logout Hooks", "Log IP/Username with Login/Logout Hooks" and
"Check for Policies with Login/Logout Hooks" in Management Preferences,
which is found in the Management tab.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

or Use iHook

I use iHook rather than using Casper for login hooks

Criss

Criss Myers
Senior Customer Support Analyst (Mac Services)
Apple Certified Technical Coordinator v10.5
LIS Business Support Team
Library 301
University of Central Lancashire
Preston PR1 2HE
Ex 5054
01772 895054

not sure about for Casper but for normal login hooks to work you need to
activate login hook for the root loginwindow.plist

Criss Myers
Senior Customer Support Analyst (Mac Services)
Apple Certified Technical Coordinator v10.5
LIS Business Support Team
Library 301
University of Central Lancashire
Preston PR1 2HE
Ex 5054
01772 895054

For Casper...I just check the box in the management preferences and it just works...

Craig E

On 1/22/09 7:14 AM, "Criss Myers" <cmyers at uclan.ac.uk> wrote:

not sure about for Casper but for normal login hooks to work you need to activate login hook for the root loginwindow.plist

Criss Myers

Senior Customer Support Analyst (Mac Services)

Apple Certified Technical Coordinator v10.5

LIS Business Support Team

Library 301

University of Central Lancashire

Preston PR1 2HE

Ex 5054

01772 895054

I've used iHook in the past (back when I was a Radmind admin), but it's been
a while and I don't recall off hand how to properly write scripts for it.
I gave up Radmind and iHook because with Casper I get a commercial product
with support, and an interface that I can teach to and document for
inexperienced techs rather easily.

I'd suggest dropping, or at least starting the slow, testing-heavy process
of moving from iHook to scripting through Casper policies. An iHook script
will only ever be a login script. A script, once it's in your JSS, can be
deployed via nearly any policy you can think up, or as an ad-hoc action
through Casper Remote.

Of course, the best solution is the one that works for you, so please don't
think I'm telling you you're doing anything wrong. I'm just offering my
point of view and the benefit of my experience.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

ihooks are just bash scripts that have extension .hook and placed in the
hooks folder in /etc, with login hooks filename beginning with LI and
logout hooks LO, e.g LIFonts.hook , LOFonts.hook. All LI files are run
at login and all LO at logout one after the other, each can have custom
pictures or branding and each can display an output via echo so a user
can see the progress and state of the hook, this also helps for testing,
the size of the window can also be altered.

You can have as many login and logout hooks as you like, i keep mine
modular so i have a separate hook for each command so i can easily
remove or update by deploying new hooks via Casper.

For example I have a login hook that resets the Audio settings for the
audio hardware thats connected to a particular machine, its called
LIAudio.hook and has our company branding on it, it displays via echo
what is happening informing the user that is it copying the new
settings, i can then use this output to check that the hook is running
properly.

I also have a logout hook that displays a custom picture remind the user
to remove their USB drivers when they logout, it doesn't run any command
just changes to this picture and when done the other scripts run their
own picture.

Personally as my system was setup before Casper and i already had
working login and logout hooks which i can customize with my own company
branding i preferred to keep them rather than moving to Casper. I prefer
the flexibility that ihook offers to display feedback to the user as
well as custom pictures per hook.

I can deploy a new login hook by creating a package for it and deploying
it via Casper, if i need to remove it i can unistall it with Capser or
amend and deploy an updated version.

Personally I find this offers me what i want, BUT i have never used
Capser login hooks so do not know what feedback and display the output
for the user.

I also use ihook for running shell scripts that the user can execute
themselves without need terminal and give a graphical feedback.

For example i have a script which moves the contents of a backup folder
to the users home folder, which they can run themselves to recover data,
The double click and it opens the script via iHook with a custom picture
telling them whats happening and again feedback via echo.

Hope this all makes sense

Criss

Criss Myers
Senior Customer Support Analyst (Mac Services)
Apple Certified Technical Coordinator v10.5
LIS Business Support Team
Library 301
University of Central Lancashire
Preston PR1 2HE
Ex 5054
01772 895054

It makes sense, it's just a different way of doing things than I use.

If you want to accomplish the same things using Casper, you can...

display messages to the end user by using osascript. There is an example in
the Resource Kit. You can display your own icons in a dialog box using an
applescript via osascript.
deploy or remove a login item by creating/deleting/enabling/disabling a
policy.

let users run shell scripts or items that would normally require admin
authentication via Casper's Self Service app. The Self Service app runs a
policy, so you could include osascript dialog box(es) in your policy if you
want to give user feedback.
----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

Thanks to everyone for their input on this issue. I think I have enough information to figure out what I'm going to do next -> which is contact JamF support. Once I used local user accounts for testing everyone's wonderful suggestions, everything worked as expected using Casper policies. However as soon as I took a working machine and used an ActiveDirectory network account with contains a space in the name, then nothing works.

I had contacted and confirmed a issue with JamF regarding adding Dock icons using Casper policies and we discovered that ActiveDirectory user accounts which contain spaces in the user's names breaks the policy and yields random results. I think this is related to the same issue in that all the scripting breaks with users who have spaces in their short names.

Thanks for your help everyone.

Gene Anderson
Systems Analyst, ACTC, MCP
Pembina Hills Regional Division No.7
Phone: (780) 674-8535 ext 6860
email: ganderson at phrd.ab.ca

"Passwords are like bubble gum, strongest when fresh, should never be
used by groups and create a sticky mess when left laying around"

-anon