view · edit · print · history

SambaX

This file was originally located at http://culater.net/software/SambaX/SambaX.php, but the website is no longer available. I found a Google cache.

 SambaX

 Problem:
     When my IP address changes, Samba stops responding. 
 Solution:
     Restart Samba every time my IP address changes.
 Better Solution:
     Use configd to restart Samba automatically when my IP address changes.

 Note

 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>

 Background

 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.

 Disclaimer

 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

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

 There are several ways to access this information:

    1. 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.
    2. 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.
    3. /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.

 configd has a farily simple plugin architecture which uses bundles to provide additional
 functionality. There are a number of bundles installed with Mac OS X - the most useful, for
 my purposes, is the Kicker.bundle.

 Kicker

 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.bundl
     * changedKeysAsArguments (boolean) - if , then the key or keys which trigger the command
       execution will be passed as arguments

 samba.sh

 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: 

     * State:/Network/Global/IPv4
     * Setup:/

 A notification on the key State:/Network/Global/IPv4 indicates that the primary IP address
 for the machine has changed. The shell script reacts by terminating all running instances of
 smbd and nmbd, and then restarting them as root.

 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` 

 Footnotes

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

 ©2002-2004 Mike Solomon
Nixes changes · ALL changes
Page last modified on April 09, 2005, at 01:45 PM