So here’s a very simple procedure for updating the hostname of your Solaris 10 server.

Step 1: Update /etc/hosts

Quite simply, you need to add an IP to hostname association for in here, for the new hostname you plan to use. In this example, I’ll use a “newsolaris” hostname.

192.168.0.6 newsolaris

Step 2: Change /etc/nodename

Just overwrite the previous value in this file (or make a backup copy of /etc/nodename to make possible going back to old hostname a bit easier):

echo "newsolaris" > /etc/nodename

Step 3: Update /etc/hostname.<primary interface>

This is a step more important for physical Solaris servers rather than for Solaris zones:

echo "newsolaris" > /etc/hostname.e1000g0

Step 4: Reconfigure network and reset hostname to the new value

/etc/init.d/network stop
/etc/init.d/network start

or, as it was in my case, if you don’t want to refresh network config and just need to apply the new hostname, do it manually:

uname -S newsolaris

See also:

• IP address configuration in Solaris zones
• inetadm – changing service properties
• S8MA – Solaris 8 migration assistant

Solaris 10 patch error codes

Exit    Meaning
code

0       No error
1       Usage error
2       Attempt to apply a patch that's already been applied
3       Effective UID is not root
4       Attempt to save original files failed
5       pkgadd failed
6       Patch is obsoleted
7       Invalid package directory
8       Attempting to patch a package that is not installed
9       Cannot access /usr/sbin/pkgadd (client problem)
10      Package validation errors
11      Error adding patch to root template
12      Patch script terminated due to signal
13      Symbolic link included in patch
14      NOT USED
15      The prepatch script had a return code other than 0.
16      The postpatch script had a return code other than 0.
17      Mismatch of the -d option between a previous patch install and the current one.
18      Not enough space in the file systems that are targets of the patch.
19      $SOFTINFO/INST_RELEASE file not found
20      A direct instance patch was required but not found
21      The required patches have not been installed on the manager
22      A progressive instance patch was required but not found
23      A restricted patch is already applied to the package
24      An incompatible patch is applied
25      A required patch is not applied
26      The user specified backout data can't be found
27      The relative directory supplied can't be found
28      A pkginfo file is corrupt or missing
29      Bad patch ID format
30      Dryrun failure(s)
31      Path given for -C option is invalid
32      Must be running Solaris 2.6 or greater
33      Bad formatted patch file or patch file not found
34      Incorrect patch spool directory
35      Later revision already installed
36      Cannot create safe temporary directory
37      Illegal backout directory specified
38      A prepatch, prePatch or a postpatch script could not be executed
39      A compressed patch was unable to be decompressed
40      Error downloading a patch
41      Error verifying signed patch
42      Error unable to retrieve patch information from SQL DB.
43      Error unable to update the SQL DB.
44      Lock file not available
45      Unable to copy patch data to partial spool directory.

See also:

• Solaris 8/9 patch return codes
• How to make sure you don’t corrupt your netinstall miniroot
• Installing Solaris with DHCP and PXE
  

Shared IP configuration for non-global Solaris zones

By default, non-global zones will be configured with a shared IP functionality. What this means is that IP layer configuration and state is shared between the zone you’re creating and the global zone. This usually implies both zones being on the same IP subnet for each given NIC.

Shared IP mode is defined by the following statement in zone configuration:

set ip-type=shared

Here’s all the commands needed to enable it for a zone called s10zone in my example:

solaris# zonecfg -z s10zone
zonecfg:s10zone> set ip-type=shared
zonecfg:s10zone> verify
zonecfg:s10zone> commit
zonecfg:s10zone> end
solaris#

While I’ve deployed quite a few zones before, it was only recently that I learned what sharing IP layer configuration meant in practical terms: no IP routing within non-global zone. So if for some reason you want your non-global zone to use a different IP route for connecting one of the available networks, you really can’t don it in shared IP mode, because your non-global zone can only inherit the routing rules of the global zone.

You still have an option of assigning different IP addresses to different virtual interfaces of a non-global zone, but unless their routing is catered for by the global zone, it won’t be of much use.

Exclusive IP configuration for non-global Solaris zones

Configured using this statement in zone configuration:

set ip-type=exclusive

… this mode implies that a given non-global zone will have exclusive access to one of the NICs on your system.

While for me the most important aspect of such exclusivity was the possibility to configure zone-specific routing, there’s obviously much more offered by this mode:

• DHCPv4 and IPv6 stateless address autoconfiguration
• IP Filter, including network address translation (NAT) functionality
• IP Network Multipathing (IPMP)
• IP routing
• ndd for setting TCP/UDP/SCTP as well as IP/ARP-level knobs
• IP security (IPsec) and IKE, which automates the provision of authenticated keying material for IPsec security association

So here it is – another design lesson for you – make sure you know what kind of networking your zones will need.

See also:

• Solaris 10 zones – a working example
• Types of resources in Solaris zones
• sparse root vs whole root in Solaris zones
  

What’s new in Solaris 10 update 7?

• ZFS support when cloning a Solaris zone – quite a useful tool for someone who always copied the files of Solaris zones. I personally did similar cloning myself, but it’s handy that now ZFS cloning is supported in the zoneadm command itself.
• IPsec – SMF services – Service Management Framework now manages all the necessary IPsec functionality with traditionally thorough approach: interface consistency, restarting anf fault-tracking are all provided. SMF services for IPsec are: ipsec/policy, ipsec/ike, ipsec/manual-key and ipsec/ipsecalgs.
• SunSSH with OpenSSL PKCS#11 Engine support – this opens way for more optimal use of hardware crypto accelerators.
• iSCSI Target improvements – greatly improved iSNS (Internet Storage Name Service) support, updates for improved interoperability. Most common iSCSI initiators are now supported
• NetXen 10-GigE driver – a new NIC driver called ntxn will make it possible to use 10-Gigabit cards on your x86 platform
• New locale support – greetings go to Kazakhstan and Ukraine which are now fully supported

This isn’t a full list of improvements, so if you’re interested in all the details – please read the official What’s New in Solaris 10 update 7 doc.

Solaris 10 u7 screenshots gallery

I’ve uploaded a few screenshots for you, nothing revolutionary but will still give you an idea if you have never seen Solaris 10 before:

[View with PicLens]

See also:

• What’s new in Solaris 10
• Solaris 10 zones: part one
• What is Solaris Express
  

If you run this command without any parameters, you’ll simply get a list of all the services it manages along with their current status:

solaris# inetadm
ENABLED   STATE          FMRI
enabled   online         svc:/application/x11/xfs:default
enabled   online         svc:/application/font/stfsloader:default
enabled   offline        svc:/application/print/rfc1179:default
enabled   online         svc:/network/rpc/gss:default
disabled  disabled       svc:/network/rpc/mdcomm:default
disabled  disabled       svc:/network/rpc/meta:default
disabled  disabled       svc:/network/rpc/metamed:default
disabled  disabled       svc:/network/rpc/metamh:default
...

I needed to start a time service on my system:

solaris# inetadm | grep time
disabled  disabled       svc:/network/daytime:dgram
disabled  disabled       svc:/network/daytime:stream
disabled  disabled       svc:/network/time:dgram
disabled  disabled       svc:/network/time:stream

To enable or disable a certain network service, you have to use -e (enable) and -d (disable) command line parameters. For instance, the following command has activated time for UDP:

solaris# inetadm -e svc:/network/time:stream

Now all we have to do is just make sure the service has been successfully started:

solaris# inetadm | grep time
disabled  disabled       svc:/network/daytime:dgram
disabled  disabled       svc:/network/daytime:stream
disabled  disabled       svc:/network/time:dgram
enabled   online         svc:/network/time:stream

Here is a partial list of what I regularly read, maybe you’ll like some of it:

Solaris blogs in Russian

• Ruslan Valiev – Designerus
• Unix Pin
• SunHelp.Ru

Solaris blogs In English

• Bryan Cantrill – The Observation Deck
• Ilya Voronin – CurThread.org
• Robert Milkowski – Milek’s Blog
• James Dickens – Unix Admin Corner
• Blog O’ Matty
• Bill Rushmore – Developer’s Quarterdeck Log
• Ben Rockwood – Cuddletech: use UNIX or die
• Derek Crudgington – A look into Solaris

Well, that seems to be all I read. Surely, there are hundreds more on blogs.sun.com and OpenSolaris.org blogs, so I enjoy opening main pages of these resources now and then just to selectively read the most interesting posts (I also find weekly lists of posts on OpenSolaris to be particularly useful).

If you know an interesting Solaris blog, please share it with me and I’ll update the list above.

Today I simply would like to tell a bit more about the contents of a BFU archive, using the latest available one as an example: ON b41.

After you download and unpack the archive, you will get a directory like this:

bash-3.00$ cd /export/dist/archives-b41
bash-3.00$ ls
BINARYLICENSE.txt THIRDPARTYLICENSE.BFU-ARCHIVES
README.BFU-ARCHIVES.i386 i386

Besides the text files with licenses, it also contains a README file with the full list of files supplied within the BFU along with the architecture-depended directory – i386 (this is because I’ve downloaded the BFU for my amd64-based box).

The i386 subdirectory contains the following:

bash-3.00$ cd /export/dist/archives-b41/i386
bash-3.00$ ls -al
total 512286
drwxr-xr-x 2 greys other 512 May 30 17:50 .
drwxr-xr-x 3 greys other 512 May 30 17:59 ..
-rw-r--r-- 1 greys other 61585 May 30 17:50 conflict_resolution.gz
-rw-r--r-- 1 greys other 67812860 May 30 17:50 generic.kernel
-rw-r--r-- 1 greys other 21769100 May 30 17:50 generic.lib
-rw-r--r-- 1 greys other 2097796 May 30 17:50 generic.root
-rw-r--r-- 1 greys other 1100800 May 30 17:50 generic.sbin
-rw-r--r-- 1 greys other 161510640 May 30 17:50 generic.usr
-rw-r--r-- 1 greys other 1264640 May 30 17:50 i86pc.boot
-rw-r--r-- 1 greys other 5329920 May 30 17:50 i86pc.root
-rw-r--r-- 1 greys other 1105920 May 30 17:50 i86pc.usr

As you can see, these files are nothing but cpio-archives with all the files supplied in the given BFU build:

bash-3.00$ file generic.kernel
generic.kernel: ASCII cpio archive

The README file contains the full list of all the files provided in the BFU archive, split by arhives which contain these files. So, this list has sub-sections named like ==== conflict_resolution.gz ====, or ==== generic.root ====, and so on.

If you’re keen on finding out what exactly you’ve got, feel free to browse your archives like this:

bash-3.00$ cpio -itv 
-rwxr-xr-x 1 root sys 5156384 May 30 17:37 2006, kernel/amd64/genunix
drwxr-xr-x 2 root sys 0 May 30 17:37 2006, kernel/amd64
-rwxr-xr-x 1 root sys 20512 May 14 16:51 2006, kernel/crypto/blowfish
-rwxr-xr-x 1 root sys 46216 May 30 17:36 2006, kernel/crypto/rsa
-rwxr-xr-x 1 root sys 8260 May 14 16:51 2006, kernel/crypto/arcfour
-rwxr-xr-x 1 root sys 35776 May 14 16:51 2006, kernel/crypto/aes
-rwxr-xr-x 1 root sys 12024 May 14 19:05 2006, kernel/crypto/amd64/arcfour2048
-rwxr-xr-x 1 root sys 27936 May 14 19:05 2006, kernel/crypto/amd64/blowfish448
-rwxr-xr-x 1 root sys 48072 May 14 19:05 2006, kernel/crypto/amd64/aes256
-rwxr-xr-x 1 root sys 27928 May 14 16:51 2006, kernel/crypto/amd64/blowfish
-rwxr-xr-x 1 root sys 23640 May 30 17:36 2006, kernel/crypto/amd64/swrand
-rwxr-xr-x 1 root sys 48072 May 14 16:51 2006, kernel/crypto/amd64/aes
-rwxr-xr-x 1 root sys 68352 May 30 17:36 2006, kernel/crypto/amd64/rsa
-rwxr-xr-x 1 root sys 12024 May 14 16:51 2006, kernel/crypto/amd64/arcfour
drwxr-xr-x 2 root sys 0 May 30 17:36 2006, kernel/crypto/amd64
-rwxr-xr-x 1 root sys 14784 May 30 17:36 2006, kernel/crypto/swrand
...

And if you want to check quickly, whether a particular file is part of the BFU, then that’s how you do it:

bash-3.00$ grep sbin/tar README.BFU-ARCHIVES.i386

… and just in case you want to compare it against the existing file you have in your current environment, it’s very easy to get the full listing of this file’s entry in an archive:

bash-3.00$ cpio -itv
lrwxrwxrwx 1 root root 11 May 30 17:17 2006, usr/bin/tar -> ../sbin/tar
-r-xr-xr-x 1 root bin 83788 May 30 17:49 2006, usr/sbin/tar

That’s it for today. Good luck with your OpenSolaris experiments!

So this is the ZFS pool I have:

solaris# zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
stock                  33.8G   2.40G   31.4G     7%  ONLINE     -

And like I said, it has only one drive in it:

solaris# zpool status
pool: stock
state: ONLINE
scrub: scrub stopped with 0 errors on Tue Jan 17 21:00:45 2006
config:
NAME        STATE     READ WRITE CKSUM
stock       ONLINE       0     0     0
c0t1d0      ONLINE       0     0     0

By default, when you create a zfs-pool, all of its disk space is represented as a single filesystem with the same name. This filesystem also gets a mountpoint with the same name and is automatically mounted off /. So, after doing a zpool create (here is my example) you can immediately start working with your newly made filesystem.

At the moment I’ve got only 1 additional filesystem created, I use it for Oracle 10g. So here’s how it looks:

solaris# zfs list
NAME                   USED  AVAIL  REFER  MOUNTPOINT
stock                 2.40G  31.1G  8.50K  /stock
stock/oracle          2.32G   693M  2.32G  /stock/oracle

According to ZFS concepts, all the newly made filesystems may use all the available disk space of the zfs-pool they belong to. So, when I create another filesystem in my stock pool, this filesystem has more than 30Gb available to it:

solaris# zfs create stock/try
solaris# zfs list
NAME                   USED  AVAIL  REFER  MOUNTPOINT
stock                 2.40G  31.1G   9.5K  /stock
stock/oracle          2.32G   693M  2.32G  /stock/oracle
stock/try                8K  31.1G     8K  /stock/try

To make sure that some of your filesystems don’t eat up all the available disk space, you have to limit them. And it’s very easily done so:

solaris# zfs set quota=512m stock/try
solaris# zfs list
NAME                   USED  AVAIL  REFER  MOUNTPOINT
stock                 2.40G  31.1G   9.5K  /stock
stock/oracle          2.32G   693M  2.32G  /stock/oracle
stock/try                8K   512M     8K  /stock/try

As you have probably guessed, quota is the parameter name, while set is a keyword to alter parameters values. There is quite a number of ZFS filesystem parameters, and most of them you can modify, but there are also some which are read-only. Here's an example of such a parameter, and you can see what happens if you try modifying them:

solaris# zfs get mounted stock/try
NAME             PROPERTY       VALUE                      SOURCE
stock/try        mounted        yes                        -
solaris# zfs set mounted=on stock/try
cannot set mounted property: read-only property

You can find the full list of ZFS filesystem parameters on the man page for zfs, as for me – I’ll show you only 1 more parameter today, and a very useful one in my opinion: a mount point. As all the rest things about ZFS, this parameter is very easy to change, and you even have the filesystem automatically remounted for you:

solaris# df -k | grep ^stock
stock                 35112960       8 32597478     1%    /stock
stock/oracle           3145728 2436188   709540    78%    /stock/oracle
stock/try               524288       8   524280     1%    /stock/try
solaris# zfs set mountpoint=/try stock/try
solaris# df -k | grep ^stock
stock                 35112960       8 32597478     1%    /stock
stock/oracle           3145728 2436188   709540    78%    /stock/oracle
stock/try               524288       8   524280     1%    /try

I left the df output intentionally here, to show that there were no additional manipulations made to the try filesystem – it really is this easy!

I guess that’s enough for today – so next time I’ll tell you about few more useful ZFS filesystem parameters. Good luck with your experiments!

Note: going with mod_auth_pam was decision made without me, and I was only asked to help get the chosen solution work. This being said, the recommended way to do external authentication for Apache 2 now is to use the mod_authz_external module and pwauth password authenticator.

It did seem like a rather trivial task – download mod_auth_pam, compile it for Apache 2, make sure everything works. The remote server uses NIS, I could freely log onto it.

And you know what? It didn’t work!

The module compiled pretty easily, but I couldn’t get it to work – error_log was reporting the same lines over and over again (I had to break the line to squeeze it into my blog format):

[Tue Dec 20 16:48:44 2005] [error] [client xxx.xxx.xxx.xxx]
PAM: user 'greys' - not authenticated: No account present for user

Up to this point, everything was done by the user himself with small help from me. At this stage is was decided I’d have a look myself. To make things easier, I also wanted to:

1. Move all the experiments onto my own Solaris 10 box
2. Make it all work for local users first, and only then get NIS working as well

Seeing the same errors on my box, I’ve decided to take a serious look at PAM. I’ve created Apache-related lines in /etc/pam.conf and added a debug option:

httpd  auth required           pam_authtok_get.so.1 debug
httpd  auth required           pam_unix_auth.so.1 debug

To make it more convenient to track all the messages, I’ve updated /etc/syslog.conf to include the following:

auth.debug                      /var/log/auth_log
user.debug                      /var/log/user_log

It got easier to see what was happening, at least I knew it was the /etc/pam.conf section I was thinking of. But the error was still there – my user definitely did exist in the system, only it wouldn’t be recognized by Apache (and I’ve broken the lines yet again here):

Dec 21 09:47:35 pele httpd[29143]: [ID 634615 user.debug]
pam_authtok_get:pam_sm_authenticate: flags = 1
Dec 21 09:47:35 pele httpd[29143]: [ID 378613 user.debug]
pam_dhkeys: user greys not found
Dec 21 09:47:35 pele httpd[29143]: [ID 896952 user.debug]
pam_unix_auth: entering pam_sm_authenticate()
Dec 21 09:47:35 pele httpd[29143]: [ID 219349 user.debug]
pam_unix_auth: user greys not found

It was the right time to look at how exactly PAM and Apache 2 interacted when I was giving the username and password trying to access my page. I immediately thought of Brendan Gregg’s OpenSnoop script for DTrace. And it was this script indeed which helped me see the problem:

60001 24744 httpd         -1   2 /etc/pam_debug
60001 24744 httpd         11   0 /etc/pam.conf
60001 24744 httpd         11   0 /usr/lib/security/pam_authtok_get.so.1
60001 24744 httpd         11   0 /usr/lib/passwdutil.so.1
60001 24744 httpd         11   0 /usr/lib/libsldap.so.1
60001 24744 httpd         11   0 /usr/lib/security/pam_dhkeys.so.1
60001 24744 httpd         11   0 /usr/lib/security/pam_unix_cred.so.1
60001 24744 httpd         11   0 /lib/libbsm.so.1
60001 24744 httpd         11   0 /lib/libsecdb.so.1
60001 24744 httpd         11   0 /usr/lib/libproject.so.1
60001 24744 httpd         11   0 /lib/libproc.so.1
60001 24744 httpd         11   0 /lib/librtld_db.so.1
60001 24744 httpd         11   0 /lib/libelf.so.1
60001 24744 httpd         11   0 /lib/libctf.so.1
60001 24744 httpd         11   0 /usr/lib/security/pam_unix_auth.so.1
60001 24744 httpd         -1   2 /var/run/syslog_door
60001 24744 httpd         -1  13 /etc/shadow
60001 24744 httpd         11   0 /var/run/name_service_door
60001 24744 httpd         11   0 /etc/passwd
60001 24744 httpd         -1  13 /etc/shadow
60001 24744 httpd         -1   2 /var/run/syslog_door

Apparently, httpd could not open /etc/shadow (-1 means error), obviously becase of permissions for the file. But just to make sure, I’ve looked for the error code (it’s 13 as you can see):

solaris# grep 13 /usr/include/sys/errno.h
#define EACCES  13      /* Permission denied                    */

So it all was suddenly clear, and I’ve proceeded like this:

solaris# groupadd shadows
solaris# chown root:shadows /etc/shadow
solaris# chmod 440 /etc/shadow

All that’s left to be done now was to make sure httpd.conf has a Group parameter set to this shadows group, and not nobody.

pS: you might ask why didn’t it work for NIS on the remote server in first place. This is because /etc/nsswitch.conf had not this:

passwd: files nis

but this:

passwd: compat

so NIS maps were consulted, but only based on + and – specifications in /etc/passwd and /etc/shadow files. This means we still needed to be able to read /etc/shadow, even though later PAM would consult NIS.

This script generates a table of Apache PIDs and PHP scripts started within, and later you’ll get a table of all the functions with PIDs which ran them and the time spent.

You can download this script here: php-scripts-timer.d

#!/usr/sbin/dtrace -s
#pragma D option quiet
BEGIN
{
printf("php scripts timer startedn");
}
:dtrace.so::function-entry
/ copyinstr(arg0) == "" && name[pid,copyinstr(arg1)] != 1 /
{
printf("%d -> %-30sn", pid, copyinstr(arg1));
name[pid,copyinstr(arg1)] = 1;
}
:dtrace.so::function-entry
/ copyinstr(arg0) != "" /
{
self->ts = timestamp;
}
:dtrace.so::function-return
/ copyinstr(arg0) != "" /
{
self->elapsed = timestamp - self->ts;
@time[pid, copyinstr(arg0)] = sum(self->elapsed);
}
END
{
printf("<------ php scripts timer finished");
printf("n%10s %40s %14sn", "PID", "PHP function", "Time elapsed");
printa("%10d %40s %14@un", @time);
}

A typical result of running this script while opening some PHP pages served by your Apache will look like this:

php scripts timer started
223074 -> /export/www/nightly/pma/left.php
223071 -> /export/www/nightly/pma/main.php
223074 -> /export/www/nightly/pma/css/phpmyadmin.css.php
223071 -> /export/www/nightly/pma/css/phpmyadmin.css.php
<------ php scripts timer finished
PID                             PHP function   Time elapsed
223074                             ob_get_level          22280
223074                              get_cfg_var          32678

I will, of course, read and understand all the inner workings of ZFS later, but the first impression of it is this – too easy to be true!

Here’s what I did:

solaris# mkdir /export/vdev
solaris# mkfile 128m /export/vdev/d1
solaris# mkfile 128m /export/vdev/d2
solaris# zpool create try /export/vdev/d1 /export/vdev/d2
solaris# zpool status
pool: try
state: ONLINE
scrub: none requested
config:
NAME               STATE     READ WRITE CKSUM
try                ONLINE       0     0     0
/export/vdev/d1  ONLINE       0     0     0
/export/vdev/d2  ONLINE       0     0     0
solaris# zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
try                     246M   32,5K    246M     0%  ONLINE     -

After this the newly made filesystem automatically became available (it’s a partial output of df -k):

Filesystem            kbytes    used   avail capacity  Mounted on
try                   235520    3722  231771     2%    /try

Enough for the moment! Now the next challenge will be freeing up one of the two physical disks I’ve got in my Netra t1, so that I could bring it under ZFS control.

As with sh or bash, you can access command line parameters via $0..$9 macroses. But there’s a catch. Values of these macroses should match a certain definition – a number, an identifier or a string. If there isn’t a match here, you’ll get an error.

Let’s start with a simple script.

#pragma D option quiet
BEGIN {
#!/usr/sbin/dtrace -s
printf("Your parameter: %dn", $1);
}

If you pass a number as a command line parameter, there will be no error, and you’ll get this message:

Your parameter: 123

But if you pass a string instead of number, here’s the error you’ll get:

solaris# ./args.d a1b2c3
dtrace: failed to compile script ./args.d: line 9: failed to resolve a1b2c3: Unknown variable name

This happens because DTrace tries to find an identifier “a1b2c3″. Why does this happen? Because of the way DTrace tries to recognize the type of a command line parameter. The parameter doesn’t look like a number, but to make DTrace accept the value as a string, you have to specify it in quotes. Without them, DTrace accepts we’ve passed an identifier name. And since there isn’t one with such a name, we get an error.

To prove this theory, you simply have to create a variable with the same name in your script:

#!/usr/sbin/dtrace -s
#pragma D option quiet
BEGIN {
a1b2c3=1979;
printf("Your parameter: %dn", $1);
}

There you go – it works just like I said:

Your parameter: 1979

And if your parameter is definitely a string, you have to change your script (the line with printf, so that it has %s for a string, and not %d for an integer, otherwise you’ll get another error)…

#!/usr/sbin/dtrace -s
#pragma D option quiet
BEGIN {
a1b2c3=1979;
printf("Your parameter: %sn", $1);
}
...

and also put your parameter in quotes, like this:

solaris# ./args.d '"a1b2c3"'
Your parameter: a1b2c3

As you can see, we’re getting a string we passed, and not the variable with the same name, which was left in the script intentionally to demonstrate it’s not used anymore.

And finally, one more thing. If you want all your command line parameters to be treated as strings by default and even leave the quotes around parameters out, all you have to do is to access the macroses for your parameters with a double $ sign, and then the parameter type definition will be skipped:

#!/usr/sbin/dtrace -s
#pragma D option quiet
BEGIN {
a1b2c3=1979;
printf("Your parameter: %sn", $$1);
}

And here’s how you’d access such a script with the same parameter we’ve used before:

solaris# ./args.d a1b2c3
Your parameter: a1b2c3

That’s it for today! Good luck with your DTrace scripts!

All of this is done on a software level, and by default every Solaris 10 machine has a global zone – only from this zone you can view processes of all the rest zones on your system. You probably didn’t even notice, but upon the completion of your Solaris 10 install, you’re immediately put into the global zone. It’s very easy to see this zone:

solaris# zoneadm list -vc
ID NAME             STATUS         PATH
0 global           running        /

To create a non-global zone, just plan some hard drive space for it, and work away! You’re going to need a zonecfg command. You must specify a zone name as a command line parameter:

solaris# zonecfg -z zone3

If the zone specified doesn’t exist, you’ll see a message about it, and zonecfg will put you into it’s command interface, where you can manage or create zones. Type the following (line by line):

solaris# zonecfg -z zone3
zone3: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone3> create
zonecfg:zone3> set zonepath=/sr/zones/3
zonecfg:zone3> set autoboot=false
zonecfg:zone3> add net
zonecfg:zone3:net> set address=192.168.0.7
zonecfg:zone3:net> set physical=bge0
zonecfg:zone3:net> end
zonecfg:zone3> verify
zonecfg:zone3> exit

This set of commands will create you a simple zone. There aren’t that many parameters initially, as you can see:

• zonepath is the full path to the directory where the specified zone’s files will reside
• autoboot is a flag used to determine whether a non-global zone should be automatically booted up every time your actual system (with your global zone) boots.

Further on, we’re assigning one network interface to our zone, and give it an IP address. You should specify the name of the real network interface present in your global zone. For the zone you’re creating, zonecfg will have a virtual interface based off the real one you specify.

Now it’s time to verify your config – this command makes sure all the necessary parameters have got their values set. After this, we’re done.

Now, if you look at the list of your zones again, you’re going to see a newly created zone as well:

solaris# zoneadm list -vc
ID NAME             STATUS         PATH
0 global           running        /
- zone3            configured     /sr/zones/3

Right now our zone is in a “configured” state – it can’t be used until we install OS onto it and it gets its unique ID. Obviously, you won’t be able to boot your zone unless it has installed OS.

Here’s a list of the states a non-global zone can be in:

• configured – our zone is configured, but it’s yet to have its initial boot
• incomplete – zoneadm command sets a zone’s state to this value while installing and uninstalling a zone. When the operation is completed, zone’s status is changed.
• installed – zone is fully configured, OS packages have been installed. It’s a ready-to-use zone, all you have to do is to boot it. The zone has no virtual platform associated yet.
• ready – the zone is ready. It already has a virtual platform established, the kernel has created a zsched process, all the network interfaces are plumbed, devices are configured and file systems are mounted. No processes have been started yet, but since the zone is ready it already has a unique ID assigned to it. We normally don’t see a zone in this state, and it always moves one to the next one – running.
• running – the zone is up and running. You can connect to the zone. It’s a fully working environment now.
• shutting down and down are short-term states which are shown when the zone is being halted. Upon completion of halt, the zone gets back into installed state.

Now, it’s time to continue configuring our zone. We should install it. It is done with the following command:

solaris# zoneadm -z zone3 install

After this you can watch the process of packages installation for your zone, and when all the packages are installed, you’ll get the location of the OS installation log file. That’s it! Our zone is ready, and you can boot it:

solaris# zoneadm -z zone3 boot

Wonderful. But we still can’t log in… Why? Because we’ve yet to configure the OS inside our zone – just like we would configure any box we’ve just installed with Solaris. As you’ve noticed, the order of OS installation is slightly different – in real life you have to configure the box first, and then you get to watch all the packages installing on it, with zones it’s the other way around – first copy all the stuff, then configure the OS.

What we need now is connect to the zone’s console and answer all the standard Configuration Assistant’s questions, one of them is the root password. After this, your zone will want to reboot, and you’ll be able to log in as root on your console. If you want to allow remote root logins, you’ll obviously need to add theCONSOLE=/dev/console line to /etc/default/login.

To reach a zone’s console, you should use zlogin command, -C means “console”:

solaris# zlogin -C zone3

You can disconnect from the console using the standard combination: “~.” (tilda dot)

One more thing. Since non-global zones will share the physical network interface with your global zone – you’ve got to make sure your system (your global zone) can see your non-global zones networks.

For instance, here’s the ifconfig -a from my laptop:

bge0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
zone zone2
inet 192.168.0.6 netmask ffffff00 broadcast 192.168.0.255
bge0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.0.2 netmask ffffff00 broadcast 192.168.0.255
bge0:3: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
zone zone1
inet 192.168.0.5 netmask ffffff00 broadcast 192.168.0.255

As you can see, interfaces assigned to zones are marked with the “zone” parameter. I had to create a virtual interface (bge0:2) from the same subnet as the IPs of my zones. This way, I can ping interfaces assigned to each of the zones configured.

One more thing I wanted to mention: software packages, installed in a zone. Most curious of you have probably looked inside the installation log file, and noticed, that most of the standard Solaris 10 packages have been installed in our zone. At the same time, the directory with our zone’s files takes up roughly 70mb…

Such an incostistancy is explained by one of the key features of the zones virtualization: non-global zones can easily share files with the global zone. Thus, you can specify for each zone, that some files (packages), when required by the installer, should not be actually copied and installed, but just borrowed from the global zone – every time you’ll want to access some of these files in your non-global zone, they’ll be taken from the ones in your actual system – from your global zone.

Obviously, all the files inherited in such a way by non-global zone, will be read-only.This technique allows you save lots of space, and by default all the files from /lib, /platform, /usr and /sbin directories are shared with the global zone. It is important to undestand that this happens only to the standard packages. So, if you’ve added some files of yours in the abovenamed directories, they will obviously NOT be shared with non-global zones.

Well, I guess it’s enough for the part one of my notes on Solaris zones – with any luck you should now have a working zone which you can access remotely – log in, manage services, do whatever you want.

I’ll add more stuff whenever I have a minute to spare….

When trying to FTP some files off my laptop, I’ve noticed FTP client failing to parse the ls -l output due to Russian weekdays used in listing. It was obvious that such FTP daemon behavior was due to one of its options, which specifically made sure the daemon inherited all the environment variables. Luckily such a behavior was easy to change with inetadm:

To list all the options of a given service, use a command similar to this:

solaris# inetadm -l svc:/network/ftp:default
SCOPE    NAME=VALUE
name="ftp"
endpoint_type="stream"
proto="tcp6"
isrpc=FALSE
wait=FALSE
exec="/usr/sbin/in.ftpd -a"
user="root"
default  bind_addr=""
default  bind_fail_max=-1
default  bind_fail_interval=-1
default  max_con_rate=-1
default  max_copies=-1
default  con_rate_offline=-1
default  failrate_cnt=40
default  failrate_interval=60
default  inherit_env=TRUE
default  tcp_trace=FALSE
default  tcp_wrappers=FALSE

As you can see, there was an inherit_env variable, set to TRUE by default. All I had to do was to switch it off:

solaris# inetadm -m svc:/network/ftp:default inherit_env=FALSE

After this FTP daemon has stopped inheriting environment variables, and, accordingly, switched to using C (English) locale for displaying weekdays in ls listings.

Using similar command line, you can alter any options of any service which is under inetadm control.

DTrace aggregations are created specifically for answering such questions. Working with sets of numerical data, aggregation functions help us to easily determing average, min and max values of data sets, count numbers and sums of elements in these data sets, and even build frequency distributions.

More information can be found here, but today I’ll show only few examples of using aggregations.

DTrace stores the results of aggregation functions in objects called aggregations.
The syntax is:

@name[ keys ] = aggfunc ( args );

here’s what this line means:

• name – name of our aggregation
• keys – index keys, very similar to those of associative arrays.
• aggfunc – aggregation function
• args – function arguments, usually it’s a set of numerical data

Today I’ll use sum aggregation function, which as it’s obvious from the name, helps us calculate the sum of a numerical data set,

Only the current value of the aggregation function is stored in the memory, it’s calculated off the previous function argument values. Then the function is calculated for the current value of the argument, and this result is applied to the current aggregation value.

For basic analysis you can use as few aggregations keys as you can – for instance, use only PID, without specifying thread ID as another index key.You can even use execname – but keep in mind that there might be more than one process running on your system with the same name. Still, execname-based aggregation will be quite useful to track what’s getting most of our system’s attention:

Here’s our script:

#!/usr/sbin/dtrace -s
#pragma D option quiet
syscall:::entry
{
self->ts=timestamp;
}
syscall:::return
{
self->elapsed = timestamp - self->ts;
@time[execname]=sum(self->elapsed);
}
END
{
printf("n%20s %20sn","Execname", "Time elapsed");
printa("%20s %20@un", @time);
}

Save it into a file, do chmod a+x on this file and start it. You’ll get an output similar to this:

Execname               Time elapsed
xscreensaver                   5710
gnome-smproxy                  6886
wnck-applet                    7735
gnome-panel                   52032
metacity                      54430
gnome-settings-d              60419
vim                           66452
mixer_applet2             670078802
gnome-netstatus-          819836799
nautilus                  900025830
Xorg                     1074783431
gnome-terminal           1074816530
firefox-bin              2000076871
dtrace                9843796821648

The time in the last column is given in nanoseconds, so don’t be scared with such huge numbers For timing some actions in your script timestamp proves to be VERY useful. It’s a nanoseconds counter which increments from an arbitrary point, so it can be used for relative computations only.

Now you can look at the output and notice how much of unnecessary actions is happening on my laptop with started Gnome

If you want a deeper analysis, you can make our script a bit more complex, and you’ll get a powerful tool for determining what process was doing what on our system, and for how long.

#!/usr/sbin/dtrace -s
#pragma D option quiet
syscall:::entry
{
self->ts=timestamp;
}
syscall:::return
{
self->elapsed = timestamp - self->ts;
@time[execname,probefunc,pid,tid]=sum(self->elapsed);
}
END
{
printf("n%20s %20s %8s %7s %20sn",
"Execname", "Syscall", "Process", "Thread", "Time elapsed");
printa("%20s %20s %8d %7d %20@un", @time);
}

If you save this code into syscalls.d and start the script, you’ll probably get something similar (I’ve deleted lots of lines to save up some space):

Execname              Syscall  Process  Thread         Time elapsed
gnome-terminal           read     7199       1                12867
Xorg                     read     6953       1                13769
dtrace                    brk     7331       1                33647
dtrace               schedctl     7331       1                39320
gnome-terminal          write     7199       1                48052
Xorg                   writev     6953       1                57112
gnome-terminal        pollsys     7199       1               646816
dtrace               lwp_park     7331       1             44817217
Xorg                  pollsys     6953       1             46936244
dtrace                  ioctl     7331       1        9269224066655

If you leave such a script running for a couple of minutes, you’ll get a very long output with the list of every process running on your system all the system calls it’s been executing, with the time spent by each thread of each process.

Full list of macro variables can be found here, I will only talk about $target variable this time.

$target specifies the PID of the process you associate with your DTrace script.

DTrace has two useful command line options which can be used not only when running a dtrace command, but also when running DTrace-scripts:

solaris# ./script.d -c xterm

This command asks DTrace to run a command which follows the -c option, and process the actual script.d only after this. Our macro variable, $target, will containt a PID of the started command we specified – xterm in this example.

solaris# ./script.d -p 654

This is a similar way of running a DTrace script, only we notify DTrace that we’d like to work with the process with PID of 654. This way of using DTrace is especially useful as you don’t have to start or restart an already running process. $target will contain the PID specified in the command line – 654 in this example.

$target may be used like this:

#!/usr/sbin/dtrace -s
#pragma D option quiet
syscall:::entry, syscall:::return
/pid == $target/
{
printf("%d/%d: %s:%sn", pid, tid, probefunc, probename);
}

If you execute this script, you’ll probably get an output like this:

solaris# ./script.d -c xterm
26525/1: munmap:entry
26525/1: munmap:return
26525/1: mmap:entry
26525/1: mmap:return
26525/1: setcontext:entry
26525/1: setcontext:return
26525/1: getrlimit:entry
26525/1: getrlimit:return
26525/1: getpid:entry
26525/1: getpid:return
...

Just a little bit later I’ll talk about aggregations – yet another one of the wonderful DTrace features, and then I’ll be able to give you more interesting and useful examples of DTrace scripting.

The following example catches all the probes of the fbt provided. By default (that’s our case since we’re not changing any other options but flowindent), DTrace registers and prints to the standard output all the probes matched in the tracing process.

Here is our script:

#!/usr/sbin/dtrace -s
fbt:::
/execname == "dtrace"/
{
}

And this is the output we’ll get by running this script:

dtrace: script './try5.d' matched 32659 probes
CPU     ID                    FUNCTION:NAME
1   2027                    xc_sync:entry
1    819                 xc_do_call:entry
1   1210         mutex_vector_enter:entry
1   1238               lock_set_spl:entry
1   2353                       splx:entry
1  15484                apic_setspl:entry
1  15485               apic_setspl:return
1   2354                      splx:return
1   1239              lock_set_spl:return
1   1211        mutex_vector_enter:return
1    821                  xc_common:entry
1  15510              apic_send_ipi:entry
1  15511             apic_send_ipi:return
...

But if we only add the flowindent option to our script (you can also achieve the same result by using -F dtrace command line option), the output is going to appear much more readable and easy to follow:

Our new script:

#!/usr/sbin/dtrace -s
#pragma D option flowindent
fbt:::
/execname == "dtrace"/
{
}

And this is the output we’ll get:

dtrace: script './try5.d' matched 32659 probes
CPU FUNCTION
1  -> xc_sync
1    -> xc_do_call
1      -> mutex_vector_enter
1        -> lock_set_spl
1          -> splx
1            -> apic_setspl
1            <- apic_setspl
1          <- splx
1        <- lock_set_spl
1      <- mutex_vector_enter
1      -> xc_common
1        -> apic_send_ipi
1        <- apic_send_ipi
...

Such a command line will show you all system calls made by Xorg in the last 5 seconds:

solaris# dtrace -n 'syscall:::entry /execname == "Xorg"/ {@[probefunc] = count(); } tick-5sec {printa(@); clear(@);}'
dtrace: description 'syscall:::entry ' matched 227 probes
CPU     ID                    FUNCTION:NAME
0  36588                       :tick-5sec
writev                                                           20
lwp_sigmask                                                      38
setcontext                                                       38
setitimer                                                        75
read                                                            422
pollsys                                                         426

pS: some time later I’ll hopefully write more about what DTrace and D language are

For example, here’s a start of the most basic analysis.

My setup: The system is constantly busy with something, and our task is to find what’s responsible for this. How? One of the possible solutions is to simply watch the system for a certain period of time (5 seconds in our case) to see what process makes most system calles… And it’s clearly seen now that the most active consumer of system calls is Java VM which happens to run a very complex graphics applet at this very moment.

As for rxvt terminals, we’re seeing so many calls simply because we’re building our list based on the command name and not PID, so in the table we really see the cumulative number of system calls made by roughly 40 terminals I’ve got running on my box, and not a single session as one might think. Had I done the PID-based list, all the 40+ rxvt processes would have been shown separately.

Here it goes:

solaris# dtrace -n syscall:::entry'{@[execname] = count()} tick-5sec {printa(@); clear(@);}'

And this is the result of such a command line. Every 5 seconds you’ll see an output similar to this:

dtrace: description 'syscall:::entry' matched 227 probes
CPU     ID                    FUNCTION:NAME
1  36588                       :tick-5sec
svc.configd                                                       1
expect                                                            3
telnet                                                            4
svc.startd                                                        6
sendmail                                                         10
thunderbird-bin                                                  10
htt_server                                                       10
nscd                                                             13
mozilla-bin                                                      19
soffice.bin                                                      77
xautolock                                                       106
dtrace                                                          173
icewm                                                           225
Xorg                                                            874
rxvt                                                           2008
java_vm                                                        2651

DTrace – dynamic tracing

DTrace allows you to dynamically trace anything and everything in real time. You can observe processes both in userland and kernel space, watch them as closely as you want and this all with virtually no performance impact. This allows DTrace to be used on a production system being absolutely sure it’s not going to considerably slow the system down or crash it.
I think it’s one of the best Solaris 10 innovations – all the administrators and developers will like it.

ZFS file system (zettabyte file system)

This is a new filesystem – it promises to put an end to all the standard troubles every system administrator has with file systems. By introducing a virtual storage pool, you will be able to grow or shrink file systems much easier by simply adding new physical disks to this pool. The same storage pool is going to be used for all the filesystems you need – so, having added 10 more physical disks to the pool, you’ll be able to decide which filesystems you want to grow.

Predictive Self-Healing (PSH)

PSH is a set of automated diagnostics, isolation and recovery procedures for most of the hardware and software faults which might occur on your system. In case of hardware failure, PSH will be able to safely isolate the faulty part and notify all the hardware and software resources which might be dependant on this faulty part.

PSH has few components. Someday I’ll write more on it, but in short – here’s how it works: mst of the work is done by Solaris Fault Manager (SFM) and Solaris Service Manager (SSM).

SFM is watching the hardware – if it find a faulty processor, a bad memory region or some faulty I/O device, it will automatically isolate the part before it fails completely and provokes a system crash or some other failure.

SSM in its turn is looking after all the applications – all the daemons are started as services, and with just few commands you can get their status, restart them or set up logical dependancies between them.

For instance, a telnet service will be dependant on the basic network services – the ones which configure network interfaces. Because of the dependancies, if system interfaces weren’t configured on boot-up, the appropriate service will not be in online state and this will make dependant telnet service to fall into the maintenance mode, waiting for the necessary network services to come online. It all sounds rather complicated (and it actually is!), but if you properly configure everything, it works together fairly well.

Network performance

There was a lot of stuff rewritten in TCP/IP stack and this allowed Solaris 10 to reach a much better performance.
One of the main achievements is the linear scalability on multi-processor systems. All the latest network technologies are obviously supported as well. The project name for these improvements is FireEngine, and I’ll probably try and find some links to the pages related to it.

Janus – Linux environment running on Solaris

It is promised that you’ll be able to run many Linux applications on Solaris systems. Practically, this feature allows you to run any native Linux application without any changes to it or any reboots, with the performance almost as good as original. To make this work, you’ll have to free up some spance on your disks for Linux libraries, and there is still no guarantee that every application will work, but to proove the concept, Sun engineers have already successfully started BEA WebLogic Server and Oracle Database Server for Linux, Samba and Apache were also tested, as well as lots of browsers and office packages.

So, here it is – my first PHP Dtrace script: php-scripts-snoop.d

#!/usr/sbin/dtrace -s
#pragma D option quiet
:dtrace.so::function-entry
/ copyinstr(arg0) == "" /
{
printf("%d -> %-30sn", pid, copyinstr(arg1));}
:dtrace.so::function-return
/ copyinstr(arg0) == "" /
{
printf("%d <- %-30sn", pid, copyinstr(arg1));
}

So go ahead, download the script, do

solaris# chmod a+x ./php-scripts-snoop.d

for it, and after you start it in a terminal of your web-server, you can run PHP scripts from this server, and our DTrace script will be reporting us whenever each PHP script stars or finishes, specifying which Apache process is responsible for this:

solaris# ./php-scripts-snoop.d
204934 -> /export/www/pma/index.php
204934 <- /export/www/pma/index.php
204934 -> /export/www/pma/css/phpmyadmin.css.php
204934 <- /export/www/pma/css/phpmyadmin.css.php
204936 -> /export/www/pma/left.php
204934 -> /export/www/pma/queryframe.php
204936 <- /export/www/pma/left.php
204936 -> /export/www/pma/main.php
204934 <- /export/www/pma/queryframe.php
204934 -> /export/www/pma/css/phpmyadmin.css.php
204934 <- /export/www/pma/css/phpmyadmin.css.php
204934 -> /export/www/pma/css/phpmyadmin.css.php
204936 -> /export/www/pma/css/phpmyadmin.css.php
204934 <- /export/www/pma/css/phpmyadmin.css.php
204934 -> /export/www/1.php
204934 <- /export/www/1.php
204936 <- /export/www/pma/css/phpmyadmin.css.php

pS: yes, starting of today I’ve decided to provide download links for each of my scripts – should be more convenient for you now. This means that sooner or later I’ll update all the archive blog entries to have download links for respective scripts.

Example of fully configuring a Solaris 10 zone

For starters, let’s have a look at the full configuration of our zone. You’ve probably guessed by now, that we only specified the minimal number of parameters when creating our zone. Now I’ll show you how to get a full view of our zone’s configuration, and I’ll also talk a bit about types of resources you can allocate to a non-global zone.

Start zonecfg with export command to get a full configuration (export is a command line parameter in my example, but if you like, you can do zonecfg -z zone1 and then type export when prompted for a command):

solaris# zonecfg -z zone1 export
create -b
set zonepath=/sr/zones/1
set autoboot=false
add inherit-pkg-dir
set dir=/lib
end
add inherit-pkg-dir
set dir=/platform
end
add inherit-pkg-dir
set dir=/sbin
end
add inherit-pkg-dir
set dir=/usr
end
add net
set address=192.168.0.5
set physical=bge0
end

As you can guess from the name of the command -export, we’re getting a full list of commands for zonecfg to create a similar zone. We’re exporting the config. I’ll talk about this a bit more some other time.

Lookinf at the output, you can recognize some of the commands we’ve actually typed following the instructions from my previous entry, but there are also few new commands. Particularly, they are the file-system (packages) related ones. I’ll definitely have a separate blog entry on file systems in zones, but for now I’ll just talk about resources for zones.

Each non-global zone can be allocated any resources you have on your actual system. Resources are added with an add command, which you can see now in the output I’ve given. This commands takes a parameter – a resource type.

Resource types in Solaris 10 configuration

• net - a network interface. As you remember, when adding such a resource, you have to specify a physically present network adapter card you have in your box, and zone’s network interface will be a virtual interface on this network adapter.
• device - any additional device. Using device names mask (for instance, /dev/pts*), you can allow a non-global zone access any devices you have on your actual system.
• fs - a file system. You can grant access to a physical disk or any directory of your actual system to any non-global zone. You can specify a file system type along with mount options, which is very convenient.
• inherit-pkg-dir - a globa zone root filesystem directory which is inherited by a non-global zone. Specifying a directory name, you’re pointing to the fact that all the files from this directory of your actual system (global zone) will not be physically copied into the non-global zone, but insteal will be inherited. The fact is, files from these directories will be accessible through a read-only loopback filesystem in your non-global zone (thanks, Dan!)
• attr - an attribute. With resources of this type you can create text comments for your zones – these comments might come in handy when you get back to reconfiguring your zone some time later.
• rctl - a zone-wide resource control. At this stage, there are only two parameters of this type -zone.cpu-shares and zone.max-lwps, but there will be more in the future. These parameters allow you to limit a CPU time given to a zone, and limit a max number of lwp processes which can be created in a zone.

As I’ve already told before, this motherboard comes equipped with 2 network adapters:nForce4 and Yukon Gigabit Ethernet 10/100/1000Base-T Adapter. Both adapters are based on Marvell chips – they are Marvell 88E8001-LKJ1 (PCI Gigabit Ethernet) and Marvell 88E1111-RCJ (PHY) respectively.

So, the first one of these adapters is properly found and supported in Solaris 10 out of the box. In fact, Solaris 10 even finds and attempts to configure nge0 during the initial OS install.

To make the Yukon Gigabit (Marvell) adapter work, you should go to the SysKonnect website and navigate to the drivers downloads page (skge is there as well). What’s REALLY cool is that there is a 64bit driver already! So I’ve got myself this file: skgesol_x64v8.12.1.3.tar.Z

After you unpack the archive, you should install the SKGEsolx, and that’s it – the pre-install script even allows you to configure skge0 adapter – set its IP and network mask.
This is where my two network adapters are found (taken from /etc/path_to_inst):

"/pci@0,0/pci10de,5c@9/pci1043,811a@c" 0 "skge"
"/pci@0,0/pci1043,8141@a" 0 "nge"

Attention: due to unknown reasons, prtconf -vp clearly shows only one of the adapters – skge. That’s the one represented by the “Ethernet controller” model name. Don’t know why, but nge is called “Bridge device” there.

I believe those of you who are just getting started with ZFS will really like the -n command line option for zfs and zpool, which allows you to see what result would a certain command yield, while there is nothing actually done to your disks.

So, if you’re thinking of creating a new storage pool, you don’t have to actually create it just to see how it will look – you can use -n option instead:

solaris# zpool create -n mypool raidz /export/vdev/d1 /export/vdev/d2 /export/vdev/d3 /export/vdev/d4

mypool
raidz
/export/vdev/d1
/export/vdev/d2
/export/vdev/d3
/export/vdev/d4

The command will still be validated – its syntax will be checked, plus you’ll have the existance of the disks verified as well. So, if you don’t have one of the devices in your system, you might see something like this:

solaris# zpool create -n mypool raidz /export/vdev/d1 /export/vdev/d2 /export/vdev/d3 /export/vdev/d4
cannot open '/export/vdev/d1': No such file or directory

Why use Solaris 8 zones?

First of all, just a few words about the niche for this product. Many companies are rather conservative about their Solaris upgrades. Most systems are still running Solaris 8, if not something older. Quite often this is also dictated by third-party software dependencies – products which were bought and configured for Solaris 8, which are now so tightly integrated that there isn’t an easy way to migrated them into Solaris 10. Such systems are doomed for slow but very expensive death. Expensive, because with every year the hardware support for servers capable of running Solaris 8 raises again and again.

That’s where the Solaris 8 zones come in. It’s very easy, really: you create a flar-copy fo your existing physical server under Solaris 8, then create a Solaris 8 zone, import your flar-archive and get a virtual copy of your Solaris 8 environment, with all your processes, programs and startup scripts.

To make things easier, it’s even possible to configure your hostid in Solaris 8 zone to match the one of the physical Solaris 8 system, this way no programs running in the zone will even guess that they’ve been virtualized.

Who knows, maybe I’ll tell you more about this technology some other day, but for now – just the simplest list of actions and commands for your S8MA proof of concept.

Preparation: Solaris 10u4 server an S8MA packages

1. Find and prepare a sparc box with Solaris 10u4. It is important to have the latest Solaris 10 update. Preparations are usually limited to applying a kernel patch, 127111-01 in my case.

2. Download the Solaris 8 Migration Assitant (current version is 1.0) from this location: Solaris 8 Migration Assistant. The 3 packages in archive are dead easy to install using standard pkgadd.

Here are the packages you’ll get:

Make a snapshot of your old Solaris 8 server

You need to create a flar-archive of your Solaris 8 system.

Log onto your Solaris 8 box, and run the command. In this and all the following examples, solaris8 is nothing but an arbitrary name I’ve chosen for my zone. You might as well call it anything you like.

solaris# flarcreate -S -n solaris8 solaris8.flar

Set up a Solaris 8 zone

Here’s how you do it:

solaris# zonecfg -z solaris8
solaris8: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:solaris8-system> create -t SUNWsolaris8
zonecfg:solaris8> set zonepath=/export/solaris8
zonecfg:solaris8> add net
zonecfg:solaris8:net> set address=172.21.7.155/24
zonecfg:solaris8:net> set physical=ce0
zonecfg:solaris8:net> end
zonecfg:solaris8> commit
zonecfg:solaris8> exit

Naturally, your IP and network device name will be different. As of now, our zone is fully configured, but not yet installed.

Install Solaris 8 zone using flar-archive

solaris# zoneadm -z solaris8 install -u -a /export/solaris8.flar
Log File: /var/tmp/solaris8.install.13597.log
Source: /export/solaris8.flar
Installing: This may take several minutes…
Postprocessing: This may take several minutes…
WARNING: zone did not finish booting.

In my case the Solaris 8 zone got stuck on sys-unconfig, and so I had to connect to the virtual console of the zone to help it move on:

Here’s how you connect to a zone’s console:

solaris# zlogin -C solaris8

That’s it! The rest was easy – just a few minutes of configuring the network parameters and DNS/NIS settings. Finally, I was able to ssh into the new zone and run uname:

solaris8 #uname -a
SunOS solaris8 5.8 Generic_Virtual sun4u sparc SUNW,Sun-Fire-V490

I liked Solaris 8 Migration Assistant very much. It’s an incredibly quick and easy way to have a whole bunch of Solaris 8 systems virtualized and running under on one of the most advanced servers with the most advanced OS – Solaris 10u4.