Rutgers, The State University of New Jersey
OFFICE OF INFORMATION TECHNOLOGY | TECHNICAL DIRECTOR'S WEB PAGE
 

Setting up Solaris 10 at Rutgers

This document was developed primarily for installing servers. While what it says should be true for desktops, desktops present special issues. See the section on desktop systems at the end of this document.

This document was originally developed during installation of a v20z, although it has been used with a variety of systems (primarily x64, i.e. Opteron).

Assumption: You've got your hardware installed and configured. For the v20z this means

  1. Configuring the network parameters in the SSP, using the buttons on the front,
  2. Doing
    ssh -l setup IP-address
    which creates an account on the SSP and sets it up.
  3. Attaching the SSP to the Solaris console:
    platform set console -s sp -e -S 9600 {one-time setup}
    platform console {connect to the console; do that every time you connect}
  4. Powering on using the power button on the front
  5. Going through the one-time setup menu you get thrown into

Set up DNS

Create /etc/resolv.conf, containing

domain rutgers.edu
search rutgers.edu
nameserver 128.6.216.19
nameserver 128.6.224.114
Although this will work anywhere within Rutgers, ideally you should choose the servers for your campus. See the Network Service Systems.

To cause Solaris to use DNS,

cp /etc/nsswitch.dns /etc/nsswitch.conf

Putting on standard software

Fairly early in setup, you'll want to install the Solaris free software. The important thing for me is that it contains emacs, which I use to create the various configuration files. Unfortunately you can only get it from the web, and until you set up a browser, you can't get to the web from the system. I ended up downloading it to a local machine and then ftping it to the system I'm setting up. You get an ISO CD image file from Sun's Solaris Freeware.

Ftp it from whereever you downloaded it.

bunzip2 software_companion_x86.iso.bz2

lofiadm -a .../software_companion_x86.iso
for me, it returns /dev/lofi/1. Use whatever it is below

mount -F hsfs -o ro /dev/lofi/1 /mnt

cd /mnt
./install
take default, which installs everything into /opt/sfw/bin

You now have a fairly good set of software in /opt/sfw. You'll want to add /opt/sfw/bin to your path. (I put it in the default environment below.)

You probably also want to go to www.mozilla.org and download firefox. Fortunately you'll end up being pointed to an FTP archive, so you'll be able to retrieve it with FTP. I created /usr/local/firefox and expanded the file there. Then I did

ln -s /usr/local/firefox/firefox /usr/local/bin/firefox
to put the executable someplace in users' path.

Allocate your disk

I was somewhat surprised that by default only swap, root, and /var were set up. That left most of the disk, which you'd expect to go to /export, unallocated.

You'll want to use format to allocate a partition for the rest of the space. I'm not going to give detailed instructions on using format.

Assume you used partition 6 on c1t0d0. In /etc/vfstab add

/dev/dsk/c1t0d0s6 /dev/rdsk/c1t0d0s6 /export ufs 1 yes logging

This puts all the extra space in /export. You may prefer to create a partition for /usr. /usr tends to grow.

Check your umask. It should be 022. Otherwise you may create mount points that aren't accessible. Obviously c1t0d0s6 may be different on your system:

newfs /dev/dsk/c1t0d0s6
mount /export
mkdir /export/home

Create some users

I use traditional uids and group ids from central OIT systems. That may or may not apply to you. These days most people use the group "wheel" for privilged users. I'd do that rather than "slide" unless you need compatibility with older systems, as I do.

Create some groups, sysprog as a default group for systems staff, and slide to indicate users who can become root. You don't have to use the same names or group numbers.

groupadd -g 109 slide
groupadd -g 11001 sysprog

Create a user for yourself. The primary group is sysprog. I also put it on slide so I can become root. I like tcsh. You might prefer another shell.

useradd -u 103 -g 11001 -G slide -d /export/home/hedrick -s /bin/tcsh -c "Charles Hedrick" hedrick
mkdir /export/home/hedrick
chown hedrick /export/home/hedrick

Set up a password. The traditional approach is "passwd hedrick". However I'm going to use an Enigma one-time password. I end up using "password hedrick" temporarily, then once Enigma is up, editing /etc/shadow to change hedrick's encrypted password to ###CLH2. If you use Enigma, you'll understand. Otherwise just use passwd to set a password.

If you need to add an existing user to a group, use

usermod -G slide hedrick

Default environment

Set up the paths. There are various ways to do this. I prefer to use shell default files. Here's what I put in /etc/.cshrc. That works for csh and tcsh. If you use bash or sh, there's an equivalent for them. I always test to see whether the entry is already there before adding it, since this will get called multiple times if you start subshells.

if ("$path" !~ */opt/sfw/bin*) set path = ($path /opt/sfw/bin)
if ("$path" !~ */usr/local/bin*) set path = ($path /usr/local/bin)
if ("$path" !~ */usr/sbin*) set path = ($path /usr/sbin)
if ("$path" !~ */usr/ccs/bin*) set path = ($path /usr/ccs/bin)

You may not need the last two. /usr/sbin is useful for administrators. If most of your users are (as they will be on servers), it's a useful default. /usr/ccs/bin has "make", "m4", etc., so it's useful if a number of users build software.

I'm putting stuff I build in /usr/local, so I can replace /opt/sfw completely if there's a new version.

Setup various things for privileged users

Rutgers has traditionally used a program "slide" to become root. These days most os's have sudo, so my inclination is to use it rather than port slide yet again. It's installed from the free software CD, so it' /opt/sfw/bin/sudo. However it is installed without being setuid root, so it won't actually work:

chmod u+s /opt/sfw/bin/sudo
/opt/sfw/sbin/visudo
uncomment %wheel illustration. If you use the group slide, make it
%slide ALL=(ALL) NOPASSWD: ALL
If you aren't stuck with using the group name slide, you may prefer to leave it as wheel.

Now we come to an issue of preference. By default, sudo is designed for staff who mostly do non-privileged things. It makes sense to ask them to use sudo when they want to do something privileged. However on a server, typically everything I do requires privileges, so I just want to become root and stay there. With sudo, the easy approach is "sudo /bin/tcsh". However since most of our machines still have "slide", I created /usr/local/bin/slide:

#!/bin/sh
exec /opt/sfw/bin/sudo $SHELL

Take a look at /etc/ssh/sshd_config. I set

PermitRootLogin no
For operational reasons, I'm going to set the root password to blank, so I want to make sure that they can't get in remotely. My systems are in a machine room with full-time operators. In a more typical situation, I would set root so it can't login (or perhaps a very long and obscure password) and require people to login as themselves and use sudo.

For error recovery situations, if the system comes up single user, either you need a real root password, or you need to set the system so single user doesn't need a password. To do that (as I did), create a file /etc/default/sulogin containing a single line

PASSREQ=NO
That causes single user not to require a login.

Patching

You probably want to get your systems up to date. I rather like the tool smpatch. You can just do "smpatch update" and it will apply most of the patches you need. Or you can do it step by step:

smpatch analyze: see what should be applied
smpatch download: download them
smpatch update: applies them
Again, I note that you don't need analyze and download. Update will do that.

By default, update will only install patches that are fairly safe. I.e. they can be installed with the system running normally, and won't cause trouble. Patches that require an immediate reboot will be skipped, and put into a file /var/sadm/spool/disallowed_patch_list. When you're ready to do them, kick everybody off the system, shut down as much as you can, and do

smpatch add -x idlist=/var/sadm/spool/disallowed_patch_list
then reboot.

Engima authentication

If you use the Enigma one-time cards, you need pam_ru and rval_crypt. The following files need to be installed:

If you use Enigma, you should know what goes into enigmad.conf. It's the same on all systems. A version for Solaris 10 x86 is contained sol10.x86/enigma.tar. It can be untarred in /, as root. The equivalent for Solaris 10 SPARC is in sol10.sparc/enigma.tar.

WARNING: We are moving from this old Enigma code to new code from the vendor. There will be a new version of rval_crypt in late 2006 or early 2007. If you install this, please check for updates, because this version will stop working at some point. The new code will use a lightweight door server to do the actual communications with the Enigma server, so it will be distributed as a .so file in /usr/lib/security and a daemon, probably in /usr/local/sbin. It will require Java, because the only portable client code for the new Enigma server is in Java. I will make source for the library and daemon available.

In /etc/pam.conf, for any services you want enigma, replace pam_unix_auth.so.1 with

xxxx auth sufficient pam_unix_auth.so.1
xxxx auth required pam_ru.so.1 try_first_pass
xxxx is the service name, e.g. login. the try_first_pass may not be needed. It's from their ldap example. Now edit /etc/shadow and replace the user's encrypted passwords with ###IID

Kerberos

The kerberos plugin for PAM is also available as sol10.x86/krbcrypt.tar and sol10.sparc/krbcrypt.tar. It is designed to be untarred in /. It contains

pam_ru.so.1 is available from the Enigma package, above. This is a completely new version of krb_crypt, which is far cleaner than any of the previous ones. For that reason, I'm making the source available.

The Firewall

I strongly recommend using the firewall.

Edit /etc/ipf/pfil.ap. Uncomment the interfaces you want filtering on, probably your primary ethernet interface. Use /sbin/ifconfig -a if you don't know the interface names

/usr/sbin/svcadm restart network/pfil

Create /etc/ipf/ipf.conf. I suggest starting with rules that allow all traffic:

pass in quick all
pass out quick all

/usr/sbin/svcadm enable network/ipfilter

Reboot. You're supposed to be able to replumb but it didn't work for me.

Once the system is up and you verify that you can still use the network, try doing some real rules. Here's an example ipf.conf. It is 'default deny'. I.e. it allows specific things and prohibits everything else. I strongly recommend that. It also runs in stateful mode, which is the only practical way to allow all outgoing transactions and deny incoming.

This example allows all outgoing connections, and incoming for a few services. For a pure client machine I'd remove all the pass in TCP rules and maybe also ICMP. icmp type 8 is needed to respond to ping. 13 is time stamp request, which may or may not matter. With this setting you won't get or process various error mesages that are sent by routers, etc using ICMP. They have been a source of security issues, but may still be useful. Obviously you can turn on all ICMP by removing the icmp-type NN or omit the icmp rules in which case all ICMP incoming will be off. (Note that the instructions in the web page below are wrong for allowing ping. It is icmp type 8, not 0)

pass in quick proto tcp from any to any port = 22 keep state
pass in quick proto tcp from any to any port = 80 keep state
pass in quick proto tcp from any to any port = 8080 keep state
pass in quick proto tcp from any to any port = 443 keep state
pass in quick proto icmp from any to any icmp-type 8 keep state
pass in quick proto icmp from any to any icmp-type 13 keep state
pass out quick from any to any keep state
block in quick all

After changing /etc/ipf/ipf.conf, do

ipf -Fa -f /etc/ipf/ipf.conf

Even if you're not going to create a NAT, you'll want one entry in ipnat.conf. It's a proxy that makes FTP work. Otherwise you can only use passive FTP. Put the following in /etc/ipf/ipnat.conf

map bge0 0/0 -> 0/32 proxy port 21 ftp/tcp
Note that is needs your ethernet interface name, which on my machine is bge0. Use ifconfig -a to find your name if you don't know it. This only handles clients who want to use FTP. If you want incoming FTP to work, things get a lot more complex. You'll need to see the full instructions

After changing /etc/ipf/ipnat.conf do

ipnat -CF -f /etc/ipf/ipnat.conf

There's a utility "ipfstat" that will show you the current rules and how they are working. See the man page for details.

For more detailed instructions, see http://www.obfuscation.org/ipf/ipf-howto.html.

Console setup

The v20z and v40z have a separate front end processor running Linux. It has its own Ethernet interface. This lets you do console operations remotely. You ssh into it and do "platform console" to take over the console. (It also has a web interface if you like GUI tools.)

Make sure you check the instructions for your model. While most of the Sun servers have front end processors, the commands are very different for different models of server.

If you need a conventional console, you'll want to attach the serial console to the hardware serial port. This is actually the default as the system is shipped, but the install instructions tell you to attach it to the SSP. To put it back from the SSP do

platform set console -s platform
It is configured by default at 9600. The terminal must use a null modem cable and should be set for no flow control.

SMF: starting/controlling services

In most Unix systems, startup scripts in /etc/rc3.d, etc, are used to start and stop services. Solaris 10 uses a different approach. There are two advantages to the Solaris 10 method:

Services are managed by svcadm. The most common commands are

svcadm enable SERVICE
svcadm disable SERVICE
Note that enable and disable are persistent. That is, if you enable a service it will be brought back up after a reboot. Similarly with disabling. If you want to stop a service but have it come back up after the next reboot, use "svcadm -t disable SERVICE". That stops it temporarily.

To look at services, two common commands are

svcs {lists summary of all}
svcs -l SERVICE {details on one service}

Solaris 10 still pays attention to /etc/rcN.d, but services defined there are "legacy", and can't be fully monitored and controlled.

To define a service, you create an XML file that specifies dependencies, and methods to start and stop it. Then you do "svccfg import FOO.xml". Normally the XML file is written to create an instance but not enable it. So if the import works, you would need to do "svcadm enable SERVICE" to start it.

A good way to start writing the XML file is to look at existing ones. They are in subdirectories of /var/svc/manifest. Sun suggests system/utmp.xml as a simple example. Since many of your services may be network services, take a look at what is in network. In network, there are two types of services, some that are standard daemons (e.g. http_apache2) and some there are run by inet (e.g. telnet).

If you add services, you probably want to put your .xml files in /var/svc/manifest and your scripts in /lib/svc/method. That way anyone who needs to work with the system can find them, just as they now know to look in /etc/init.d for all startup scripts. However I suggest making those symbolic links to files that are actually in /usr/local/svc/manifest and /usr/local/svc/method. That way you won't lose your information in a system reinstallation.

I suggest two pages in Sun's BIGADMIN site:

Most of the XML files refer to scripts to do start, stop and restart. The Sun scripts all reside in /lib/svc/method. It's worth looking at some of the examples. There are two standard approaches: a script that just starts the service. You then use :kill in the XML file to stop it. This causes all processes started by the start script to be killed. Or you have a script that looks a lot like a traditional init.d script, which is called as "SCRIPT start" and "SCRIPT stop". Use that if you need to do something beyond just killing the process.

For a quick conversion you can use the example above, and call the init.d script with start and stop. However you may want to change the script slightly:

The second item is critical if other processes depend upon this one, since they'll go on to the dependencies as soon as the start process returns. If there are no dependencies, you can get away with a simple init.d script, as long as it returns 0.

Note that if all processes started by a service die, the system will try to restart the service by doing a stop and then a start.

You can also define a "refresh" action, which prods a service if a configuration file changes.

Containers

Solaris 10 has features that let you isolate applications and services from each other. This can greatly improve security. If you put each application in its own container, then you can make sure that even if someone finds a security problem in it, it can't affect other applications or overall system integrity. Ideally, you should set up the firewall to allow only sshd (for administration) and a set of applications. Each application should then run in a container. For a timesharing system, you might consider putting normal users in a container, and having a separate copy of ssh for just sysadmins that gives access to the global enviornment.

See Practical Security Using Solaris Containers in the Solaris 10 OS for an introduction.

I haven't tried this yet. I'll add more specific information after I do. (I invite other members of the Rutgers community who have done this to contribute cookbook instructions for this section.)

Desktop systems

Solaris 10 has a decent desktop environment. However as of Spring 2007 you can get a better desktop experience by using one of the distributions based on Opensolaris, rather than the standard Solaris 10 distribution. See the http://www.opensolaris.org.

While Solaris will work on most desktop systems, support for notebooks is currently limited. There is a wireless web page at Opensolaris, which points you to drivers for many common wireless cards. However some cards (e.g. my Broadcom) don't work reliably, even with ndiswrapper. If you are going to try ndiswrapper I recommend running in 32-bit mode. Hibernate and suspend are not currently supported by Solaris.

Opensolaris is rather like Linux, in that there are a number of distributors that build packages with different user-level environments around the Solaris kernel. The "downloads" page at www.opensolaris.org lists the major distributions.

I rather like Sun's own distribution, Solaris Express. However it's over 3 GB.

A more compact distribution is BeleniX, maintained by staff in Sun's development center in India. It is a "live CD", meaning that it can run entirely from CD (using a ram disk). It can also be installed on disk.

NextentaOS is an interesting experiment. It is the Ubuntu userland on top of a Solaris kernel. It is nearly impossible to tell that you aren't running Ubuntu Linux. They have ported the package manager and most of the packages that come with Ubuntu.

marTux is a distribution for Sparc. Except for Solaris Express, the others are for x86 and x64.

It doesn't appear that SchiliX is currently being developed.

The only one of these that I'm using in production is Nextenta. I use it on an older system with limited memory, for which Windows XP is too slow. (However there are Linux distributions that will work with less memory than any of the Solaris distributions.)

BACK TO TOP

For more information, contact hedrick@rutgers.edu.
Last updated: Saturday, 24-Mar-2007 11:58:10 EDT
© 2007 Rutgers, The State University of New Jersey. All rights reserved.