It looks like Sun has made a pretty good addition to the already excellent SXDE/SXCE offering. It appears that now you can compliment your Solaris Express installation with Solaris Cluster Express, which is basically an OpenSolaris-like spin on Sun Cluster product. And the sweet part that you can use this real gem of software for free. I hope I don't have to remind you that Sun Cluster is probably the best clustering product on Unix platforms bar none. Sun Cluster is well known for tight and excellent integration between the cluster framework and the OS. The only other Unix cluster product that could say the same is TruCluster, but with the forced demise of Tru64 by HP the TruCluster is hardly relevant nowadays. Download your copy of Solaris Cluster Express 7/07 at the following URL:

http://www.sun.com/download/products.xml?id=46a94a22

OpenSolaris has many exciting projects in progress that are making Solaris more and more palatable for use as a desktop OS. One of the projects is Network Auto-Magic, which intention is to deliver a more user-friendly way of configuring network interfaces (a la on Mac or Windows). Network Auto-Magic is already enabled by default in the more recent ships of SXCE/SXDE, which is great especially when you use a laptop and jump between different networks. I use a laptop with Solaris Express on it, but I'm not sure I'm really comfortable with using Auto-Magic -- perhaps because the software is still beta quality it has a few niggles in my experience and I still feel more comfortable configuring my network interfaces by myself. As you would guess I would try to find a way to disable the auto-magic service, but finding the name of the service was not that trivial - "svcs -a" does not show any service that would any sort of "magic" in its name. So only after checking the OpenSolaris project page I noticed that Network Auto-Magic is known internally as nwam, even though I would certainly prefer a more descriptive name. Not surprisingly there is an SMF service running under that name:

# svcs -a | grep nwam
online 11:53:23 svc:/network/physical:nwam

Easy! Now to disable the pesky service I just did:

# svcadm disable svc:/network/physical:nwam

Now I can do my own network magic with my own hands thank you very much.

It looks like someone finally summoned the courage to do a benchmark on PostgreSQL and pitch it squarely against Oracle -- a feat that is likely to arouse some wrath from the 300 lb. gorilla which is Oracle. Well, seems like Sun had the balls to do it proving in the process that PostgreSQL can indeed be a worthy competitor to Oracle database. It looks like PostgreSQL lagged only 12% behind Oracle on the benchmark on similarly priced hardware yet again proving that you don't need to pay megabucks for a bloated product to a vendor that will stiff you every step of the way just to let you run a high volume database. Well done Sun! I hope Sun will push PostgreSQL further into enterprise and reach the reputation it deserves. Read more about the benchmark at this URL:

http://www.informationweek.com/windows/showArticle.jhtml?articleID=201001901&subSection=Open+Source

I visit Sun blogs at blogs.sun.com pretty regularly and here is a little gem I came across with - a blog by Jonh R. Meyer who is a SPARC server technical specialist at Sun. Particularly interesting is a series of posts on IBM Power6 performance or rather lack of thereof. Truly enlightening stuff, much recommended:

http://blogs.sun.com/jmeyer/date/200706

It looks like IBM made available the documentation for the upcoming AIX 6.1. Finally it is possible to have a look at the actual meat of the new features promised by IBM. What interests me the most in AIX 6.1 is WPAR or to be more precise not the WPAR feature itself ,which seems to be an imitation of Solaris Zones, but rather the fact that WPAR's are capable of checkpointing and relocation. According to the "IBM Workload Partitions Manager for AIX" guide:

Checkpoint and restart operates transparently at the application level, capturing the full context of the application memory, including the following:

• Resources
• Process hierarchies
• States
• Signals
• Inter-process communication pipes
• Semaphores
• Shared memory
• Open files
• TCP/IP sockets

In other words at least theoretically you should be able to checkpoint a WPAR on one machine and then resume it on another, sort of like VMotion on VMware. This in essence can make a foundation for a very nice clustering solution -- at the first sign of impending failure or perhaps just system's inability to cope with the load the WPAR is checkpointed and resumed on a healthy machine. And what matters the most is that the applications running within WPAR would be completely oblivious to what has just happened -- the application and most importantly the users of the application would continue running without a skip. All of this sounds very nice in theory of course, but what makes me wonder is how well IBM can make it work in reality. Checkpointing and resuming an application if far from trivial exercise which can cause all sorts of mischief, which is the reason we don't see that many solutions of that nature in the OS landscape. Typical of IBM the manual does not talk about any limitations imposed on the WPAR live migration even though I presume there should be quite a few limitations for that to work as sold in the enterprise environment. That indeed would be very interesting to see for myself how well this works in reality, but I'm afraid I don't have two Power4 or better systems at my disposal to test it on. So hopefully somebody else can test this out using the AIX 6 beta and blog about it.

I use XDMCP logins via Xnest quite frequently with X Window to get graphical console on another machine, mostly to do an install that requires a graphical environment (Oracle quickly comes to mind) or launch an application from the point of view of a different machine. With the Solaris Nevada (Solaris Excepress or SXDE/SXCE) builds on x86 I noticed that the XDMCP logins no longer work and when using Xnest querying the other host I end up with an empty window -- in other words the machine is not accepting the XDMCP requests. Scratching my head I decided to poke around the to see if dtlogin process responsible for accepting the XDMCP requests runs with any special arguments. Sure enough for some reason the Nevada builds have "-udpPort 0" argument passed to dtlogin process:

# ps -ef | grep dtlogin
root 4919 4838 0 12:37:58 ? 0:00 /usr/dt/bin/dtlogin -daemon -udpPort 0
root 4838 1 0 12:36:50 ? 0:00 /usr/dt/bin/dtlogin -daemon -udpPort 0

The XDMCP requests are usually accepted on udp port 177, so udp port set to 0 would surely remove the dtlogin's ability to accept the requests. I'm not sure why the Solaris developers decided to do that, but I'm guess it was done to improve the security of the installation out of the box. Knowing this fact it is easy to fix this pesky problem. All I had to do is to change the udpPort property value for cde-login service in SMF repository:

# svccfg
svc:> select cde-login
svc:/application/graphical-login/cde-login> listprop *arg*
dtlogin/args astring " -udpPort 0"

So here we go, all we need to do is to set the dtlogin/args property to " -udpPort 177" and we should be in business as usual:

svc:/application/graphical-login/cde-login> setprop dtlogin/args=astring:" -udpPort 177"
svc:/application/graphical-login/cde-login> quit
#

Now we can just restart the cde-login service and XDMCP login should work (Note: if you're doing this in an X Window session, the session will be restarted):

# svcadm restart cde-login

As a configmation, lets see if the dtlogin process is running with correct arguments:

# ps -ef | grep dtlogin
root 4919 4838 0 12:37:58 ? 0:00 /usr/dt/bin/dtlogin -daemon -udpPort 177
root 4838 1 0 12:36:50 ? 0:00 /usr/dt/bin/dtlogin -daemon -udpPort 177

Sure enough, we've got the dtlogin process listening on the correct port. We should now be in business as usual:

# /usr/openwin/bin/Xnest :1 -query nevada

gives me a nice login as it should have in the very beginning

I've been itching to see iSCSI target support in Solaris for a long time and it looks like it will be coming in Solaris 10 Update 4, which is approaching pretty fast. If you're one of the less patient people wanting to kick the tires of the iSCSI target on Solaris, you can do it using Nevada builds or Solaris Express as it is otherwise known. To see what you can do with iSCSI target and initiator all you need is two machines with a fairly recent build of Solaris Express that can talk to each other via a reasonably fast network and may be 10 minutes of your time (yes, it just takes a few commands to get it going). Assuming I have two machines call them box1 and box2, I'm going to make box1 an initiator (client) and box2 a target (iSCSI server). We can start off by creating a backing store for the target and creating a target itself on the box designating /data directory as the area for this target's files (I'm dedicating 2G of space to this target):

box2# iscsitadm modify admin -d /data
box2# iscsitadm create target --size 2g mytarget
box2# iscsitadm list target -v
Target: testtarget
iSCSI Name: iqn.1986-03.com.sun:02:46b9e65a-ddfb-ec77-f2c4-dce110a8a906.mytarget
Connections: 0
ACL list:
TPGT list:
LUN information:
LUN: 0
GUID: 0100080020fa7dde00002a00469b4cee
VID: SUN
PID: SOLARIS
Type: disk
Size: 2.0G
Status: offline

Having setup the target we can now configure the initiator and let it connect to the target. All we need the IP address on the target (box2) that is reachable from box1:

box2# ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843 mtu 1500 index 2
inet 10.0.0.111 netmask ffffff00 broadcast 10.15.3.255
ether 8:0:20:fa:7d:de

So it looks like our target is listening on 10.0.0.111 IP address and this is what we will use to configure our initiator (3260 is the standard iSCSI port btw):

box1# iscsiadm add discovery-address 10.0.0.111:3260
box1# iscsiadm modify discovery --sendtargets enable

Now, box1 should see the new target as the new LUN:

box1# iscsiadm list target
Target: iqn.1986-03.com.sun:02:46b9e65a-ddfb-ec77-f2c4-dce110a8a906.testtarget
Alias: testtarget
TPGT: 1
ISID: 4000002a0000
Connections: 1

box1# format < /dev/null
AVAILABLE DISK SELECTIONS:
0. c0t0d0
/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037e2d327,0
1. c0t1d0
/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100000c503b5a74,0
2. c3t0d0
/iscsi/disk@0000iqn.1986-03.com.sun%3A02%3A46b9e65a-ddfb-ec77-f2c4-dce110a8a906.mytarget0001,0

Viola! The new LUN is now visible on the box1 as c3t0d0 and can now be labeled as just a regular disk. Having labeled the disk you can create a filesystem and mounted just like any other disk on the system:

box1# newfs /dev/rdsk/c3t0d0s6
newfs: construct a new file system /dev/rdsk/c5t0d0s6: (y/n)? y
/dev/rdsk/c3t0d0s6: 3800832 sectors in 29694 cylinders of 4 tracks, 32 sectors
1855.9MB in 928 cyl groups (32 c/g, 2.00MB/g, 512 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 4160, 8288, 12416, 16416, 20544, 24672, 28800, 32800, 36928,
Initializing cylinder groups:
..................
super-block backups for last 10 cylinder groups at:
3760224, 3764352, 3768352, 3772480, 3776608, 3780736, 3784736, 3788864,
3792992, 3797120

box1# mkdir /mnt/iscsi
box1# mount -F ufs /dev/dsk/c3t0d0s6 /mnt/iscsi

Done! You've got yourself a network accessible iSCSI target. Easy. Of course this is a simplistic example, which completely does not take into account security. For a "production" level secure setup, please investigate CHAP authentication, which can be configured which just a few extra commands. For more information on how to setup iSCSI initiator and target on Solaris, check out the followin Sun documenation:

http://docs.sun.com/app/docs/doc/819-2723/6n50a1mvf?a=view

Here is a bit of not Unix, but nonetheless computing trivia. Did you know what 400 means in AS/400? As it comes it out when AS/400 platform was first announced in 1988 the 400 was supposed to be the designator for the maximum number of users the system can support. Apparently that was a pretty high number back in the days and IBM was proud of it.

Assume the following situation - you're trying to find out what time it is in France and being a hard core Unix admin you're got a console of your trusty Solaris box. You could of course start scrambling searching Google for one of those world time sites doing the time conversions, but a much quicker way to find the current time is actually right in front of you -- just use the tzselect and zdump commands. You need tzselect to find the exact name of the time zone you're looking for and once you've got it, zdump will happily give you the current date and time for the time zone in question. So coming back to the to my curiosity of what time it is in Paris I would run the tzselect command to find out the proper time zone name:

bash-3.00$ tzselect
Please identify a location so that time zone rules can be set correctly.
Please select a continent or ocean.
1) Africa
2) Americas
3) Antarctica
4) Arctic Ocean
5) Asia
6) Atlantic Ocean
7) Australia
8) Europe
9) Indian Ocean
10) Pacific Ocean
11) none - I want to specify the time zone using the POSIX TZ format.
#? 8
Please select a country or region.
1) Aaland Islands 17) Finland 33) Netherlands
2) Albania 18) France 34) Norway
3) Andorra 19) Germany 35) Poland
4) Austria 20) Gibraltar 36) Portugal
5) Belarus 21) Greece 37) Romania
6) Belgium 22) Hungary 38) Russia
7) Bosnia & Herzegovina 23) Ireland 39) San Marino
8) Britain (UK) 24) Italy 40) Serbia and Montenegro
9) Bulgaria 25) Latvia 41) Slovakia
10) Croatia 26) Liechtenstein 42) Slovenia
11) Czech Republic 27) Lithuania 43) Spain
12) Denmark 28) Luxembourg 44) Sweden
13) Estonia 29) Macedonia 45) Switzerland
14) Europe - Central 30) Malta 46) Turkey
15) Europe - Eastern 31) Moldova 47) Ukraine
16) Europe - Western 32) Monaco 48) Vatican City
#? 18

The following information has been given:

France

Therefore TZ='Europe/Paris' will be used.
Local time is now: Thu Jul 12 06:49:05 CEST 2007
Universal Time is now: Thu Jul 12 04:49:05 UTC 2007
Is the above information OK?
1) Yes
2) No
#? 1
Here is the TZ value again, this time on standard output:
Europe/Paris

So the time zone name for Paris is "Europe/Paris". Armed with this information we can run zdump and obtain the current Paris time:

bash-3.00$ zdump Europe/Paris
Europe/Paris Thu Jul 12 06:49:25 2007 CEST

Well, look at that, it is 06:49am now in Paris. So there you have it, everything you need at your fingertips in your trusty Unix console and sure as hell faster then looking for and using one those conversion web sites.

Managing a large number of disks in JBOD configurations can be a bit of a pain in the neck, especially when the drives start failing. On Solaris when drive is failing and some SCSI operations fail, the Solaris kernel reports the failing device by its physical device path and by an sd number:

Jul 11 11:29:23 v240-xa Error for Command: write(10) Error Level: Retryable
Jul 11 11:29:23 v240-xa scsi: Requested Block: 4885119 Error Block: 4885119
Jul 11 11:29:23 v240-xa scsi: Vendor: HITACHI Serial Number: 0333S19LXA
Jul 11 11:29:23 v240-xa scsi: Sense Key: Hardware Error
Jul 11 11:29:23 v240-xa scsi: ASC: 0x44 (internal target failure), ASCQ: 0x0, FRU: 0x0
Jul 11 11:29:23 v240-xa scsi: WARNING: /pci@1c,600000/scsi@2/sd@1,0 (sd55):
Jul 11 11:29:23 v240-xa Error for Command: write(10) Error Level: Fatal

Which is useful if you know the device configuration on the system, but not so useful provided most system/storage administrators deal with logical device names (aka c#t#d#). Well here is a little shortcut I discovered that can help you quickly translate the sd number reported by the kernel into a logical device name. The trick is in the fact that the minor number of the device in question is the sd number times 8. So, for instance in the error snip above the reported sd number of the failing device is 55, which means that the minor number of the failing device should be 55*8=440. Armed with this information identifying the logical device name is trivial:

# cd /dev/rdsk/
# ls -alL | grep 440
crw-r----- 1 root sys 32, 440 Jul 11 12:11 c3t8d0s0

So c3t8d0s0 is disk that needs to be replaced, easy!

I don't know about you, but I'm not really known for having superb memorization abilities, in other words I forget things when I don't use them very often. Digging in OpenBoot PROM on Sun servers is not something I do all the times, since the machines just keep on running and rarely do I drop them to OBP. So when I'm faced with an unusual OBP task, I'm usually stumbling with the correct command names. Well, here is a little hack I use to locate the correct command names in OBP without resorting to a manual -- the 'sifting' command. As an example lets pretend I've got a bare metal workstation (no OS installed) and would like to know what frame buffers are installed in it without taking it apart or trying to boot an OS. What is the correct command to list the frame buffers visible to OBP? I wouldn't remember from the top of my head, but I remember it has something to do with displays, so I can just do the following right in OBP:

{0} ok sifting display

In vocabulary magic-device-types
(f002cb64) display

In vocabulary forth
(f003c7ec) display-status (f002ec4) show-displays

We're interested in the forth vocabulary, since this is how the OBP commands are defined, and out of the two it looks like show-displays is the command I'm looking for. So running show-displays:

{0} ok show-displays
a) /SUNW,afb@1e,0
b) /pci@1f,2000/SUNW,Expert3D@1
q) NO SELECTION

Viola! This workstation has got an Elite3D frame buffer in UPA slot and and an Expert3D frame buffer in PCI slot. Problem solved. I really love OBP for this and wish other computers outside of Sun had it.

If you've been using Unix shell for reasonable amount of time, it is pretty much certain that you have come across a situation when there is a file on the filesystem with a wacky name consisting of some special characters. How would you go about removing a file named "'\" for instance? These sort of files sometimes appears either because of bugs in the programs or more frequently due to completely innocent typos in when putting in the command lines. Well, regardless of the origin of these pesky files, you need to either remove them or rename to something more intelligible. At first you would of course try to escape the special characters and in some cases that would work, but it is not a fool-proof solution, since sometimes the file name would consist of "unprintable" or special characters making it a futile task. A much easier way capable of blowing away any file regardless how wacky it's name is to refer to the file not by the name but by the inode number. If you supply the "-i" option to ls utility it will happily report the inode numbers assigned to the files, for instance:

# ls -ali
total 16
3651947148 -rw-r--r-- 1 root sys 0 Jul 6 16:36 &\@
3651464248 drwxr-xr-x 2 root sysadmin 298 Jul 6 16:36 .
3627815649 drwxrwxrwt 10 root sys 1556 Jul 6 16:36 ..
3651945669 -rw-r--r-- 1 root sys 0 Jul 6 16:36 bar
3651916857 -rw-r--r-- 1 root sys 0 Jul 6 16:36 foo

As you can see we've got a very unusual file named '&\@', which has inode number 3651947148 assigned to it. Knowing the inode number we can now either delete or rename the file. The unix find utility is capable of addressing files by their inode number and so it comes useful for just this sort of task:

# find . -inum 3651947148 -exec rm {} \;
#

Problem solved!