Home/IT/Solaris/Interactive Installation/Configuration  

Solaris on VMware: Interactive Installation  

← Previous|Next →  

Now that Solaris has been installed I will set up certain things on my virtual machine.

Halting the Machine

The machine can be stopped on the system's console or over the network by typing as root:

bob# shutdown -i 5 -g 0 -y

Once you can see the message Press any key to continue you can power off the machine.

Root Login

If you have installed Solaris in the way I suggested, no local Xserver could be started. You should see a message like:

*****************************************************
*
* The X-server can not be started on display :0...
*
*****************************************************

Press the ENTER key to get a login prompt.

bob console login:  root
Password: ++++++
Jan 8 09:42:53 bob login: ROOT LOGIN /dev/console
Sun Microsystems Inc.   SunOS 5.6   Generic August 1997
#

Unfortunately, there are sometimes difficulties to type commands on the Solaris console. Some characters are taken multiple times and typing passwords blindly is not so easy.

I recommend to allow root to log on over the network, as it is much easier to type commands in a telnet or ssh terminal. To do so, comment out the CONSOLE variable in /etc/default/login. If you don't know how to use a UNIX editor like vi, try the following:

# cd /etc/default
# cp -p login login.ORIG
# sed 's/^CONSOLE/#CONSOLE/' login.ORIG > login

Log in over the virtual network. If your guest's hostname is not known to the VMware host try using the IP address instead.

$ telnet bob
Trying 192.168.4.63...
Connected to bob.
Escape character is '^]'.


SunOS 5.6

login: root
Password: 
Last login: Mon Nov 27 17:08:03 from 192.168.4.1
Sun Microsystems Inc.   SunOS 5.6       Generic August 1997
#

Adding Users

When adding a regular user to the system it is a good idea to use the same name, user ID and group as you have on your Linux host. In Windows, using the same user name has advantages in case you want to share Solaris file systems via Samba.

In the old style UNIX world, all regular users share the same common group (for example users). I prefer the Debian or OpenBSD concept where every user has its own group of the same name. Matter of opinion.

bob# groupadd -g 1042 jexss
bob# useradd -u 1042 -g 1042 -d /export/home/jexss -m -s /bin/sh jexss
6 blocks
bob# passwd jexss
New password: ********
Re-enter new password: ********
passwd (SYSTEM): passwd successfully changed for jexss

Hostnames

You should introduce the new Solaris machine to the host operating system and vice versa. This simplifies the network communication. On the host the entry could look like:

192.168.4.63 bob

In Linux this must be added to the file /etc/hosts. This file also exists in Windows. In my Windows XP, this is C:\WINDOWS\system32\drivers\etc\hosts.

In the virtual Solaris computer you should announce the Linux or Windows host. This is usually the first address of the Vmware vmnet8 network, 192.168.4.1 in my case.

bob# echo "" >> /etc/inet/hosts
bob# echo "192.168.4.1 colin" >> /etc/inet/hosts

Short Test:

bob# ping colin
colin is alive

By the way, you also should give a domain name to the Solaris system, even if your guest doesn't belong to any official domain. This makes life easier for certain system services such as sendmail. In /etc/inet/hosts, modify the line that reads

192.168.4.63 bob loghost

to:

192.168.4.63 bob.localdomain bob loghost

This file is write protected, in vi the write must be forced (!). If you can't handle vi or any other UNIX editor, you may change the file that way:

bob# cd /etc/inet
bob# cp -p hosts hosts.ORIG
bob# sed 's/bob/bob.localdomain bob/' hosts.ORIG > hosts

Gateway and Name-Server

If you want to leave the local network with your Solaris computer and want to connect to the Internet or to another non-local network, you must specify a gateway. Do this by creating a new file /etc/defaultrouter and add the gateway address (the VMware NAT gateway address) to that file.

bob# echo "192.168.4.2" >> /etc/defaultrouter

Same with the DNS server:

bob# echo "nameserver 192.168.4.2" >> /etc/resolv.conf

Finally, make sure that Solaris is using the name server to determine IP addresses.

# cd /etc/
# cp -p nsswitch.conf nsswitch.conf.ORIG
# sed 's/^hosts:.*files/hosts: files dns/' /etc/nsswitch.conf.ORIG > nsswitch.conf

Reboot and reconfigure the system to make sure the changes take effect.

bob# reboot -- -r

Once rebooted, check that the network is configured correctly:

# ping exss.de
exss.de is alive
# 

Recommended Patch Cluster

Even Solaris has bugs and security holes. Every single reported problem that has been fixed is handled by a patch. Instead of download every single patch the typical system administrator will download a bundle of patches from time to time. This bundle is called a Recommended Patch Cluster. This is an archive which contains all patches that have been provided since the operating system has been released and that a regular system probably would need to keep up to date. A shell script that comes with the cluster will check the system against every patch that is included and will decide whether to install a certain patch or not and will determine the order.

If your system is connected to the Internet I recommend that you install a patch cluster now. The size of a cluster is typically about 40 Megabytes or more. Installing a patch cluster is very easy:

  • Go to the Patch Cluster Homepage and select 2.6 x86 and Download HTTP and click the Go button.
    Update: Sorry. The Solaris 2.6 patch cluster is not available anymore...

  • If you have done this with the real host instead with the Solaris VM, move the cluster to your install client by ftp

  • Move the file *_Recommended.* to a directory with about 200 MB free hard disk space, such as /export/home.

  • Unpack the cluster file:
    # cd /export/home
    # zcat /cdrom/cdrom/patches/cluster_20060413/2.6_x86_Recommended.tar.Z | tar xf -
    # cd 2.6_x86_Recommended/
  • Install the cluster:
    # ./install_cluster -nosave -q
    Note that installing the cluster might take a long time.

  • Clean up and remove both the cluster file and the unpacked archive.
    # cd ..
    # rm -rf 2.6_x86_Recommended*
  • Reboot the machine:
    # reboot -- -r
  Next →