Topic
  • 7 replies
  • Latest Post - ‏2014-06-16T13:35:28Z by JMadill
JMadill
JMadill
4 Posts

Pinned topic Anyone able to edit com.bigfix.BESAgent.plist?

‏2014-06-10T14:53:21Z |

Has anyone been able to successfully edit the com.bigfix.BESAgent.plist file?

I am attempting to edit the file to change a custom "owner" field that was initially created via the console as Master Operator, but once I start the BESAgent back up, the changes are immediately replaced by the original information.  The purpose of this is to allow non Master Console Operators (Local IT Support Personnel) to be able to reassign ownership of Macs so the computers are visible to them in the console for managing.

 

Here are the sequence of commands I have been using.

  • sudo launchctl unload /Library/LaunchDaemons/BESAgentDaemon.plist
  • ps -ef | grep BESAgent
  • sudo /usr/libexec/PlistBuddy -c 'Delete :Settings:Client:Owner' /Library/Preferences/com.bigfix.BESAgent.plist
  • sudo /usr/libexec/PlistBuddy -c "Add :Settings:Client:Owner:Date date Tue Jun 10 08:54:04 EDT 2014" /Library/Preferences/com.bigfix.BESAgent.plist
  • sudo /usr/libexec/PlistBuddy -c "Add :Settings:Client:Owner:Value string fubar" /Library/Preferences/com.bigfix.BESAgent.plist
  • sudo launchctl load /Library/LaunchDaemons/BESAgentDaemon.plist
Everything is pointing to the BESAgent, or some child process not actually/completely stopping.

If I disable the LaunchDaemon process and reboot the Mac, I can then successfully use the above commands to change the owner field.  Having the Local IT Support run a script, reboot the workstation, then run a second script should be unnecessary.  A single script should be able to perform the action.

 

I have also manually killed the BESClientUI.app and then the BESAgent processes with extreme prejudice ( -9 ) before making the .plist file changes, but that didn't work either.

 

  • jgstew
    jgstew
    52 Posts

    Re: Anyone able to edit com.bigfix.BESAgent.plist?

    ‏2014-06-11T23:14:29Z  

     

    I don't understand why you would do this. Why wouldn't you just assign the computer to the user using a group?

     

  • JMadill
    JMadill
    4 Posts

    Re: Anyone able to edit com.bigfix.BESAgent.plist?

    ‏2014-06-12T12:39:55Z  
    • jgstew
    • ‏2014-06-11T23:14:29Z

     

    I don't understand why you would do this. Why wouldn't you just assign the computer to the user using a group?

     

    I am not sure what you mean when you say "assign the computer to the user using a group".  If you mean "End user" when you say "user", this is not for that purpose.  If you mean "Local IT Support" when you say "user" then, yes, we are on the same page.

     

    Perhaps explaining our IT Support model might help.  We have a distributed administration model here.  We have only a few Master Console operators, basically the administrators of the IEM server environment.  We have over 100 regular Console Operators.  These are all Local IT Support personnel, distributed in various departments around our institution.  Each Local IT Support person has their own set of computers that they are responsible for maintaining, either individually, or with other Local IT Support personnel in their group.

    Windows machines are easily added into IEM Computer groups dynamically, based on the OU they are located in within Active Directory.  Local IT Support personnel have the ability to add computers to their own OUs, which would then become manageable within the IEM console by that Local IT Support.

     

    Macintoshes and other Unix machines are not placed within Active Directory.  As such, they are unable to be automatically made members of a particular dynamic IEM computer group.  They need to be added in another way.  The solution we have come up with is to have a property defined within IEM on the client computer, that IEM can read.  This property is named "Owner" (Summary field of the computer, under the "Client Settings" section).  The value of this property is then used to by the IEM server to dynamically place the computer into the appropriate computer group.

     

    One way of creating this custom property is through the console by manually adding the custom property to the "Client Settings" section.  However, in order to do so, one must be a Master Operator, because these computers have not yet been assigned to a group.  Only Master Console Operators are able to create custom property fields.

     

    So, the solution we came up with is to have a script that Local IT Support personnel can run on the client computer that will set this property in its IEM preferences file for the Mac this file is com.bigfix.BESAgent.plist.  The problem is that once the BESAgent process is running on the client Mac, it does not seem to be able to be completely shut down.  There is either some part of it remaining running, or an unknown associated process that will undo any editing manually performed to the .plist file when the launchctl load/unload command is manually performed.

     

    This post was to see if anyone has been able to figure out how to successfully edit the com.bigfix.BESAgent.plist file.

     

    I do have a work around, but it is considerably more complex.  My script performs the following actions:

    • Disables the automatic running of the BESAgent process at computer startup.
    • Creates a second script to perform the edits to com.bigfix.BESAgent.plist at the next computer startup.
    • Sets this second script to be run at startup.
    • Restarts the Mac.

    The second script performs the following:

    • Runs at computer startup, (as root).
    • Edit the settings in com.bigfix.BESAgent.plist.
    • Reenable automatic running of the BESAgent process at startup.
    • Manually starts up the BESAgent process.
    • Disables the running of itself at startup.

     

  • jgstew
    jgstew
    52 Posts

    Re: Anyone able to edit com.bigfix.BESAgent.plist?

    ‏2014-06-12T16:41:47Z  
    • JMadill
    • ‏2014-06-12T12:39:55Z

    I am not sure what you mean when you say "assign the computer to the user using a group".  If you mean "End user" when you say "user", this is not for that purpose.  If you mean "Local IT Support" when you say "user" then, yes, we are on the same page.

     

    Perhaps explaining our IT Support model might help.  We have a distributed administration model here.  We have only a few Master Console operators, basically the administrators of the IEM server environment.  We have over 100 regular Console Operators.  These are all Local IT Support personnel, distributed in various departments around our institution.  Each Local IT Support person has their own set of computers that they are responsible for maintaining, either individually, or with other Local IT Support personnel in their group.

    Windows machines are easily added into IEM Computer groups dynamically, based on the OU they are located in within Active Directory.  Local IT Support personnel have the ability to add computers to their own OUs, which would then become manageable within the IEM console by that Local IT Support.

     

    Macintoshes and other Unix machines are not placed within Active Directory.  As such, they are unable to be automatically made members of a particular dynamic IEM computer group.  They need to be added in another way.  The solution we have come up with is to have a property defined within IEM on the client computer, that IEM can read.  This property is named "Owner" (Summary field of the computer, under the "Client Settings" section).  The value of this property is then used to by the IEM server to dynamically place the computer into the appropriate computer group.

     

    One way of creating this custom property is through the console by manually adding the custom property to the "Client Settings" section.  However, in order to do so, one must be a Master Operator, because these computers have not yet been assigned to a group.  Only Master Console Operators are able to create custom property fields.

     

    So, the solution we came up with is to have a script that Local IT Support personnel can run on the client computer that will set this property in its IEM preferences file for the Mac this file is com.bigfix.BESAgent.plist.  The problem is that once the BESAgent process is running on the client Mac, it does not seem to be able to be completely shut down.  There is either some part of it remaining running, or an unknown associated process that will undo any editing manually performed to the .plist file when the launchctl load/unload command is manually performed.

     

    This post was to see if anyone has been able to figure out how to successfully edit the com.bigfix.BESAgent.plist file.

     

    I do have a work around, but it is considerably more complex.  My script performs the following actions:

    • Disables the automatic running of the BESAgent process at computer startup.
    • Creates a second script to perform the edits to com.bigfix.BESAgent.plist at the next computer startup.
    • Sets this second script to be run at startup.
    • Restarts the Mac.

    The second script performs the following:

    • Runs at computer startup, (as root).
    • Edit the settings in com.bigfix.BESAgent.plist.
    • Reenable automatic running of the BESAgent process at startup.
    • Manually starts up the BESAgent process.
    • Disables the running of itself at startup.

     

     

    I would recommend against the approach you are trying to take. It is a bad idea to try to assign a computer to a specific user in general. Also editing the "com.bigfix.BESAgent.plist" directly is not a good idea and completely unnecessary to do what you are trying to do. You would be better off using an arbitrary plist or file to store this information, and then an open action that would see this info and add it to the setting or property or both automatically.

     

    We are definitely talking about the same issue. We have over 300 console operators and only 4 Master Operators.

     

    We call the "OU"s in the context of BigFix/IEM "Divisions" since they are not exactly equivalent to AD. We have over 300 Divisions and Subdivisions.

     

    We assign computers to Divisions and then Divisions to Users. Some users will get assigned the same divisions as another user, while in other cases a user may have a different mix of divisions as another from the same IT group.

     

    We do not use active directory to accomplish this at all. We do not have a single AD within our organization, so AD wasn't even an option for our windows machines. We do it the same way for all machines regardless of operating system.

     

    We do it by placing a file in the root directory of the BES Client on each system. We use the file name as the "tag" to determine which computers belong to which "Division", but you could also use the file's contents or some other similar method. We use the file extension "id", but you could use one like "division" or "besgroup" or "tag"... it really depends on what you want, as long as it is consistent. You could have the file name match or be similar to the "Division" or group name, but this causes a problem if the name of the Division itself changes over time, and also opens it up to tampering more easily. In our case we use a randomly generated but unique GUID that gets assigned to each "Division". We then have automatic groups for each Division which have relevance that looks for the specific GUID assigned to that division in a property. We then have an open action that places that GUID from the file in a client setting, which then gets picked up by the property if and only if there is exactly 1 GUID file on the client. These automatic groups are what gets assigned to a user in the "Computer Assignments" in the console. Computers missing the file or having more than one go into an "orphaned" group.

     

     The GUID file is provided to the IT groups so that after they install the BES Client, they can place this file in the same directory as the client and automatically add the computer to the Division. Each group only has access to the file that they should have access to. To make it easier we also provide an MSI and PKG that places the file in the correct location automatically that can be installed along side the client.

     

    It turns out that having TONS of automatic groups in addition to those created by console operators like we have is a bad idea for performance reasons. We could use the property to assign computer rights to a user instead of the automatic group. We haven't switched to this approach, but it is something we are considering.

     

  • JMadill
    JMadill
    4 Posts

    Re: Anyone able to edit com.bigfix.BESAgent.plist?

    ‏2014-06-12T17:07:06Z  
    • jgstew
    • ‏2014-06-12T16:41:47Z

     

    I would recommend against the approach you are trying to take. It is a bad idea to try to assign a computer to a specific user in general. Also editing the "com.bigfix.BESAgent.plist" directly is not a good idea and completely unnecessary to do what you are trying to do. You would be better off using an arbitrary plist or file to store this information, and then an open action that would see this info and add it to the setting or property or both automatically.

     

    We are definitely talking about the same issue. We have over 300 console operators and only 4 Master Operators.

     

    We call the "OU"s in the context of BigFix/IEM "Divisions" since they are not exactly equivalent to AD. We have over 300 Divisions and Subdivisions.

     

    We assign computers to Divisions and then Divisions to Users. Some users will get assigned the same divisions as another user, while in other cases a user may have a different mix of divisions as another from the same IT group.

     

    We do not use active directory to accomplish this at all. We do not have a single AD within our organization, so AD wasn't even an option for our windows machines. We do it the same way for all machines regardless of operating system.

     

    We do it by placing a file in the root directory of the BES Client on each system. We use the file name as the "tag" to determine which computers belong to which "Division", but you could also use the file's contents or some other similar method. We use the file extension "id", but you could use one like "division" or "besgroup" or "tag"... it really depends on what you want, as long as it is consistent. You could have the file name match or be similar to the "Division" or group name, but this causes a problem if the name of the Division itself changes over time, and also opens it up to tampering more easily. In our case we use a randomly generated but unique GUID that gets assigned to each "Division". We then have automatic groups for each Division which have relevance that looks for the specific GUID assigned to that division in a property. We then have an open action that places that GUID from the file in a client setting, which then gets picked up by the property if and only if there is exactly 1 GUID file on the client. These automatic groups are what gets assigned to a user in the "Computer Assignments" in the console. Computers missing the file or having more than one go into an "orphaned" group.

     

     The GUID file is provided to the IT groups so that after they install the BES Client, they can place this file in the same directory as the client and automatically add the computer to the Division. Each group only has access to the file that they should have access to. To make it easier we also provide an MSI and PKG that places the file in the correct location automatically that can be installed along side the client.

     

    It turns out that having TONS of automatic groups in addition to those created by console operators like we have is a bad idea for performance reasons. We could use the property to assign computer rights to a user instead of the automatic group. We haven't switched to this approach, but it is something we are considering.

     

    We are not assigning these computers to specific operators, the relevance statement for the automatic computer groups contains something like:

     

    OR (exists true whose (if true then (exists (value of setting "Owner" of client) whose (it as string as lowercase contains "CLINENG" as lowercase)) else false))

     

    It is this computer group that the particular console operators are given rights to see.

     

     

    We had also considered using a file external to IEM for identifying the group the computer should belong to.  This file would be read, the computer's recording IEM updated, and then the file deleted from the computer to break the relevance for the task to identify computers.  This, however does not all for identifying the group by looking at the computer's contents.  Keeping the file would require a more complicated relevance process.

     

  • jgstew
    jgstew
    52 Posts

    Re: Anyone able to edit com.bigfix.BESAgent.plist?

    ‏2014-06-12T17:48:13Z  
    • JMadill
    • ‏2014-06-12T17:07:06Z

    We are not assigning these computers to specific operators, the relevance statement for the automatic computer groups contains something like:

     

    OR (exists true whose (if true then (exists (value of setting "Owner" of client) whose (it as string as lowercase contains "CLINENG" as lowercase)) else false))

     

    It is this computer group that the particular console operators are given rights to see.

     

     

    We had also considered using a file external to IEM for identifying the group the computer should belong to.  This file would be read, the computer's recording IEM updated, and then the file deleted from the computer to break the relevance for the task to identify computers.  This, however does not all for identifying the group by looking at the computer's contents.  Keeping the file would require a more complicated relevance process.

     

     

    What you are doing makes more sense now that I understand it better.

     

    I don't think keeping the file is more complicated, but I suppose you wouldn't have to either. 

    If the file exists and the setting does not, then set the setting. If the file does not exist and the setting does, then either leave the setting alone or clear it depending on what you'd prefer. If the setting exists and it does not agree with the file, then update the setting.

    This can all be accomplished with 1 open action and relevance. 

     

  • amelgares
    amelgares
    1 Post

    Re: Anyone able to edit com.bigfix.BESAgent.plist?

    ‏2014-06-12T21:12:36Z  

    The OS X CFPreferences API starting in 10.8 caches and overwrites manual changes to preferences plists.  Use the "defaults" command in your script to change the BESAgent plist files instead of plistbuddy.

     

  • JMadill
    JMadill
    4 Posts

    Re: Anyone able to edit com.bigfix.BESAgent.plist?

    ‏2014-06-16T13:35:28Z  
    • amelgares
    • ‏2014-06-12T21:12:36Z

    The OS X CFPreferences API starting in 10.8 caches and overwrites manual changes to preferences plists.  Use the "defaults" command in your script to change the BESAgent plist files instead of plistbuddy.

     

    That is interesting information to know and would explain the resetting of information.  However, I don't think that the defaults command can create key entries in a hierarchical structure.  I have not been able to find a way to do so, to add the custom property in the correct location.