Often times, password requirements may differ between the two system types. This means users will have to use a different password on Windows and Unix. Also, when password change dates are not synchronized between the Windows and Unix systems you’ll end with users that forget their Unix passwords on a very frequent basis.

This article is meant to provide the basic procedures to allow a Solaris system to use user information provided by Active Directory on a Windows 2008 server as the authentication method for logging into Solaris.

The following instructions are cobbled together from several locations on the internet and from in house testing.
We primarily used the following two sites, which offer steps on configuration using Windows 2003 R2. We then made changes where required.

Sun Wikis
Scott Lowe’s Blog

Our Test Environment

• Domain Controller Information
  • Windows 2008 R2
  • Hostname = win2k8-dc
  • IP Address = 192.168.3.76
  • Domain = test.sog.com
  • Kerberos Realm = TEST.SOG.COM
• Client Information
  • Solaris 10_u8 x86
  • Hostname = keystone
  • IP Address = 192.168.3.66

Windows Configuration

It is assumed that Active Directory is setup and that DNS is configured on the domain controller. The steps provided are what you need to do to add Unix functionality to an already existing Windows AD environment. The Solaris clients should be added to the DNS records on the DC.

The following steps are required to add all additional functionality to the domain controller to allow for Solaris clients to authenticate against AD.

Install UNIX Schema into Active Directory

Open “Server Manager” and click on “Roles” in the left pane. Click on “Add Role Services” in the “Active Directory Domain Services” section in the right pane.

Any users that you want to be able to use Active Directory for Solaris logins must have the Unix Attributes set under User Properties for that user. These properties include the UID, Primary GID, login shell, and home directory. (The users’ GECOS will come from the Display Name setting under the General tab of the users’ properties.)

Under Active Directory Users and Computers Right click the new user account and select Properties. In the user’s properties window select the Unix Attributes tab.

Select the domain under “NIS Domain” and fill in the fields.

All other user properties (secondary groups, RBAC roles/profiles/auths…) will come from the standard file locations on the Solaris client systems- (/etc/group, /etc/users, /etc/security/*attr)

Also, make sure that the user’s password is not set to ‘change at next login.’ Solaris does not have the hooks back into AD to do password management, so your user will not be prompted to change their password and they will not be allowed to login. All they will see is a messages saying: “Login Incorrect.”

Create Kerberos Keytab for Client System

Although this step is given on both of the sites provided above, I have found that it is not required to create a functioning Solaris -> AD authentication environment. I do not know the security implication of not performing this step.
On the Windows system, create a user account for the Solaris system that will be authenticating. In this example we are creating a user account named host-keystone for the host keystone. (Note: this is a user account, not a computer account)

Once this user is created you can disable it for security purposes.

The purpose of this step is create the keytab file that will be transferred to the /etc/krb5 directory of the Solaris system that will be authenticating against AD. In order to create the keytab file run the following command from a CMD prompt on the domain controller. (Make appropriate changes for you local environment.)

C:\Users\Administrator> ktpass –princ HOST\keystone.test.sog.com@TEST.SOG.COM -mapuser TEST\host-keystone –crypto DES-CBC-MD5 +DesOnly –pass p@ssword1 -ptype KRB5_NT_PRINCIPAL –out Desktop\keystone.keytab

Transfer the file to the host keystone as /etc/krb5/krb5.keytab

Create ProxyDN User Account

On the Windows system, create a user account that will be the proxyDN. Make this user a member of “Domain Guests.” Give it a password, and select ‘password never expires’
This will be the proxyDN username used when you run the ldapclient command later on. This account must remain enabled.
In this test we created a user account called “ProxyDNUser” with a password of “p@ssword1”

Make sure to use the Display Name under the General properties (Full Name when creating the user) during the ldapclient step. In this case the correct user to use during the ldapclient command will be ProxyDNUser. Do not use the user logon name. We ran into a bit of a problem when we kept trying to use the Windows logon name and we kept getting messages saying:

libsldap: Status: 49 Mesg: openConnection: simple bind failed – Invalid credentials

It was a bit frustrating when we were completely sure that we were using the right password and still kept getting a messages saying ‘Invalid Credentials.’

Use ADSIedit on your domain controller to see the full DN for the user account if you keep getting the message above and you’re positive you have the password correct.

Solaris Configuration

Client Side DNS Configuration

Your Solaris system should be a member of the DNS domain defined by your domain controller. Make sure to create both forward and reverse lookup records in the domain for the Solaris system.

# cat /etc/resolv.conf
domain test.sog.com
nameserver 192.168.3.76

Make sure you have the /etc/nsswitch.conf file setup to use DNS as a name service for hosts.

# grep ‘^hosts’ /etc/nsswitch.conf
hosts files dns

Verify that DNS works.

# nslookup `hostname`
Server: 192.168.3.76
Address: 192.168.3.76#53

Name: keystone.test.sog.com
Address: 192.168.3.66

The following nslookup commands should produce output similar to the following.

# nslookup -querytype=any _ldap._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_ldap._tcp.test.sog.com service = 0 100 389 win2k8-dc.test.sog.com.

# nslookup -querytype=any _gc._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_gc._tcp.test.sog.com service = 0 100 3268 win2k8-dc.test.sog.com.

Kerberos

Configure the /etc/krb5/krb5.conf file on the Solaris client. Make appropriate changes required for your local environment.
This is the /etc/krb5/krb5.conf that we used on our test system.

[libdefaults]
default_realm = TEST.SOG.COM
dns_lookup_kdc = true
verify_ap_req_nofail = false
[realms]
TEST.SOG.COM = {
kdc = WIN2K8-DC.TEST.SOG.COM
default_domain = TEST
admin_server = WIN2K8-DC.TEST.SOG.COM
}
[domain_realm]
.test.sog.com = TEST.SOG.COM
test.sog.com = TEST.SOG.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
kinit = {
renewable = true
forwardable= true
}

Run the kinit command and enter the administrator’s password. If the command runs successfully, you will see no output.

# kinit administrator
Password for administrator@TEST.SOG.COM:

LDAP

ldap client initialization on Solaris host. The part of the command in orange needs to be modified for your environment. The rest of the command is standard across all configurations.

# ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=”ProxyDNUser,cn=Users,dc=TEST,dc=SOG,dc=COM” \
-a proxyPassword=p@ssword1 \
-a defaultSearchBase=dc=TEST,dc=SOG,dc=COM \
-a domainName=TEST.SOG.COM \
-a “defaultServerList=192.168.3.76″ \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=TEST,dc=SOG,dc=COM?sub \
-a serviceSearchDescriptor=group:dc=TEST,dc=SOG,dc=COM?sub

# cp /etc/nsswitch.files /etc/nsswitch.conf

# vi /etc/nsswitch.conf
passwd files ldap
group files ldap
hosts files dns

# svcadm restart ldap/client

PAM

Edit /etc/pam.conf to use Kerberos authentication. Both sites provided at the top of this article show the same modifications to pam.conf. In our tests we found that those entries caused problems, most notably that the root user could not login from the console. Here is the /etc/pam.conf that we found to work best.

# vi /etc/pam.conf
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_cred.so.1
login auth sufficient pam_krb5.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth sufficient pam_krb5.so.1
other auth required pam_unix_auth.so.1
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth sufficient pam_krb5.so.1
other auth required pam_unix_auth.so.1

Create home directory for user.

# mkdir -p /export/home/john.doe
# chown john.doe:staff /export/home/john.doe
# chmod 700 /export/home/john.doe

You should now be able to log into your Solaris system with your AD user account.

For example, at one customer site there is a Java developer that needs to be able to restart a webserver instance after he updates his application.  Giving him the root password is not an option, that would give way too much administrative control to somebody who is not a Unix admin.  I could install sudo and let him run the svcadm command as root, but I don’t really want to allow him to be able to have control over all the SMF services.  The same is true with RBAC; I could give him the solaris.smf.manage authorization, which would allow him to have a limited amount of svcadm control, but it would still be for all services.

The following procedure creates and grants the RBAC authorization to control just a single service.  This example is for a webserver SMF service named svc:/network/http:https-test-webserver, which corresponds to a Sun Java Enterprise Webserver 7 configuration named test-webserver.

The amount of control this procedure gives a user is still a bit more than I would prefer.  It allows the user to restart, refresh, clear or put a service into maintenance mode.  I would prefer to just allow the user to restart the service, but it’s better than any of my other options.  Certainly much better than handing out the root password.

# svcs http:https-test-webserver
STATE          STIME    FMRI
online         14:21:51 svc:/network/http:https-test-webserver

# svccfg
svc:> select http:https-test-webserver
svc:/network/http:https-test-webserver> setprop \
general/action_authorization=astring:”solaris.smf.manage.https-test-webserver”
svc:/network/http:https-test-webserver> exit

# svcadm refresh http:https-test-webserver

# echo “solaris.smf.manage.https-test-webserver:::Manage Test Webserver::” >> /etc/security/auth_attr

# usermod -A solaris.smf.manage.https-test-webserver user1

Now user1 can log in and perform certain levels of management on this webserver instance.  User1 can’t do everything to this service and has no control over any other services.

$ id
uid=100(user1) gid=10(staff)

$ svcs http:https-test-webserver
STATE          STIME    FMRI
online         14:23:56 svc:/network/http:https-test-webserver

$ svcadm restart http:https-test-webserver

$ svcs http:https-test-webserver
STATE          STIME    FMRI
online         14:27:53 svc:/network/http:https-test-webserver

Notice that the STIME has changed in the outputs of svcs for this service.  This shows that the service has indeed been restarted.

The next two examples illustrate that the user is not able to disable the service and has no control over other SMF services.

$ /usr/sbin/svcadm disable http:https-test-webserver
svcadm: svc:/network/http:https-test-webserver: Permission denied.

$ /usr/sbin/svcadm restart ssh
svcadm: svc:/network/ssh:default: Permission denied.

Starting with Solaris 9 link-based IPMP was released.  This uses the interfaces link state to determine the status of the network connection for failover/failback purposes.  With link-based IPMP the failover will occur instantly when a link goes down.   Since the failover is instantaneous and no extra IP addresses are required to build test interfaces, link-based IPMP is the preferred way to build redundant network interfaces on Solaris.

IPMP requires that each NIC has a unique MAC address. Before configuring IPMP verify that the local-mac-address? setting on the system PROM is set to true.
# eeprom local-mac-address?
local-mac-address?=true
If it’s not set to true then run the following command to change the setting and then reboot the system
# eeprom local-mac-address?=true

Link based IPMP can be configured as active/active or active/passive.  Examples of both are provided below.

Active/Passive
If your server is only using 1 IP address you will have to configure your IPMP as Active/Passive.  Here is a sample configuration.

/etc/hostname.e1000g0
192.168.3.32 group IPMP-1

/etc/hostname.e1000g1
group IPMP-1 standby

The standby keyword is used on the passive interfaces.  No hostname or IP address should be assigned to this NIC.
This configuration will result in the following after a system reboot.

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.3.32 netmask ffffff00 broadcast 192.168.3.255
groupname IPMP-1
ether 0:21:28:27:bc:84
e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
e1000g1: flags=69000842<BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 0 index 4
inet 0.0.0.0 netmask 0
groupname IPMP-1
ether 0:21:28:27:bc:85

An attempt to assign an IP address to a standby interface will cause that IP to be configured on another NIC in the IPMP group.
Notice in the following example an attempt to assign an IP address to e1000g1 will result in a new logical interface being configured on e1000g0. As long as the link status of one NIC in the IPMP group is good, then the standby interface will not allow any IP addresses to be configured on it.

# ifconfig e1000g1 addif 192.168.3.33 up
Created new logical interface e1000g0:2

In an active/passive configuration you can setup as many virtual IP address on the active NIC as you want.  However, if multiple IP addresses are to be used then it would probably make sense to use an active/active configuration for load balancing purposes.

Active/Active

If your server uses multiple IP address on the same network you can spread your network load across all NIC’s in your IPMP group.  The following example shows 2 IP address on 2 NIC’s.

/etc/e1000g0
192.168.3.32 group IPMP-1

/etc/e1000g1
192.168.3.33 group IPMP-1

This configuration will result in the following after a system reboot.

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.3.32 netmask ffffff00 broadcast 192.168.3.255
groupname IPMP-1
ether 0:21:28:27:bc:84
e1000g1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 192.168.3.33 netmask ffffff00 broadcast 192.168.3.255
groupname IPMP-1
ether 0:21:28:27:bc:85

-> set /HOST send_break_action=break
-> start /SP/console

ok>

In this article I have changed the font color for most of the commands you will need to run instead of putting a shell prompt.  This should make it easier to copy and paste multiple lines of shell commands right from your browser window.  If you going to try to retype the commands instead of copy/paste make sure you pay special attention to the quotation marks.  There is a difference between ‘ and ` and ” in a Unix shell.

Procedure 1: Using -t option to named.
When using -t option to named the executable itself defines the chroot jail environment.  named will execute using the standard location of the shared libraries as well as /etc/passwd and /etc/shadow, and then chroot itself.  This means that you do not have to create a full chroot environment.

1- Create named user and group for named processes and directory ownership
groupadd -g 20000 named
useradd -u 20000 -g 20000 -d /tmp -c "Bind DNS Daemon" -s /bin/false named
passwd -N named

2- Create the chroot jail environment
In this example the root of the chroot jail is going to be /opt/bind.
jail=/opt/bind
mkdir $jail
mkdir -p $jail/dev $jail/usr/local/{etc,sbin,var/run/named,var/named}

A. The $jail/dev directory
The following loop will create all required device files in the chroot jail and set the user, group and permissions correctly.

for DEV in conslog log null poll syscon tcp udp zero
do
MAJ=`ls -lL /dev/$DEV | nawk '{print $5}'`; MAJ=${MAJ%,}
MIN=`ls -lL /dev/$DEV | nawk '{print $6}'`
USER=`ls -lL /dev/$DEV | nawk '{print $3}'`
GROUP=`ls -lL /dev/$DEV | nawk '{print $4}'`
UPERM=`ls -lL /dev/$DEV | cut -c 2-4`
GPERM=`ls -lL /dev/$DEV | cut -c 5-7`
OPERM=`ls -lL /dev/$DEV | cut -c 8-10`
mknod ${jail}/dev/${DEV} c $MAJ $MIN
chown ${USER}:${GROUP} $jail/dev/$DEV
chmod u=${UPERM},g=${GPERM},o=$OPERM $jail/dev/$DEV
done

B. The $jail/usr/local directory
chown named:named $jail/usr/local/var/run/named
cp -p /usr/local/sbin/named  $jail/usr/local/sbin/
cp -p /usr/local/etc/* $jail/usr/local/etc/
cp -pr /usr/local/var/named/* $jail/usr/local/var/named/

Setup your named.conf and zone files in the $jail/usr/local directory structure.

If this DNS server is a slave server then the named user will have to have write permission to the zones directory.  If it is not a slave, this step isn’t necessary.  If you don’t change the permissions or ownership of the zones directory then you’ll see the following message when you start BIND.
[ID 873579 daemon.error] the working directory is not writable
Run the following two command to change the ownership and permissions of the zones directory.
chown named:named $jail/usr/local/var/named
chmod 750 $jail/usr/local/var/named

3- Update the dns/server SMF service to run your new version of BIND in the chroot jail using the named -t option.

svccfg -s dns/server:default
setprop start/user=astring:"named"
setprop start/group=astring:"named"
setprop options/chroot_dir=astring:"/opt/bind"
exit
svcadm refresh dns/server

Then edit the service method to run the named executable from the chroot jail.
# vi /lib/svc/method/dns-server
Change the line that says:
server="/usr/sbin/named"
to
server="/opt/bind/usr/local/sbin/named"

You can now manage your updated and chroot’ed version of BIND with your svcadm commands:
# svcadm enable dns/server
# svcadm disable dns/server
# svcadm restart dns/server

Or you can start named manually
# /opt/bind/usr/local/sbin/named -t /opt/bind -u named

=============================================================================================================================

Procedure 2: Using the /usr/sbin/chroot command
This procedure can be used to create a chroot jail for any binaries, not just named.  (Of course, you’ll have to modify the procedure to fit the executable you’re chroot’ing).  When using the /usr/sbin/chroot binary the change root occurs prior to the execution of the named binary. This means that by the time named executes it’s whole world is bound to the chroot jail.  The result is that all libraries and all configuration files that named depends on will have to be copied into the chroot jail.

Follow steps 1 & 2 from Procedure 1 above and then we’ll just add the necessary libraries and configuration files to that environment.

1- Add required libraries to the chroot jail.
Use the ldd command to get a list of the libraries that the original named binary uses, and copy those libraries over to your chroot jail.
jail=/opt/bind
ldd /usr/local/sbin/named

You will see that there are library files under /lib, /usr/lib, /usr/local/lib and /usr/local/ssl/lib. On SPARC systems you will also have some libraries from /platform/`uname -i`/lib as well.
You can either create these directories under your chroot jail and then copy the libraries over, or you can use the following loop to do all of it for you.

for LIB in `ldd /usr/local/sbin/named | nawk '{print $NF}'`
do
if [ ! -d "`dirname ${jail}${LIB}`"  ]
then
mkdir -p ${jail}`dirname ${LIB}`
fi
cp  $LIB  ${jail}${LIB}
done

A few other libraries are required as well:
cp -p /usr/lib/ld.so.1 $jail/usr/lib
cp -p /lib/nss_files.so.1 $jail/lib

And the zoneinfo library
mkdir -p `dirname $jail/usr/share/lib/zoneinfo/$TZ`
cp -p /usr/share/lib/zoneinfo/$TZ   `dirname $jail/usr/share/lib/zoneinfo/$TZ`

2- The chroot jail will also need to have a passwd, shadow and group file with the named user and group information to start the process.
mkdir $jail/etc
grep named /etc/passwd > $jail/etc/passwd
grep named /etc/shadow  >$jail/etc/shadow
grep named /etc/group > $jail/etc/group

3- Modify the dns/server SMF service to run /usr/sbin/chroot to set the chroot jail for named.
svccfg -s dns/server:default
setprop start/user=astring:"named"
setprop start/group=astring:"named"
setprop options/chroot_dir=astring:""
exit
svcadm refresh dns/server

Then edit the service method
# vi /lib/svc/method/dns-server
Change the line that says:
server="/usr/sbin/named"
to
server="/usr/sbin/chroot /opt/bind /usr/local/sbin/named"

You can now manage your updated and chroot’ed version of BIND with your svcadm commands:
# svcadm enable dns/server
# svcadm disable dns/server
# svcadm restart dns/server

Or you can start named manually
# /usr/sbin/chroot /opt/bind /usr/local/sbin/named -u named

BIND 9.6.1-P3 SPARC
BIND 9.6.1-P3 x64

These packages contain everything needed to run BIND on Solaris.  I have included a few necessary libraries from the Sunfreeware packages installed in step 2 below to avoid having any package dependency requirements.  I’ve also included a sample named.conf file, a few sample zone files and the most recent named.root file.

Compile and Run BIND 9.6.1-P3
1- Solaris does not come with compilers.  Sun/Oracle does, however, offer SunStudio as a free download.
You will need to setup an SDN account.
On my system I downloaded the tarfile installer for Sun Studio 12u1 and extracted it under /opt.  Depending on how you install Sun Studio you PATH variable may change in Step 3 below.

2-  Download and install a few extra packages from sunfreeware.com.
libgcc-3.4.6
openssl.0.9.8l
make-3.81

3- After installing the Sun Studio compiler and the sunfreeware packages,  edit your PATH variable so that all binaries will be found in the correct order.
# PATH=/usr/sbin:/usr/bin:/usr/dt/bin:/usr/openwin/bin:/usr/local/bin:/opt/sunstudio12.1/bin:/usr/ccs/bin
# export PATH

4- Obtain a copy of the BIND 9.6.1-P3 source code.

Once you’ve extracted the source code and entered the bind-9.6.1-P3 directory you can compile the usual way.
# ./configure –prefix=/usr/local
# make install
You now have a copy of Bind 9.6.1-P3 for use on your Solaris system.
Your configuration file will be /usr/local/etc/named.conf.

5- If you’d like, you can make a change to the Solars SMF dns/server start method so that you can control your newer version of BIND with the svcadm command.   Just edit the file /lib/svc/method/dns-server and change the line that says:
server=/usr/sbin/named
to
server=/usr/local/sbin/named

6- Create your named.conf file and zone files and you’re ready to go.
You can either start the new version of bind by running
# /usr/local/sbin/named
or, if you followed step 5 you can start it with
# svcadm enable dns/server

7- If you want to be able to manage DNS with rndc you will need to create a /usr/local/etc/rndc.conf file, and then create a “key” and a “controls” statement in your named.conf file.
The easiest way to do this is to run the following two commands. This will create the statements in proper syntax, including tab spacing, with a shared key for rndc to communicate with named.
# /usr/local/sbin/rndc-confgen > /usr/local/etc/rndc.conf
# sed -n ‘/# key/,$s/^#//p’ /usr/local/etc/rndc.conf  | grep -v ‘End of named.conf’ >> /usr/local/etc/named.conf

If you don’t do this you will get the following messages in your /var/adm/messages file when you start BIND.
[ID 873579 daemon.notice] couldn’t add command channel 127.0.0.1#953: not found
[ID 873579 daemon.notice] couldn’t add command channel ::1#953: not found
This is really nothing more than a notice that you will not be able to manage your named daemon with rndc.

Latest patch utilites patches list 01/26/10:

142251-01
141588-03
127884-01
125555-06
121296-01
119317-01
119254-72
121133-02
120900-04

If patching a system with zones also include the following patches:

121428-13
121430-43

Happy patching!

First, and most important, is that the mirroring must be done prior to the OS installation.  When you use the raidctl command to create or delete a RAID device all data will be wiped from the member disks.  In order to do this you will need to boot the system into single user mode from a Solaris DVD or a Jumpstart server.

The most current release of Solaris, update 8 (10/09), has a problem with the format command as outlined in bug 6901327.
If you intend on installing Solaris 10_u8, you should boot from the DVD of an earlier release to create the mirror. Then perform the installation from the update 8 media.

1) Boot into single user mode from Solaris 10_u7 (or earlier) DVD or Jumpstart image.

ok> boot cdrom –s

2) Run raidctl to get information needed to create raid device.

# raidctl
Controller: 1
Disk: 0.0.0
Disk: 0.1.0

3) Use raidctl to create mirror device.

Notice that you are informed that this action will delete all data on both disks and that have to answer “yes” in order to proceed.  This is why mirroring the boot disks using this method must be done prior to installing the OS.

# raidctl –C “0.0.0 0.1.0” –r 1 1
Creating RAID volume will destroy all data on spare space of member disks, proceed (yes/no)? yes
/pci@0/pci@0/pci@2/scsi@0 (mpt0):
Physical disk 0 created.
/pci@0/pci@0/pci@2/scsi@0 (mpt0):
Physical disk 1 created.
/pci@0/pci@0/pci@2/scsi@0 (mpt0):
Volume 0 created.
/pci@0/pci@0/pci@2/scsi@0 (mpt0):
Physical disk (target 1) is |out of sync||online|
/pci@0/pci@0/pci@2/scsi@0 (mpt0):
Volume 0 is |enabled||degraded|
/pci@0/pci@0/pci@2/scsi@0 (mpt0):
Volume 0 is |enabled||resyncing||degraded|
WARNING: /pci@0/pci@0/pci@2/scsi@0/sd@0,0 (sd0):
Corrupt label – bad geometry
Label says 286718976 blocks; Drive says 286607360 blocks
WARNING: /pci@0/pci@0/pci@2/scsi@0/sd@0,0 (sd0):
Corrupt label – bad geometry
Label says 286718976 blocks; Drive says 286607360 blocks
Volume c1t0d0 is created successfully!
Volume   Size   Stripe  Status   Cache  RAID
Sub             Size                    Level
Disk
—————————————————————-
c1t0d0  136.6G  N/A     SYNC     OFF    RAID1
0.2.0   136.6G          GOOD
0.1.0   136.6G          GOOD

3)  Label the mirror disk.

The following step does not work under Solaris 10_u8.  This is why it is suggested to use a previous update release of Solaris to perform these steps.

When you run “format” you will see error messages indicating that there is a corrupt label on the new disk drive.  You will have to use the “type” subcommand to install the appropriate VTOC for the RAID disk drive.  Under “type” choose “0” for auto configure, then label the disk.

# format
Searching for disks…WARNING: /pci@0/pci@0/pci@2/scsi@0/sd@0,0 (sd0):
Corrupt label – bad geometry
Label says 286718976 blocks; Drive says 286607360 blocks
WARNING: /pci@0/pci@0/pci@2/scsi@0/sd@0,0 (sd0):
Corrupt label – bad geometry
Label says 286718976 blocks; Drive says 286607360 blocks
done
c1t0d0: configured with capacity of 136.49GB
AVAILABLE DISK SELECTIONS:
0. c1t0d0 <LSILOGIC-LogicalVolume-3000 cyl 65533 alt 2 hd 16 sec 273>
/pci@0/pci@0/pci@2/scsi@0/sd@0,0
Specify disk (enter its number): 0
selecting c1t0d0
[disk formatted]
WARNING: /pci@0/pci@0/pci@2/scsi@0/sd@0,0 (sd0):
Corrupt label – bad geometry
Disk not labeled.  Label it now? no
FORMAT MENU:
disk       – select a disk
type       – select (define) a disk type
partition  – select (define) a partition table
current    – describe the current disk
format     – format and analyze the disk
repair     – repair a defective sector
label      – write label to the disk
analyze    – surface analysis
defect     – defect list management
backup     – search for backup labels
verify     – read and display labels
save       – save new disk/partition definitions
inquiry    – show vendor, product and revision
volname    – set 8-character volume name
!<cmd>     - execute <cmd>, then return
quit
format> type
AVAILABLE DRIVE TYPES:
0. Auto configure
1. Quantum ProDrive 80S
2. Quantum ProDrive 105S
3. CDC Wren IV 94171-344
4. SUN0104
5. SUN0207
6. SUN0327
7. SUN0340
8. SUN0424
9. SUN0535
10. SUN0669
11. SUN1.0G
12. SUN1.05
13. SUN1.3G
14. SUN2.1G
15. SUN2.9G
16. Zip 100
17. Zip 250
18. Peerless 10GB
19. LSILOGIC-LogicalVolume-3000
20. other
Specify disk type (enter its number)[19]: 0
c1t0d0: configured with capacity of 136.49GB
<LSILOGIC-LogicalVolume-3000 cyl 65533 alt 2 hd 16 sec 273>
selecting c1t0d0
[disk formatted]
WARNING: /pci@0/pci@0/pci@2/scsi@0/sd@0,0 (sd0):
Corrupt label – bad geometry
Label says 286718976 blocks; Drive says 286607360 blocks
Disk not labeled.  Label it now? yes
WARNING: /pci@0/pci@0/pci@2/scsi@0/sd@0,0 (sd0):
Corrupt label – bad geometry
Label says 286718976 blocks; Drive says 286607360 blocks
WARNING: /pci@0/pci@0/pci@2/scsi@0/sd@0,0 (sd0):
Corrupt label – bad geometry
Label says 286718976 blocks; Drive says 286607360 blocks
format> label
Ready to label disk, continue? yes

4) Now you can continue with the installation of Solaris.

The important piece of that is doing everything right.  One critical piece of information that is not often discussed is that software RAID should always be built on top of partitions, not with raw disk devices.  The reason for this is that superblocks get written to the last raw disk  in the RAID volume instead of the software RAID partition.  At boot the kernel will read the partition table from the raw disk for the RAID volume and cause all kinds of nastiness.  The partition tables will all look wrong, the kernel will write to addresses on the disk that don’t exist, and you will generally be unhappy with your system.  So plan ahead, create those partitions first, and then create the SW RAID volume using those partitions and lay your fs on top.

In the following sample environment there are a set of Solaris servers that exist in a local DNS domain that is different than my public DNS domain. We’ll say the public domain name is mycompany.com and the Solaris systems will be on an internally managed domain called solservers.mycompany.com.  The masquerade_envelope feature allows me to configure the domain portion of the e-mail address so that it shows my public DNS name instead of the internal.

Here is a sample configuration of a Solaris 10 SMTP server.

# cd /etc/mail/cf/cf
# cp main.mc new.mc
# vi new.mc

divert(0)dnl
VERSIONID(`@(#)sendmail.mc 1.11 (Sun) 06/21/04′)
OSTYPE(`solaris8′)dnl
DOMAIN(`solaris-generic’)dnl
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA’)
DAEMON_OPTIONS(`Port=smtp,Addr=192.168.1.25, Name=MTA’)
MASQUERADE_AS(`mycompany.com’)
FEATURE(masquerade_envelope)
MAILER(`local’)dnl
MAILER(`smtp’)dnl

# /usr/ccs/bin/make new.cf
# cp new.cf /etc/mail/sendmail.cf
# svcadm restart sendmail

The DAEMON_OPTIONS lines will configure your SMTP server to forward mail that is sent to either of those IP addresses.  The assumption here is that this server has an IP address of 192.168.1.25 and other mail clients will be sending mail to this system for forwarding.   If you only want this system to forward it’s own mail, and reject other client mail forward requests,  then get rid of the second line.




…And here is a sample sendmail client configuration that will forward it’s mail through this sever.

# cd /etc/mail/cf/cf
# cp main.cf new.cf
# vi new.mc

divert(0)dnl
VERSIONID(`@(#)sendmail.mc 1.11 (Sun) 06/21/04′)
OSTYPE(`solaris8′)dnl
DOMAIN(`solaris-generic’)dnl
define(`SMART_HOST’, `smtp.solservers.mycompany.com’)dnl
MASQUERADE_AS(`mycompany.com’)
FEATURE(`masquerade_envelope’)
MAILER(`local’)dnl
MAILER(`smtp’)dnl

# /usr/ccs/bin/make new.cf
# cp new.cf /etc/mail/sendmail.cf
# svcadm restart sendmail

The assumption here is that there is an entry on the internal DNS server that points smtp.solservers.mycompany.com to the IP address 192.168.1.25.