To begin, setup a chart that graphs the desired data in a typical manner before adding in the running average.  The following graph command creates a somewhat typical visualization of the last day’s network traffic as illustrated by the following graph:

rrdtool graph example.png \
  --title "Network Traffic" \
  --width=500 \
  --slope-mode \
  --end=now \
  --start=end-24h \
  --base=1000 \
  DEF:bytesIn=network.rrd:bytesIn:AVERAGE \
  DEF:bytesOut=network.rrd:bytesOut:AVERAGE \
  CDEF:bpsIn=bytesIn,8,* \
  CDEF:bpsOut=bytesOut,8,* \
  CDEF:bpsOutNeg=bpsOut,-1,* \
  VDEF:bpsInTot=bpsIn,TOTAL \
  VDEF:bpsOutTot=bpsOut,TOTAL \
  COMMENT:"              current     min        max      total\n" \
  AREA:bpsIn#FF880044:"Bits/s In " \
  GPRINT:bpsIn:LAST:"%6.1lf%s\t" \
  GPRINT:bpsIn:MIN:"%6.1lf%s\t" \
  GPRINT:bpsIn:MAX:"%6.1lf%s\t" \
  GPRINT:bpsInTot:"%6.1lf%s\n" \
  LINE1:bpsIn#FF8800CC \
  AREA:bpsOutNeg#44C80044:"Bits/s Out" \
  GPRINT:bpsOut:LAST:"%6.1lf%s\t" \
  GPRINT:bpsOut:MIN:"%6.1lf%s\t" \
  GPRINT:bpsOut:MAX:"%6.1lf%s\t" \
  GPRINT:bpsOutTot:"%6.1lf%s\n" \
  LINE1:bpsOutNeg#44C800CC \
  HRULE:0#000000

With the basic graph setup, adding the elements necessary for the running average can now begin.  In this example, it appears there is a roughly hourly cycle (Time Machine backups) that defines the period so a reasonable start is to work with a minimum average calculated over 60 minutes.

First, additional CDEF statements need to be declared applying the TREND operator to the desired data.  The format for this operation is straightforward:

CDEF:label=data_source,time_span,TREND

In this case, two new data sources are defined and are given the labels bspInTrend and bpsOutTrendNeg.  The data sources for these are the previously declared bpsIn and bpsOutNeg and the time span for them is 1 hour (3600 seconds).

  CDEF:bpsInTrend=bpsIn,3600,TREND \
  CDEF:bpsOutTrendNeg=bpsOutNeg,3600,TREND \

With the running averages now defined, it is possible to graph the data.  For the purposes of this example, the running average is graphed as a “shadow” on top of the base data.

  LINE2:bpsInTrend#000000CC \
  LINE2:bpsOutTrendNeg#000000CC \

The graph shown below illustrates the new running averages.

The running averages are now shown and it illustrates that despite the hourly peaks, the overall trend is fairly flat with the slight exception around 00:15.  However, the running averages also show a gap at the beginning of the graph. This gap is because it takes an hour of data before the hourly running average can be computed.  While this may be acceptable, it doesn’t look polished.

A minor tweak of the original DEF statements can provide “padding” necessary to eliminate the displayed gap in the running average lines.  This can be accomplished by extending the start time of the data sources by at least the same duration specified in the running averages.  Note that the display area is not affected by altering the start time of the DEF statements — that is controlled by the --start and --end options.  For the example data, the DEF statements need to extend the range of the data set by 1 hour so as to encompass 25 hours instead of the display area’s 24 hours:

  DEF:bytesIn=network.rrd:bytesIn:AVERAGE:start=end-25h \
  DEF:bytesOut=network.rrd:bytesOut:AVERAGE:start=end-25h \

Putting it together, the following command will pull in all the data necessary to calculate a running average for the extent of the display area, calculate the running averages, and display the results:

rrdtool graph example.png \
  --title "Network Traffic" \
  --width=500 \
  --slope-mode \
  --end=now \
  --start=end-24h \
  --base=1000 \
  DEF:bytesIn=network.rrd:bytesIn:AVERAGE:start=end-25h \
  DEF:bytesOut=network.rrd:bytesOut:AVERAGE:start=end-25h \
  CDEF:bpsIn=bytesIn,8,* \
  CDEF:bpsOut=bytesOut,8,* \
  CDEF:bpsOutNeg=bpsOut,-1,* \
  CDEF:bpsInTrend=bpsIn,3600,TREND \
  CDEF:bpsOutTrendNeg=bpsOutNeg,3600,TREND \
  VDEF:bpsInTot=bpsIn,TOTAL \
  VDEF:bpsOutTot=bpsOut,TOTAL \
  COMMENT:"              current     min        max      total\n" \
  AREA:bpsIn#FF880044:"Bits/s In " \
  GPRINT:bpsIn:LAST:"%6.1lf%s\t" \
  GPRINT:bpsIn:MIN:"%6.1lf%s\t" \
  GPRINT:bpsIn:MAX:"%6.1lf%s\t" \
  GPRINT:bpsInTot:"%6.1lf%s\n" \
  LINE1:bpsIn#FF8800CC \
  AREA:bpsOutNeg#44C80044:"Bits/s Out" \
  GPRINT:bpsOut:LAST:"%6.1lf%s\t" \
  GPRINT:bpsOut:MIN:"%6.1lf%s\t" \
  GPRINT:bpsOut:MAX:"%6.1lf%s\t" \
  GPRINT:bpsOutTot:"%6.1lf%s\n" \
  LINE1:bpsOutNeg#44C800CC \
  LINE2:bpsInTrend#000000CC \
  LINE2:bpsOutTrendNeg#000000CC \
  HRULE:0#000000

To begin, it helps to setup a chart that graphs the desired data in a typical manner before adding in the time shifted overlays.  The following graph command creates a somewhat typical visualization of the last hour’s network traffic as illustrated by Example 1 graph:

rrdtool graph example.png \
  --title "Network Traffic" \
  --width=500 \
  --slope-mode \
  --end=now \
  --start=end-1h \
  --base=1000 \
  DEF:bytesIn=network.rrd:bytesIn:AVERAGE \
  DEF:bytesOut=network.rrd:bytesOut:AVERAGE \
  CDEF:bpsIn=bytesIn,8,* \
  CDEF:bpsOut=bytesOut,8,* \
  CDEF:bpsOutNeg=bpsOut,-1,* \
  VDEF:bpsInTot=bpsIn,TOTAL \
  VDEF:bpsOutTot=bpsOut,TOTAL \
  COMMENT:"            current     min        max      total\n" \
  AREA:bpsIn#FF880044:"Bits/s In " \
  GPRINT:bpsIn:LAST:"%6.1lf%s\t" \
  GPRINT:bpsIn:MIN:"%6.1lf%s\t" \
  GPRINT:bpsIn:MAX:"%6.1lf%s\t" \
  GPRINT:bpsInTot:"%6.1lf%s\n" \
  LINE1:bpsIn#FF8800CC \
  AREA:bpsOutNeg#44C80044:"Bits/s Out" \
  GPRINT:bpsOut:LAST:"%6.1lf%s\t" \
  GPRINT:bpsOut:MIN:"%6.1lf%s\t" \
  GPRINT:bpsOut:MAX:"%6.1lf%s\t" \
  GPRINT:bpsOutTot:"%6.1lf%s\n" \
  LINE1:bpsOutNeg#44C800CC \
  HRULE:0#000000

With the basic chart setup as desired, now the command can be modified to support a time shifted overlay.

First, additional DEF statements need to be defined for time range for the source data to encompass the time span desired for comparison.  Note that this is not the same as the graph’s display range; those options (--start and --end) should remain unchanged.  The override start time should extend the time frame to the start of the time shifted data.  For example, the following would be suitable for comparison of the previous 1 hour:

  DEF:bytesInPrevHour=network.rrd:bytesIn:AVERAGE:start=end-2h \
  DEF:bytesOutPrevHour=network.rrd:bytesOut:AVERAGE:start=end-2h \

As another example, the following would be suitable for a comparison of the same hour, 1 day (24 hours) ago:

  DEF:bytesInPrevDay=network.rrd:bytesIn:AVERAGE:start=end-25h \
  DEF:bytesOutPrevDay=network.rrd:bytesOut:AVERAGE:start=end-25h \

Next, a new SHIFT statement needs to be introduced that shifts the data being displayed by the specified number of seconds.  The SHIFT statements must be specified after the DEF statements they are shifting.  The following statements would shift the newly inserted DEF statements by 1 hour (3600 seconds):

  SHIFT:bytesInPrevHour:3600 \
  SHIFT:bytesOutPrevHour:3600 \

Next, the CDEF and VDEF operations need to be supplied in order to transform the new data in a consistent manner with the original data.

  CDEF:bpsInPrev=bytesInPrevHour,8,* \
  CDEF:bpsOutPrev=bytesOutInPrevHour,8,* \
  CDEF:bpsOutPrevNeg=bpsOutPrev,-1,* \

Finally, the new elements are ready for graphing.  Care should be made to ensure the shifted data is displayed in a distinct manner from the current data so as to prevent visual confusion or obscuring the current data.

  LINE1:bpsInPrev#00000088 \ 
  LINE1:bpsOutPrevNeg#00000088 \

Pulling it all together, the following command will pull in the data from the extended time frame, shift it forward by the appropriate amount of time so that it aligns with the displayed time frame, perform the desired transformation options, and finally display the results:

rrdtool graph example.png \
  --title "Network Traffic" \
  --width=500 \
  --slope-mode \
  --end=now \
  --start=end-1h \
  --base=1000 \
  DEF:bytesIn=network.rrd:bytesIn:AVERAGE \
  DEF:bytesOut=network.rrd:bytesOut:AVERAGE \
  DEF:bytesInPrevHour=network.rrd:bytesIn:AVERAGE:start=end-2h \
  DEF:bytesOutPrevHour=network.rrd:bytesOut:AVERAGE:start=end-2h \
  SHIFT:bytesInPrevHour:3600 \
  SHIFT:bytesOutPrevHour:3600 \
  CDEF:bpsIn=bytesIn,8,* \
  CDEF:bpsOut=bytesOut,8,* \
  CDEF:bpsOutNeg=bpsOut,-1,* \
  CDEF:bpsInPrev=bytesInPrevHour,8,* \
  CDEF:bpsOutPrev=bytesOutInPrevHour,8,* \
  CDEF:bpsOutPrevNeg=bpsOutPrev,-1,* \
  VDEF:bpsInTot=bpsIn,TOTAL \
  VDEF:bpsOutTot=bpsOut,TOTAL \
  COMMENT:"            current     min        max      total\n" \
  AREA:bpsIn#FF880044:"Bits/s In " \
  GPRINT:bpsIn:LAST:"%6.1lf%s\t" \
  GPRINT:bpsIn:MIN:"%6.1lf%s\t" \
  GPRINT:bpsIn:MAX:"%6.1lf%s\t" \
  GPRINT:bpsInTot:"%6.1lf%s\n" \
  LINE1:bpsIn#FF8800CC \
  AREA:bpsOutNeg#44C80044:"Bits/s Out" \
  GPRINT:bpsOut:LAST:"%6.1lf%s\t" \
  GPRINT:bpsOut:MIN:"%6.1lf%s\t" \
  GPRINT:bpsOut:MAX:"%6.1lf%s\t" \
  GPRINT:bpsOutTot:"%6.1lf%s\n" \
  LINE1:bpsOutNeg#44C800CC \
  LINE1:bpsInPrev#00000088 \ 
  LINE1:bpsOutPrevNeg#00000088 \
  HRULE:0#000000

First, the /etc/named.conf file needs to be modified to specify both the statistics file and the appropriate control mechanisms.  As this is an essential configuration file, create a backup copy of the existing (working) file before editing in case something goes wrong.

In the named.conf file, ensure that there is an configuration block for the “controls”.  By default, it should already be present and look similar to the following:

controls  {
        inet 127.0.0.1 port 54 allow    {any;   }
        keys    { "rndc-key";    };
   };

This section defines the access control for the stats tool (among other things).  The essential elements for this purpose is that it defines the communications port as port 54 and it uses the key identified as “rndc-key” as its security token.  The key is actually defined in a separate file and read into the configuration via the include "/etc/rndc.key" statement earlier in the named.conf file.

There should also be a configuration block for the “options”.  A typical installation will look like the following:

options  {
        include "/etc/dns/options.conf.apple";
                /*
         * If there is a firewall between you and nameservers you want
         * to talk to, you might need to uncomment the query-source
         * directive below.  Previous versions of BIND always asked
         * questions using port 53, but BIND 8.1 uses an unprivileged
         * port by default.
         */
        // query-source address * port 53;
   };

This section requires some minor modification to specify the stats file.  In the block, insert a line specifying statistics-file "/full/path/to/the/named.stats";.  It is best to make the addition after the include statement so that the edited result looks similar to the following:

options  {
        include "/etc/dns/options.conf.apple";

        // Addition to enable statistics
        statistics-file "/var/log/named.stats";

                /*
         * If there is a firewall between you and nameservers you want
         * to talk to, you might need to uncomment the query-source
         * directive below.  Previous versions of BIND always asked
         * questions using port 53, but BIND 8.1 uses an unprivileged
         * port by default.
         */
        // query-source address * port 53;
   };

After the named.conf file has been configured properly, a new file must created for the configuration of the rndc utility.  Create the /etc/rndc.conf file and edit it with the following settings:

include "/etc/rndc.key";

options {
    default-key "rndc-key";
    default-server localhost;
    default-port 54;
};

The include statement must match the same included file specified in the named.conf file as the security key (“rndc-key”) must match or the rndc utility used to trigger the stats dump will not be authorized to connect.  The options block specifies the key name and the default server and port.  The assumption here is that the rndc tool will be run on the same host (localhost) as the DNS server.  The port should match the port specified in the controls block of the named.conf file.

At this point, the named daemon can be safely signaled to pick up the configuration changes.  This can be done easily via the Server Admin tool by restarting the DNS service or, for the more advanced sysadmin, a SIGHUP can be sent to the process.

To trigger a stats dump, simply call the rndc stats and look for the stats file specified in the named.conf file.  If the file isn’t found, there may be a authorization issue:  try running the command as an administrator or call the command via sudo (e.g. sudo rndc stats).

The stats can be triggered on an ongoing basis by specifying an appropriate entry for the launchd system.  A simple plist formatted file located in /Library/LaunchDaemons can serve to repeatedly call the stats file for ongoing monitoring.  (See launchd tips and tricks for more information.)

The following example would be named com.hostname.namedstats.plist and specifies that the stats should be generated every 5 minutes (300 seconds).

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.hostname.namedstats</string>
    <key>StartInterval</key>
    <integer>300</integer>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/sbin/rndc</string>
        <string>stats</string>
    </array>
</dict>
</plist>

Note that every time the stats are generated they are appended to the existing file which can quickly result in a very large, unwieldy file.  If recurring stats are desired, then ensuring the stats file is periodically rotated is essential.

In Linux, the typical log rotation utility is, appropriately enough, logrotate.  However, Mac OS X uses a different tool, newsyslog, to manage the log rotation responsibilities.  This utility is run automatically by the OS at frequently intervals and evaluates the rules defined in its configuration file — /etc/newsyslog.conf.  For the log files defined in the config, it can evaluate the need to rotate based on a number of criteria, such as file size, at a specific time, at a specific interval, etc.  It can also specify additional actions to take on the rotated log, including compression of the old log, maintaining a fixed number of previous log files, setting appropriate permissions, etc.  Full documentation is available in the man page for newsyslog.conf.

Each entry in the newsyslog.conf file is specified as a single line with space-delimited fields for the various options.  The general format is as follows (with [] surrounding the optional fields):

logfilename [owner:group] mode count size when flags [/pid_file] [sig_num]

An example entry for rotating the named.stats log file can be specified as follows:

/var/log/named.stats                    640  5     1000 *     J

In the above example, the full path is specified for the target log file — /var/log/named.stats.  Permissions (640) are specified in the typical Unix manner, in this case enabling read/write for the owner and read-only for the group.  This log file will maintain a maximum of 5 files, removing the oldest file as newer archived logs are created.  This log file is also set to rotate at a fixed size — 1000 kilobytes and can rotate at any time (“*”) this size threshold is exceeded.  The “J” flag specified calls for the the older log files to be compressed (further reducing used disk space) using the bzip2 utility.

A special note for binary (not text-based) logs:  by default, newsyslog will inject a line at the beginning of a file indicating when and why the log rotated.  For most text-based logs, this can be easily skipped over but for binary logs this might result in an unreadable file.  In this case, be sure to specify the “B” flag which suppresses the informational line from being injected.

It is often desirable to collect the system logs from various devices onto a central “logging host”.  This can simplify monitoring needs considerably as tools and scripts need only work on a single host.  It also provides some security benefits as hackers will have a harder time masking their activities if they do not have access to the logging host.

On Mac OS X, there is a logging daemon (the Unix standard syslogd utility) that can be used to write both local logs and receive logs from remote hosts.  Unfortunately, the ability to receive remote logs is turned off in the default installation.  However, it is a trivial task to enable this functionality.

Setup (for 10.5 and older systems)

1. Login as administrator to the logging host
2. Open a terminal session using the Terminal utility
3. Navigate to the LaunchDaemons directory
   cd /System/Library/LaunchDaemons
4. Edit the com.apple.syslogd.plist file
   sudo vi com.apple.syslogd.plist
5. Remove the comment delimiters (<!-- and -->) surrounding the NetworkListener block and save the changes
   

   <!--
    <key>NetworkListener</key>
    <dict>
    <key>SockServiceName</key>
    <string>syslog</string>
    <key>SockType</key>
    <string>dgram</string>
    </dict>
   -->

6. Stop the currently running instance of the syslog daemon
   sudo launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist
7. Restart the syslog daemon to pick up the changes in the LaunchDaemon configuration
   sudo launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist

The logging facility on the log host should now be available for remote devices to use.

Setup (for 10.6 and later systems)

1. Login as administrator to the logging host
2. Open a terminal session using the Terminal utility
3. Navigate to the LaunchDaemons directory
   cd /System/Library/LaunchDaemons
4. Convert the com.apple.syslogd.plist to XML format
   sudo plutil -convert xml1 com.apple.syslogd.plist
5. Edit the com.apple.syslogd.plist file
   sudo vi com.apple.syslogd.plist
6. Add the NetworkListener dict entry after the end of the BSDSystemLogger dict entry and save the changes
   

   <key>NetworkListener</key>
   <dict>
   <key>SockServiceName</key>
   <string>syslog</string>
   <key>SockType</key>
   <string>dgram</string>
   </dict>

7. Convert the com.apple.syslogd.plist file back to the binary format
   sudo plutil -convert binary1 com.apple.syslogd.plist
8. Stop the currently running instance of the syslog daemon
   sudo launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist
9. Restart the syslog daemon to pick up the changes in the LaunchDaemon configuration
   sudo launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist

The logging facility on the log host should now be available for remote devices to use.

Setup (using the Property List Editor)

Apple provides the Property List Editor utility as part of its developer tools.  The developer tools are usually a separate install from the operating system and is frequently not installed on systems.  If it is present, then using the Property List Editor may be the most convenient means of modifying the com.apple.syslogd.plist file.

1. Login as administrator to the logging host
2. Launch the Property List Editor utility (typically located in /Developer/Applications/Utilities)
3. Open the /System/Library/LaunchDaemons/com.apple.syslogd.plist file
4. Select the “Sockets” dictionary entry and “Add Item” to create a new key in the “Sockets” dictionary
5. Change the name of the item to “NetworkListener” and set its type to “Dictionary”
6. Select the “NetworkListener” dictionary entry and “Add Item” to create a new key in the “NetworkListener” dictionary
7. Change the name of the item to “SockServiceName”, its type to “String” and its value to “syslog”
8. Select the “NetworkListener” dictionary entry and “Add Item” to create another new key in the “NetworkListener” dictionary
9. Change the name of the item to “SockType”, its type to “String”, and its value to “dgram”
10. Save the file and quit the Property List Editor utility.  The property list should resemble the following example:
11. Open a terminal session using the Terminal utility
12. Navigate to the LaunchDaemons directory
    cd /System/Library/LaunchDaemons
13. Stop the currently running instance of the syslog daemon
    sudo launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist
14. Restart the syslog daemon to pick up the changes in the LaunchDaemon configuration
    sudo launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist

The ReadyNAS appliance can advertise the services available on their system through the Bonjour or UPnP protocols.  These service discovery protocols can greatly simplify the client connection and configuration problems.  The web administration interface provides an easy method of controlling some of the services advertised, but there may be additional services running on the ReadyNAS that do not have an administrative interface for controlling their advertisement.

Because the ReadyNAS uses the open-source project avahi to handle service discovery, documentation on extending the list of services to be advertised is readily available.  With this information, it is relatively easy to create new service records for additional services and simplify the user experience.

Setup

In order to create additional avahi service records, it is necessary to enable root SSH access to the ReadyNAS system.

The service file is a simple XML file which defines a service-group record.  The service-group record contains a number of elements which may vary according to the service being advertised.  The two essential elements are the name record, which defines the displayed name for the service in question, and the service record, which defines the type, port, and any other connection-related information.

The name element has one possible attribute – replace-wildcards – which can take a value of “yes” or “no”.  If the attribute is present and the value is “yes”, then a %h can be used in the value which will be automatically substituted with the host name of the system.

The service element groups together the necessary information for service connectivity.  The two most essential elements it contains are the type element and the port element.  The type is the is the official service type as defined by RFC 2782 and the port is simply the listening port number.

Depending on the service, there may be additional elements or attributes that are necessary to have a properly formatted service file.  Be sure to consult the documentation to ensure the service is properly defined before making any changes.

Example

The following is an example configuration that enables service discovery for SSH:


<?xml version="1.0" standalone='no'?>
<service-group>
<name replace-wildcards="yes">SSH on %h</name>
<service>
<type>_ssh._tcp</type>
<port>22</port>
</service>
</service-group>

To activate this service, perform the following actions:

1. Login (via ssh) as “root” to the ReadyNAS appliance.
2. Navigate to the configuration directory.

   cd /etc/avahi/services

3. Create a new file named ssh.service containing the configuration information listed above.
4. Restart the avahi service to load the new service file.

   kill -SIGHUP `ps ax | grep avahi | grep -v grep | awk '{ print $1 }'`

Bugzilla is a very popular open-source issue tracking system.  However, setting up all the user accounts can be a tedious chore, particularly for large user bases.  In addition, there are additional user-management headaches associated with maintaining another list of user names, password issues, and access changes due to staff turnover.

Fortunately, Bugzilla is capable of integrating with the RADIUS service available on the Mac OS X Server.  RADIUS is a remote authentication and authorization service which can handle the user authentication requests for Bugzilla and permit users to simply sign on with their standard account name and passwords.  This relieves the administrator from having to create and maintain another set of accounts and allows the users to simply use their standard account name and password.

It should be noted that the implementation of the RADIUS service on the Mac OS X Server is the open-source FreeRADIUS.  More configuration information and usage can be found on the projects web site.

Prior installation of Bugzilla is assumed for these directions.

Enabling the RADIUS Service

If the RADIUS service has not been enabled on the server, then it is necessary to activate it.  Do not start the service during this step.

1. Open the Server Admin application and connect to the server hosting the RADIUS service.
2. Select the server in the “Servers” pane and then click on the “Settings” icon.
3. Click on the “Services” tab and enable the “RADIUS” service by clicking on the appropriate checkbox.
4. Save the new configuration by clicking on the “Save” button.
5. Select the “RADIUS” service now available in the “Servers” pane.
6. Select the “Settings” icon and select a security certificate to use for the service.  A self-signed certificate can easily be created using the “Manage Certificates” option in the drop-down menu.  Regardless, the certificate used for this service should not have a Private Key Passphrase set.
7. Save the new configuration by clicking on the “Save” button.

Configuring the RADIUS service

The stock RADIUS service on Mac OS X (Leopard) has been configured to work only with Apple’s Airport and Airport Express WiFi systems.  In order to extend its functionality to provide service to other types of systems,  the configuration file must be edited and a special entry must be created.

1. Open the Server Admin application and connect to the server hosting the RADIUS service.
2. Select the RADIUS service for configuration.  If the service is already running, then click on the “Stop RADIUS” button to stop it.
3. Click on the “Base Stations” icon and then the “Add…” button to create a new entry.  The most important elements to set correctly are the Type and IP Address.  Type must be “other” and the IP Address should be the address of the Bugzilla server.
   

   Name: Bugzilla
   Type: other
   IP Address: 192.168.1.2
   Shared Secret: ********
   Verify: ********

4. Make a backup copy of the /etc/raddb/users configuration file for safety.

   sudo cp /etc/raddb/users /etc/raddb/users.orig

5. Edit the /etc/raddb/users configuration file to alter the default authentication type to use the Open Directory service instead of the local account database.  The line in question should be approximately 153 lines down in the file (as of 10.5.8).

   Replace: DEFAULT Auth-Type = System
   with: DEFAULT Auth-Type = opendirectory

6. Return to the Server Admin application and start the RADIUS service.

Testing the RADIUS service

In order to verify the RADIUS service is working properly it should be tested using the included test tool radtest.  The general format for testing the RADIUS service is:

radtest user password radius-server nas-port-number shared-secret

user is the username to be tested.

password is the user’s password.  Note that this is given in cleartext and so may be considered a security risk.  It is suggested that you change the password immediately after concluding the test.

radius-server is the hostname (or IP address) of the server hosting the RADIUS service.

nas-port-number is the value of the NAS-Port attribute.  For testing purposes, it does not matter what value is provided as long as it is between 0 and 2^31.

shared-secret is the shared secret established when the service was configured.

The following is an example usage showing the result of a successful test:

$ radtest groucho RufusTFirefly radius.example.com 10 SecretWord
Sending Access-Request of id 203 to 192.168.1.2 port 1812
User-Name = "groucho"
User-Password = "RufusTFirefly"
NAS-IP-Address = 255.255.255.255
NAS-Port = 10
rad_recv: Access-Accept packet from host 192.168.1.2:1812, id=203, length=20

Configuring Bugzilla for RADIUS authentication

RADIUS configuration requires administrative access to the Bugzilla installation.  It cannot be performed as a “normal” user of the system.  It is best practice to verify the RADIUS service is working properly before attempting to configure a dependent service.

1. Install the Authen::Radius perl module (if not already installed as part of the initial setup).

   sudo cpan -i Authen::Radius

2. Login as administrator to Bugzilla.
3. Click on the “Administration” link.
4. Click on the “Parameters” link.
5. Click on the “RADIUS” link
6. Fill in the information for all the RADIUS fields.  The server is the hostname where the RADIUS service is running.  The secret it the shared secret established when the service was configured.  The NAS IP is the address where the Bugzilla service is running.  The email suffix is appended to the username to generate the appropriate email address for each user.
   

   RADIUS_server:  radius.example.com
   RADIUS_secret:  ********
   RADIUS_NAS_IP:  192.168.1.2
   RADIUS_email_suffix:  @example.com

7. Click on the “Save Changes” button to save the new configuration information.
8. Click on the “User Authentication” link.
9. Navigate to the user_verify_class and activate RADIUS as a valid authentication mechanism.  It is strongly suggested that you leave the DB method also activated.
10. Click on the “Save Changes” button to save the new configuration information.

Related Links

• Installing Bugzilla on Mac OS X Server

Bugzilla is a very popular open-source bug-tracking system.  It is used by many companies (large and small) to not only track defects and their remediation, but also to track various other development tasks, including new feature work, enhancement requests, etc.  It can even be used as part of a change-control process (e.g. SAS-70, SOx, etc.).

Because Bugzilla is an open-source project, it is actively enhanced and can be installed on a number of different systems.  It is easily customized in both appearance and functionality which provides it with the flexibility to fit into the existing development process of almost any team.

The project’s site (http://www.bugzilla.org) has a plethora of documentation, example usages, forums, as well as the latest releases.  The latest stable release can be found on their download page.  This post contains specific instructions for installing Bugzilla on a system running Mac OS X Server (Leopard).

Preliminary Preparations

Perl

An appropriate version of perl should already be available as part of the normal operating system installation.  Bugzilla requires a minimum of version 5.8.1 and version 5.8.8 should already be installed (as of OS X 10.5.8).  The version of perl can be verified with the following command:

/usr/bin/perl --version

MySQL

Bugzilla can utilize several different databases to store its data, but Mac OS X Server already has MySQL included in its normal installation so it makes sense to use that option.  However, the MySQL installed by default with Mac OS X Server does not include the necessary files to build a MySQL application so these must be installed manually.

To install the MySQL build files:

1. Go to the Apple open source download page and select the appropriate version of the operating system the installation is running.
2. Download the binary version of the MySQL package (for 10.5.8, the correct package is MySQL-45).
3. Decompress the packaged binary.

   tar xzf MySQL-45.binaries.tar.gz

4. Navigate to the uncompressed package directory.

   cd MySQL-45.binaries

5. Decompress the internal package into the destination directory.

   sudo tar -xzvf MySQL-45.root.tar.gz -C /

To enable the MySQL service:

1. Open the Server Admin application and connect to the server.
2. Select the server name and click on the “Settings” icon and then the “Services” tab.
3. Enable the MySQL service by clicking on the appropriate checkbox.
4. Click on the “Save” button to save the new configuration.

To start the MySQL service:

1. Open the Server Admin application and connect to the server.
2. Select the MySQL service from the list of available services.
3. Click on the “Settings” tab.
4. If necessary, set the root password for the MySQL service.  The default database location of /var/mysql may also be overridden if desired.
5. Click on the “Save” button to save the new configuration.
6. Click on the “Start MySQL” to startup the new service.

Apache

Bugzilla can utilize a wide variety of web servers, but Apache is already installed with Mac OS X Server so it makes sense to use that option.  For this installation, Bugzilla will be configured in its own subdomain (e.g. bugzilla.example.com) and not as a directory of another domain (e.g. www.example.com/bugzilla).

To setup the bugzilla domain:

1. Open the Server Admin application and connect to the server hosting DNS services.
2. Select the DNS service from the list of available services.
3. Select the “Zones” icon.
4. Select the Primary Zone for the site (e.g. example.com).
5. Click on the “Add Record” drop-down and select the “Add Alias (CNAME)” item.
6. Enter the Alias Name for the bugzilla subdomain.  The alias name should be fully qualified. This means the full domain name should be given and terminated with a period.

   bugzilla.example.com.

7. Enter the Destination for the bugzilla alias.  (i.e. the name of the server running Apache).  The domain name should be fully qualified. This means the full domain name should be given and terminated with a period.

   www.example.com.

8. Click on the “Save” button to save the new configuration.
9. Restart the DNS service to activate the new domain name.

To setup the bugzilla web site:

1. Open the Server Admin application and connect to the server hosting the web server.
2. Select the Web service from the list of available services.
3. Select the “Sites” icon.
4. Click on the “+” button to create a new site entry.
5. Click on the “General” tab and fill out the information for the new site entry:
   

   Domain Name: bugzilla.example.com
   Host Description: Bugzilla
   IP Address: any
   Port: 80
   Web Folder: /opt/local/www/bugzilla
   Default Index Files: index.cgi
   Error Document: /error.html
   Administrator Email: admin@example.com

6. Select the “Options” tab and enable the “CGI Execution” and “Allow All Overrides” options.
7. Select the “Logging” tab and setup the logging information:
   

   Enable Access Log: enabled
   Archive every: 7 days
   Location: /var/log/apache2/bugzilla_access_log
   Error Log Archive every: 7 days
   Error Log Location: /var/log/apache2/bugzilla_error_log
   Error Log Level: Warnings

8. Select the “Web Services” tab and disable any additional services selected.
9. Enable the new site by clicking the “Enabled” checkbox next to the site entry.
10. Click on the “Save” button to save the new configuration.
11. Restart the Web service to activate the new site.

Bugzilla

In this installation, Bugzilla is installed in the /opt/local/src directory so as to keep it isolated from the “stock” operating system tools and utilities.  This makes upgrading either the operating system or Bugzilla easier and less likely to result in conflicts.  In order to further simplify future upgrades, a symbolic link (/opt/local/www/bugzilla) is used as the root web folder instead of directly utilizing the actual Bugzilla source directory.

1. Download the latest Bugzilla source tarball.
2. Copy the tarball to source directory.

   sudo cp bugzilla-3.4.2.tar.gz /opt/local/src

3. Unpack the source tarball.

   cd /opt/local/src
sudo tar xzf bugzilla-3.4.2.tar.gz

4. Change the owner and group to the default web server user.

   sudo chown -R _www:_www bugzilla-3.4.2

5. Create an alias in the web folder to the active Bugzilla source.

   sudo ln -s /opt/local/src/bugzilla-3.4.2 /opt/local/www/bugzilla

Perl Modules

There are a number of perl modules (both required and optional) that Bugzilla requires for operating.  Fortunately, there are several utilities included in the Bugzilla directory that can be used to determine what needs installation as well as actually installing the necessary modules.  For these installations, it is strongly suggested that you run the commands in a root shell.

To install the perl modules:

1. Create a root shell.

   sudo bash

2. Execute the check-modules.pl script.

   /opt/local/src/bugzilla-3.4.2/checksetup.pl --check_modules

3. Install all the required perl modules identified by the check-modules.pl script.
4. Install the appropriate database binding module (DBD:mysql)

   /usr/bin/perl install-module.pl DBD::mysql

5. Install any optional modules desired.
6. Exit from the root shell.

   exit

Mail

Mac OS X Server already comes with a compatible mail transfer agent (Postfix) so no additional installation is necessary.  A working mail service is necessary for Bugzilla to issue event alerts and notifications.

Configuration

localconfig

The localconfig file is an auto-generated file that contains many of the core Bugzilla configuration variables.  Generation of the file is done by running the checksetup.pl script (with no additional parameters).  The resulting file is not immediately usable as it requires a couple quick updates to properly configure the database access.

1. Execute the checksetup.pl script to generate the localconfig file.

   cd /opt/local/src/bugzilla-3.4.2
./checksetup.pl

2. Change the $db_driver variable in the localconfig file.

   $db_driver = 'mysql'

3. Change the $db_pass variable in the localconfig file to the password for ‘bugs’ user of the database.  (The ‘bugs’ user will be created shortly.)

   $db_pass = '********'

4. Change the $webservergroup variable in the localconfig file.

   $webservergroup = '_www'

MySQL

In order to provide a better working experience with Bugzilla, it is necessary to update some of the MySQL configuration variables.  In addition, a new database user must be created.

1. Edit the /etc/my.cnf file to permit large attachments and many comments

   max_allowed_packet=4M

2. Edit the /etc/my.cnf file to allow small words in full-text indexes

   ft_min_word_len=2

3. Add the ‘bugs’ database user with associated privileges.  Be sure to specify the same password for the ‘bugs’ users as in the configuration of the localconfig file.

   mysql -u root -p
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER, CREATE, LOCK TABLES, CREATE TEMPORARY TABLES, DROP, REFERENCES on bugs.* to bugs@localhost IDENTIFIED BY '********';
mysql> FLUSH PRIVILEGES;
mysql> commit;
mysql> exit;

4. Run the checksetup.pl script again to create the database tables, groups, users, and indexes.  Be sure to note the created administrator account and password for future reference.

Bugzilla

Bugzilla should now be accessible to a web browser at the domain specified earlier.  (http://bugzilla.example.com)  While it is usable in this state, there are some additional configuration settings that should be made with the administrator’s account.

1. Login as the administrator using the bugzilla administrator’s email address and password previously set.
2. Click on the “Administration” link.
3. Click on the “Parameters” link.
4. Set the email address of the maintainer.

   bugadmin@example.com

5. Set the URL base of the installation.

   http://bugzilla.example.com/

6. Set the cookie domain for the service.

   bugzilla.example.com

7. Click on the “Save Changes” button to save the new parameters.

Related Links

• Configuring RADIUS support for Bugzilla

The robots.txt file provides guidance to the search agents (from Google, Yahoo, MSN, etc.) on how to search your web site.  Well-behaving search agents (aka “bots”, “crawlers”, or “spiders”) look for a robots.txt file in the root directory of the web site in order to determine permissions, restrictions, or hints for properly crawling and indexing the site.  Observance of the controls expressed in a robots.txt file is strictly voluntary on the part of the search agents and is not a substitution  for appropriate security measures on any sensitive information.

The robots.txt file is intended to be read and processed only by the automated search agents.  The rules expressed in the file do not apply to users visiting the site with a typical web browser (e.g. Internet Explorer, FireFox, Safari, etc.).

File Format

The format of a robots.txt file consists of a minimum of one record.  Each record consists of a series of directives with one or more User-agent directives followed by one or more Disallow directives.  There can be only one directive specified per line, and it should be in the format of <directive>: <value>.  Comments are specified by a leading “#” character.

While there are a number of other possible directives that can be specified within a record, the minimum required are a User-agent and a Disallow directive.

Location

The search agent looks for the robots.txt file at the root of the web site.  If the server is running more than one site, then one file should be created for each site.  The exact location may vary depending on the site configuration, but this can be checked in the Server Admin application.  (Select the “Web” service, click on the “Sites” icon, and note the “Web Folder” value for each Domain Name.)

Basic Directives

User-agent

The User-agent directive consists of either the name of a search agent or the wildcard character (“*”).  The wildcard character indicates the rule set applies to all search agents and can only be specified once in the robots.txt file.

Disallow

The Disallow directive follows the User-agent directive and specifies a path (either partial or full) that should not be accessed by the search agent.  Multiple paths may be specified by using multiple Disallow directives within a record.  Multiple paths should not be specified within a single Disallow directive.  The value of the directive may be left blank to indicate there are no agent restrictions.

Additional Directives

There are a number of additional directives that may be specified in a record, but not all of them are recognized by the various search agents.  The only directives that seem to be universally parsed are the basic directives — User-agent and Disallow.

Crawl-delay

The Crawl-delay directive specifies a delay (in seconds) between requests by a search agent.  The delay can be used to help prevent an aggressive search agent from overloading the site by issuing requests too rapidly.

Visit-time

The Visit-time directive specifies the acceptable time range for a search agent to crawl the site.  This can be used to defer any search traffic that might otherwise occur during peak traffic times.  The times specified are in 24 hour (military) format and are based on GMT.  (e.g. “2200-0530″ would advise search agents to crawl the site from 10:00pm to 5:30am GMT.)

Request-rate

The Request-rate directive is similar in effect to the Crawl-delay directive however instead of specifying an absolute time between requests a rate is used.  For example, a rate of 1/30 indicates a maximum of 1 request should be issued every 30 seconds.  In addition, time of day restrictions can also be specified which can be used to provide a more flexible policy with different rates for different times of day.

Comment

The Comment directive can be used instead of the comment delimiter (“#”).  The Comment directive is intended to be returned to the administrator of the search agent and should contain a statement of the site’s crawl policy.

Allow

The Allow directive provides an exception into an otherwise disallowed area of the site.  This may provide a means whereby a search agent can bypass restrictions in order to access deeply-nested content.

Robot-version

The Robot-version directive specifies which version of the Robot Exclusion Standard the rule set observes.  It is intended primarily for site documentation purposes.

Examples

Open Access

The wildcard User-agent indicates the record applies to all search agents and the blank Disallow value means there are no restrictions.

User-agent: *
Disallow:

Blocked Access

The wildcard User-agent indicates the record applies to all search agents and the specification of the root directory (“/”) restricts the search agent from all content.

User-agent: *
Disallow: /

Multiple Restrictions

The wildcard User-agent indicates the record applies to all search agents and the Disallow directives restrict the search agents from content in the /doc/private and /cgi-bin directories.

User-agent: *
Disallow: /doc/private
Disallow: /cgi-bin

Timed Access

The wildcard User-agent indicates the record applies to all search agents and the Disallow directive restricts the search agents from content in the /doc/private directory.  The Visit-time directive advises the search agent to only attempt to crawl the site betwen 11:00pm and 4:30am (GMT).

User-agent: *
Disallow: /doc/private
Visit-time: 2300-0430

It is a common practice for many ISP’s to place restrictions on the sending and receiving of mail in order to reduce the potential for abuse by spammers.  For the typical home user, these restrictions are non-intrusive and are effective in preventing gratuitous abuse of the mail systems.  However, for users running their own mail server, these restrictions interfere with the proper operation of the service.

The origin for the restrictions began when spammers began directly injecting their email into the ISP’s mail relay servers for distribution.  This activity caused massive headaches for the ISP, as server utilization soared, bandwidth costs increased, and they would receive a torrent of angry calls from other ISPs for relaying so much spam.  The solution was to impose access restrictions on the mail relay servers so that only authenticated users from within the ISP’s network would be able to access them.  While effective in protecting the ISP’s mail relay servers, the tactics of the spammers shifted to work around this obstacle.

With direct access to the mail relay servers of the ISP blocked, hackers turned to using the large BotNets of Zombie Computers.  These compromised systems were used by the hackers to run their own mail relay servers and so the spam continued to flood the mail systems.  In order to reduce the effectiveness of this strategy, the ISPs  blocked all traffic for port 25 (the standard communication port for mail relay service) to their customers’ systems.  This prevented these systems from proxying spam throughout the email delivery systems.

In order to run a mail server, the restrictions imposed by the ISP must be overcome.  In some cases, simply contacting the customer support of the ISP can result in a lifting of the restrictions on the connection.  However, some ISPs do not have a flexible policy in place for customers wishing to run their own mail servers and so extra effort must be made in order to work around the situation.  Typically, there are two main blocks that must be overcome for mail service to be fully functional:  inbound blocking and outbound blocking.  The majority of ISPs implement both types of blocks, but occasionally only one or the other form of blocking is implemented.

Service Requirements

In order to work around the inbound or outbound blocks imposed by the ISP, an additional service provider must be used.  DynDNS.com offers several services that can be used to work around the ISP restrictions.  There are several other service providers that may have similar offerings, so you may wish to shop around.

The MailHop Relay service offers the ability to redirect incoming mail from the standard mail relay port (port 25) to an alternate port which is not blocked.  In addition, it provides a number of other benefits including:  spam filtering, white-listing, black-listing, virus scanning, and back-up queueing (which safely stores any incoming mail if your mail server should be temporarily unavailable).

The MailHop Outbound service offers the ability to bypass any outbound restrictions your ISP may have in place.  It is able to accept mail destined for other domains on an alternate port and so avoid a block placed on the standard mail relay port.  In addition, it offers a secure, authenticated mail relay connection (via SSL), the ability to send mail from any network, outgoing virus scanning, and detailed usage graphs.

Inbound Blocking

Inbound blocking prevents other mail servers from relaying mail to your mail server.  This means that mail which originates from another domain will not be able to be delivered to your email system.  Mail which originates from within your domain will not be affected by this type of restriction.  The MailHop Relay service offered by DynDNS is able to work around this restriction by accepting mail on behalf of your domain and then relaying it to your domain on an alternate port.

1. Subscribe to and setup the MailHop Relay service on the DynDNS site.
   1. Specify the destination mail server (e.g. example.com)
   2. Specify the alternate relay port (e.g. 10025)
   3. Enable any additional services desired (spam checking, virus scanning, etc.)
   4. Ensure the Mail Exchange (MX) Records are setup correctly for the domain
2. Create a port-forwarding rule on your gateway device to forward incoming connections from the alternate relay port specified (e.g. 10025) to the local mail server and standard mail relay port (e.g. mail.example.com, port 25).

   Protocol   External Port    Destination Address    Destination Port
      TCP         10025          mail.example.com            25

3. Verify inbound mail service is working properly by using Yahoo Mail to send a message to a test account in your domain.  It may take a few minutes for the DNS changes to propagate fully, so be patient if the mail does not appear quickly.

Outbound Blocking

Outbound blocking prevents mail originating from your server from being relayed to any other mail server.  Mail sent from within the domain to other members within the domain will not be affected.  The MailHop Outbound service offered by DynDNS is able to work around this restriction by accepting mail originating from your domain on an alternate port and then forwarding it on to the destination mail servers.

1. Subscribe to the MailHop Outbound service on the DynDNS site.
2. Open the Server Admin application and connect to the server hosting the mail service.
3. Select the Mail service from the list of available services.
4. Click on the “Settings” icon and select the “General” tab.
5. Enable the “Relay outgoing mail through host” option.
6. Enter the MailHop Outbound server address and port.

   outbound.mailhop.org:10025

7. Enable the “Authenticate to relay with user name” option.
8. Enter the account name and password for your DynDNS account in the appropriate fields.
9. Restart the Mail service.