The first step is to install the NTP packages SUNWntpr and SUNWntpu, both of which are available from the first CD of the Solaris 10 installation CDs.  These packages are located, along with the others, are located in /mnt/cdrom/Solaris_10/Product/ assuming that you mounted your Solaris 10 CD 1 or its ISO image to /mnt/cdrom, of course.  Personally, I keep an ISO copy of this CD available on the network for easy access to these packages although they could very easily be copied off into a package directory.  Depends on the number of machines which you need to maintain.

Go ahead and install the two packages.  This can be done easily by moving into the Product directory and using the “pkgadd -d .” command and selecting the two packages from the menu.  There are no options to worry about with these packages so just install and then we are ready to configure.

The “gotcha” with NTP on Solaris is that there is no default configuration to get you up and running automatically and most online information about the installation either leaves out this portion or supplies details unlikely to be used under common scenarios.

Solaris’ NTP comes with two sample configuration files, /etc/inet/ntp.client and /etc/inet/ntp.server.  Confusingly, for the most basic use we are going to want to work from the ntp.server sample file rather than from the ntp.client sample file.  NTP uses /etc/inet/ntp.conf as its actual configuration file and, as you will notice, after a default installation this file does not exist.  So we start by making a copy of ntp.server.

# cp /etc/inet/ntp.server /etc/inet/ntp.conf

Now we can make our changes to the new configuration file that we have just created.  I will ignore any of the commented lines here and only publish those lines actually being used by my configuration.  In this case I have gone with the most simple scenario which includes using an external clock source and ignoring my local clock.  In a production machine you should set up the local clock as a fallback device.

For my example here, I am syncing NTP on Solaris 10 to the same machine pool to which my CentOS Linux machines get their time, the CentOS pool at ntp.org.  You should replace the NTP server names in this sample configuration with the names of the NTP servers in the pool which you will use.

server 0.centos.pool.ntp.org
server 1.centos.pool.ntp.org
server 2.centos.pool.ntp.org
server 3.centos.pool.ntp.org
broadcast 224.0.1.1 ttl 4
enable auth monitor
driftfile /var/ntp/ntp.drift
statsdir /var/ntp/ntpstats/
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable
keys /etc/inet/ntp.keys
trustedkey 0
requestkey 0
controlkey 0

This very standard and simple setup provides you with four servers from which to obtain NTP data and also rebroadcasts this data on the local network via multicast using the NTP standard multicast address of 224.0.1.1.  Feel free to remove or comment out the broadcast line if you have no desire to have any machines locally getting their NTP data from this machine.  The ease of which you can republish NTP locally via multicast is just too simple to pass up.

Now that we have a working configuration file, we need to fire up NTP and let it sync up with our chosen servers.  The best practice here is to use the ntpdate command a few times to get the box date and time as close as reasonable to accurate before turning NTP loose to do its thing.  The NTP daemon is designed to slowly adjust the clock whereas ntpdate will set it correctly immediately so this gets the initial time correct right away.

# ntpdate pool.ntp.org; ntpdate pool.ntp.org

# svcadm enable ntp

At this point, the NTP Daemon should be running and your time should be extremely accurate.  You can verify that NTP is running by looking in the process pool for /usr/lib/inet/xntpd which is the actual name of the NTP Daemon running on Solaris 10.

First of all there appear to be two naming conventions for these packages. The most common, by far, is to end a package in .pkg while the less common variant is to end the name in .dstream. Some people also leave off the postfix altogether leaving it unclear as to what the file is intended to be.

Installing a dstream is only slightly different than a regular package. The dstream is much more similar to a Linux RPM as it is a single, atomic file. Once it is installed it will act just like any other Solaris package and can be managed and removed in the usual ways (e.g. pkginfo, pkgrm, etc.)

Installing is simple. Let’s assume that we are dealing with the package myNewSoftware.dstream which is saved in /tmp. To install simply:

pkgadd -d /tmp/myNewSoftware.dstream

But in some cases you may want to have access to the contents of the Dstream without needing to install it first. If we are on Solaris this is easy. Just use pkgtrans.

pkgtrans myNewSoftware.dstream .

Or, possibly, you need to get access to the contents of the Dstream without having access to a Solaris machine or the pkgadd command. Do not fret. The solution is much simpler than you would imagine. The Dstream is created in the cpio format which we can extract using common tools.  Unfortunately I have had some issues getting the packages to unpack correctly using this trick.  If anyone has additional insight intot his process, please comment.

So to unpack, but not install, our previous example file on any UNIX box (or even Windows with cpio installed via Cygwin or a similar utility) we can simply:

cpio -idvu < myNewSoftware.dstream

or, I have also seen this option as well – both work for me equally:

dd if=myNewSoftware.dstream skip=1 | cpio -idvu

The “v” option just gives us some verbose output so that we can see what we just unpacked without having to look around for it. You will now have a directory (or a few) as contained in the cpio archive.

After much searching I discovered that the obvious SUNWrsync package does, in fact, exist but not, at this time, for Solaris 10. Rather it is only available in Solaris Express (aka Solaris 11.) This means that it is not available in the standard Solaris 10 Update 4 or earlier installation CDs. Rsync has not been available on any previous version of Solaris to my knowledge either. The version of Rsync available from Solaris Express is currently 2.6.9 which is current, as of November 6, 2006, according to the official Rsync project page.

Fortunately SUN has made Solaris Express available as a free download. Unfortunately it is a single DVD image that must be downloaded in three parts and then combined into a single, huge image. This is not nearly as convenient as having an online package repository from which a single package could be downloaded (hint, hint SUN!)

You will need to download all three files from SUN, unzip them and then concatenate them into a single 3.7GB ISO file from which you can extract the necessary package.

# unzip sol-nv-b64a-sparc-dvd-iso-a.zip
# unzip sol-nv-b64a-sparc-dvd-iso-b.zip
# unzip sol-nv-b64a-sparc-dvd-iso-c.zip
# cat sol*a sol*b sol*c > sol-nv-sparc.iso
# mkdir /mnt/iso
# lofiadm -a sol-nv-sparc.iso /dev/lofi/1
# mount -F hsfs -o ro /dev/lofi/1 /mnt/iso
# cd /mnt/iso/Solaris_11/Product/
# ls -l | grep rsync

You will now have the list of the two available Rsync packages: SUNWrsync and SUNWrsyncS. It is SUNWrsync that we are really interested in here. I like to move all of my packages that I am installing to my own personal repository so that I can keep track of what I am installing and to make it easier to build a matching machine or to rebuild this one. If you are going to use a repository in this way be sure to back it up or it won’t be very useful during a rebuild.

# cp -r SUNWrsync/ /data/PKG/
# pkgadd -d /data/PKG/

You will now be able to pick from the available packages in your repository to choose which to install. [Helpful hint: If you have a large number of packages in your personal repository, consider placing each package into its own directory. For example, make a directory called “rsync” or “rsync_client” and symlink (ln -s) back to the installation directory. This makes it easier and quicker to install a single package. You can simple “cd /data/PKG/rsync” and “pkgadd -d .” Much quick and easier for large repos. By using the symlink method you maintain a single directory of the files while also having handy individual directories.]

Once you have installed the Rsync client package it is ready to be used. Because we are not using Rsync in a server based configuration we have no configuration to worry about. Rsync is most popularly used as a client package over SSH. Unlike most network aware packages that require that an SSH tunnel be created for them Rsync has SSH tunneling built into it making it extremely easy to use.

Let start with an example of moving files from one server to another without using SSH.

/usr/bin/rsync -av remote-host:/data/home/ /data/home

In this example we are synchronizing the remote /data/home directory with the local one pulling files from the remote site to the local. This is a one way sync so only files missing locally are brought over and files that exist locally but do not exist remotely are left intact. This is a relatively safe process. Files of the same name will be overwritten, however, so do this with test directories until you are used to how it works. You can run a test command using the -n option. With this option you will get the output of the Rsync command without actually moving any files so that you have a chance to see what would have happened. Here is the same command run in “test” mode.

/usr/bin/rsync -avn sc-sol-nfs:/data/home/ /data/home

With this particular Rsync package, the default mode of operation is to use SSH as the transport. This can be set explicitly but that is not necessary. By using SSH you have the security of the SSL tunnel to protect your traffic and you have the security and ease of use that comes with not needing to run a daemon process on any server that you want to sync to or from. The final command that you will normally want to run will involve the “-z” option which turns on file compression. This will normally decrease the time that it takes to transfer files. The gzip algorithm used for the compression is very effective on text documents and general files and is quite fast but on already compressed files such as tgz, Z, zip, jpeg, jpg, png, gif, mp3, etc. it can, at worst case, actually expand the files and will use a lot of CPU overhead without increasing the transfer speed. So best to be aware of the file types that you will be transferring. But for most users gzip is the right compression to use. So our final transfer command is:

/usr/bin/rsync -avz sc-sol-nfs:/data/home/ /data/home

automount[10581]: >> mount: block device 192.168.0.2:/data/home/samiller is write-protected, mounting read-only
kernel: call_verify: server 192.168.0.2 requires stronger authentication.

It turns out that the solution is quite simple. The issue is with a mismatch of anonymous credentials. Let’s take a look at the erroneous entry in /etc/dfs/dfstab on the Solaris NFS server:

share -F nfs -o public,nosuid,rw,anon=-1 -d "backup" /data

The piece of this configuration that is an issue here is “anon=-1”. In theory this is designed to block users who do not have accounts on the local system. However this causes issues with Linux systems. You can solve this problem by simply removing the anon setting from the configuration file. Not an ideal fix but it does solve the problem.

share -F nfs -o public,nosuid,rw -d "backup" /data

Simply run the “shareall” command and you should be back in business.