Packaging mistake

Sean_M_Harper
Contributor

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?

1 ACCEPTED SOLUTION

mm2270
Legendary Contributor III

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

View solution in original post

10 REPLIES 10

jcurrin
New Contributor III

The way I would do it is create composer package that removes those files or just use sudo rm file/path/

rockpapergoat
Contributor III

stop using composer.

mm2270
Legendary Contributor III

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

donmontalvo
Esteemed Contributor III

@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

--
https://donmontalvo.com

donmontalvo
Esteemed Contributor III

(dupe)

--
https://donmontalvo.com

bentoms
Release Candidate Programs Tester

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.

Sean_M_Harper
Contributor

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

bentoms
Release Candidate Programs Tester

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?

donmontalvo
Esteemed Contributor III

@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>)

--
https://donmontalvo.com

Sean_M_Harper
Contributor

You win for the best big mac analogy. :)