Posted on 08-19-2011 01:19 PM
Hey all,
I was curious as to what a recommended approach would be to getting rid of a single file in a firefox profile directory. The command to do what I'd like would be:
find /Volumes/Users/logname
/Library/'Application Support'/Firefox/*/* -name ".parentlock" -exec rm "{}" ;
I want to publish it out via self service; it works if I use that exact command on a workstation. However, looking at the logs, it tells me that the file or folder doesn't exist...and of course...they do.
I'm not much of a programmer, but am just using the execute command portion in the advanced section of the policy I've created for this. I've used a ton of variables and even made the script longer than it needed to be. What was a pain was that I need it ran as the specific user, and SS executes as root. I'm not sure if that's playing a role in all of this, but it's a simple command that I'm sure someone can hopefully shed some light on.
Thanks so much,
Brian
Posted on 08-22-2011 03:41 PM
The user that initiated the Self Service script should be passed as argument 3
(see http://www.jamfsoftware.com/kb/article.php?id=040). This is also the case
for Casper Remote, and policies when they are associated with a user (e.g. login
hooks). So, in short, you can probably just replace `logname` with "$3" and have
it work.
If you want your script to be more robust, you can additionally check which
user is running the script and which users are logged in. This can get trickier,
but it can allow your script to run standalone, in a tool associated with a
user, or in a tool not associated with a user at all (though that's a bit more
dangerous).
One other thing to note is your find command is searching recursively (that's
what find does) so if there happens to be a file called .parentlock inside an
extension or something (yes it's highly unlikely, but you never know), it will
be wiped out. I think you can do what you want with just
rm "/Volumes/Users/$3/Library/Application Support/Firefox/Profiles/*/.parentlock"
As always, test before using rm. You can replace "rm" with "ls" to see what
would get deleted or use "rm -i" to prompt before each deletion.
Good luck!
Posted on 08-23-2011 07:16 AM
Matt,
Thanks so much for your help on this. I have a few things to add if you
don't mind helping further, or if anyone has anything to offer for further
assistance.
I have tried the $3 variable as you have instructed but I get the exact
output shown below:
rm: /Volumes/Users/Staff//Library/Application
Support/Firefox/Profiles/*/.parentlock: No such file or directory.
I had read that using the $3 variable in Self Service has its issues if
you aren't using it as a login or logout process so I'm not sure if that's
why I'm seeing such things...Looking above, you'll notice that there's
just a double slash after "Staff" and it excludes the user's real login
name when using that variable. The line I added to the Advanced command
looks like this:
rm "/Volumes/Users/Staff/$3/Library/Application
Support/Firefox/Profiles/*/.parentlock"
Your other comments are quite helpful and I appreciate the response and
help so far. I'm still trying to find out what's what with getting a
setting that works correctly. I'll tell you this if it matters at all:
even if I add the name of the logged in user manually to this script
(because I'll pick a specific user to login as) it still tells me that the
directory cannot be found, or the file.
There's likely a few things going on...1 being that if I start listing my
Volumes, I cannot list my server for one reason or another. So if I do a
/Volumes/[tab] it Only shows my Macintosh HD drive and NOT my server
volume where my home folders reside. I can certainly access everything on
the server by manually going there but I simply can't list it under
/Volumes.
So alternatively, I look at doing something like this for a command:
rm "/$3/Library/Application Support/Firefox/Profiles/*/.parentlock"
Problem is, as soon as I do that, it still tells me that it can't find the
file or folder even if I paste it in the Terminal.
The $3 never replaces it with a username of the person logged in. It just
replaces it with a "//" instead. If I use `logname` then it displays the
correct path, yet it still says that it doesn't exist...so I end up using
the looooong format, like:
rm
"/Network/Servers/SERVERNAME/Volumes/Path/to/Users/Staff/logname
/Library/
Application Support/Firefox/Profiles/*/.parentlock"
That command works if I put it in a terminal command and execute it...but
as soon as I use the same statement inside of the advanced section it
always states that the file or path doesn't exist...when of course...it
does.
Any other ideas? I'm not sure if it consistently doesn't find the actual
folder on account of this being launched as a root of localadmin account
instead of the logged in user. Seeing as it works when I launch a
separate terminal window versus logging it via Self Service...it seems
like the issues has something to do with Self Service. Maybe I'm wrong,
but something is amiss. This single command seems more complex than it
should be, I'm sure. I just don't know where I'm going wrong with getting
this to work.
-----Edit-----
Well here's what I have added and what worked for me so far:
rm
/Network/Servers/MYSERVER/Volumes/Path/To/Users/Staff/logname
/Library/App
lication Support/Firefox/Profiles/*/.parentlock
Looks like removing the quotes worked a bit but I also still can't use the
$3 variable which is why I kept in the `logname` for the path there. It
just removes the name and adds the "//" and that's it :(
It's odd (maybe?) that I HAVE to use the looong server names and can't
just use /Volumes for a shortcut and I know I can't use ~ either. At any
rate, I'm going to see how this looks for the time being from a testing
standpoint and can report back any errors or issues. But so far, this is
working in my testing.
What I will likely still have to add in (maybe as a variable?) is how I
can do this for both staff and students that have different paths. Maybe
I can define path using some kind of logic here.
Thanks again,
Brian
Posted on 08-23-2011 07:31 AM
Sorry, this is just a repost since I didn't reply correctly. My apologies
I don't do much with Listserv's, honestlyŠjust wanted to make sure it
replied correctly to Matt's response.
-----
Matt,
Thanks so much for your help on this. I have a few things to add if you
don't mind helping further, or if anyone has anything to offer for further
assistance.
I have tried the $3 variable as you have instructed but I get the exact
output shown below:
rm: /Volumes/Users/Staff//Library/Application
Support/Firefox/Profiles/*/.parentlock: No such file or directory.
I had read that using the $3 variable in Self Service has its issues if
you aren't using it as a login or logout process so I'm not sure if that's
why I'm seeing such things...Looking above, you'll notice that there's
just a double slash after "Staff" and it excludes the user's real login
name when using that variable. The line I added to the Advanced command
looks like this:
rm "/Volumes/Users/Staff/$3/Library/Application
Support/Firefox/Profiles/*/.parentlock"
Your other comments are quite helpful and I appreciate the response and
help so far. I'm still trying to find out what's what with getting a
setting that works correctly. I'll tell you this if it matters at all:
even if I add the name of the logged in user manually to this script
(because I'll pick a specific user to login as) it still tells me that the
directory cannot be found, or the file.
There's likely a few things going on...1 being that if I start listing my
Volumes, I cannot list my server for one reason or another. So if I do a
/Volumes/[tab] it Only shows my Macintosh HD drive and NOT my server
volume where my home folders reside. I can certainly access everything on
the server by manually going there but I simply can't list it under
/Volumes.
So alternatively, I look at doing something like this for a command:
rm "/$3/Library/Application Support/Firefox/Profiles/*/.parentlock"
Problem is, as soon as I do that, it still tells me that it can't find the
file or folder even if I paste it in the Terminal.
The $3 never replaces it with a username of the person logged in. It just
replaces it with a "//" instead. If I use `logname` then it displays the
correct path, yet it still says that it doesn't exist...so I end up using
the looooong format, like:
rm
"/Network/Servers/SERVERNAME/Volumes/Path/to/Users/Staff/logname
/Library/
Application Support/Firefox/Profiles/*/.parentlock"
That command works if I put it in a terminal command and execute it...but
as soon as I use the same statement inside of the advanced section it
always states that the file or path doesn't exist...when of course...it
does.
Any other ideas? I'm not sure if it consistently doesn't find the actual
folder on account of this being launched as a root of localadmin account
instead of the logged in user. Seeing as it works when I launch a
separate terminal window versus logging it via Self Service...it seems
like the issues has something to do with Self Service. Maybe I'm wrong,
but something is amiss. This single command seems more complex than it
should be, I'm sure. I just don't know where I'm going wrong with getting
this to work.
-----Edit-----
Well here's what I have added and what worked for me so far:
rm
/Network/Servers/MYSERVER/Volumes/Path/To/Users/Staff/logname
/Library/App
lication Support/Firefox/Profiles/*/.parentlock
Looks like removing the quotes worked a bit but I also still can't use the
$3 variable which is why I kept in the `logname` for the path there. It
just removes the name and adds the "//" and that's it :(
It's odd (maybe?) that I HAVE to use the looong server names and can't
just use /Volumes for a shortcut and I know I can't use ~ either. At any
rate, I'm going to see how this looks for the time being from a testing
standpoint and can report back any errors or issues. But so far, this is
working in my testing.
What I will likely still have to add in (maybe as a variable?) is how I
can do this for both staff and students that have different paths. Maybe
I can define path using some kind of logic here.
Thanks again,
Brian