OpenSolaris

Setting up Solaris 10 to play with SBC Yahoo! DSL

Most Digital Subscriber Line (DSL) carriers serve primarily the PC/Mac markets, so their standard installation instructions only apply to those environments, and they don't claim to support anything else.  But we all know that standards-based Solaris ought to be able to make the same connections, if only you knew how.  In the interest of making this a more-common configuration, this document describes the steps I needed to take to get full external DSL connectivity to a Solaris 10 box.

The steps needed to establish a full SBC Yahoo! DSL connection include the following components:

• SpeedStream 5100-b DSL modem configuration
• Solaris DHCP setup
• SBC Yahoo! DSL registration
• outgoing email via authenticated SMTP
• incoming email via POP3

and also include some other things you will want for an Internet-connected machine:

• Solaris IP Filter
• NTP

These instructions are intended only for your general edification.  Your mileage may vary, and you are solely responsible for verifying any and all ideas and procedures listed here.  Some of this is being typed after the fact, so I hope I remember all the details correctly.

Voice/data line sharing

If you haven't had a DSL line before, the following general description may help you understand the setup.

DSL capability can be added to an existing phone line.  When this is done, the same circuit (the two-wire "last-mile" loop between your phone jack and the phone company) can carry both voice (low-frequency) and data (high-frequency) communications at the same time.  Thus for a simple home installation, there is probably no need to order a second phone line in order to get DSL service.

However, the voice and data traffic must be safely and cleanly multiplexed on the same wires.  This is done using DSL filters.  A simple wall-phone filter suppresses all the data signals and allows only the voice signals to pass.  It's a thin box that fits between the wall jack and your phone, allowing it to still be hung on the wall as before.  In contrast, for desk-phone jacks, a DSL splitter/filter is a short (6-inch) cable which at one end has a phone plug that plugs into the wall jack, and at the other end houses a simple electronic circuit that separates/combines the voice and data signals.  This end of the splitter/filter has two jacks, one to plug a phone cable into and one to plug a data cable into.  Either jack can be left unfilled, but you must install such a splitter/filter on each wall jack in use for either voice or data traffic.  The same wall jack can serve both uses, by connecting both a phone and the DSL modem to the same splitter/filter.

Equipment

The contents of the equipment packages are not spelled out very well on the SBC website.  The basic $99 self-install equipment package came with:

• an Efficient Networks SpeedStream 5100-b DSL modem and power supply
• a 6-foot Ethernet cable, for connecting between your Sun box and the DSL modem
  
• a 14-foot data cable, for connecting between the DSL modem and the DSL filter on the phone line
• one DSL filter for a wall-mounted phone
• four DSL splitter/filters for other phone jacks
• installation instructions and CD-ROM software for a PC or Mac

Other equipment packages are available.  For details, check the SBC website, or call SBC.

You should also be aware that pulse dialing is a big no-no on a DSL line, because of the way it interrupts the circuit (and probably causes large, noisy, potentially damaging transients).  This means that if you have any rotary phones still in use, you must replace them with push-button phones (and set them to use tone dialing).  Replacing old phones is not necessarily expensive; for instance, Panasonic has a basic no-frills model for $15 (and as of this writing, free UPS Ground shipping).

On the computer side, you will of course need a free Ethernet port to connect to the DSL modem.  Whether this is a direct attach to your computer, or occurs through hub/switch/router/bridge equipment, depends on your own in-house network setup.

Surge protection

Presumably you are already using power-line surge protection for all computer components.  But with DSL, you now have a different way for lightning-induced electric surges or other transients to snake their way into your equipment.  This is a complicated area full of obfuscational fog.  You may wish to look at products such as the following from Panamax, which combine power-line, telephone-line, and perhaps LAN-line protection into a single unit, and may be extendable with add-on modules to provide protection on other connections as well:

• M8T-EX
• PM8T-EX
• SurgeProtector8™ Tel

There are at least two key things to watch out for when you purchase and install such equipment.  One, from an electrical point of view, it makes a big difference how you plug everything together.  Do it the wrong way, and you may unintentionally leave some unprotected path for surge currents to flow, and be voiding your connected-equipment warranty to boot.  This is especially problematic when you're trying to protect a whole group of equipment, not just one box.  Get advice from the manufacturer if you're in doubt.  The other issue is to be careful where you buy this equipment.  If you do not purchase direct from the manufacturer or from an authorized dealer, your connected-equipment warranty may be invalid.  See the manufacturer's website to find an authorized local or Internet dealer.

Ordering

The maximum attainable DSL data-transfer speed on your phone line depends partly on the electrical distance between your wall jack and the phone company's central-office equipment.  You'll have to call them to see what is available for your particular connection, and what the monthly rates are for different service packages.  In my case, for this initial foray I chose the least-expensive package, which provides only a single dynamic IP address.  Hence, later in these instructions you will see I needed to set up DHCP on the Sun box.

Check the SBC website for promotional deals (less costly than if you order by phone).  You can still call them up before you order and ask questions, though.  As to the chicken-and-egg problem of how you get to their web site without first having DSL installed, well you probably wouldn't be reading this without such a connection.  Perhaps your local community has a place like the public library with short-term-use public Internet terminals available.

Once the order is submitted, it takes a few days for the self-install kit to arrive, and about a week for the DSL provisioning on your phone line to be turned on.  You may run into a little confusion about the exact time the service is available.  The service is "provisioned" at the point where the phone company has turned on the DSL signals on your phone line, but it's not fully "activated" after that until you've gone through the registration process (below).

Security

With a connection to the Internet, you will become the potential target of all manner of security infestation.  The time to deal with this is now, while you know your system is still clean.  Lock down your Sun system with at least the following measures:

• Consider setting up BART to perform automated file integrity checking, and save one or more snapshots of your system now before any modifications are made.
• Turn off all unnecessary services.
• Deal with password issues.
• Use standard tools to analyze your existing passwords, to make sure none of them can be easily cracked.
• Consider using the /etc/default/passwd tuneable parameters.
• Consider modifying CRYPT_DEFAULT and related parameters in /etc/security/policy.conf to select a password encryption algorithm which is more secure than the traditional UNIX algorithm.
  
• Make sure you are up-to-date with Sun security and recommended patches.
• Set up Solaris IP Filter (see the System Administration Guide:  IP Services manual, and the following section below).
• Edit your browser's security settings (block pop-ups, disable Java, restrict cookies, etc.) to get as good a level of security as you feel comfortable with.

There are other, more detailed, steps to take as well.  Sun has a BluePrints article for Solaris 9 that covers security lockdown issues.  Consider either following its advice (while looking out for mechanisms that are now different in Solaris 10) or watching for an updated version pertaining to Solaris 10.

See the References list below for some links to other resources.

Solaris IP Filter setup

At this point, you may not think that the firewall setup (Solaris IP Filter) is really necessary for your machine.  But once you do set it up cleanly and start logging the blocked attempts to probe your machine from the Internet, you will quickly conclude otherwise.  The simple fact that you're using DHCP will not prevent all manner of intruders from scanning your ports and attempting access, even before the first time you intentionally send any outgoing packets after a reboot.  In fact, DHCP may make the problem worse, by almost guaranteeing some level of noise:  if some Internet machine was recently connected to the last previous machine that owned your current DHCP IP address, it will often try to re-establish the connection, now with your machine instead.

For simplicity of exposition here, the details on IP Filter setup are listed separately.  Additional comments are included below in the context of particular issues.

You will find the following commands most useful during testing, for re-loading Solaris IP Filter rulesets without rebooting the entire machine.  These must all be run as the superuser.

• ipfstat -i                      (list input-filtering rules)
• ipfstat -o                      (list output-filtering rules)
• ipf -Fa                         (flush all rules)
• ipf -Fa -f /etc/ipf/ipf.conf    (flush all rules and load a new set of rules)

DSL modem setup

The SpeedStream 5100-b DSL modem is a small package that packs a lot of punch.  Among its features are:

• It presents its own single fixed IP address on the Ethernet port (typically, 192.168.0.1).  This address and a unique default modem-access security code are shown on a sticker on the bottom of the modem.
  
• It runs a simple HTTP server on the fixed IP address.  Accessing that interface through an ordinary browser, you can view and modify the modem-configuration data.
• It runs its own DHCP server.  Your Solaris box will need to operate as a DHCP client on the interface that talks to the DSL modem, and receive its IP address from the DHCP server on the modem.
• It routes DNS queries to your service provider.
  
• In the default configuration, the DSL modem runs its own PPPoE software to talk over the DSL line to the phone company.  (SBC/Ameritech DSL uses PPPoE as the link protocol; other SBC regions don't use PPPoE exclusively as SBC/Ameritech does.)  This means you don't have to run PPPoE on the Sun box; all network communication to the DSL modem and the wider Internet occurs over ordinary TCP/IP on Ethernet as far as your Sun box is concerned.

The firmware in this DSL modem is not the generic version you would get if you purchased the box on the open market.  Rather, it's been customized for use with the SBC network, and some capabilities in the generic version may not be accessible or configurable in this version.

For the initial modem setup, you'll need to plumb an Ethernet port on your Sun box with a 192.168.x.x IP address (such as 192.168.0.9) so your machine knows it can talk out that port to the modem.  Later on, this fixed address will be replaced with a DHCP configuration.  (Or possibly, you could delay this step until after the DHCP setup on the Sun box.)

Now open a browser to access the modem.  (If you haven't installed a browser from some other source, you can find one in /usr/sfw/bin/mozilla; I'm not sure whether this is part of the standard install or only comes in with the Software Companion software.)  Navigate to http://192.168.0.1 to access the modem's configuration pages.  Go into the Advanced section, and press the Connection Configuration button.  You will be required to enter the DSL modem's access code.  In the Connection Configuration screen, select "No, use private IP address." at the bottom of the screen.  Then call the SBC Yahoo! DSL help line to obtain the User ID and Password to enter at the top of the screen.  They will provide you with temporary values which enable restricted Internet access (only to the SBC Yahoo! DSL registration site at http://help.sbcglobal.net/register).  Save the changes, then reset the modem.  After this, the Internet light on the modem should be lit.

Solaris DHCP setup

Before you begin this section, look on the SunSolve web site for security bulletins and patches that may affect your system (e.g., Security Vulnerability in Solaris 10 "DHCP" Clients and patch 119593-01 [SPARC] or 119594-01 [x86]).

I chose an inexpensive DSL service package which involves only dynamic IP addressing (no static IP address on the Internet for my machine), so it was necessary to configure the Sun box to match.

In my case, I didn't have an Ethernet hub or other standalone network equipment to intervene between my Sun box and the DSL modem.  Instead, my Sun box had a spare Ethernet port available; so I had one Ethernet port (hme0) connecting via a fixed IP address to the rest of my in-house network, and one Ethernet port (hme1) connecting via a dynamic IP address to the DSL modem.  This complicates matters somewhat on the Sun side, because of an interaction between the DHCP setup, the local nameservice domain, and email-setup requirements.  More on that later.

At this point, I logged out, started a Command Line Login session as root, and ran sys-unconfig to reset the machine's configuration and get it to install most of the DHCP stuff using its own configuration procedures.  There were some tricks to configuring the machine during the setup menus once it rebooted.

• If you've been operating your machine beforehand, you should save a copy of /etc/inet/hosts before running sys-unconfig and the reconfiguration, because its contents will be destroyed.  That way, you can easily reconstruct the deleted information afterward.
• You should have in hand the hostnames and IP addresses you wish to assign for all of the non-DHCP network interfaces.
• The Ethernet interface you want to run DHCP on must be selected as the primary network interface, even if it's not the first one listed or the one you otherwise think of as the principal interface in your machine's context.  This selection is necessary in order to get the hosts file constructed correctly (both DHCP and non-DHCP IP addresses listed).  It does have one unfortunate side effect that must be repaired later:  the loghost alias gets lost.
  
• Some necessary configuration is not completed by the reconfiguration menus and boot-time setup.  The missing required steps are listed below.
• I selected "None" as the default route for non-DHCP interfaces, and this worked fine.
• I selected "None" as the local name service, and this worked fine.  As noted below, enough stuff gets configured automatically that the system is still able to resolve external network addresses such as www.google.com .
  

Once the system came back up, I dealt with the complication mentioned earlier.  It had to do with the way the /etc/inet/hosts and /etc/inet/ipnodes files are automatically modified when the Sun box boots up and configures its DHCP port(s).  Both of these files are hacked by the /lib/svc/method/net-svc script, which edits the files so the dynamic IP address has an up-to-date entry in each file.  Unfortunately, the stock net-svc script that ships with Solaris 10 doesn't cleanly maintain the fully-qualified hostname (FQHN) as part of the lines that it appends to the file.  Without the FQHN on the same line, the setup is not correct for sendmail (/usr/sbin/check-hostname shows a problem).  Whether or not this matters to you depends on your email setup (below) and whether other programs also need access to the FQHN.  Fixing this automatically at boot time required a modification to the net-svc script, to include the FQHN on the same line as the bare hostname:

(SPECIAL NOTE:  I have it on good authority from within Sun that if you ever, for some reason, want to modify one of the existing service startup scripts, please do not edit the ones Sun ships.  Make a copy, edit it as much as you need, then modify the start/exec property for the service to point to your changed copy.  That way, your changes won't be overwritten should you install a patch Sun supplies or upgrade to a newer version of the OS.  I haven't worked out all the details yet of how to follow that advice for the net-svc script, but will modify the instructions here shortly when I do.)

*** net-svc.orig	Fri Jan 21 15:38:22 2005
--- net-svc	Sun Jun 12 16:56:06 2005
***************
*** 137,143 ****
  		#
  		/usr/bin/sed -e "/^[ 	]*${ipaddr}[ 	]/d" \
  		    /tmp/${filename}_clear.$$ >/tmp/${filename}.$$
! 		echo "${ipaddr}\t${hostname}\t# Added by DHCP" \
  		    >>/tmp/${filename}.$$
  	else
  		#
--- 137,143 ----
  		#
  		/usr/bin/sed -e "/^[ 	]*${ipaddr}[ 	]/d" \
  		    /tmp/${filename}_clear.$$ >/tmp/${filename}.$$
! 		echo "${ipaddr}\t${hostname}\t${hostname}.${domain}\t# Added by DHCP" \
  		    >>/tmp/${filename}.$$
  	else
  		#
***************
*** 170,176 ****
  			#
  			/usr/bin/mv /tmp/${filename}_clear.$$ \
  			    /tmp/${filename}.$$
! 			echo "${ipaddr}\t${hostname}\t# Added by DHCP" \
  			    >>/tmp/${filename}.$$
  		fi
  	fi
--- 170,176 ----
  			#
  			/usr/bin/mv /tmp/${filename}_clear.$$ \
  			    /tmp/${filename}.$$
! 			echo "${ipaddr}\t${hostname}\t${hostname}.${domain}\t# Added by DHCP" \
  			    >>/tmp/${filename}.$$
  		fi
  	fi

Also note the following about hostname selection.  The hostname by which the Sun box is known on the DHCP (hme1) interface is not, in fact, drawn from the /etc/hostname.hme1 file (though we will, if only as a courtesy for other software which may depend on that file, insert that hostname there).  Instead, the hostname is taken from the Hostname option value provided by the DHCP server, or if no such value is provided, the value in /etc/nodename is used.  Alas, the SpeedStream 5100-b provides no way to configure this client hostname, so its DHCP server does not provide the Hostname option back to the DHCP client on the Sun box, and the /etc/nodename value ends up being used for this interface.  The practical effect is that the DHCP-interface name becomes the de-facto machine name (the one returned by hostname and by uname -n).  This may not be what you had in mind to start with if your machine has other network interfaces.  There doesn't seem to be any good way around this, so be prepared to use some other hostname(s) for the machine's other IP address(es).

Also note the following complication.  Even with the net-svc adjustment shown, other hostname aliases for this machine can still get lost if they are associated with this interface.  Typical aliases you will care about in this context are mailhost, mailhost.domainname, and loghost.  In my case, I attached these aliases to the hme0 interface hostname, so they do not get destroyed by the startup processing.  If your machine has only one Ethernet interface, you may need further adjustments to the net-svc script to preserve these extra aliases as well.

With the net-svc script modification above in place, the remaining steps for DHCP setup are rather easy.  Assuming your chosen DHCP hostname is spider and your chosen local domain name (domainname) is web, you just type:


In practice, the SpeedStream 5100-b DSL modem always returns exactly one invariant IP address to the DHCP client, so perhaps some of the setup above could be simplified.  But playing the game this way does get not only DHCP but DNS established on your machine with very little effort.

Handling an expired DHCP lease

The Solaris machine will periodically need to renew its DHCP lease.  If it cannot, you will eventually see the following message in /var/adm/messages, put there by dhcpagent:


Then this interface will drop its connection to the DSL modem, Internet connectivity will be gone, and the interface will thereafter be non-responsive to outgoing packets.

If this happens to you exactly 24 hours after the last reboot, there's a good chance that the necessary lease-negotiation packets are being blocked by your Solaris IP Filter setup.  This may not be at all obvious, because the negotiation starts with an outgoing packet on port 68 from your Solaris box to port 67 on the DSL modem, and it won't even be logged if it's being blocked.  Unfortunately, the Solaris manual overlooks the requirement to pass such packets and does not include IP Filter rules for them in its example files.  Here's a sample rule to start with:


If this happens to you at some other time, most likely it is exactly 24 hours since the last time the lease-renewal succeeded.  With the IP FIlter rule shown above, you'll be able to see messages like this in /var/adm/messages:


It's that transition from the DSL modem (192.168.0.1) responding to your computer (192.168.1.64), to responding to a broadcast address (255.255.255.255) instead that marks the failure to renew the lease.  Why that happens, I don't yet know.  But  the fact that these packets are being logged as warnings indicates that our IP Filter rules are not letting them through to where the client DHCP agent can see them.  Eventually, the DHCP server gives up on trying to contact the specific DHCP server it was originally talking to, and tries to find some other one by sending a request to the broadcast address:


But again, the DSL modem responds to the broadcast address, and the client cannot see the response.

So what happened here to cause this service interruption when the machine had been up for 6 days (way longer than 24 hours since the last reboot)?  For some reason, the DHCP server in the DSL modem decided not to renew the lease.  Perhaps that has something to do with maintenance on this line at the phone company, or with the telco's own DHCP server deciding it needed to turn over the modem's own IP address as seen by the outside world.  Regardless of how it happens, somehow a new lease negotiation has to happen, and the warning tags in the log file show we are blocking the necessary packets from reaching their destination.  Fixing this requires a modification to the IP Filter rules:


What happens if you don't get this right, and the lease does expire?  Somehow, packets are still received on the disabled interface, at least to the point of reaching the IP Filter.  But no packets of any kind go out.  An ifconfig hme1 dhcp ping command on this interface will just hang indefinitely (poor behavior -- it should be telling you that the interface is down).  The dhcpagent process sleeps forever without waking up to respond to ifconfig or dhcpinfo requests; truss shows:


You cannot even unplumb the interface with ifconfig.  The dhcpagent remains running, but no longer probes for an address to plumb the interface with, so the interface will stay down forever or until you do something about it, whichever comes first.  Killing and restarting the dhcpagent doesn't do any good.

DNS setup

During the reboot and DHCP reconfiguration, /etc/nsswitch.conf gets edited and the dns option is added to the hosts and ipnodes entries, thereby enabling the DNS name service for external Internet access.  Also, /etc/resolv.conf gets automatically updated, and it points to the DSL modem as the nameserver.  No explicit manual work appears to be necessary to get DNS working for ordinary purposes (such as nslookup, ping, and browser access).

At this point, even though you haven't registered your DSL connection yet and cannot browse the Internet, you should be able to at least test connectivity and basic functioning, using nslookup and ping commands:


DSL registration

Completing the connection setup at the service provider end requires that you set up an authenticated account (username and password) associated with your phone number.  This will also serve as your email address on the Internet.  Unfortunately, the DSL registration process cannot be completed using Mozilla on your Solaris machine.  At one point in the procedure, the web pages demand your phone number, but the box into which you would type it does not accept any input.  You'll have to find a PC somewhere, probably running IE, to complete this step of the process.  Navigate to http://help.sbcglobal.net/register to begin.

The registration process will ask you to establish a username and password for your SBC Yahoo! Member ID, then go on to ask for some personal information, and finally try to run some installation software from the CD.  Think carefully about the password you give here.  One of its primary uses will be in retrieving email from the SBC Yahoo! email server, and in that context it will be sent out into the Internet in cleartext (using the POP3 protocol).

You may be able to stop the registration process right after the Member ID is set up, and avoid the annoying practice of having yet another database you don't control that contains more of your personal information (birth date, gender, Industry, and Occupation).  You could test this by re-entering the registration process from the beginning.  If their side already knows your Member ID (based on your phone number) and requests that you enter the password to continue, you may be able to stop right there.

(On the other hand, if you skip this, I suppose they won't have that information on file to validate it's you if you need to call in for help.  Also, one thing this procedure omits by quitting early is the selection and provisioning of various category-A and category-B service options that the service provider allows, such as extra disk space for storage on their servers.  At some point we may want to go back and re-visit this issue to see if/how such capabilities can be accessed.)

Now go back to your Sun setup and get back into the DSL modem's Connection Configuration screen.  Enter your full registered user name (MemberID@sbcglobal.net) and its password, save the changes, restart the modem when prompted, and wait for the on-screen countdown to complete (around 60 seconds).  Don't use the Login page for entering your username/password, as the setting there will not be permanent.

The following pages describe these registration procedures in more detail:

• http://www.broadbandreports.com/faq/8346
• http://www.broadbandreports.com/faq/6454

Note added later:  I seem to recall some options for linking your SBC Yahoo! Member ID with an existing Yahoo! ID.  Think carefully before you do so, if you're considering this.  See http://pixelcort.com/2005/11/16/156/ for the story of a user who regretted doing so because there was then no way to ever undo this linkage.

Email setup

SBC Yahoo! DSL uses separate communication paths for outgoing and incoming email.  This somewhat complicates the setup on your Sun box.  How you configure your email system may also partly depend on which windowing system you will run.

• SBC Yahoo! DSL uses Login-authenticated SMTP for outgoing email, and Password-authenticated POP3 for incoming email (these directions are relative to your Sun box).
• Sun sendmail, as shipped in Solaris 10, does not include the necessary authentication support for SMTP.  It also does not handle POP3-protocol email transfers.  These issues can be resolved by compiling and installing your own version of sendmail, and by using fetchmail for incoming email.
  
• If you run CDE as your windowing system, and use the types of email clients that are typically run in that environment, you will want to set up sendmail and fetchmail as described in detail below.
• If you run the Sun Java Desktop System for Solaris, its Ximian Evolution email client can handle both the Login-authenticated SMTP protocol for outgoing email and the password-authenticated POP3 protocol for incoming email.  All email-transfer setup for this configuration can be handled directly within the email client, so sendmail and fetchmail don't even come into the picture.

In addition to the master email account associated with your SBC Yahoo! DSL account, the service provider also allows you to create up to 10 sub-accounts for email delivery, each with its own externally-visible email address.  We won't discuss that feature here, except to say that you may need to log in to my.yahoo.com and set up the home page for such a sub-account before you will be allowed to send out email from your Solaris machine under that account.

Mail client user interface

You have a choice of how to read and send your mail.  There are many, many mail readers available; for simplicity, I'll mention just four:

• /usr/bin/mailx is a good basic text-based interface, suitable for running in an xterm.  It's okay for ordinary text but won't show you HTML markup (if that matters to you), and support for attachments is a bit clumsy.
  
• /usr/dt/bin/dtmail is the basic GUI-based interface supplied with CDE.  It won't show HTML markup directly (it appears as an attachment).  Attachments are easy to handle, though.
  
• /usr/lib/evolution-1.4 is a full-featured email/calendar application, with GUI support for HTML, attachments, and lots of other fun stuff.  As noted above, this program will handle all of the mail-transport duties in addition to its user-interface capabilities.  I do have a few complaints about it, though, observed in just casual use.
• Thunderbird (http://www.mozilla.org/products/thunderbird/) is a well-known open-source mail and news client.  Unfortunately, it also uses the /usr/lib/esd daemon to play a "Custom .wav file" when new mail arrives, and suffers from the same distortion and hangup problems as Ximian Evolution.  It seems to work okay with the "System New Mail Sound", though, which doesn't go through this daemon.
  

The Ximian Evolution mail client can be used even under CDE.  I set up a ~/.cshrc alias for it:


to make it trivial to start in that context and not leave a background job hanging around visible to the current shell.  I redirected the output and error streams because this program has a habit of dumping out lots of warning and error messages, as described in the Evolution complaint list.

The first time you run Ximian Evolution, it will invoke a configuration process that will enable you to enter all the appropriate email-connection values (your SBC Yahoo! DSL email address, and other information taken from the DSL installation guide).  Use the clues above if you are uncertain about anything.  You can also edit these settings later on.

The following partial lists of keyboard accelerators may help you work this tool more easily.  There's no space here to go into detail about when each of these actions are appropriate; use the tool's help facility for that.

Evolution Main-Window Keyboard Shortcuts
Action	Shortcut
create new email	Ctrl-N (when in an email folder), Shift-Ctrl-N (elsewhere)
delete email	Ctrl-D
undelete email	Ctrl-U
expunge	Ctrl-E (use to remove read mail from "unread mail" vfolder)
select all	Ctrl-A
mark selected message as read	Ctrl-K
mark selected message as unread	Shift-Ctrl-K
send and receive messages	F9
go to next unread message	] (useful when you open Inbox or the "unread mail" vfolder)
go to previous unread message	[
reply to sender	Ctrl-R
reply to all	Shift-Ctrl-R
forward message	Ctrl-F
apply filters	Ctrl-Y
quit	Ctrl-Q

Evolution Composition-Window Keyboard Shortcuts
Action	Shortcut
send	Ctrl-Return
undo	Ctrl-Z
redo	Ctrl-R
cut	Ctrl-X
copy	Ctrl-C
paste	Ctrl-V
add attachment	Ctrl-Alt-A
spell check	Shift-Ctrl-L
close window	Ctrl-W

Outgoing email

Email sent from your network into the outside world will be transported via SMTP to your DSL carrier's mail-relay server.  Ordinary sendmail can handle this, but SBC Yahoo! now requires SMTP Login authentication on this connection to cut down on spam and other nastiness.  Unfortunately and somewhat surprisingly, the standard /usr/lib/sendmail supplied with Solaris 10 is not compiled with support for such authentication.  Therefore, if you want to run a mail client that doesn't directly handle the mail-transfer functions, you will need to download the sendmail source code and compile it yourself with appropriate options.  What you might lose in this step is unclear to me.  You may get a more up-to-date version, but perhaps lose some specific changes/extensions that Sun put into their copy.  One option might be to start with a copy from http://www.opensolaris.org/, presuming that sendmail and/or the Sun-customized makefiles get included in that distribution.  Since the install process involves replacing the existing binary using the same pathnames, how any of this might affect later updates through Sun's automated patch services is also unknown to me.

After some experimentation, and despite the problems referred to above, I ultimately decided that Ximian Evolution suited my needs.  So I did not replace sendmail and don't have the complete procedure laid out for you here.  But I don't send email directly to any other users on my own local network.  Such a need might still require the use of sendmail in some capacity, and you should run your own tests if that capability is important to you.

Incoming email

Email from the outside world has to be brought back from the SBC Yahoo! servers to your Sun box, from whence it can be redistributed as needed.  If your email client doesn't do this (e.g., Ximian Evolution can be configured to perform the retrieval for a single mail client), you'll have to set it up separately.  A standard open-source program called fetchmail is available for this task.  If you've installed the Solaris Companion Software, it's already on your machine (/opt/sfw/bin/fetchmail).  If not, you can get a copy from www.sunfreeware.com, or from its home page (http://catb.org/~esr/fetchmail/).

Incoming email is transferred from the SBC Yahoo! servers to your machine using the POP3 protocol.  Why this was chosen over the more up-to-date IMAP protocol is unknown to me.  Once fetchmail has the content in hand, it passes it to your local sendmail for distribution on your network.

Here's a simple fetchmail configuration that will get you started.

• Make sure /opt/sfw/bin is in your command-search path; type fetchmail -V to verify.
• Edit ~/.fetchmailrc and populate it with the following lines:

• pop_server is the fully-qualified hostname of the POP server as listed in the installation guide you received with your modem
  
• email_address is the full MemberID@sbcglobal.net (or equivalent) string that people on the Internet will use to send email to you
  
• password is the same string you used to register your DSL account (and entered into your modem); this will be sent on the wire as cleartext during the POP3 email-transfer processing, so it's not terribly secure
  
• local_name is the UNIX account on your Sun box to which you want the email directed
  

• Give the ~/.fetchmailrc file 600 permissions.
• Run the following commands from your own login account:

If you adopt this type of setup, you should go the extra mile and figure out how to start fetchmail in daemon mode, under your own login account, at boot time.

NTP setup

Now that you have a connection to the outside world, you ought to take advantage of it to establish an accurate clock for your own network.  The instructions here will help you do that.  They are geared toward a "good enough" installation, one that will get you a combination of accurate time and reasonable security without much effort.  See the references below if you wish to explore this area in more detail, especially if you have a need beyond "good enough".

NTP can be set up both as a client to the outside world, to mirror its accurate clocks into your own local domain, and as a server to your own network, so the rest of your machines can be synchronized as well.  As part of this, you might consider a manual installation of NTP Version 4 instead of the now-deprecated NTP Version 3 software that still ships with Solaris 10.  (See http://ntp.isc.org/bin/view/Servers/RulesOfEngagement for details.)  The following instructions, though, assume you just use what Sun provides; there might be some advantage to doing so because of Sun's work in integrating the clock-discipline code with the Solaris kernel, or simply because Sun provides support for the version they ship.  If you do install a later release, the configuration setup may be somewhat different because new options are available and the semantics of existing options may have changed.

Sun's standard documentation for setting up NTP is not just inadequate, it's just plain wrong.  (In the System Administration Guide: Network Services, Chapter 3 ["Time-Related Services"], it says all you have to do to set up an NTP server is to copy the sample ntp.server file to ntp.conf and start the daemon.  Nothing is said about the required customization of the sample server file before you use it for production.  Similarly, for setting up an NTP client, it says nothing about the proper selection of other hosts for the time source, and making sure you actually receive the time-synchronization messages.  Caveat lector.)  A better source of information from Sun is the set of three Sun Blueprints articles mentioned in the references below.

Side note:  the DSL modem itself already keeps its own internal clock synchronized with the Internet.  My copy shows that it points to two public stratum-1 NTP servers for this purpose.  That seems like a really bad idea to me, considering that both of the chosen servers are stratum-1 (inappropriate for general leaf-node clients), both are restricted-access servers, SBC is on a big promotional kick to sell millions of new DSL connections, and the load from all of those new customers will be directed to the same public first-tier servers.  In any case, I don't see any hint that the DSL modem can in turn function as an NTP server, so we have to go outside for that.

So let's get down to business.  You will first need to set up your Solaris machine as an NTP client of external time sources.  To do this, start by creating /etc/inet/ntp.conf with the following contents:


That setup assumes you're located in the United States or Canada.  If your machine lives elsewhere, see the list of pool-server virtual hostnames at http://ntp.isc.org/bin/view/Servers/NTPPoolServers and choose some which are more appropriate for your location.  Be aware that the advice given there on how to verify your DNS server is doing round-robin resolving correctly is a little suspect.  My experience is that instead of showing repeated copies of the same server (if the round-robin resolution is failing), the "ntpq -pn" command output will simply show one copy.

Modify the permissions of the NTP configuration file:


Set up IP Filter rules to allow the NTP packets through:


and load those rules into active service:


Before you start NTP the first time, force a coarse synchronization with the outside world.  It may be best to do this while the system is in single-user mode, right before a reboot, to prevent any application problems if the time needs to be stepped backward or by some large amount.  Once the service is enabled, this synchronization will happen anyway when the machine restarts after a reboot, but executing it once now gives you a chance to see what will happen then and correct any problems right away.


Finally, you must start the NTP service manually the first time.


Thereafter, it will start automatically on each reboot.

If failures occur, /var/adm/messages may contain some error lines.  Otherwise, the system will be fairly silent about problems, so you need to be proactive about verifying your initial setup.  Fortunately, the basic command to do so is not difficult:


After the service has been up about a minute, this should show the status of the servers you're connected to.  The numbers at the end of each line will change over time as the NTP daemon collects more data and eventually converges on what it believes is the true time.  Interpreting this output, and for that matter any further troubleshooting, is beyond the scope of this paper.  See the Sun Blueprints articles in the references below if you have questions.

Other software

• If your Solaris box serves as a gateway to the Internet for other machines on your network, or if you simply want to improve your web browsing experience, you may want to set up a web proxy such as squid (from the Solaris Companion CD, installed under /opt/sfw/squid/; see http://squidbook.org/index-two.html for a comprehensive description).  Among other capabilities, this allows you to impose access controls for youngsters in your home, or to filter out adware, through the use of a redirector like squidGuard or perhaps AdZapper.  The complete procedure for a vanilla installation of Squid is available, including its integration into SMF.
  
• Sun has recently announced that a wide variety of software which formerly had hefty licensing fees will be made available for development and production use (without support) at no cost.  This includes the Sun Java System Web Proxy Server, which is an alternative to Squid.  The Solaris Enterprise System will also include a wide variety of other tools, including the Sun Studio 11 compilers.  The timetable for releasing these software components as no-cost downloads is not yet clear, but poke around on the Sun site to find other stuff that might be of interest and of use to you.
  
• You may want to modify your system's handling of the keyboard and terminal settings, to get consistent interpretation of some keys in all contexts.
  

Security cleanup

Take the following steps to finalize your configuration.

• Optionally, modify the DSL modem's access code from its default value, as a security measure.  Be sure to save the new access code in some secure offline location.
• You may wish to download and install a newer version of the Mozilla browser, to take advantage of its recent security fixes.  Then make sure that new copy is the one you invoke by default, instead of the /usr/sfw/bin/mozilla version included in Solaris 10.
• You should examine the preferences in your browser, and set them to increase the protection level.  This includes blocking pop-up windows, perhaps disabling Java, controlling cookie acceptance, and other security settings.  Some of these settings can be adjusted on a per-site basis later on if you need to allow access from specific sites.
  
• You may wish to download and install a newer version of Java than came with your Solaris installation, and then configure your browser to point to its version of the Java plugin.
• Take a new BART snapshot of your system, so it incorporates all the changes you've made.
  

Backups

As always when making system-configuration changes like this, once everything is working, be sure to make offline backups of the operational configuration.  And institute a program of regular backups thereafter!

References

I found the following documents and resources helpful, even if some of them are out-of-date:

Connection setup

• http://help.sbcglobal.net/
• http://www.charvolant.org/~doug/network/html/network.html
• http://www.mihalis.net/public/linux/
• http://www.kempston.net/solaris/configsendmail.html
• http://www.kempston.net/solaris/fetchmail.html
• http://www.sendmail.org/~ca/email/auth.html#smtpclient
• http://www.dslreports.com/faq/amfaq
• http://www.dslreports.com/faq/sbc
• http://www.dslreports.com/forum/sbcdirect
  
• http://www.rite-group.com/consulting/solaris_dhcp.html
  
• http://www.broadbandreports.com/nsearch?q=5100b+router
  
• the comp.mail.sendmail newsgroup
• the comp.dcom.xdsl newsgroup
  

Security

• http://www.sans.org/top20/
• http://www.sans.org/top20/Q1-2005update/
• http://www.sans.org/resources/hard_solaris.htm
• http://www.yassp.org/
• https://www.grc.com/x/ne.dll?bh0bkyd2 (Gibson Research Corporation's SheidsUP! port testing; also good for running reverse DNS on your Internet connection to find your current public hostname)
• http://www.fish.com/titan/
• http://www.sans.org/score/checklists/AuditingUnix.doc
• http://www.sans.org/NS2001/track6.htm
• http://www.sans.org/peachtree02/track6.htm
• http://www.sans.org/resources/idfaq/index.php
• http://www.usenix.org/publications/login/2004-06/pdfs/alexander.pdf
• http://www.usenix.org/publications/login/2003-12/pdfs/perrine.pdf
• http://www.usenix.org/publications/login/2001-11/pdfs/singer.pdf
• http://docs.hp.com/en/B9901-90009/ch03s06.html
• http://www.tuketu.com/dsl/xdsl.htm#Security
• http://www.obfuscation.org/ipf/
• http://www.nsa.gov/snac/downloads_sunsol_9.cfm?MenuID=scg10.3.1.1 (what the NSA thinks about hardening Solaris 9)
• http://www.schneier.com/index.html (Bruce Schneier's home page; a great place from which to continue your education on computer security)
  

NTP setup

• http://www.ntp.org/
  
• http://www.sun.com/blueprints/0701/NTP.pdf:  Using NTP to Control and Synchronize System Clocks - Part I: Introduction to NTP
  
• http://www.sun.com/blueprints/0801/NTPpt2.pdf:  Using NTP to Control and Synchronize System Clocks - Part II: Basic NTP Administration and Architecture
  
• http://www.sun.com/blueprints/0901/NTPpt3.pdf:  Using NTP to Control and Synchronize System Clocks - Part III: NTP Monitoring and Troubleshooting
  
• http://ntp.isc.org/bin/view/Support/SelectingOffsiteNTPServers
• http://ntp.isc.org/bin/view/Support/AccessRestrictions
  
• the comp.protocols.time.ntp newsgroup

Feedback

Send corrections, accolades, or other feedback to:


That's not the same email address I set up earlier in this paper, primarily because I don't know much spam might appear as a result of this posting.  I don't guarantee quick (or even any) response, but if you don't send it, I'll never get it.

The following people were most helpful in reviewing this page and suggesting improvements:


To do

• Fix the net-svc modification description to provide the context diffs in a convenient form, to demonstrate the use of gpatch to apply them, and to show how to modify the start/exec property of the network service to point to the modified script.
  
• Have somebody with a Sun support service contract submit the actual and potential net-svc script changes, and the esd problems, as bug fixes, RFEs, and bug reports.  Or submit them to the OpenSolaris project.
• Document the procedures for running smpatch on a regular basis to keep your system up-to-date with at least the publicly available security patches.
  
• Figure out if it makes sense to make changes to /etc/default/dhcpagent instead of some of the shenanigans above.
  
• See if a more recent version of Ximian Evolution fixes the problems noted above, without introducing any equivalently annoying issues.
• Figure out how to make Ximian Evolution interoperate with the local sendmail, to exchange email with the local system.
• Describe how to add email sub-accounts and set up certain critical mail features on your primary email account (via my.yahoo.com or somesuch).
  
• Learn about intrusion detection tools.
• Document the setup for BART.  Also refer to the Sun Blueprints article on BART and the Solaris fingerprint database and the Sun Blueprints article on automating Solaris 10 file integrity checks.  Better, don't just describe here taking a few static snapshots when you first set up your system; instead, give a cookbook procedure here for notifying you when files on your system unexpectedly change later on.  Also document a simple procedure for saving/restoring your system's personality (essentially, any system files you changed from the defaults provided at install time), with adjustments made for accommodating changes that might appear after a sys-unconfig and reconfiguration afterward.
  
• Create a separate web page on my mailcall new-mail notifier, and refer to it here.
  
• Fix the text where appropriate to describe active and inactive IP Filter rulesets, and flipping between them, rather than flushing and re-loading.
  
• All of your internal-network addresses should be chosen from a private IP address space (RFC 1918).  Figure out how NAT/proxy support should be set up if you want to allow any other machines on your network access to the Internet through your Solaris 10 box.
• Add material on how to set up other Solaris boxes as NTP clients of the server you just set up, with just a single driftfile line and a single server line in ntp.conf.
• Sun provides a "Solaris Security Toolkit 4.2" for hardening and auditing your system, available through their on-line downloads.  This release provides support for Solaris 10.  Describe it here, and give references to the Sun Blueprints article on auditing system security, the book from which it was drawn, the Sun Blueprints article on methods that hackers use, and the rest of the Sun Blueprints articles on security.
  

Author

Glenn Herteg

Revision date

This page was last revised on 2005-12-19.