Home › Forums › OS X Server and Client Discussion › Open Directory › Is it possible to force refresh MCX settings?
- This topic has 6 replies, 4 voices, and was last updated 15 years, 7 months ago by
cashxx.
-
AuthorPosts
-
January 23, 2009 at 11:07 pm #375217
jdyck
ParticipantSo, I have thousands of laptops in the hands of students, all running Leopard and bound to AD and OD and doing the whole Golden Triangle thing. However, it’s almost completely wireless, and due to some earlier issues with 802.1x wireless authentication, we set the laptops so that they would not connect to wireless at the login window.
Now, however, it would be nice to push out MCX changes if, for example, we add a printer at a site, but because these don’t really login outside of cached folders, I’m not sure how to do this.
I have dug around a bit in the ManagedClient app, but so far haven’t found anything.
Basically, what I’m looking for is a way I can call (via launchd timed script,or pushed via ARD) some kind of ‘MCX Refresher” that would update the MCX settings of the cached Mobile User, to be applied at the next login.
Any ideas?
Thanks in advance,
Jeff
January 27, 2009 at 11:12 pm #375255jdyck
ParticipantJoel,
That sounds promising and I’m going to give it a try this week, but just wanted to clarify my understanding of how MCX gets refreshed…
My understanding has always been that it happens at login, which in my case, with the chances of a laptop being plugged in (Wireless is specifically disabled at loginwindow due to intermittant login to AD issues) being very very small, the laptops aren’t getting updates to the MCX settings…
As an example, we had a school that wanted to add a seperately purchased application for their students – easy enough to develop a proper installer for ARD installation, and to update the MCX settings, all remotely… But then we need to plug each of the laptops in and do a login cycle before we see the changes… And due to our intermittant AD issue, it seems like half the machines won’t work, requiring an unbind and rebind procedure. Since our Sites are scattered over 1000s of kms and this can mean having to fly a tech to a site it’s not very good.
But you just said something about MCX auto-refreshing and I’m wondering if perhaps I’m missing something? Is there another mechanism going on that perhaps I can tie into? Meanwhile, I am going to experiment with the commands given.
Thanks,
Jeff
January 28, 2009 at 5:34 pm #375264tlarkin
ParticipantAccording to the Apple white pages, my Apple SE, and every other doc I have read, MCX gets updated at log in/out and of course reboot. I have tested this a bit. A while back we had a local admin account that was compromised, and in return many mobile account users promoted them self to admin via system preferences. So, after a bit of fooling with the dscl command I found a way to remove them from the admin group, but to actually see what it did when they promoted them self I did some testing. MCX policy still trumped admin accounts even after log in/out and reboot until the local admin account authenticated, then it trumped MCX.
As far as I can tell, it updates itself in that manner but I am sure there are always tons of environmental factors.
February 12, 2009 at 1:53 am #375382tlarkin
ParticipantWell, in an unrelated event, I was doing some work in the dscl interactive command line and saw that the dscl command line in 10.5 now has MCX settings for commands. This could be scriptable, pushed out via ARD admin task server, or third party like Casper.
I actually did not know this was here until earlier this week….
[code]
> -mcxhelp
MCX Extensions:
-mcxread[optArgs] [ [ ]]
-mcxset[optArgs] [ [ ]]
-mcxedit[optArgs] [ ]
-mcxdelete[optArgs] [ [ ]]
-mcxexport[optArgs] [ [ ]]
-mcximport[optArgs]
-mcxhelpThe
specifies which record in the directory node is to be operated
on (i.e. ‘/Users/mcx1’). This parameter is always required, but if you are in
interactive mode, you can use ‘.’ to mean ‘current directory’ (the directory
that was last set using the ‘cd’ command).The
parameter is something like ‘com.apple.dock’ The
parameter is something like ’tilesize’ The
parameter is a path to a sub-plist within an existing key value.
For example ‘mount-controls:dvd:1’ means the 2nd element within the array with
the key name ‘dvd’ within the key called ‘mount-controls’The
is the type of management applied to the key. Legal values are:
‘none’ (not managed)
‘always’
‘once’
‘often’
‘unset’The
is the new value to be used for a key. This parameter can be
specified using the same syntax as used by the ‘defaults’ command line tool.
NOTE: When specifying plist or xml values, you will need to enclose the parameter
in single quotes. For example:
dscl … ‘(authenticate, eject)’
dscl … ‘64.0 ‘The MCX extensions follow the same syntax as other dscl comamnds and follow
the same authentication rules as dscl commands. They can be used in both
interactive and command-line modes (with exceptions noted below). For example:Local command-line example
————————–
$ dscl . mcxread /Users/mcxtest com.apple.dock tilesize
$ dscl -u admin -P apple . mcxset /Users/mcxtest com.apple.dock tilesize always -float 32Local interactive example
————————-
$ dscl
> cd /NetInfo/Users/mcxtest
> mcxread . com.apple.dock =
** for write-based commands you must first ‘cd’ to the appropriate node and then issue the ‘auth’ command **
> cd /NetInfo/Users/mcxtest
> auth admin apple
> mcxset . com.apple.dock tilesize always -float 32Remote command-line example
—————————
$ dscl -u diradmin -P apple 10.0.116.132 mcxread /LDAPv3/127.0.0.1/Users/phd1 = =NOTE: It’s not currently possible to use commands (e.g. ‘mcxset’) that require write access
to the node remotely due to Radar 4122565Remote interactive example
————————–
$ dscl -u diradmin -P apple 10.0.116.132
> mcxread /LDAPv3/127.0.0.1/Users/phd1 com.apple.SoftwareUpdate CatalogURL
** for write-based commands you must first ‘cd’ to the appropriate node and then issue the ‘auth’ command **
> cd /LDAPv3/127.0.0.1
> auth diradmin apple
> mcxset Users/phd1 com.apple.dock tilesize always -float 62.5mcxread
[optArgs] [ [ ]]
=========================================================
Used to display existing values for MCX preference key(s).[optArgs]
-v
Specifies which version of the key should be retrieved. If this
parameter is omitted, version 1 keys are searched for.-o
Specifies the output file where results should be written. If
this parameter is omitted, results are written to stdout.-format
Specifies how the output should be formatted. If omitted, the
default is ‘text’.
Specify the application domain you want to retrieve keys from. If
this parameter is omitted or is equal to ‘=’ then all application
domains will be dumped for the specified record.
Specify the name of the key you want to retrieve. If this
parameter is omitted or is equal to ‘=’ then all keys will be
displayed.Examples:
mcxread /Users/mcx1 com.apple.dock autohide
Displays the value of the ‘autohide’ key in the ‘com.apple.dock’ application domainmcxread /Users/mcx1 -format xml com.apple.dock =
Displays, in XML format, all the keys in the ‘com.apple.dock’ application domainmcxread . -format plist = =
Displays, in plist format, all keys for all application domains for the current recordmcxset
[optArgs] [ [ [ ]]]
=======================================================================================
Used to set values for a new or existing MCX preference key.[optArgs]
-v
Specifies the version of the key to set. If this parameter is omitted,
version 1 keys will be created.
Specify the application domain in which the key is to be set.
Specify the name of the key being set
Specify the type of management to be applied to the key. See above for
valid values. Additionally, if this parameter is missing or ‘.’ then
an existing key will be searched for and the existing management value
will not be changed. Setting management to ‘none’ is the same as deleting
the key (will remove management for that key in the specified record).
Specify the new value for the specified key. Values can be specified using
the same syntax as used by the ‘defaults’ command line tool. If the value
parameter is omitted, then the existing value for the key will not be updated.
The (optional) value for the Union Policy Key. If present, the UPK *must*
be specified as a dictionary. The valid keys for the dictionary include:
mcx_input_key_names (single string or array of strings)
mcx_output_key_name (single string)
mcx_remove_duplicates (boolean)
mcx_union_as_dictionary (boolean)
mcx_replace (boolean)
You can specify ‘input’ as a shorthand for ‘mcx_input_key_names’.
You can specify ‘output’ as a shorthand for ‘mcx_output_key_name’.
If either mcx_input_key_names or mcx_output_key_name is omitted, the value
ofwill be used for the missing value(s). Examples:
mcxset /Users/mcx1 com.apple.dock autohide always -bool 1
Sets the ‘autohide’ key in the com.apple.dock domain to a value of
TRUE with ‘always’ management.mcxset . com.apple.dock autohide once
Moves the ‘autohide’ key to ‘once’ management, preserving the existing
value of the key.mcxset . com.apple.dock autohide none
Removes management of the autohide key in com.apple.dock domain for
the current record.mcxset . com.apple.dock autohide . -bool 0
Sets the value of autohide to FALSE, preserving the existing management levelmcxset . com.apple.dock tilesize .
64.0
Sets the tilesize key to the floating point number 64.0Examples specifying UPKs:
mcxset . com.apple.test testkey-Raw always ‘(1,2,3)’ ‘{ input=testkey-Raw; output=testkey; mcx_remove_duplicates=1; mcx_replace=1; mcx_union_as_dictionary=0;}’
mcxset . com.apple.test testkey-Raw always ‘{ keya=a; keyb=b; keyc=c; }’ ‘{ output=testkey; mcx_union_as_dictionary=1;}’mcxedit
[optArgs] [ ]
==================================================================
Used to update the value of an existing MCX preference key.[optArgs]
-v
Specifies the version of the key to set. If this parameter is omitted,
version 1 keys will be edited.
Specify the application domain in which the key is to be set.
Specify the path to the EXISTING key to be edited.
Specify the new value for the specified key path. Values can be specified using
the same syntax as used by the ‘defaults’ command line tool. If the value
parameter is omitted, then the key path will be deleted.
NOTE: It is not permissable to delete an entire key using this command. To delete
an entire key, use ‘mcxset’ and specify a management domain of ‘none’.Examples:
mcxedit . com.apple.dock autohide -bool 1
Change the autohide key to TRUE, preserving current management settingmcxedit . com.apple.systemuiserver mount-controls:dvd ‘(authenticate, eject)’
Sets the ‘dvd’ key within the ‘mount-controls’ dictionary to the array
containing two strings: ‘authenticate’ and ‘eject’mcxedit . com.apple.systemuiserver mount-controls:dvd
authenticate eject
Same effect as previous example, just using xml syntaxmcxedit . com.apple.systemuiserver mount-controls:dvd:1 deny
Change the 2nd array element within the ‘dvd’ key of the ‘mount-controls’
dictionary to the string ‘deny’mcxedit . com.apple.systemuiserver mount-controls:dvd
Remove the ‘dvd’ key of the ‘mount-controls’ dictionarymcxdelete
[optArgs] [ [ ]]
===========================================================
Used to remove management of MCX preference key(s). This is equivalent to using
the mcxset command with a ‘mcxDomain’ value of ‘none’.[optArgs]
-v
Specifies the version of the key to delete. If this parameter is omitted,
version 1 keys will be deleted.
Specify the application domain in which the key is to be set. Omitting this
parameter, or specifying ‘=’ means all application domains will be processed.
Specify the name of the key to be deleted. Omitting this parameter, or
specifying ‘=’ means all keys in the application domain will be deleted.Examples:
mcxdelete . com.apple.dock autohide
No longer manage the ‘autohide’ Dock key.mcxdelete . com.apple.dock
Delete management of all Dock-related keys.mcxdelete .
Delete management of all keys for the current record.mcxexport
[optArgs] [ [ ]]
=========================================================
Same functionality as the ‘mcxread’ command but produces output in a format that
can later be imported using ‘mcximport’. Usually you will also want to specify
the -o optional argument to cause the output to be written to a file.Examples:
mcxexport . -o /tmp/export.plist com.apple.dockmcximport
[optArgs]
=============================================
Imports the keys/values previously exported using ‘mcxexport’. Each key/value in
the import file will be processed as if the data were passed to ‘mcxset’. This
means the data in the import file is added to the existing data in the record.[optArgs]
-d
Causes mcximport to delete any key found in the import file from the
record. This is equivalent to calling mcxdelete for every key in the
import file. The value of the key in the import file is ignored.
Specify the location of the file containing the data to be imported.Examples:
mcximport . /tmp/export.plist
mcximport . -d /tmp/export.plist—————
>
[/code]September 9, 2009 at 8:14 pm #377118cashxx
ParticipantSnow Leopard has a new feature called “mcxrefresh”. Should hopefully do what you want! man mcxrefresh in Terminal.app or look it up in the Server User Management Manual at about page 260.
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed