Home Forums OS X Server and Client Discussion Questions and Answers PackageMaker PostFlight

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #377346
    jamesnp
    Participant

    Hi 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,
    jp

    #377348
    tlarkin
    Participant

    This 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.

    #377349
    jamesnp
    Participant

    Yep. 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!
    -jp

    #377350
    tlarkin
    Participant

    I 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.

    #377351
    jamesnp
    Participant

    Cheers 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

    #377352
    tlarkin
    Participant

    I 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.

    #377353
    tlarkin
    Participant

    Now, 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 example

    file=”/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.

    #377359
    Greg Neagle
    Participant

    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_IE

    Not 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.

    #377361
    jamesnp
    Participant

    Cheers 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,
    jp

    #377370
    tlarkin
    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_IE

    Not 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]

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.

Comments are closed