At least as of Solaris 10 10/09 (Update 8), Solaris Flash Archive technology is not compatible with Solaris Zones, making systems with zones more difficult to clone and deploy.

See Solaris Flash (Planning) for details

Workaround

The solution is to handle the zones separately using the zone clone/migration features. In the example below, we will be cloning a single zone, zone1, so that we can leave the clone detached and accessible. Newly flashed systems, on first boot, will copy the detached, cloned zone data to their primary zone1 root, then they will attach the copied data to their preconfigured zone1.

1. Create a one-time boot script for the destination system(s) to copy and attach the zone data

# vi /etc/rc3.d/S99zone_attach

#!/sbin/sh
/usr/bin/test -d /zones/zone1 || /usr/bin/mkdir -p /zones/zone1
/usr/bin/chmod 700 /zones/zone1
/usr/bin/cp -rp /net/master/zones/zone1_clone /zones/zone1
/usr/sbin/zoneadm -z zone1 attach
/usr/bin/rm /etc/rc3.d/S99zone_attach
exit 0
:wq!

# chmod a+x /etc/rc3.d/S99zone_attach

Note: This is just a simplified example. Be sure to modify the above script to account for changes in the flar master server and zone names. Additional modifications may also be necessary to account for alternate zone data locations or changes to the zone configuration.

2. Detach the primary zone

# zoneadm -z zone1 detach

3. Create the flash archive

# flarcreate -n s10zones -x /zones /var/archives/s10zones.flar

This archive will contain the one-time first boot script necessary for obtaining and attaching the cloned zone data below.

4. Re-attach the zone

# zoneadm -z zone1 attach

5. Set up the new zone, copy the configuration and clone the install data

# mkdir /zones/zone1_clone; chmod 700 /zones/zone1_clone
# zonecfg -z zone1 export | zonecfg -z zone1_clone -f -
# zoneadm -z zone1_clone clone zone1

6. Detach the new zone

# zoneadm -z zone1_clone detach

7. Delete the cloned zone configuration

# zonecfg -z zone1_clone delete

8. Export the detached, cloned zone filesystem

# share -o ro /zones/zone1_clone

• More information about cloning zones is here: Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones

• More information about zone migration is here: Moving and Migrating Non-Global Zones

• More information about flash archives is here: Solaris 10 10/09 Installation Guide: Solaris Flash Archives (Creation and Installation)

The supported method for dealing with this is to make changes to only one side of the mirror, then unencapsulate the root mirror before rebooting/resyncing.

1. Mount the root slice on one side of the mirror and make necessary repairs

# mount /dev/dsk/c0t0d0s0 /a

2. Backup the SVM configuration

# cp /a/etc/vfstab /a/etc/vfstab.svm
# cp /a/etc/system /a/etc/system.svm

3. Update /etc/vfstab and /etc/system to boot from plain slices on the repaired side of the mirror

# vi /a/etc/vfstab
(return all md devices to plain slices)

# vi /a/etc/system
(comment out rootdev line)

4. Reboot

# init 0
ok boot -r

5. Once the system is up, split the metadevice

# metadetach <mirror device> <secondary submirror>
(repeat for all mirrored slices)

6. Restore the configuration files in order to re-encapsulate, so the system boots on single-disk (single sub-mirror) mirror metadevices

# mv /etc/system.svm /etc/system
# mv /etc/vfstab.svm /etc/vfstab

7. Reboot

# init 6

8. After reboot, sync the mirrors

# metattach <mirror device> <secondary submirror>
(repeat for all mirror slices)

The boot archive is managed by two services:

svc:/system/boot-archive:default
svc:/system/boot-archive-update:default

The first checks, during boot, the contents of the boot archive against the files in the root filesystem. If there are any inconsistencies, the service drops to maintenance mode, preventing a full boot. While this can often be ignored, it may be necessary to re-create the boot archive from scratch (see below).

The second service updates the boot archive during a graceful shutdown or reboot, ensuring it is consistent with the equivalent files in the root filesystem for the next boot. A sudden or non-graceful shutdown is likely to leave the boot archive out of sync, resulting in the boot-archive service dropping to maintenance mode on the next boot.

If the contents of the boot archive do not match the files on the root filesystem, the following warning is displayed:

WARNING: The following files in / differ from the boot archive:

…along with a list of culprit files. If the list is empty, there may be some other problem, but in most cases, the archive simply needs to be updated. You can try ignoring the issue with the command # svcadm  clear boot-archive and on next shutdown the archive will be updated automatically, but the best way to deal with this issue is to recreate the boot archive while booted from alternate media; either from Failsafe mode, cd/dvd media, or a network image in single user mode.

ok boot -F failsafe
ok boot cdrom -s
ok boot net -s

1) Mount the root filesystem if it is not mounted already

# mount /dev/dsk/c0t0d0s0 /a

2) Remove the old archive (important, since simply updating the archive may not be sufficient for successful boot)

# rm -f /a/platform/`uname -i`/boot_archive

3) Finally, recreate it

# /usr/sbin/bootadm -R /a update-archive

4) Reboot

# init 6

This guide is not a discussion on which is better: ZFS or BtrFS (While many may argue that the fundamental design of BtrFS is superior, it is an unavoidable fact that ZFS is far older and thus more mature in terms of features, stability, and usability). Rather, it is meant to be used as a practical administrative reference containing instructions for performing some basic tasks in BtrFS, targeted at administrators who may be more familiar with ZFS concepts.

Note 1: This table was generated using Btrfs v0.19, included in the 2.6.33 kernel shipped with Fedora 13.

Note 2: The btrfs command aggregates the functionality of several legacy commands: btrfsctl, btrfs-show, and btrfs-vol. Each of the tasks below can be accomplished with these legacy commands as an alternative.

# btrfs device scan
# mount /dev/sda /pool1

# btrfs device add -a /dev/sdc /pool1
# btrfs device balance /pool1

N/A

# btrfs device delete /dev/sdc /pool1

# btrfs device delete /dev/sdc /pool1
or
# mount -o degraded /dev/sdb /pool1
# btrfs-vol -r missing /pool1
# btrfs device add /dev/sdb /pool1
# btrfs device balance /pool1

# btrfs subvolume list /pool1
OR
# mount -o subvol=. /dev/sda /mnt
# ls /mnt

List of things ZFS can do that BtrFS can’t (yet):

Disks/RAID/Integrity

Convert to a mirror

Split mirror (leaving pool identity on secondary disk intact)

Convert from RAID1 to RAID10

Replace disk live

Deduplication

RAIDZ/RAIDZ2/RAIDZ3

Block pointer rewrite: convert RAID types, expand RAIDZ

Automatic checksum healing

Recover uberblock

Space management

Clearly report space usage

User/group space accounting

Set reservation/refreservation/refquota

Enable compression live

Administrative options

COMSTAR integration

Solaris Zones integration

Solaris Live Upgrade integration

Delegated administration

Integrated exporting (CIFS/NFS/iSCSI)

NFSv4 ACLs/inheritence properties

Mixed case sensitivity

ZFS Send/Receive

Performance tuning

Separate ZIL

Tunable ARC cache

Cache devices

]]> http://www.seedsofgenius.net/uncategorized/zfs-vs-btrfs-a-reference/feed 0 http://www.seedsofgenius.net/solaris/solaris-authentication-login-with-active-directory http://www.seedsofgenius.net/solaris/solaris-authentication-login-with-active-directory#comments Thu, 03 Jun 2010 20:41:33 +0000 fcaton http://www.seedsofgenius.net/?p=301 In most office environments users will have a Windows workstation on their desktop; most locations do not have users’ log into a Unix/Linux desktop as their primary work environment. In these environments a small percentage of these users may have a need to connect to their Unix servers in order to manage databases, application servers, web servers, etc. It becomes an administrative nightmare to manage multiple sets of users for the Windows and the Unix systems. The reason for this nightmare is primarily password management. In a lot of cases, Windows and Unix systems have different password requirements even though they may be in the same environment.

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

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.