Booting from CD/DVD inside VMware guest

We are now using CentOS 5.2 in VMware. Last time we tried to boot from CentOS 5.2 DVD (to experiment with its rescue image), it flatly refused. I'm still relatively new to using the VM setups, so it took time to sort it out...

It turned out that there were two issues:

1 - the accessibility of the CD/DVD from the guest
2 - the booting sequence in the guest BIOS

Below are the steps resolving both.

First enable CD/DVD visibility in the guest:
1. Power off the guest OS
2. In "Devices" tab (right-hand side of the screen) select CD/DVD(IDE)
3a. Tick "Connect at power on" and
3b. Mark "Use physical drive"
3c. From the drop-down list select "Auto detect"

Now fix the BIOS boot sequence (in the guest). Notice that you have to change the focus into the guest screen before you can do anything (CTRL-G)
1. Power on guest OS
2. Intercept the boot - hit CTRL-G followed by hit F2 *quickly* - it doesn't hang around for long!
3. In the BIOS menu, identify the boot sequence screen, and change to place CDROM before the hard disk
4. Save and continue boot...

Forcing Solaris 10 to recognise network interface

Installed six PCs with Solaris 10 (10/08). Only two out of of them installed with correct network configuration. The unfortunate four didn't recognise the card at all, no kernel module included.

Standard (well, for Solaris) tools like kstat -c net, or dladm show-dev had no network card information ...

Quite a bit of trial and error later (not forgetting googling), here is a working solution:

1. Identify the PCI vendor/device information:

# prtconf -pv | more

Search for Ethernet paragraph (you can do it within more using /Ethernet) and identify its vendor/device data. On my system, it showed:

vendor-id 00008086
device-id 00001050

The last 4 digits of these two values is what we are after.

To find out which particular card this is, I googled for "pci8086,1050" and it's "Intel 82562EZ PRO/100 VE Ethernet"

2. Configure device database

# vi /boot/solaris/devicedb/master

Go to the section with pci8086 entries, possibly using vi's search:

/^pci8086

Insert the following line (ensure it goes in the proper numerical order of the vendor/device pairing):

pci8086,1050 pci8086,1050 net pci iprb.bef "Intel 82562EZ PRO/100 VE Ethernet"

3. Add a new alias to the card

# vi /etc/driver_aliases

Search for the iprb related section and insert the following line (in the right alphabetically place):

iprb "pci8086,1050"

4. Load the kernel driver module for the interface

# modload /kernel/drv/iprb

5. Perform a 'reconfigure' reboot. First initialise the reconfigure flag file, then reboot the machine:

# touch /reconfigure
# reboot


6. After the reboot, 'plumb' the card in and complete the configuration (here, I'm assuming IP address of 192.168.1.100):

# ifconfig iprb0 plumb
# ifconfig iprb0 192.168.1.100 up
# touch /etc/hostname.iprb0

Make sure that the hosts file under /etc/inet is fine. Mine has the following lines:

127.0.0.1 localhost localhost.qa.com
192.168.1.100 yogi yogi.qa.com loghost

Notice that on Solaris the main /etc/hosts file is a symbolic link to /etc/inet/hosts and in addition it will be replicated (automatically) into /etc/inet/ipnodes as well.

Time ticket with sudo

The sudo facility has been available in UNIX for a long time. Often as an add-on, it provides secure and highly configurable mechanism for "delegating" tasks. It is meant to step in where the basic "switch user" command, su, leaves off.

In the sudo configuration file (/etc/sudoers) we define who can do what on which machines with whose identity. The configuration can be as complex as it is powerful, so a lot of the time administrators start with a basic facility, which specifies that a user can do every command, on every machine as any user:

fred ALL=(ALL) ALL


So how does that differ from login as user root in the first place? Well, with sudo you don't disseminate root's password. Users attempting to use the sudo facility will have to authenticate themselves by providing their own password (not the password of the 'target' identity!).

Once authenticated, the user can continue executing sudo commands for a default timeout (typically 5, 10 or 15 minutes). This timeout is known as the 'time ticket'. Once the time ticket expires, the user will have to provide his/her password again.

The default for the time ticket is not always appropriate. Depending on the job role, there may be a requirement to extend (or indeed shorten) the time ticket's length.

To do that, edit the /etc/sudoers file (using visudo tool), and add the line into the Defaults block of instructions (it actually doesn't matter where the line ends up, the suggested location is for clarity reasons only):

Defaults:fred timestamp_timeout = "X"

where X stands for the number of minutes you want the time ticket to last.

If you want for the timetickets to never expire (not really recommended - it defeats the purpose!) replace X with -1.

You can add a line for each user you want to modify, and you can replace the user name with ALL - meaning.... all users ;-)