Run job when network configuration changes
Dear all, I would like to support Jeremy Reichman's request, because I apparently have similar needs. I have used the Kicker.xml technique to make automatic backups of my laptop. However, this laptop connects to various networks, and should backup only when connected to the ones where enough bandwidth is available. Moreover, one of such networks uses a 802.1x authentication, and I can backup only when authenticated. In that case, I go from a wired- non-authenticated connection to a wired-authenticated connection, and I need to launch the backup script after authentication. Thanks, Louis
At 23:29 +0100 22/11/07, Louis Granboulan wrote:
I would like to support Jeremy Reichman's request, because I apparently have similar needs.
Cool. Please file a bug describing what you want to achieve: <http://developer.apple.com/bugreporter/> It may not be easy (or possible) to do what you want (because of layering constraints within the system) but, once we have an official bug report, we'll have a reason to investigate this properly. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
On 11/26/07 4:47 AM, "Quinn" <eskimo1@apple.com> wrote:
At 23:29 +0100 22/11/07, Louis Granboulan wrote:
I would like to support Jeremy Reichman's request, because I apparently have similar needs.
Cool. Please file a bug describing what you want to achieve:
<http://developer.apple.com/bugreporter/>
It may not be easy (or possible) to do what you want (because of layering constraints within the system) but, once we have an official bug report, we'll have a reason to investigate this properly.
S+E
If I haven't filed one myself, I will be doing so. And I think I have one other person from the MacEnterprise set who will, as well. -- Jeremy
On Dec 4, 2007, at 7:26 PM, Jeremy Reichman wrote:
If I haven't filed one myself, I will be doing so. And I think I have one other person from the MacEnterprise set who will, as well.
Since using an ip-up script has been known to destroy VPN connectivity (4873060) this would be a useful feature indeed.
On 12/4/07 10:47 PM, "Nathan Duran" <launchd@khiltd.com> wrote:
On Dec 4, 2007, at 7:26 PM, Jeremy Reichman wrote:
If I haven't filed one myself, I will be doing so. And I think I have one other person from the MacEnterprise set who will, as well.
Since using an ip-up script has been known to destroy VPN connectivity (4873060) this would be a useful feature indeed.
Since Kicker.xml seems to be no more, it would potentially be useful to have launchd jobs be able to fire for almost any arbitrary SystemConfiguration change. I'm sure there is a possibility of using that for evil, so I'd want to guard against that as much as possible. Using launchd for this would also make the configuration much more granular for sys admins: just drop your script and your launchd plist onto the target computer in a launchd directory, and your job is all set to go when loaded. Compare that to editing Kicker.xml in Tiger, which was a Apple-supplied file in the System domain ... -- Jeremy
On Dec 4, 2007, at 8:01 PM, Jeremy Reichman wrote:
it would potentially be useful to have launchd jobs be able to fire for almost any arbitrary SystemConfiguration change
Well since you *can* register for almost any arbitrary SC change, it wouldn't take much to whip something up that would invoke launchctl on your behalf without any direct support from Apple, though that would mean running yet another process (or two if it needed admin privileges). I can't remember if I tried doing this or not at this point, but it seems like it should work.
On Dec 4, 2007, at 8:46 PM, Nathan Duran wrote:
On Dec 4, 2007, at 8:01 PM, Jeremy Reichman wrote:
it would potentially be useful to have launchd jobs be able to fire for almost any arbitrary SystemConfiguration change
Well since you *can* register for almost any arbitrary SC change, it wouldn't take much to whip something up that would invoke launchctl on your behalf without any direct support from Apple, though that would mean running yet another process (or two if it needed admin privileges). I can't remember if I tried doing this or not at this point, but it seems like it should work.
This is probably the most pragmatic solution for deployment on Leopard. - Kevin
On Dec 4, 2007, at 8:01 PM, Jeremy Reichman wrote:
On 12/4/07 10:47 PM, "Nathan Duran" <launchd@khiltd.com> wrote:
On Dec 4, 2007, at 7:26 PM, Jeremy Reichman wrote:
If I haven't filed one myself, I will be doing so. And I think I have one other person from the MacEnterprise set who will, as well.
Since using an ip-up script has been known to destroy VPN connectivity (4873060) this would be a useful feature indeed.
Since Kicker.xml seems to be no more, it would potentially be useful to have launchd jobs be able to fire for almost any arbitrary SystemConfiguration change. I'm sure there is a possibility of using that for evil, so I'd want to guard against that as much as possible.
Using launchd for this would also make the configuration much more granular for sys admins: just drop your script and your launchd plist onto the target computer in a launchd directory, and your job is all set to go when loaded. Compare that to editing Kicker.xml in Tiger, which was a Apple- supplied file in the System domain ...
I agree this would be a very useful feature, but there are subtleties that complicate the implementation of what seems like a straightforward idea (for example, Launchd cannot be a direct client of SystemConfiguration without fear of deadlock as SystemConfiguration talks to the launchd-managed daemon configd). Nevertheless, we are exploring ways to broaden the set of events that can be specified in a launchd plist. - Kevin
On 12/5/07 4:02 AM, "Kevin Van Vechten" <kvv@apple.com> wrote:
I agree this would be a very useful feature, but there are subtleties that complicate the implementation of what seems like a straightforward idea (for example, Launchd cannot be a direct client of SystemConfiguration without fear of deadlock as SystemConfiguration talks to the launchd-managed daemon configd). Nevertheless, we are exploring ways to broaden the set of events that can be specified in a launchd plist.
I would be just as happy if there were a file that was consistently and reliably modified during network changes, so that the WatchPaths key could be used. I'm not aware of such a file and past discussions about this on the MacEnterprise list haven't turned one up (to my recollection), but that doesn't mean it doesn't exist. -- Jeremy
On Dec 5, 2007, at 7:04 AM, Jeremy Reichman wrote:
On 12/5/07 4:02 AM, "Kevin Van Vechten" <kvv@apple.com> wrote:
I agree this would be a very useful feature, but there are subtleties that complicate the implementation of what seems like a straightforward idea (for example, Launchd cannot be a direct client of SystemConfiguration without fear of deadlock as SystemConfiguration talks to the launchd-managed daemon configd). Nevertheless, we are exploring ways to broaden the set of events that can be specified in a launchd plist.
I would be just as happy if there were a file that was consistently and reliably modified during network changes, so that the WatchPaths key could be used. I'm not aware of such a file and past discussions about this on the MacEnterprise list haven't turned one up (to my recollection), but that doesn't mean it doesn't exist.
The problem is that "network changed" is vague. It means different things to different people. Does it include updates to the list of DNS servers? Does it include updates to the DNS database? What about when the default route changes? What about if any route is added or deleted? What about when interfaces go on and offline? What about when interfaces are added or removed? What about when the computer switches between wireless base stations? What about when the computer updates the IP address(es) assigned to an interface? Does network change notification include explicit testing for the presence or absence of a given node? Does it include updates to proxy configuration details? Does it include updates to the list of LDAP servers the machine is using? Does it include updates to the list of Kerberos servers being used? What about when the ARP table updates? One can easily make "slippery-slope" arguments towards the "network change" notification firing continuously… As a consequence of both real and contrived examples, we frequently advise that developers write a program to use the System Configuration framework to directly narrow down the criteria that they are specifically interested in. *shrug* davez
On Dec 5, 2007, at 10:04 AM, Jeremy Reichman wrote:
I would be just as happy if there were a file that was consistently and reliably modified during network changes, so that the WatchPaths key could be used. I'm not aware of such a file and past discussions about this on the MacEnterprise list haven't turned one up (to my recollection), but that doesn't mean it doesn't exist.
How about /Library/Preferences/SystemConfiguration/preferences.plist ? -- Edward R. Marczak e: marczak@radiotope.com w: http://www.radiotope.com b: http://www.radiotope.com/writing
At 1:57 -0500 6/12/07, Edward R. Marczak wrote:
How about /Library/Preferences/SystemConfiguration/preferences.plist
That changes when the network /preferences/ change, not when the network state changes. For example, if someone plugs or unplugs the Ethernet, this file won't change. What /does/ change is the System Configuration framework "dynamic store". However, I don't know of any good way to hook into the dynamic store from a script. OTOH, it's trivial to do this from C code. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
On 12/6/07 4:23 AM, "Quinn" <eskimo1@apple.com> wrote:
At 1:57 -0500 6/12/07, Edward R. Marczak wrote:
How about /Library/Preferences/SystemConfiguration/preferences.plist
That changes when the network /preferences/ change, not when the network state changes. For example, if someone plugs or unplugs the Ethernet, this file won't change.
What /does/ change is the System Configuration framework "dynamic store". However, I don't know of any good way to hook into the dynamic store from a script. OTOH, it's trivial to do this from C code.
I believe this was more or less the gist, minus the C code bit, of this topic on the MacEnterprise list. We couldn't find a file that always worked, so Kicker.xml (despite being in the System domain) seemed the option closest to the action. But, being in the System domain in Tiger, there was reluctance to edit it, and being gone in Leopard makes it a moot point. What about a future launchd that could monitor for changes to SystemConfiguration? What if I could supply a dictionary of paths/keys (i.e. "State:/Network/Global/IPv4" which I can see when I use "list" with scutil) I care about, and if any of them are modified, the job fires? It seems like this could also let me tap into other events I care about, like maybe even wake/sleep. Nathan said, "Well since you *can* register for almost any arbitrary SC change ... [snip]," so I'm just hoping launchd can register for me and I can edit a plist become a developer. I'm just trying to lower the bar to make this possible. I may be clearly flailing here, but I'm still curious. And I'll be filing my requests if I haven't done already so. :) -- Jeremy
On Dec 6, 2007, at 6:17 AM, Jeremy Reichman wrote:
What about a future launchd that could monitor for changes to SystemConfiguration?
As has already been stated, doing so would introduce cyclical dependencies and potential deadlock conditions whereby launchd and SC were both waiting for the other to do something neither one ever would. Your computer would cease working at that point. It just isn't going to happen without some coding.
On Dec 6, 2007, at 4:23 AM, Quinn wrote:
At 1:57 -0500 6/12/07, Edward R. Marczak wrote:
How about /Library/Preferences/SystemConfiguration/preferences.plist
That changes when the network /preferences/ change, not when the network state changes. For example, if someone plugs or unplugs the Ethernet, this file won't change.
Got it. I was basing this on Airport on/off which, in some situations is good enough for me. That updates preferences.plist and can fire a script. Thanks. -- Edward R. Marczak e: marczak@radiotope.com w: http://www.radiotope.com b: http://www.radiotope.com/writing
Le 5 déc. 07 à 16:04, Jeremy Reichman a écrit :
I would be just as happy if there were a file that was consistently and reliably modified during network changes, so that the WatchPaths key could be used. I'm not aware of such a file and past discussions about this on the MacEnterprise list haven't turned one up (to my recollection), but that doesn't mean it doesn't exist.
Maybe /private/var/run/resolv.conf (which is also /var/run/ resolv.conf and /etc/resolv.conf) By the way, has anyone a comprehensive reference on how name resolving is parameterized in MacOSX? For example, who changes the resolv.conf file, and who uses it? Louis
Le 26 nov. 07 à 10:47, Quinn a écrit :
At 23:29 +0100 22/11/07, Louis Granboulan wrote:
I would like to support Jeremy Reichman's request, because I apparently have similar needs.
Cool. Please file a bug describing what you want to achieve:
<http://developer.apple.com/bugreporter/>
It may not be easy (or possible) to do what you want (because of layering constraints within the system) but, once we have an official bug report, we'll have a reason to investigate this properly.
S+E -- Quinn "The Eskimo!" <http://www.apple.com/ developer/> Apple Developer Relations, Developer Technical Support, Core OS/ Hardware
Here is the answer I received:
In practice, the number of event sources a "StartOnNetwork" feature would entail is so large that we recommend developers to write a program and use the System Configuration framework to directly monitor the multitude of network status changes.
We consider this issue closed. Thank you for taking the time to notify us of this issue.
Therefore, I might need some help to write that program which monitors the network status changes... Regards, Louis
participants (8)
-
Dave Zarzycki
-
Edward R. Marczak
-
Jeremy Reichman
-
Kevin Van Vechten
-
Louis Granboulan
-
Louis Granboulan
-
Nathan Duran
-
Quinn