Home › Forums › OS X Server and Client Discussion › Questions and Answers › PackageMaker PostFlight
- This topic has 9 replies, 3 voices, and was last updated 15 years, 5 months ago by
tlarkin.
-
AuthorPosts
-
October 15, 2009 at 11:53 am #377346
jamesnp
ParticipantHi there,
I’m trying to make a fairly simple package, everythings working well except the postflight script. I know the postflight is running, but the commands do not seem to be having any effect. When I run the postflight script in the terminal it works as expected.
Does the installer use a sandbox?
The following is the script:
#!/usr/bin/php -q
I’ve used perl, bash, etc. all the shells I can think of and the result is the same.
Any ideas?
Cheers,
jpOctober 15, 2009 at 2:11 pm #377348tlarkin
ParticipantThis is a post script to configure an installed package? Can you drop a few more details? I think I can probably whip up a shell script that can do what you want. If the script runs as root (which is probably does) and if you need to modify user level preferences, you will need to either wild card the users (or use an expression), or have it pull up who is the current user.
October 15, 2009 at 3:01 pm #377349jamesnp
ParticipantYep. Basically it’s just an installer that drops two dictionary files into /System/Library/Spelling to add support for Irish Language spell checking.
Once the two files are installed, I run a script to configure system spelling settings as I don’t want the user to have to manually go into Language & Text -> Text and manually select Irish from the list. The above script deactivates the “Automatic by Language” setting, adds Gaeilge (ga_IE) to the NSPreferredSpellServers list and then sellects Gaeilge (ga-IE) as the language.
I used the echo ‘Current script owner: ‘ . get_current_user(); to see what user the script was running as, as I thought it may have been root, but it returned my username. That ended up confusing me even more! haha
The settings really only need to be applied for the current user.
Your help is really appreciated!
-jpOctober 15, 2009 at 3:53 pm #377350tlarkin
ParticipantI am the type of person, that if I can do it in BASH I do it in BASH and like to use native binaries.
So, this is what I would do in my environment. Take it for what you will, modify it if you wish, or disregard it since it may not be exactly what you are looking for.
[code]
#!/bin/bash#########
# post flight script for ________
#
# this will modify the current user’s preferences
#
########### Now we get the current logged in user
cur_user=`/bin/ls -l /dev/console | awk ‘/ / { print $3 }’`
# Assuming these are user prefs in ~/Library/Preferences…
/usr/bin/defaults write /Users/$cur_user/Library/Preferences/NSGlobalDomain NSSpellCheckerAutomaticallyIdentifiesLanguages -bool FALSE
/usr/bin/defaults write /Users/$cur_user/Library/Preferences/NSGlobalDomain NSPreferredSpellServers -array-add ‘( \”ga_IE\”, Open )
/usr/bin/defaults write /Users/$cur_user/Library/Preferences/NSGlobalDomain NSPreferredSpellServerLanguage ga_IE
/bin/echo “done writing preferences”
exit 0
[/code]There is another way you could loop through /Users and just write it globally to all user accounts on the system. I am not sure if this code will work exactly as advertised because I have no way of testing it. So you’ll need to test it out.
Let me know how it works.
October 15, 2009 at 4:28 pm #377351jamesnp
ParticipantCheers again for your help.
Unfortunately, it doesn’t seem to work. It places a new NSGlobalDomain.plist file in the user’s preferences folder, but that doesn’t seem to be the actual user’s NSGlobalDomain being used by the system.
I’ve done a little bit more digging and called ‘defaults read NSGlobalDomain’ from the actual installed. The installer log file then gave me the output of the NSGlobalDomain. It appears that the settings are being saved, but for a different user, I presume root.
Does NSGlobalDomain have an actual location where it saves itself for each different user? I presume so if it is non-volitile. Is there anyway to address a particular user with ‘defaults write’.
Again, many thanks for any help!
-jp
October 15, 2009 at 4:56 pm #377352tlarkin
ParticipantI read through the manual page and it seems that the defaults command always uses the current user. My script should instead use full paths of the current user, though it may be tricky.
Here go some other ways you can do this:
1) Configure it exactly how you want to under your account. Then mass copy that plist file out to all the client machines, into the user’s folder via ARD admin’s copy command.
2) Modify the user template, and whenever a new user logs in, they get that pref from the template. This only works on new users logging in, so existing users won’t get this.
3) Use some sort of snap shot based package maker, push it out that way
4) Look at getting better third party management tools
5) if you use Open Directory try to push it out via MCX.
There are plenty of options for you to do this. I have done this exact thing with the Casper Suite at my job (I manage about 8,000 Macs) for plist files that are user level specific.
Well to answer your question, if it is in /Library/Preferences then it is global (may also be in /Library/Application Support/), but if the plist file is in ~/Library/Preferences then it is user specific.
If it is user specific it may not actually create a plist until the app actually runs. most of them are created on the fly first time run. If that is the case I can modify the script to make sure it is there before we proceed.
October 15, 2009 at 6:40 pm #377353tlarkin
ParticipantNow, if that preference is only created on the fly when it is first ran, we can go ahead and create the file. Please edit my script if it is wrong.
[code]
#!/bin/bash#########
# post flight script for ________
#
# this will modify the current user’s preferences
#
########### Now we get the current logged in user
cur_user=`/bin/ls -l /dev/console | awk ‘/ / { print $3 }’`
# Assuming these are user prefs in ~/Library/Preferences…
# Now check if the file exists and if not, create it
# MAKE SURE that the correct file path is put here, below is just an examplefile=”/Users/$cur_user/Library/Preferences/com.NSGlobalDomain.plist”
# Now check to see if it exists
if [[ -e $file ]]
then /bin/echo “$file exists, proceeding”
else /usr/bin/touch $file
fi
# now write default setting to said file.
/usr/bin/defaults write /Users/$cur_user/Library/Preferences/NSGlobalDomain NSSpellCheckerAutomaticallyIdentifiesLanguages -bool FALSE
/usr/bin/defaults write /Users/$cur_user/Library/Preferences/NSGlobalDomain NSPreferredSpellServers -array-add ‘( \”ga_IE\”, Open )
/usr/bin/defaults write /Users/$cur_user/Library/Preferences/NSGlobalDomain NSPreferredSpellServerLanguage ga_IE
/bin/echo “done writing preferences”
exit 0
[/code]You will have to edit the names of the plists and test this.
October 16, 2009 at 4:06 pm #377359Greg Neagle
ParticipantSome bits of info:
1) The NSGlobalDomain data is currently stored in a file called .GlobalPreferences.plist (note the leading period). Each user can have one, and there’s a “global” .GlobalPreferences.plist in /Library/Preferences
2) The defaults command has a nasty habit of changing the owner of the file to the user running the command and the mode to 600. So if you modify a user’s file as root with the defaults command, you could cause it to be owned by root and mode 600, and now the user can’t read the file. So be careful when doing this sort of thing as root; you may need to chown/chmod afterwards.
3) Don’t hard-code paths like /Users/$var/Library/Preferences. Your users may not all have home dirs in /Users. A better way to modify the defaults for a given user:
sudo -u “$username” defaults write NSGlobalDomain NSSpellCheckerAutomaticallyIdentifiesLanguages -bool FALSE
So:
#!/bin/sh
# get the current logged in user
cur_user=`/bin/ls -l /dev/console | awk ‘/ / { print $3 }’`# modify user logged-in user’s defaults
sudo -u “$username” /usr/bin/defaults write NSGlobalDomain NSSpellCheckerAutomaticallyIdentifiesLanguages -bool FALSE
sudo -u “$username” /usr/bin/defaults write NSGlobalDomain NSPreferredSpellServers -array-add ‘( \”ga_IE\”, Open )’
sudo -u “$username” /usr/bin/defaults write NSGlobalDomain NSPreferredSpellServerLanguage ga_IENot sure about the quoting/escaping in the second defaults command; you may need to tweak it.
4) If this installer is run in an automated fashion, like via ARD, Casper, LANrev, or munki (as examples), there may be _no_ logged in user, and so it may not do what you expect. So you may want to provide a way for a user to configure these preferences for themselves later.
October 16, 2009 at 7:32 pm #377361jamesnp
ParticipantCheers for the information, gneagle. That’s exactly what I was looking for.
In the mean time I worked out my own work around. I compiled an applescript that runs the defaults command. This postflight.app is copied to /tmp/postflight.app, and the postflight script launches the applescript. The postflight then pauses 2 seconds and deletes the postflight.app from /tmp.
It’s a but rough and ready, but it does work. Is there any reason I shouldn’t use this method? Is applescript inherently insecure or should I be worried about this solution on any level.
I will never be deploying this script via remotedesktop, it’ll always be a local user installing. So, nothing to worry about there!
Cheers again guys,
jpOctober 19, 2009 at 4:19 pm #377370tlarkin
Participant[QUOTE][u]Quote by: gneagle[/u][p]Some bits of info:
1) The NSGlobalDomain data is currently stored in a file called .GlobalPreferences.plist (note the leading period). Each user can have one, and there’s a “global” .GlobalPreferences.plist in /Library/Preferences
2) The defaults command has a nasty habit of changing the owner of the file to the user running the command and the mode to 600. So if you modify a user’s file as root with the defaults command, you could cause it to be owned by root and mode 600, and now the user can’t read the file. So be careful when doing this sort of thing as root; you may need to chown/chmod afterwards.
3) Don’t hard-code paths like /Users/$var/Library/Preferences. Your users may not all have home dirs in /Users. A better way to modify the defaults for a given user:
sudo -u “$username” defaults write NSGlobalDomain NSSpellCheckerAutomaticallyIdentifiesLanguages -bool FALSE
So:
#!/bin/sh
# get the current logged in user
cur_user=`/bin/ls -l /dev/console | awk ‘/ / { print $3 }’`# modify user logged-in user’s defaults
sudo -u “$username” /usr/bin/defaults write NSGlobalDomain NSSpellCheckerAutomaticallyIdentifiesLanguages -bool FALSE
sudo -u “$username” /usr/bin/defaults write NSGlobalDomain NSPreferredSpellServers -array-add ‘( \”ga_IE\”, Open )’
sudo -u “$username” /usr/bin/defaults write NSGlobalDomain NSPreferredSpellServerLanguage ga_IENot sure about the quoting/escaping in the second defaults command; you may need to tweak it.
4) If this installer is run in an automated fashion, like via ARD, Casper, LANrev, or munki (as examples), there may be _no_ logged in user, and so it may not do what you expect. So you may want to provide a way for a user to configure these preferences for themselves later.
[/p][/QUOTE]Well then a better method would be something like this then perhaps, going by your input here for best practices.
[code]
#!/bin/bash#loop through /Users and execute a command
for i in /bin/ls /Users | grep -v “Shared” ; do
sudo -u “$i” /usr/bin/defaults write NSGlobalDomain NSSpellCheckerAutomaticallyIdentifiesLanguages -bool FALSE
sudo -u “$i” /usr/bin/defaults write NSGlobalDomain NSPreferredSpellServers -array-add ‘( \”ga_IE\”, Open )’
sudo -u “$i” /usr/bin/defaults write NSGlobalDomain NSPreferredSpellServerLanguage ga_IE/bin/echo “done”
exit 0
[/code] -
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed