Posted on 03-08-2013 03:38 PM
So if a package (in this case, for firefox) is made with composer, and not all data you want to be deleted is (in this case, saved login/password info for gmail and such). What is the fastest method to fix this issue?
And yes, I am only asking because the tech who pushed out the package checked fill existing user directories box. Otherwise I wouldn't care so much. Anyone have their hands on a quick script that scans the /Users/* directory of a machine and illuminates a certain file until its gone through all the folders?
Solved! Go to Solution.
Posted on 03-08-2013 09:17 PM
While I would agree Composer has its issues, it isn't going to help with the current situation to just stop using it.
That said, you do need to be careful with Composer's snapshot process. I almost never use it unless I really need to, and when I do I often go through the capture results with a fine tooth comb to be sure there is nothing in it I don't want. Especially remove any home directory stuff if you don't plan on using the FEU/FUT options.
As for your current dilemma, I assume this file/plist/whatever is in a known, consistent location? If so, here is the general syntax you can use in a search and destroy type script to find it and remove it in any local accounts. As always, there are several ways this can be accomplished and this is only one. Obviously, modify this to your needs and test it out before pushing, since you're deleting files. You don't want to make a bad situation worse by nuking the wrong stuff.
#!/bin/bash
targetFile="/relative/path/to/target" ## Exclude any home directories, just the path to the file from the account, i.e, /Library/Preferences/preference.plist
for user in $( dscl . list /Users UniqueID | awk '$2 > 500 {print $1}' ); do
userHome=$( dscl . read /Users/$user NFSHomeDirectory | awk '{print $NF}' )
if [ -e "$userHome$targetFile" ]; then
rm "$userHome$targetFile" ## use 'rm -R' if the target is a folder
echo "deleted $userHome$targetFile"
else
echo "Nothing found to delete for $user"
fi
done
Posted on 03-08-2013 04:04 PM
The way I would do it is create composer package that removes those files or just use sudo rm file/path/
Posted on 03-08-2013 04:25 PM
stop using composer.
Posted on 03-08-2013 09:17 PM
While I would agree Composer has its issues, it isn't going to help with the current situation to just stop using it.
That said, you do need to be careful with Composer's snapshot process. I almost never use it unless I really need to, and when I do I often go through the capture results with a fine tooth comb to be sure there is nothing in it I don't want. Especially remove any home directory stuff if you don't plan on using the FEU/FUT options.
As for your current dilemma, I assume this file/plist/whatever is in a known, consistent location? If so, here is the general syntax you can use in a search and destroy type script to find it and remove it in any local accounts. As always, there are several ways this can be accomplished and this is only one. Obviously, modify this to your needs and test it out before pushing, since you're deleting files. You don't want to make a bad situation worse by nuking the wrong stuff.
#!/bin/bash
targetFile="/relative/path/to/target" ## Exclude any home directories, just the path to the file from the account, i.e, /Library/Preferences/preference.plist
for user in $( dscl . list /Users UniqueID | awk '$2 > 500 {print $1}' ); do
userHome=$( dscl . read /Users/$user NFSHomeDirectory | awk '{print $NF}' )
if [ -e "$userHome$targetFile" ]; then
rm "$userHome$targetFile" ## use 'rm -R' if the target is a folder
echo "deleted $userHome$targetFile"
else
echo "Nothing found to delete for $user"
fi
done
Posted on 03-08-2013 09:20 PM
@rockpapergoat Amen brother...snapshots are dangerous. Have a look at Packages...free, awesome developer, and beats the other solutions (including Composer...sorry JAMF!).
http://s.sudre.free.fr/Software/Packages/about.html
The developer is very active on Installer-Dev:
https://lists.apple.com/mailman/listinfo/installer-dev
Posted on 03-08-2013 09:20 PM
(dupe)
Posted on 03-09-2013 12:48 AM
FEU/FUT's only works with DMG's.
So if this is a DMG... Index it then uninstall it via policy.
Open the DMG in composer & correct it, recreate the DMG , then redeploy.
Posted on 03-09-2013 09:11 AM
@bentoms:
The package is a DMG, and is indexed, but when I asked to uninstall via a policy it did not delete all the files in the user folders as "intended". Thank you all for the helpful answers.
@donmontalvo:
I am going to look at that packaging option, and may possibly shoot you a message with a question or two if you don't mind (should I run into any issue, seeing you are apparently using it now).
Posted on 03-09-2013 09:24 AM
Hi Sean,
No worries.
I'm guessing that additional files etc are created post install when the user runs whatever app it is.
Perhaps you could create a snapshot/package of these as a DMG & then uninstall that?
Posted on 03-09-2013 09:35 AM
@lucid772 Happy to help, but let'do it thorugh Apple's Installer-Dev list. That's the best place to post questions about tools, strategy, issues, etc. I wouldn't mention Composer on that list...that would be like mentioning Big Mac sandwiches at a culinary siminar.
(Sorry JAMF, if that sounded snarky...I really wish you guys would bundle/support Packages for PKG/MPKG format packages. It's an easy to use, is highly customizable, and follows Apple guidelines...<g>)
Posted on 03-10-2013 12:02 PM
You win for the best big mac analogy. :)