- When my IP address changes, Samba stops responding.
- Restart Samba every time my IP address changes.
- Better Solution:
- Use configd to restart Samba automatically when my IP address changes.
This worked at one point. I haven't verified this on Panther. Also, since Jaguar, Mac OS X has had support for Samba built in which kind of makes this discussion obsolete. I mostly keep this around for the kicker and configd banter./p>
I started noticing this problem when I began moving my laptop between networks at home and work. Initially, I would just use the Samba Sharing control panel to stop and then start the smbd and nmbd daemons. Unfortunately this is somewhat cumbersome and really isn't necessary. After a few weeks of poking around on and off, I have found a better solution.
This only works with version SambaX v2.2.2. The newest release from the Xamba project does not work with the method that I am about to describe. However, you can always roll back to the previous version. I assume at this point that you have installed SambaX and SSCT, and that you have at least one working configuration.
configd is a daemon that I believe is unique to Darwin-based systems. Its purpose is to provide configuration information dynamically to applications and other daemons. Essentially it is a local server that exports information stored using the SystemConfiguration framework. Here is a brief list of exported data:
- Location (reflected in the system-wide Location menu)
- IP address
- Computer Name
- and much, much more...
- The SystemConfiguration.framework itself, which is part of CoreFoundation. This allows an application to interact directly with configd, but requires code modifications. This is a good choice if you've got time on your hands and want to make your application very robust. However, it is Darwin-specific, and thus not readily available on other systems like Linux, or other BSD distrobutions.
- scutil is command line interface to configd. It seems mostly for debugging purposes, but it can be used to extract basic information from configd in a rudimentary fashion.
- /var/db/SystemConfiguration/preferences.xml is the persistant store for SystemConfiguration data. I wouldn't interact directly with (as in, make changes to) this file, but it can be handy to peruse if you are looking for a specific piece of data.
The Kicker is essentially a narrow bridge between the information available from the SystemConfiguration and the wonderful world of command line tools. The interesting files reside in /System/Library/SystemConfiguration/Kicker.bundle/Resources. The most important file is Kicker.xml, which essentially ties SystemConfiguration events to executing a particular shell script.
Kicker.xml is basically an array of dictionaries. 1 Each dictionary supports a number of keys, each of which are required, as far as I can tell:
- name (string) - a convienient name for this entry, not sure where this is used
- keys (array of strings) - SystemConfiguration keys with trigger command execution
- execUID (integer) - uid that the shell script will execute as (0 is root)
- execCommand (string) - absolute path to a binary to execute, this can contain the special value $BUNDLE, which usually resolves to /System/Library/SystemConfiguration/Kicker.bundle
changedKeysAsArguments (boolean) - if
, then the key or keys which trigger the command execution will be passed as arguments
This is a small script to control the Samba daemons via the command line. It has been written to accept arguments from either the Kicker or the command line directly. The two keys we are interested in are:
The second one informs us that someone, most likely the user, has altered the system location, most likely via the Location option in the System menu or the Network System Preferences. In this case, the shell script extracts the name of the selected location and attempts to find a Samba configuration with a matching name. If a match is found, it switches the active configuration and restarts the daemons.
Installing the Files
The only file you need to modify, Kicker.xml, is stored within /System/Library/SystemConfiguration/Kicker.bundle/Resources/
Simply edit the Kicker.xml file, (sudo vi Kicker.xml) and place your control script in a well defined location.
The shell variable $BUNDLE resolves to /System/Library/SystemConfiguration/Kicker.bundle and can be used to simplify the path to your shell script, if you store it within the Kicker bundle.
Once you have made the changes, you can issue the following command to reset configd and reload the kicker.
kill -HUP `cat /var/run/configd.pid`
- While I am glad that Apple has decided to use xml for some of its configuration files, I have to say that at the same time, they seemed to have missed the point a bit. Their xml files, or plist, are highly suited to mapping back into CoreFoundation objects, like arrays, dictionaries and strings. However, one of the goals of xml is to make files more human readable. Apple has made steps in the right direction - at least we are beyond binary preferences in resource forks, however, I personally would have been inclined to use an even more human readable format, supplying a DTD and an XSL to convert from human-readable to more machine friendly. Obviously, this is just an opinion, and it has limitations as well.