cfgmaker has logic in it that will access these larger counters, but only if you use SNMP version 2c or 3 when querying for them. To use SNMP version 2c, you add the option --snmp-options=:::::2 to the command line before the target (e.g. community@router-name) when you use cfgmaker. Please note that there are devices (like the Apple Time Capsule) which do not support the 64-bit counters, so using SNMP version 2c for them will produce a configuration that generates no results when MRTG is run. To determine how best to proceed, I run cfgmaker twice (one with the option and one without) and compare the two configuration files. I use the SNMP version 2c file when it will generate results and the SNMP version 1 file otherwise.

If you have a requirement to use SNMP version 3, the options on the command line are --enablesnmpv3 --snmp-options:::::3. You also need to specify the username of the SNMP version 3 user that is authorized to use SNMP version 3 to query the device.

Here is an example using SNMP version 3 and a Cisco Catalyst 2960 Switch running IOS 12.2(53)SE2.

• First, insure that the switch is properly configured to answer SNMP version 3 queries. For this example, no authentication will be used. Here are the IOS command to setup SNMP version 3 on the switch.


snmp-server group mrtggroup v3
snmp-server user mrtguser mrtggroup v3


• Next, use cfgmaker to generate the mrtg configuration file.


cfgmaker --enablesnmpv3 --snmpoptions=:::::3 -username mrtguser switch-hostname > switch-hostname.cfg


The configuration file generated when used by MRTG will query the switch using SNMP version 3 retrieving data from the 64-bit counters.

I want to thank Jeff Chandler for commenting about MRTG and SNMP version 3 on another post. It made me curious enough to figure it out and write it up for this posting.

Nagios organizes monitoring in to two categories: host and services. Host availability is monitored by configuring a host object. For the services to the monitored on the host, a service object is created for those services of interest. Generally, the host object once installed and activated will using ping to determine the availability of the host. Service objects will generally use a plug-in, sometimes a custom plug-in, to determine the availability of services on that host. For the purposes of this posting, I am using a widely available plug-in called check_ifstatus which can be installed a part of the FreeBSD ports nagios-plugins package. If installed from the FreeBSD ports collection, the plug-in will automatically be configured for use by Nagios and can be used in a service object or template directly.

When adding a new device type to Nagios, it’s important to consider how that device will be represented on Nagios’ web pages. This means selecting an appropriate icon, vrml image and statusmap image to represent the device. The FreeBSD ports collection comes with a set of logos that cover most common devices called nagios-base-logos. For the Time Capsule, I want to use an icon that looked like the device. I found a satisfactory one at deviantArt by ElevatorHappyFun. Nagios uses logos that are 40×40 pixels, so I use Photoshop to resize the icon of the Time Capsule to that size (this is in the Image menu in Photoshop) and then (based on guidance from the Nagios Wiki ) I change the image mode to Indexed from RGB format (also in the Image menu). Because the Time Capsule is a long short box, there is a lot of blank space above the box. That’s ok. The image needs to be square to work properly with Nagios. This work is now saved as a PNG file (I call it time-capsule40.png), transferred to the Nagios server and installed in the Nagios image file location (which on FreeBSD is /usr/local/www/nagios/images/logos by default). The final step is to create another version of the icon in GD2 format. When the gd FreeBSD port is installed (as part of installing Nagios), pngtogd2 is also installed. I do the conversion by entering the command line pngtogd2 time-capsule40.png time-capsule.gd2 0 1 to create an uncompressed GD2 formatted icon file (The Nagios FAQ suggests it be uncompressed).

To add the host to Nagios, I create a template for Time Capsule devices (I have three in my network) and then create a host object for each Time Capsule referencing that template. Here is the template entry:


define host{
name apple-time-capsule
icon_image time-capsule40.png
statusmap_image time-capsule.gd2
vrml_image time-capsule40.png
use generic-switch
register 0
}


Because I am using Nagios 3.2.1, I can take advantage of a new feature in Nagios 3 by putting the information on the images directly in the host template. The old approach of using a hostextinfo object still works as well, but is deprecated in Nagios 3 and will likely no longer work when Nagios 4 comes out.

With the host template in place, I now add the three Time Capsules in my network using these objects:


define host{
use apple-time-capsule
host_name red-tc
alias Red Time Campsule
address 192.0.2.2
hostgroups wireless-ap
parents blue-tc
}



define host{
use apple-time-capsule
host_name blue-tc
alias Blue Time Campsule
address 192.0.2.3
hostgroups wireless-ap
parents switch
}



define host{
use apple-time-capsule
host_name green-tc
alias Green Time Campsule
address 192.0.2.4
hostgroups wireless-ap
parents blue-tc
}


Besides host availability, I want to know that all the interfaces in the Time Capsule are operational. To do that, I am using the check_ifstatus plug-in. Here is the service object to activate this checking:


define service {
service_description Network Interface Status
check_command check_ifstatus!public
use network-service
host_name red-tc,green-tc,blue-tc
}


Now, with a restart of Nagios, these three Time Capsules will be checked for availability with ping and have the status of the interfaces checked using check_ifstatus using SNMP version 1 and a community of public.

Logging data for service testing results (when everything is working properly) should look like this:


[05-11-2010 00:00:00] CURRENT SERVICE STATE: red-tc;Network Interface Status;OK;HARD;1;OK: host '192.0.2.2', interfaces up: 6, down: 0, dormant: 0, excluded: 0, unused: 0
[05-11-2010 00:00:00] CURRENT SERVICE STATE: green-tc;Network Interface Status;OK;HARD;1;OK: host '192.0.2.4', interfaces up: 6, down: 0, dormant: 0, excluded: 0, unused: 0
[05-11-2010 00:00:00] CURRENT SERVICE STATE: blue-tc;Network Interface Status;OK;HARD;1;OK: host '192.0.2.3', interfaces up: 7, down: 0, dormant: 0, excluded: 0, unused: 0


blue-tc shows 7 interfaces because  its wan interface is in use. This port is not used on the other two since they are being used to extend an existing wireless network. Two other configuration notes:

1. The Time Capsules are configured with static IP addresses. While not strictly required, I don’t want to have to depend on DNS resolution in order to monitor devices on my network, so I choose to statically configure devices that are not portable.
2. The Time Capsules are configured to respond to SNMP queries (version 1 or 2c only) using the community public.

Now, I am able to see the Time Capsules in my status map as well as get notices from Nagios should any interface go down any of the Time Capsules become unavailable.

At its heart, MRTG is a polling engine and is usually used to grab two scaler data items (usually via SNMP) which by default are added to PNG-based graphs which are made available though a web page. There have been several tutorials on how to setup MRTG. A good one is available in a book called Open Source Network Administration (Prentice Hall Series in Computer Networking and Distributed Systems) and is available on the web as of this posting at http://www.informit.com/articles/article.aspx?p=102611&seqNum=4. On FreeBSD, MRTG is available via The FreeBSD Ports collection in /usr/ports/net-mgmt/mrtg directory and can be installed from there very easily.

In this posting, I am using cfgmaker and indexmaker. Both come with the MRTG package and are useful ways to quicky generate the configuration files used by MRTG and then build a web page that can display the PNG-graphs generated when MRTG does its polling.

Recently, I was updating the pages I maintain for the Southeast Texas GigaPOP (SETG), a consortium of higher-education institutions that make use of a Houston-area MAN to facilitate high-speed network connections among themselves and to the Lonestar Research and Education Network (LEARN). I had been using MRTG for years to plot the usage on the links that make up the MAN and wanted to update that installation to the latest software. Because the MAN make use of Cisco Catalyst 6500 switches and a Juniper MX-Series switch, I thought it would be great to make use of the new experimental features to make the usage information easier to navigate and eliminate information that would not be interesting to the consortium members.

The new experimental features in cfgmaker seem to be optimized for Cisco Systems gear and that made it very easy to customize the configuration file for the Cisco Catalyst 6500s in the SETG MAN. For these devices, I was primarily interested in reporting on the input and output usage on the physical interfaces. To create a configuration file just for those interfaces, I invoked cfgmaker using this command line:

cfgmaker --ifdesc=alias --global 'options[_]:bits' --global 'WriteExpires:Yes' --global 'IconDir:/icons/' --global 'WorkDir:/local/mrtg/data/devicename' --output='/local/mrtg/cfg/devicename.cfg' --if-filter='((!$if_is_ciscovlan && !$if_is_loopback && $if_type!=53 && $if_type!=1) && $if_admin && $if_oper)' --snmp-options=:::::2 community@device.gigapop.gen.tx.us

The experimental feature exploited here is the if-filter directive. In this particular case, I didn’t want anything related to Cisco VLANs, Loopbacks or devices of type 1 (a catch-all for types not specified in the SNMP standards) or 53 (a virtual interface). I wanted the interfaces reported on to be both administratively and operationally up. This generated a configuration file that contained only physical interfaces and that satisfied my requirements for these devices.

For the Juniper MX, it was harder because the SNMP device type reported for the management port and some other ports that were not of interest would not be covered by the same filter. So, I modified the filter for the Juniper to explicitly exclude the devices with descriptions that matched the names of the devices that were not of interest. The command line I used for it was this:

cfgmaker --ifdesc=alias --global 'options[_]:bits' --global 'WriteExpires:Yes' --global 'IconDir:/icons/' --global 'WorkDir:/local/mrtg/data/devicename' --output='/local/mrtg/cfg/devicename.cfg' --if-filter='((!$if_is_loopback && $if_type!=53 && $if_type!=1 && $if_type!=135 && ($if_description !~ /em|fxp|pd|pe|gr|ip|vt|mt|pd/)) && $if_admin && $if_oper)' --snmp-options=:::::2 community@devicename.gigapop.gen.tx.us

Here I added device type 135 (Layer 2 VLAN using 802.1Q) and used the $if_description along with a Perl pattern binding operator to eliminiate those devices with descriptions that were not of interest.

After I updated mrtg to use the new configuration files in its polling, I was ready to use indexmaker to build the index pages. The only thing I was doing different from the default here is setting the title of the page. The command line looks like this:

indexmaker --title="Devicename Node" /local/mrtg/cfg/devicename.cfg

The results of all this work is available at http://www.gigapop.gen.tx.us/mrtg/. [Due to some idiosyncrasies with how IPv6 is currently configured for SETG, you may want to try the IPv4 URL which is http://www.ipv4.gigapop.gen.tx.us/mrtg/.]

Of course, there are more experimental features available in MRTG than if-filter, but it was the one I thought most interesting and about which I could not find much information in other blogs. I do hope that the MRTG team will keep it in the software as they continue to develop the next release of MRTG.

There are basically two types of self-signed certificates: those that are signed by a local certificate authority and those that aren’t. To determine which is needed depends on the requirements of the specific application. In this blog, I will cover both types of certificates and list with which applications I use each type. By the way, if you need a reminder about the typography used in this post, look here.

Creating a Self-Signed Certificate with a Certificate Authority

Essentially, this requires creating two self-signed certificates: one for the Certificate Authority and one for the server certificate.

1. Create a local certificate authority (CA) on the server. I typically do this in the /etc/mail. As the root user, type cd /etc/mail; mkdir CA; cd CA, chmod 700 . to create the CA root directory and protect it.
2. Type mkdir certs crl newcerts private; echo "01" > serial; touch index.txt to create the required directories and files for the local CA.
3. Finish up by typing ln -s ../CA demoCA to insure the CA points to this working directory.
4. Now, it’s time to create the CA certificate and key. I set it to be valid for the next 3650 days instead of the default 365. Type openssl req -nodes -new -days 3650 -x509 -keyout private/cakey.pem -out cacert.pem and here is a sample session that shows the dialogue produced by this command if run on a host called shemp.academ.com:

   Generating a 1024 bit RSA private key
   .........++++++
   ...............................++++++
   writing new private key to 'private/cakey.pem'
   -----
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [AU]:US
   State or Province Name (full name) [Some-State]:Texas
   Locality Name (eg, city) []:Houston
   Organization Name (eg, company) [Internet Widgits Pty Ltd]:Academ
   Organizational Unit Name (eg, section) []:SSL Certs
   Common Name (eg, YOUR name) []:shemp.academ.com
   Email Address []:postmaster@shemp.academ.com
   

5. Type openssl req -nodes -new -x509 -keyout server.key -out server.ucrt to produce the SSL certificate. Here is a sample session that shows the dialogue produced by this command if run on a host called shemp.academ.com

   Generating a 1024 bit RSA private key
   ...++++++
   ................++++++
   writing new private key to 'server.key'
   -----
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [AU]:US
   State or Province Name (full name) [Some-State]:Texas
   Locality Name (eg, city) []:Houston
   Organization Name (eg, company) [Internet Widgits Pty Ltd]:Academ
   Organizational Unit Name (eg, section) []:SSL Certs
   Common Name (eg, YOUR name) []:shemp.academ.com
   Email Address []:postmaster@shemp.academ.com
   

6. A certificate request must now be created. Type openssl x509 -x509toreq -in server.ucrt -signkey server.key -out server.csr to create the certificate request. Here is a sample session that shows the dialogue produced by this command if run on a host called shemp.academ.com:

   Getting request Private Key
   Generating certificate request
   

7. Finally, sign this request with the CA certificate. Again, I set it to be valid for the next 3650 days instead of the default 365 days. Type openssl ca -policy policy_anything -days 3650 -out server.crt -infiles server.csr to generate the final signed certificate. Once again, the sample session on shemp.academ.com:

   Using configuration from /etc/ssl/openssl.cnf
   Check that the request matches the signature
   Signature ok
   Certificate Details:
           Serial Number: 1 (0x1)
           Validity
               Not Before: Mar  6 22:46:03 2010 GMT
               Not After : Mar  3 22:46:03 2019 GMT
           Subject:
               countryName               = US
               stateOrProvinceName       = Texas
               localityName              = Houston
               organizationName          = Academ
               organizationalUnitName    = SSL Certs
               commonName                = shemp.academ.com
               emailAddress              = postmaster@shemp.academ.com
           X509v3 extensions:
               X509v3 Basic Constraints:
                   CA:FALSE
               Netscape Comment:
                   OpenSSL Generated Certificate
               X509v3 Subject Key Identifier:
                   3C:37:11:AE:1F:60:44:F7:4D:08:90:BC:32:20:56:22:41:4E:C1:AF
               X509v3 Authority Key Identifier:
                   keyid:64:FD:A2:0D:2C:87:06:17:DA:2E:BB:07:CE:D0:85:D2:BB:31:FD:18
   
   Certificate is to be certified until Mar  3 22:46:03 2019 GMT (3650 days)
   Sign the certificate? [y/n]:y
   
   1 out of 1 certificate requests certified, commit? [y/n]y
   Write out database with 1 new entries
   Data Base Updated
   

For software (like sendmail) where this type of certificate is required, the CA certificate (cacert.pem), server certificate (server.crt), and server key (server.key) are required. As long as the hostname in these certificates matches what the software expects the hostname to be, these same certificates can be used with apache and cyrus-imapd.

Creating a Self-Signed Certificate without a Certificate Authority

1. Make a fresh directory in your home directory to use as a work space for this work and cd into it.
2. Next, protect that directory from access by others by typing chmod 700 . and only you (and root) will be able to get into the directory.
3. To generate the key, type openssl genrsa -des3 -out server.key 1024. openssl prompts for a password. I use something easy to remember since I only need it for a short period of time.
4. The next step is to create the self-signed certificate. Type openssl req -new -x509 -nodes -sha256 -days 3650 -key server.key -out server.crt. openssl prompts for several items of information. The County Name is the two letter
   Here is an example of making a self-signed certificate for the server named shemp.academ.com:

   Enter pass phrase for server.key:
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [AU]:US
   State or Province Name (full name) [Some-State]:TX
   Locality Name (eg, city) []:Houston
   Organization Name (eg, company) [Internet Widgits Pty Ltd]:Academ
   Organizational Unit Name (eg, section) []:SSL Certificates
   Common Name (eg, YOUR name) []:shemp.academ.com
   Email Address []:postmaster@academ.com
   

5. You probably don’t want to type the password for the key every time you start up the service using the SSL certificate, so remove the password from the key.
   • First, make a copy of the key. Type cp server.key server.key.orig.
   • Remove the password from the key. Type openssl rsa -in server.key.orig -out server.key

Use this key (server.key) and certificate (server.crt) for apache and cyrus-imapd on those systems where a SSL/TLS-enabled sendmail is not running.

Learning More

There are a number of good resources to read about SSL. Check http://www.openssl.org for the current status of the openssl software. You can read more in the book Network Security with OpenSSL where there is more extensive discussion of the process outlined in this posting in Chapter 5. A good web page on setting up sendmail to use STARTTLS properly is at http://www.technoids.org/starttlstut.html. The Apache Project provides details on using these certificates on their web server software at http://httpd.apache.org/docs/2.1/ssl/ssl_faq.html. I have updated my posting about cyrus to include how to add TLS/SSL to it.

When considering the system requirements, a key consideration is on how the IMAP server will be used. Will there be a large number of users? How many messages will need to be handled per hour? What IMAP clients are the users typically going to be using? One of the best discussions on this is in a book now 10 years old called Managing IMAP from Dianna Mullet & Kevin Mullet and published by O’Reilly. In Chapter 16 where they discuss performance tuning, they advise that Disk I/O is the biggest concern, followed by memory and then by bandwidth. In the last 10 years, there have been significant improvements in all three of these areas, but it is wise to be mindful of these same things when setting up a server. In particular, I would recommend the fastest disks connected the fastest possible way to the computing sub-system of your computer and a reasonably large chunk of memory for the system. For my latest generation IMAP servers (running Cyrus), I use Core Duo CPUs with 2Gb of memory and SATA 7200rpm Seagate Black 1TB drives. Setting up RAID is recommended as well as doing some kind of disk-to-disk backup. This will make it possible to recover quickly should something go awry. Because FreeBSD makes good use of multiple CPUs, parts of Cyrus can run on different CPUs at the same time and improve overall performance for certain tasks. My choices are based on my need to store a large number of messages for a long time, do lots of indexing to make searching easier, do inbound message sorting and filtering (using sieve) on a moderate number of messages per hour (less than a thousand). Those of you who are interested in doing this on Linux may want to read a more recent book called The Book of IMAP: Building a Mail Server with Courier and Cyrus where the authors, Peer Heinlein and Peer Hartleben, discuss the relative merits of the Ext3, ReiserFS 3 and ZFS on Linux (chapter 4). For small servers (20 users or less), they are satisfied with the performance of the standard Ext3 file system.

Since Cyrus maintains a common message store for all users (kinda like /var/mail for traditional Unix Mail), I recommend that this store be put on its own disk partition. I use a full 1TB drive for this. This will limit the growth of the store without using quotas. I also recommend that this store not be on the same partition as the MTA’s queue. There are a number of other database files that Cyrus uses. By default, these will be placed in the /var/imap directory. I recommend that the /var partition be bigger than you may normally use for these imap server systems. I have allocated 100GB /var on the systems I use. I don’t personally use OS quotas on these systems. I recommend that if you want to use quotas, you use the Cyrus built-in quota system. I don’t intend to discuss the details here, but you can read more about setting quotas up in The Book of IMAP: Building a Mail Server with Courier and Cyrusin Chapter 14.

As with any ports-based installation on FreeBSD (for recent versions of FreeBSD), it’s best to be sure the latest copy of the ports is on the system. portsnap is the easy way to get this done. As root, type portsnap update portsnap has been used to update /usr/ports before. If not, type portsnap fetch followed by portsnap extract.

Once the /usr/ports update is complete, type cd /usr/ports/mail/cyrus-imapd23 and type make to get the installation started. A page full of options is displayed. The defaults are fine, so tab down to OK and hit enter to move on. Now, type make all install.

Cyrus uses SASL to handle authentication, so if the cyrus-sasl2 package has not been installed previously, it will be installed to meet the prerequisites for cyrus-imapd23. I recommend using the Berkeley DB option and the defaults for the rest. Tab down to OK and hit enter to move on. There are some other things that cyrus-sasl2 will install in order to make it possible to build the package, but none of these will require further interaction.

When everything is done, there are still some post-installation tasks to do. Here is a list:

• Add an entry for the sieve service to /etc/services. Typically, this is recommended to be port 4190 over TCP, but any port is fine as long as it is the same for all the systems that will access this system.
• If my recommendation to put the mail store on its own partition was followed, then modify /usr/local/etc/imapd.conf to update the line that starts with partition-default:. Replace the default (/var/spool/imap) with the full path to the location where the mail store is mounted. On my systems, I use /store, so I have a line that looks like this: partition-default: /store.
• To make use of the saslauthd for authentication, another line in /usr/local/etc/imapd.conf needs to be changed. This line starts with sasl_pwcheck_method:. Replace the default (auxprop) with saslauthd.
• Make cyrus the name of the cyrus-imapd administrator by adding admins: cyrus to /usr/local/etc/imapd.conf
• Set the password for cyrus in the SASL database. Type /usr/local/sbin/saslpasswd2 cyrus and then enter the password for this administrative account.
• Prep the mail store by running /usr/local/cyrus/bin/mkimap.
• Add cyrus_imapd_enable="YES" to /etc/rc.conf on the server
• Setup logging.
  • Type touch /var/log/local6.log.
  • Add local6.debug /var/log/local6.log to /etc/syslog.conf
  • Restart syslogd by typing /etc/rc.d/syslogd restart
  • Add /var/log/local6.log 600 7 * @T00 JN to /etc/newsyslog.conf
• Install the saslauthd daemon and start it.
  • Type cd /usr/ports/security/cyrus-sasl2-saslauthd and then make.
  • Select the Berkeley DB option and use the rest of the defaults. Tab down to OK and hit enter to move on.
  • Add saslauthd_enable="YES" to /etc/rc.conf on the server.
  • Add saslauthd_flags="-a sasldb" to /etc/rc.conf on the server.
  • Start the saslauthd server. Type /usr/local/etc/rc.d/saslauthd start.
• Start the cyrus-imapd daemon by typing /usr/local/etc/rc.d/imapd start.
• To add a mail user called jdoe, type su -m cyrus to become the system user cyrus and then login as the mail administrator cyrus using cyradm.
  • Type cyradm localhost and hit enter.
  • Type cm user.jdoe and hit enter.
  • Type quit to exit cyradm.
• Set the password for jdoe in the SASL database. Type /usr/local/sbin/saslpasswd2 jdoe and then enter the password for this mail user account.
• Validate the installed by typing imtest -a jdoe. Type the password entered in the previous step and hit return. Here is an example of the dialogue:

  testhost# imtest -a jdoe
  WARNING: no hostname supplied, assuming localhost
  S: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=NTLM AUTH=LOGIN AUTH=PLAIN AUTH=GSSAPI AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR COMPRESS=DEFLATE] testhost.example.com Cyrus IMAP v2.3.16 server ready
  C: A01 AUTHENTICATE DIGEST-MD5
  S: + bm9uY2U9InliSUF5Nmx3RlVJMFhlSkZraUI3SzloWitCOUFDWGFDVitmbmpTaHYwTkU9IixyZWFsbT0ic2hlbXAuYWNhZGVtLmNvbSIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M=
  Please enter your password:
  C: dXNlcm5hbWU9InNiYXJiZXIiLHJlYWxtPSJzaGVtcC5hY2FkZW0uY29tIixub25jZT0ieWJJQXk2bHdGVUkwWGVKRmtpQjdLOWhaK0I5QUNYYUNWK2ZualNodjBORT0iLGNub25jZT0iWWZMMjFad2RrTzdGNDJIY0Y2S2tlZUJ1RFoxNDVhTkFOTHBJU25xTUZrVT0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVyPXJjNCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJpbWFwL2xvY2FsaG9zdCIscmVzcG9uc2U9YmNjMmE5OTdjZTQ5NTA5ZDczZWUyMDNlNWNlMzkzZTE=
  S: + cnNwYXV0aD1jM2FmOGMzMDc3OWY4OWFmNzg2MTE1NzhkNDQ3NzQ0Zg==
  C:
  S: A01 OK Success (privacy protection)
  Authenticated.
  Security strength factor: 128
  C: C01 CAPABILITY
  S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID LOGINDISABLED AUTH=NTLM AUTH=LOGIN AUTH=PLAIN AUTH=GSSAPI AUTH=DIGEST-MD5 AUTH=CRAM-MD5 COMPRESS=DEFLATE ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE URLAUTH
  S: C01 OK Completed

  Note: The Digest-MD5 strings sent by the server may be poorly formatted in this example. I would have prefer that they wrap, but I am stilll learning how to get the formatting to look right for that. If you have a hint or trick that can help me wrap it properly, contact me.

To integrate this with sendmail the default local mailer needs deliver to cyrus. This is done by changing the /etc/mail/sendmail.cf file. Here are the steps:

• Become the root user and type cd /etc/mail.
• Type make to create the hostname-based mc file.
• Add the following three lines to hostname-based mc file.

  define(`confLOCAL_MAILER',`cyrusv2')
  define(`CYRUS_MAILER_PATH',`/usr/local/cyrus/bin/deliver')
  MAILER(`cyrusv2')

• Now type make stop; make all; make start.

The IMAP server is ready to receive SMTP mail for jdoe. Keep in mind that by default cyrus is setup to use an authentication scheme that requires NTLM, DIGEST-MD5, or GSSAPI. The IMAP client needs to be properly configured to use one of these authentication schemes. I use DIGEST-MD5.

What about using TLS/SSL?

It’s pretty easy to setup TLS/SSL on cyrus.

• First, a properly signed certificate must be available that matches the hostname of the server on which cyrus is running. I have written a posting on setting up a self-signed certificate.
• Next, the /usr/local/etc/imapd.conf configuration file must be modified to define the following items:
  • tls_cert_file: must have the full path to the file containing the server certificate.
  • tls_key_file: must have the full path to the file containing the server certificate key. Note that the cyrus user must be able to read the key file.
• If you are using a certificate authority signed server certificate, tls_ca_file: must have the full path to the file containing the certificate authority certificate used to sign that server certificate.

Generally, I won’t be commenting on the news of the day or reviewing hardware or software here. There are plenty of others who spend time doing that and many do a credible job. I may reference those I believe have done those types of things in a way that resonate with me (and I may do it myself on those rare and exceptional cases I mentioned in the first paragraph of this post), but I don’t expect that to be a regular theme here. I want to cover things that I hope will be of interest to people looking for technical solutions to specific technical problems that I have worked on from time to time (or are working on at the time I write a particular posting). As such, the posts may vary pretty widely within that area as I like to learn all the time. One day, I may talk about how I configure the Apache web server to do something. Another day, I may write about building routing policy sections in  JunOS. I expect I will write about home theater as I like to dabble in that from time to time. Right now, I am not sure what the boundaries will be exactly, so bear with me as I work through this during the start up of this effort.

Every blog post will be open for comments and I will be reading every one one of them, but I will moderate the posts and publish those I consider to be on-point to the original and interesting to read. Spam comments will be treated as such. Feedback via the contact page is also welcome, but please include the title of the posting you are commenting on. Using the contact page won’t make it back to the comments page on the posting, but it could generate some private exchanges with me and may generate some follow-up posting here. I also suggest using the contact page if you have suggestions for postings.

Again, as I wrote on my home page, I appreciate you visiting and spending time reading what I post here. I hope you find it is time well spent.