Circles of Archimedes

Background

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

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
   

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

Background

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 }'`

Background

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

Background

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

Background

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

Background

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.

Background

Email extensions and aliases can be powerful tools to limit the amount of spam your system receives and provide greater security for your personal information.  Use of either technique can provide a means of both identifying the source of spam as well as a selective method to “turn off” the address without affecting other senders.  Both extensions and aliases work by obscuring your “real” email address and preventing it from being targeted directly by spammers.

A common use of aliases or extensions is to provide a unique registration email address for each site.  For example, when registering for an Amazon account, you create an alias of “amazon@example.com” or use an extension like “groucho+amazon@example.com”.  Should the Amazon address ever be compromised, it is easily disabled and obvious as to which site requires a new contact address.

Email Extensions

Email extensions are simply modifications of the “base” email address.  For example, if the base email address is “groucho@example.com”, an email extension may modify it to “groucho+marx@example.com”.  The extension is internally discarded by the mail server when routing the mail to your inbox.  The start of the extension is identified by a special separator character (typically a “+”) and anything following it up until the “@” is ignored by the receiving mail server.

Email extensions are very easy to use as once enabled they require no further setup.  Any number of extensions may be added to a base address without reconfiguration.  However, they do not provide as much security as an alias as the base email address remains easily identified.  In addition, some sites have taken to banning email addresses with extensions as legitimate registration addresses.

Email Aliases

Email aliases are a more thorough means of hiding your base email address.  They permit a total substitution of the recipient portion of the address instead of merely appending a unique extension.  For example, if the real email address is “groucho@example.com”, aliases may be created to direct “harpo@example.com”, “chico@example.com”, and “zeppo@example.com” to also forward all email to the “groucho” account.

Aliases are a bit more work to create than extensions as each alias must be added to the /etc/aliases file and the newaliases command run (as administrator).  However, they do provide a greater degree of security as the base email address is never revealed.

Implementation

Enabling Address Extensions

1. Login as Administrator.
2. Edit the /etc/postfix/main.cf file to enable the recipient_delimiter option.

   recipient_delimiter = +

3. Launch the Server Admin application and connect to the server hosting mail services.
4. Select the Mail service and restart the service.

Disabling Address Extensions

Disabling a particular email extension is not quite as easy as creating a new one.  In fact, it may be easiest simply to add a filtering rule on your email client to delete any email addressed to the compromised extension.  However, it can also be performed at a system level for cases where your email client may not support filtering rules (e.g. iPhone).

1. Login as Administrator.
2. Edit the /etc/aliases file by adding the compromised extension and redirecting it to /dev/null.

   grouch+marx:  /dev/null

3. Run the newaliases command.

   sudo /usr/bin/newaliases

Enabling Address Aliases

Aliases can be added by adding an appropriate entry into the /etc/aliases file. The format for aliases is:

alias: address[, address, ...]

Note that an alias may specify more than one recipient address which results in the mail to that alias being sent to multiple recipients.

1. Login as Administrator.
2. Edit the /etc/aliases file and add in the alias and corresponding base address.

   harpo:  groucho
   chico:  groucho
   zeppo:  groucho
   marx: groucho, karl

3. Run the newaliases command.

   sudo /usr/bin/newaliases

Disabling Address Aliases

If an email alias is compromised, it is a simple exercise to disable the alias and prevent the spam from cluttering up your inbox.  There are two different methods to disabling an alias each of which results in a different behavior.

The first method of disabling an alias is to simply either remove it or comment it out (by prefixing the line with a “#”) from the /etc/aliases file.  With it disabled in this manner, any mail destined for the alias will be “bounced” back to the originating system with a message indicating the recipient is not a valid address.  This provides feedback to the originator and may result in the address being pruned from a spammer’s list (as they don’t want to waste time and resources on a “dead” address).

The second method of disabling an alias is to redirect it to /dev/null instead of a legitimate address.  When disabled in this manner, the mail is simply discarded upon receipt by the server and no feedback is provided to the sender.  This may be preferred for hosts which recieve a lot of spam or with limited bandwidth as it uses less internal resources and outgoing bandwidth.

1. Login as Administrator.
2. Edit the /etc/aliases file and update the alias(es) as appropriate.

   # harpo:  groucho
   # chico:  groucho
   zeppo:  /dev/null

3. Run the newaliases command.

   sudo /usr/bin/newaliases

Background

The Unix utility rsync is a powerful tool for synchronizing data.  It can be used to quickly and efficiently copy files both locally and remotely.  It is best known for its delta-transfer capability which can greatly reduce the size of the data copied which results in a much faster copying process.

Setting up rsync as a daemon provides your system with an automated means of running the rsync process on-demand.  Essentially, it provides instructions to the operating system on how to respond when faced with an incoming rsync connection.  The daemon can be configured to limit access, require encryption, restrict permissions, etc. in order to ensure it provides a safe, reliable service.  When run as a daemon, rsync is often referred to as rsyncd.

Special Notice

Improper use of rsync can permanently damage your files. The standard installation of rsync installed with Mac OS X Server was not designed to handle the resource forks that are sometimes associated with Macintosh files.  Using rsync on files with these properties may result in irrecoverable file loss.  Use of rsync should be limited to files known to be “safe” (e.g. Unix utilites and data files).

Setup

There are several steps necessary to setup rsync as a daemon process.  First, a property list file (.plist) must be created specifying the appropriate arguments for the operating system’s LaunchDaemon process to instantiate rysncd.  A configuration file (.conf) must also be created providing additional rsyncd runtime arguments.  The configuration file may also include module files for easier control over individual settings.  Finally, a secrets file (.scrt) should be created to provide an additional layer of security to the rsync daemon.

A newer version of rsync is also available through MacPorts.  It may be installed in addition to the version that comes with Mac OS X.  The standard version of rsync can be found at /usr/bin/rsync, while the MacPorts version is installed by default as /opt/local/bin/rsync.

Property List File

The property list file is read by the LaunchDaemon process and contains instructions for starting the rsyncd process.  The supplied rsync.plist file is suitable for installation on standard Mac OS X Server installations.  It must be modified to reflect the alternate path (/opt/local/bin/rsync) if using the MacPorts-installed version of rsync.

1. Login as Administrator.
2. Download the rsync.plist file and make any necessary modifications.
3. Copy the rsync.plist file to the /Library/LaunchDaemons directory.

   sudo cp rsync.plist /Library/LaunchDaemons

4. Set the owner, group, and permissions on the rsync.plist file.

   sudo chown root:wheel /Library/LaunchDaemons/rsync.plist
   sudo chmod 644 /Library/LaunchDaemons/rsync.plist

5. Load the property list file with the Launch Daemon

   sudo launchctl load /Library/LaunchDaemons/rsync.plist

Configuration File

The configuration file is read by rsync upon launching and provides environment, security, and other configurable parameters.  It also provides the definitions for rsync module.  Each module exports a directory tree as a symbolic name and can define not only the directory tree but also any unique permissions, patterns, or other configuration options.

In the example configuration, the file and directory structure specifications are detailed in separate files which are included by the main configuration file.  This permits each module’s list of targets to be maintained independently.

There are a number of available configuration options of which the sample configuration file illustrates only a few.  For more information, see the man page for rsyncd.conf.

1. Login as Administrator.
2. Download the example rsyncd.conf file.
3. Edit the rsyncd.conf file and make any necessary changes for your installation.
4. Copy the rsyncd.conf file to the /etc directory.

   sudo cp rsyncd.conf /etc

5. Set the owner, group, and permissions on the rsyncd.conf file.

   sudo chown root:wheel /etc/rsyncd.conf
   sudo chmod 640 /etc/rsyncd.conf

Module Files

Module files are an extension of the main configuration file and are simply an easy method of isolating module-specific settings.  The modules files are included by the main configuration file.  A typical usage is to define the list of files and directories that are to be included (or excluded) in the rsync operation.  The example rsyncd.core module file includes several important directories that are not backed up by Apple’s Time Machine.

Secrets File

The secrets file can be used to store authentication information for restricting access to any defined rsync modules.  The usernames specified in the secrets file do not need to be actual users.

The format for the secrets file is simple:  username:password (one entry per line).  Bear in mind that some systems may have restrictions on the characters, length, or capitalization for either component.

1. Login as Administrator.
2. Download the example rsyncd.scrt file.
3. Edit the rsyncd.scrt file and add the usernames and passwords for your system.
4. Copy the rsyncd.scrt file to the location specified in your rsyncd.conf file

   sudo cp rsyncd.scrt /etc

5. Set the owner, group, and permissions on the file.

   sudo chown root:wheel /etc/rsyncd.scrt
   sudo chmod 600 /etc/rsyncd.scrt