Sun xVM: Cloning your domU

If you're using Sun xVM for server virtualization the capability of cloning a domU is a real time-saver: reduced downtime and reuse of a corporate-standard OS installation and configuration. Really cool. If you sum up the power of ZFS snapshots and clones to all this, the picture is impressing: you can configure you domU to use ZFS volumes that you can take snapshot of and clone at will.

Now that you have the big picture, assuming you already know how to administer you ZFS pools, how can you clone your domU? This way: the first thing you have to do is shutting down your domU:

# virsh shutdown your-domain

Now you can copy your domain disk files or snapshot the corresponding ZFS volumes with a command such as:

# zfs snapshot your-fs@snap-name

# zfs clone your-fs@snap-name your/clone/name

If your just using files, then:

# cp your-domain-disk-file your-new-domain-disk-file

The next thing you've got to do is dumping and editing your source domain configuration:

# virsh dumpxml your-domain > your-domain.xml

# cp your-domain.xml your-new-domain.xml

Now, before importing this file, you've got to apply some modifications. Since Sun xVM identifies domains by means of a name and an uuid: then, you've got to edit the domain definition file to change the name and remove the already-used uuid. A new uuid will be generated for you as soon as Sun xVM wil import the domain definition. So, open the file:

# vi your-new-domain.xml

First, change the name you'll find in the <name/> element and then remove the entire <uuid/> element. The last modification you must apply is having the new domain point to the new file or ZFS volume you copied or cloned earlier. An example of a disk definition is the following excerpt from a domain configuration:

<disk type='file' device='disk'>

  <driver name='file'/>

  <source file='/export/home/xvm/db-server/winsrv2003.img'/>

  <target dev='hda'/>

</disk>

Just change the file attribute of the <source/> element and the job is done.

Last thing you've got to do is importing the new domain definition:

# virsh define your-new-domain.xml

Done! Now you can boot your new domain.

A last word of warning: chances are your just-cloned system shouldn't be running aside the old one without proper configuration. Double check your virtualized OS configuration for parameters such as:

• network configuration (hostname, DNS, static IP addresses, etc.)
• network service which may clash

Enjoy your virtualized server environment.

Setting up Subversion Client Access Via SSH Using TortoiseSVN

If you read so far, you're probably running your own Subversion repositories on your Solaris box. Fine! Now, let's face the next problem: some of your users needs access from a Windows client. They installed their favorite Subversion client, TortoiseSVN, and tried to checkout your repositories. But no, it does not work.

Setting up users

The first thing to do is setting up properly a bunch of user accounts for your client. If you haven't done yet, it's time to do it, now. Read here.

Preparing some keys for your users

As I told you in my previous post, the best option you have is setting up some public key for your users: configuration on the server side will be easier and your users won't need to enter a password every time they connect to your repositories. If you don't know how to do it, read this other post.

Configure TortoiseSVN

Many people get stuck here. Windows lacks the basic set of commands you need to interact with your remote system over an encrypted connection using the SSH protocol. It may sound strange to you faithful UNIX user but unfortunately that's the truth. Programs such as TortoiseSVN bring their own implementation of the SSH client, although specifically, TortoiseSVN lets you choose an alternate external client. The problem because of which people get stuck is that TortoiseSVN configuration GUI does no mention what-so-ever of SSH authentication. Nothing. That's why, once more, you should rely to The Manual just to discover that TortoiseSVN brings with it a PuTTY client, Plink, which is the command line interface to PuTTY backends.

The problem now reduces to configuring PuTTY to use a public key to authenticate you, save the session configuration and... remember its name! As Plink will use the same configuration registry as your standalone PuTTY, you'll be done.

Checkout your repository

Now that PuTTY is configured, you can check out your first repository over an SSH connection. Just remember not to use the server's URL and use PuTTY session name instead.

Now you should be able to:

• interact with your Solaris-hosted repositories from your Windows clients...
• ... with TortoiseSVN...
• ... and without typing any password.

Moreover, if you set up your Solaris user accounts as I explained you in another post, the key you distributed to your user won't let them even login into your system. You and you're sysadmin will be happy!

Configuring SSH key authentication with PuTTY

If you're a UNIX user, you're probably already using SSH public key authentication. Personally, I use it to avoid typing so many passwords every time I connect to a remote machine. If you're running a Windows client you installed an SSH client to connect to your remote machines. I usually use Cygwin, which gives me an environment very simiilar to what I'm used to. If you didn't feel like installing Cygwin just to establish a SSH connection, you probably chose PuTTY.

PuTTY is a bit different: it's got no .ssh directory to read from, it brings its SSH client implementation with it. If you want to configure PuTTY to use SSH key authentication, you can just follow these steps.

Setting up your keys for PuTTY

Both if you own or not your own keys, you need another program to produce a file for PuTTY to read: PuTTYgen. When you run it, puttygen will let you import your private key and save it in a PuTTY-friendly format or, if you haven't got one, to generate your brand new key. If you prefer not being asked a password by TortoiseSVN again and again, you can just avoid protecting the key with a passphrase and store the key in a safe place. I'll repeat it: store the key in a safe place.

Once you've done with the process, you will have a ppk file you should better store in a safe place! 

Configuring PuTTY

To tell PuTTY to use your key, just open it, go to Connection/SSH/Auth and browse for your key file in the Private key file for authentication... field. Now you can save your session and you're done.

Have fun!

Solaris Express Community Edition build 121 has been released

It's was an unusual long time you couldn't just get and try the latest Solaris Express Community Edition build because of some serious bugs: a couple of releases were canceled or users were strongly advised about how much those bugs could affect their systems' stability. Today, Solaris Express Community Edition build 121 has been released and it can be downloaded from OpenSolaris website. The official announcement, as usual, was broadcast to the OpenSolaris Announce mailing list and here are the changelogs links if you want to check them out:

• ON (Kernel, drivers, utilities): http://dlc.sun.com/osol/on/downloads/b121/on-changelog-b121.html
• X Window Systems: http://opensolaris.org/os/community/x_win/changelogs/changelogs-nv_120/

I'm not going after any bugfix because the latest build I'm running, build 116, is pretty stable and gives me no problem at all. A system upgrade will be welcome nontheless.

ZFS filesystems with compression enabled made my system unresponsive

At home, I'm running some services onto a Solaris Express Community Edition. The last time I live-upgraded it was to build 113. Before running SXCE, I was running Solaris 10 on it. This workstation also manages a RAIDZ-1 pool composed of four USB drives. I was perfectly aware about the performance penalty I was paying for running USB instead of eSATA (or even internal SATA), but there was no choice, then. By the way, that pool is just used to offline some snapshot backup scheduled at night, so I wasn't usually hit by the slowness of this solution.

The most annoying bug affecting this setup was this:

6586537: async zio taskqs can block out userland commands

The effect was the unresponsiveness of the userland commands I was using, including Xorg itself, when doing some big I/O on a compressed file system of that pool. Originally, the compressed file systems were lzjb and moved to gzip-based compression as soon as it was released, but before knowing I was affected by that bug. The bug really made the system unusable: sometimes even the keyboard echo could be delayed more than 5 seconds. I haven't any other machine running compressed ZFS file systems and I couldn't test the bug status so often. Moreover, that's the typical machine you'd better not touch, unless you've got a lot of spare time to recover from a disaster (just in case). With time, at the end, I just learned to live with it.



The good news is that I just realized that the bug was fixed and committed in SXCE build 115 and scheduled for Solaris 10 Update 9. I live upgraded my old SXCE to build 116, the same I'm happily running on my laptop, and I must recognize that the system is really, really much more responsive when ZFS compressed file systems are being stressed. Maybe there also were improvements on the USB side, who knows.


If you're running older build affected by this bug, upgrade now.

Setting up the right umask when installing NetBeans

This isn't a problem I encounter so often when installing software on the Solaris platform. The strange thing is that NetBeans is a Sun-sponsored project! But hey, a bug's just a bug.

Solaris default umask (file mode creation mask) for user is 022. That means that during file creation the write bit is filtered away from group and other permission bits. So, if you touch a file, you'll end up with these permissions set:

$ touch test

$ ls -l test

-rw-r--r--   1 enrico   staff          0 Jul  9 23:45 test

This basically means that everybody is granted access for reading your file. That may not be an issue for you because that file is hanging from a directory hierarchy which is otherwise protected. Solaris though, if the umask is not changed when creating home directories, will create a home directory for you with world readable flags set.

To cope with such situations, a good practice could be changing the default umask to a more restrictive value, such as 077. That's the umask I use and, as you see, it filters away all the permission bits for group and others. The previous test will end up with such a result:

$ touch test2

$ ls -l test2

-rw-------   1 enrico   staff          0 Jul  9 23:49 test2

This is not a problem unless the software you're using relies on a particular umask values (such as 022). That appears to be the case for the NetBeans installer. I just installed NetBeans 6.7, replacing my "venerable" NetBeans 6.5, and I ended up with the same problem I encountered during the installation of the earlier version. If you install NetBeans with a more restrictive umask set, the installation will result in an unusable set of files.

So, remember: if you're planning to install NetBeans 6.x onto your Solaris box and you plan to install it as root to provide an installation for all of your users, don't miss (re-)setting your umask to 022:

# umask 022

# ./netbeans-6.x-ml-solaris-x86.sh

Solaris Express Community Edition, build 116

This time it wasn't announced: Solaris Express Community Edition build 116 is available for download. Changelogs are here:

• OpenSolaris ON (OS/Net) Nevada Changelog
  
• X Change Logs: Nevada Builds 110-119

It seems there's no bug I'm hitting was fixed in build 116 (while yes, there's a bug I'm waiting build 117 for!). Nevertheless live upgrading is so easy that I'm not missing the opportunity of upgrading my system, as I already explained you in another post.

This time I've experienced a couple of glitches but nothing important: the result is perfectly functioning, as usual. I've hit some minor and inexplicable problems quickly solved:

• ludelete was failing to delete the old boot environment (snv_114) reporting it as currently mounted.
• As soon as I restarted the machine the ntp service went into maintenance mode.
• Nautilus crashed at first login.

The issues were partially solved and I'm now happily running my Solaris Express Community Edition build 116.

Haven't you downloaded Solaris or OpenSolaris yet? Don't know what you're waiting for.

NTP goes into maintenance mode: /sbin/sh: /lib/svc/method/xntp: not found

After live upgrading to Solaris Express Community Edition build 116, at the first reboot, I noticed that the NTP service had gone into maintenance mode:

# svcs -xv
svc:/network/ntp:default (Network Time Protocol (NTP) Version 4)
State: maintenance since June 20, 2009 12:44:33 AM CEST
Reason: Start method failed repeatedly, last exited with status 1.
See: http://sun.com/msg/SMF-8000-KS
See: man -M /usr/share/man -s 1M ntpq
See: man -M /usr/share/man -s 1M ntpd
See: man -M /usr/share/man -s 4 ntp.conf
See: /var/svc/log/network-ntp:default.log
Impact: This service is not running.

and the log file clearly showed me the problem:

# tail /var/svc/log/network-ntp\:default.log
[ Jun 20 00:44:32 Executing start method ("/lib/svc/method/xntp"). ]
/sbin/sh: /lib/svc/method/xntp: not found
[ Jun 20 00:44:33 Method "start" exited with status 1. ]
[ Jun 20 00:44:33 Executing start method ("/lib/svc/method/xntp"). ]
/sbin/sh: /lib/svc/method/xntp: not found
[ Jun 20 00:44:33 Method "start" exited with status 1. ]
[ Jun 20 00:44:33 Executing start method ("/lib/svc/method/xntp"). ]
/sbin/sh: /lib/svc/method/xntp: not found
[ Jun 20 00:44:33 Method "start" exited with status 1. ]
[ Jun 20 00:44:43 Rereading configuration. ]

I checked and xntp isn't there. This is related to Solaris switching to NTP version 4: if you just live upgraded to build 116 don't worry. That's indeed a glitch during the first reboot and SMF should have updated the ntp service's manifest during the boot: you won't see that message anymore.

Solaris upgrades NTP to version 4

As explained in the original announcement:

The integration of
PSARC/2009/244 Upgrade NTP to Version 4
4669914 Solaris should update to Version 4 of NTP
is a Flag Day for incremental builds.

Solaris is going to upgrade NTP to version 4. You probably would care if you're building the ON consolidation or if you're really interested in running NTP version 4.

I also warned you about a problem I experienced with Solaris Express Community Edition build 116.

ludelete fails to delete the boot environment: mount point is already in use

While I was live upgrading from Solaris Express Community Edition build 115 to build 116 I decided to free some hard disk space and delete the oldest boot environment I had: snv_114.

That's easy:

# ludelete svn_114

But there was a small problem... ludelete complained about snv_114 unable to use its automatic mount point because the mount point was being used. Do you know what? It wasn't, before launching ludelete but, for reasons I don't understand, after mounting it it was reported as busy.

The Google Finger was going to be triggered immediately and look if there was some known bug out there but fortunately a forced unmount of the boot environmente solved the problem:

# luumount -f snv_114

Pretty strange, indeed.

OpenSolaris bug 6844307: bonobo-activation-server consumes one entire core

As you know, I substituted Thunderbird with Evolution in my Solaris desktop. I'm pretty happy with it but I hit a bug: bonobo-activation-server sometimes starts to spin and consumes one entire core. The user experience isn't completely compromised because I obviously have a multi processor machine but it's a pretty annoying bug. It's summer and in Spain it's very hot, you know. One CPU throttling at 100% means one fan going nuts and rotating all time long.

Googling was useless because the bug is reported in a closed database but there it is. I must thank the guys at the OpenSolaris Communities to help me find it out. A fix is reported to be delivered in build 117 and meanwhile you can safely kill the bonobo-activation-server: I experienced no problem whatsoever.

mplayer: Error opening/initializing the selected video_out (-vo) device

That was indeed the error message that mplayer was presenting me:

Error opening/initializing the selected video_out (-vo) device

Now, I had not chose one. I even deleted my ~/.mplayer folder but nothing, it got stucked there. It's strange, because mplayer should have chosen automatically a video_out device on startup and I swear I never had this problem before on my Debian/testing.

In fact, I had just reinstalled a Debian/testing distribution on Sun xVM VirtualBox on a Solaris Express Community Edition host, because I'm using it as a platform for video transcoding. I'd like to do that on Solaris but I haven't found the time to recompile at least ffmpeg, if not mplayer and all of its dependencies. Blastwave's ffmpeg, indeed, is way too old and I found some bugs that prevented it doing its job. Until then, and thanks to VirtualBox, I'll use Debian/testing instead.

Now, the solution's pretty easy but I'd like to rely on autoprobing... Anyway:

enrico@debian:~$ gmplayer -vo help
MPlayer dev-SVN-r29241Available video output drivers:
xmga Matrox G200/G4x0/G550 overlay in X11 window (using /dev/mga_vid)
mga Matrox G200/G4x0/G550 overlay (/dev/mga_vid)
tdfxfb 3Dfx Banshee/Voodoo3/Voodoo5
s3fb S3 Virge over fbdev
xv X11/Xv
x11 X11 ( XImage/Shm )
xover General X11 driver for overlay capable video output drivers
gl X11 (OpenGL)
gl2 X11 (OpenGL) - multiple textures version
dga DGA ( Direct Graphic Access V2.0 )
sdl SDL YUV/RGB/BGR renderer (SDL v1.1.7+ only!)
ggi General Graphics Interface (GGI) output
fbdev Framebuffer Device
fbdev2 Framebuffer Device
svga SVGAlib
aa AAlib
caca libcaca
dxr3 DXR3/H+ video out
v4l2 V4L2 MPEG Video Decoder Output
directfb Direct Framebuffer Device
dfbmga DirectFB / Matrox G200/G400/G450/G550
xvidix X11 (VIDIX)
cvidix console VIDIX
null Null video output
xvmc XVideo Motion Compensation
mpegpes MPEG-PES to DVB card
yuv4mpeg yuv4mpeg output for mjpegtools
png PNG file
jpeg JPEG file
gif89a animated GIF output
tga Targa output
pnm PPM/PGM/PGMYUV file
md5sum md5sum of each frame

If you're using gmplayer or another mplayer front-end you can probably access some video preferences menu, such as the following, and set your preference there. It will be remembered the next time you launch mplayer.

In my case I'm using VirtualBox 3D Acceleration so I chose gl:

mplayer -vo gl [my-movie]

By the way: KDE 4.2 just got its way into Debian/testing, but I'll tell you another day. Amazing experience! I wish I could use it on Solaris as well.

Solaris Express Community Edition build 115 and a problem with Input Methods

It isn't apparent yet in the announce section of OpenSolaris website but Sun unsupported Solaris Express Community Edition build 115 has been released. You can see changelogs, as usual, at these addresses:

• OpenSolaris ON (OS/Net) Nevada Changelog
• X Change Logs: Nevada Builds 110-119

As far as it concerns myself, this release introduces no bug fixes nor RFE I was interested into and your interest may vary depending on the hardware you're running SXCE onto and the OS features you're using.

Nevertheless, I downloaded the DVD image and Live Upgraded my SXCE build 114. Everything went fine with no package installation errors and very little cleanup.

When I booted build 115 I noticed a renewed Volume Control User Interface and experienced a blocking problem: Input Methods weren't working anymore. They just didn't work.

A search on Google was fruitless so I posted a message on the i18n discussion mailing list at OpenSolaris.org and a Sun Engineer gave me a quick response: it's a bug introduced in build 115 and fixed in build 117 (http://defect.opensolaris.org/bz/show_bug.cgi?id=9109).

The workaround is very simple:

# touch /usr/lib/gtk-2.0/2.10.0/immodules/im-iiim.so
# svcadm restart desktop-cache/input-method-cache

and then just logout and login.

Housekeeping after live upgrading

As I told on a previous blog entry, I just live upgraded my Solaris Express Community Edition from build 110 to build 113. The live upgrade experience was very good: rapid, painless and pretty secure.

At the end of the live upgrade process, you are informed about the upgrade operation:

• upgraded packages (/var/sadm/system/logs/upgrade_log)
  
• failed upgrades (/var/sadm/system/data/upgrade_failed_pkgadds)
  
• required housekeeping steps (/var/sadm/system/data/upgrade_cleanup)
  

In this case only package SUNWttf-fonts-core failed with the following message (I had to modify for blogger not to screw up the HTML):

Doing pkgadd of SUNWttf-fonts-core to /
pkgadd: ERROR: unable to create package object (/a/usr/openwin/lib/X11/fonts/TrueType/core).
file type (s) expected (d) actual
unable to remove existing directory at (/a/usr/openwin/lib/X11/fonts/TrueType/core)
32963 blocks
pkgadd: ERROR: unable to create package object (/a/usr/openwin/lib/X11/fonts/TrueType/core).
file type (s) expected (d) actual
unable to remove existing directory at (/a/usr/openwin/lib/X11/fonts/TrueType/core)

Installation of (SUNWttf-fonts-core) partially failed.

A bit of investigation and the help of the OpenSolaris community showed that a bug (6833967) is causing the observed failure. The following bug is the guilty:

6810237 - SUNWxwfnt upgrade is broken in 109 due to issues with bad *ph files delivery

If you experience fonts-related problems, here are the steps suggested by the community:

yes | pkgrm -R /a SUNWxwcft SUNWxwoft SUNWxwfnt SUNWttf-fonts-core
rm -rf /a/usr/X11/lib/X11/fonts/

100dpi
rm -rf /a/usr/X11/lib/X11/fonts/75dpi
rm -rf /a/usr/openwin/lib/X11/fonts/100dpi
rm -rf /a/usr/openwin/lib/X11/fonts/75dpi
yes | pkgadd -R /a -d /path/to/image/Solaris_11/Product SUNWxwfnt SUNWxwoft SUNWxwcft SUNWttf-fonts-core

and, in the new ABE:

# rm /var/cache/fontconfig/*
# /usr/bin/fc-cache -f -s

I also tried to solve this problems observing the pkgmap file for that package. Near the end it says:

1 s none openwin/lib/X11/fonts/TrueType/core=../../../../../X11/lib/X11/fonts/TrueType/core

core, in my system, was an empty dir with some stale fonts.cache files. I just removed the directory and restored the link.

Cleaning up.
The last thing to do was examining the upgrade_cleanup file to apply the required cleanup operations. Basically, during live upgrade, two things are likely to happen:

• Live upgrade does not replace a file because it had been modified
• Live upgrade does replace a modified file and backs up the previous version

In both cases the administrator should examine the differences and apply the patches when necessary. In my case, for example, I had reconfigured the shipped Apache2 and simply had to check the differences between the two versions of the Apache2 configuration files.

Conclusions.
Upgrading Solaris with live upgrade it's a pretty easy procedure if you're using ZFS for your root pool. I really hope that live upgrade will continue to be a feature of the next generation Solaris. In my opinion, Live Upgrade and ZFS rock.

Live upgrading a Solaris Express Community Edition

It would really be difficult for me to tell the feature I love most in Sun Solaris OS.

Today, trying to troubleshoot a font problem I'm experiencing, I decided to live upgrade my Solaris Express Community Edition from build 110 to build 113.

If you're interested in discovering the details of the Solaris features of the day, you could easily check the extensive official documentation. Let's say that Live upgrade lets you upgrade your OS while the system is running, creating an alternate boot environment. This process, which could be used with UFS, it's even easier with ZFS.

Check your tools.
The first thing you should do is installing the Live Upgrade packages from the Solaris distribution you're going to install. I'll repeat: The first thing you should do is installing the Live Upgrade packages from the Solaris distribution you're going to install. If you're installing from a DVD, just insert into the drive bay. If you just downloaded an ISO image you can just:

# mkdir /mnt/iso
# lofiadm -a /path/to/solaris/iso
[lofiadm will print on standard output a lofi device number such as /dev/lofi/n]
# mount -F hsfs -o ro /dev/lofi/n /mnt/iso

Now you can upgrade your tools:

# pkgrm SUNWlucfg SUNWluu SUNWlur
# pkgadd -d /mnt/iso/Solaris_your-version-here/Product SUNWlucfg SUNWluu SUNWlur

Creating a boot environment.
The creation of a boot environment is a straightforward process, which is pretty instantaneous on ZFS:

# lucreate -n BEName

I usually use snv_buildnum as my boot environments' name and in this case it's snv_113. If you want to check that everything's OK you can issue a:

# lustatus

and check the output to see if your new boot environment has been correctly initialized. If you check your ZFS file systems and snapshots, you'll notice something like this (don't look at used space because these boot environments have already been upgraded):

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 115G 113G 35.5K /rpool
rpool/ROOT 21.9G 113G 18K legacy
rpool/ROOT/snv_110 19.1G 113G 12.2G /
rpool/ROOT/snv_110/var 6.84G 113G 6.84G /var
rpool/ROOT/snv_113 2.82G 113G 11.8G /a
rpool/ROOT/snv_113/var 102M 113G 6.85G /a/var

You have a couple of brand new file systems for your new boot environment. Your output may vary because I decided to have /var on a separate file system.

# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
rpool/ROOT/snv_110@snv_113 9.17M - 12.2G -
rpool/ROOT/snv_110/var@snv_113 1.94M - 6.84G -

What happened, basically, is that ZFS snapshotted your current boot environment and subsequently cloned it. That's ZFS in action! With traditional file systems, such as UFS, "snapshotting" or "cloning" the entire partition would have taken a great amount of time. With ZFS copy on write semantics, it takes fractions of a second and almost a null amount of additional storage.

Upgrading the boot environment.
The last, and longest, step in the procedure. I suggest you to read luupgrade man page but, basically, you can just issue a:

# luupgrade -u -n snv_113 -s /mnt/iso

and wait until the end. Please read luupgrade output, which usually is important, and save it to a file. You would probably need to revise it later. If everything went fine you can activate your new boot environment, reboot, and enjoy your new OS with just a:

# luactivate snv_113
# init 6

You will be told by luactivate but I'll repeat: use init or shutdown to reboot your system. Before switching boot environment, Solaris needs to execute the final configuration steps which are performed during a clean reboot.

The last suggestion.
Live Upgrade helps you upgrade your system without risk and downtimes but remember: time is a precious asset and I don't like to restart a long-running task because a remote connection has been reset. If you plan to live upgrade from a remote terminal, at least use screen or some equivalent tool. Don't lose your session!

Forewarned is forearmed.

In the next blog entry I'll tell you about housekeeping activities you must perform after live upgrading.

A strange font problem using Solaris Express Community Edition build 110 and Blastwave's packages

After live upgrading SXCE from build 104 to build 110 I started to experience a problem which makes it impossible to use some (current) Blastwave's packages.

After launch, xine immediately core dumps:

grey@solaris1:~$ xine
This is xine (X11 gui) - a free video player v0.99.4.
(c) 2000-2004 The xine Team.
xiTK WARNING(xitk_font_load_font:725): loading font "*-helvetica-*-i-*-*-12-*-*-*-*-*-*-*" failed, default and system fonts "xiTK received SIGSEGV signal, RIP.
Abort (core dumped)

Core file says:

grey@solaris1:~$ pstack core
core 'core' of 3361: xine
----------------- lwp# 1 / thread# 1 --------------------
c99d22a5 _lwp_kill (1, 6, 8043e18, c997ab7e) + 15
c997ab8a raise (6, 0, 8043e68, c9951ffa) + 22
c995201a abort (813b66c, 1, 23, 815a128, c9a50000, c9392a00) + f2
080e9829 ???????? (b, 0, 8043f50, 80e9718)
c99c01bf call_user_handler (b) + 2af
c99c03ef sigacthandler (b, 0, 8043f50) + df
--- called from signal handler with signal 11 (SIGSEGV) ---
c99447a0 strlen (813ae1c) + 30
c9992b90 fprintf (815a128, 813ae1c, a3c0730, 0, 816dce8, 815a128) + a8
080c514b xitk_font_load_font (321, 646f636e, 816e020, 816e027, 816e038, 816e040) + 9bb
09230064 ???????? ()
----------------- lwp# 2 / thread# 2 --------------------
c99cd049 __lwp_park (8159c90, 8159c78) + 19
c99c678d cond_wait_queue (8159c90, 8159c78, 0, c99c6c56) + 60
c99c6cce __cond_wait (8159c90, 8159c78, c8bdee70, c99c6d13) + 86
c99c6d21 cond_wait (8159c90, 8159c78, 813c040, c99c6d54) + 24
c99c6d69 pthread_cond_wait (8159c90, 8159c78, 0, 0, 0, 0) + 21
0811a763 ???????? (0, 0, 0, 0, 10300, 43560000)
4d580000 ???????? ()
----------------- lwp# 3 / thread# 3 --------------------
c99d0fe5 __nanosleep (c8a6ef90, c8a6ef88, 0, 10c11d08, 0, 1dcd6500) + 15
c9ac25b6 xine_usec_sleep () + 6a
----------------- lwp# 4 / thread# 4 --------------------
c99cd049 __lwp_park (82626d8, 82626c0) + 19
c99c678d cond_wait_queue (82626d8, 82626c0, c834ef28, c99c6976) + 60
c99c6b53 cond_wait_common (82626d8, 82626c0, c834ef28, c99c6d96) + 1eb
c99c6dee __cond_timedwait (82626d8, 82626c0, c834efb0, c99c6e80) + 66
c99c6e91 cond_timedwait (82626d8, 82626c0, c834efb0, c99c6ec4) + 27
c99c6edc pthread_cond_timedwait (82626d8, 82626c0, c834efb0, c834efb8, c834efb8, 82626c0) + 24
c9a9e38e ???????? ()
----------------- lwp# 5 / thread# 5 --------------------
c99d1d15 __pollsys (816d820, 1, 0, 0, 5, c920e000) + 15
c9977834 poll (816d820, 1, ffffffff, c90e69ca) + 4c
c90e6aa7 _XWaitForReadable (8169170, c920e000, c819ee64, c90e79ff) + eb
c90e7b40 _XReply (8169170, c819ee7c, 0, 1) + 2c8
c90f2df2 XSync (8169170, 0, 48003bb, 8262d58, a548800, 0) + 72
c81b48cb ???????? ()
----------------- lwp# 6 / thread# 6 --------------------
c99cd049 __lwp_park (8a9b6ec, 8a9b6d4) + 19
c99c678d cond_wait_queue (8a9b6ec, 8a9b6d4, 0, c99c6c56) + 60
c99c6cce __cond_wait (8a9b6ec, 8a9b6d4, c807eed4, c99c6d13) + 86
c99c6d21 cond_wait (8a9b6ec, 8a9b6d4, c807ef10, c99c6d54) + 24
c99c6d69 pthread_cond_wait (8a9b6ec, 8a9b6d4, 8a9b6c8, 8a9b6fc, c807ef10, c99c5258) + 21
c9aaaf08 ???????? (0, 0, 0, 0, 10300, 43560000)
4d580000 ???????? ()
----------------- lwp# 7 / thread# 7 --------------------
c99cd049 __lwp_park (8262f70, 8262f58) + 19
c99c678d cond_wait_queue (8262f70, 8262f58, c7f4ed24, c99c6976) + 60
c99c6b53 cond_wait_common (8262f70, 8262f58, c7f4ed24, c99c6d96) + 1eb
c99c6dee __cond_timedwait (8262f70, 8262f58, c7f4eda0, c99c6e80) + 66
c99c6e91 cond_timedwait (8262f70, 8262f58, c7f4eda0, c99c6ec4) + 27
c99c6edc pthread_cond_timedwait (8262f70, 8262f58, c7f4eda0, 8a7c300, 0, 49fee5a8) + 24
c9aa8231 ???????? ()
----------------- lwp# 8 / thread# 8 --------------------
c99cd049 __lwp_park (8fd8d1c, 8fd8d04) + 19
c99c678d cond_wait_queue (8fd8d1c, 8fd8d04, 0, c99c6c56) + 60
c99c6cce __cond_wait (8fd8d1c, 8fd8d04, c7e4fee4, c99c6d13) + 86
c99c6d21 cond_wait (8fd8d1c, 8fd8d04, 8fd8cf0, c99c6d54) + 24
c99c6d69 pthread_cond_wait (8fd8d1c, 8fd8d04, 0, 8fd8d04, c9adccb8, 8fd8cf0) + 21
c9aa0edc ???????? (a41ce40, 1, 82651f0, 8bdf660, 8a7cd80, 8fd8cf0)
08bdf430 ???????? (0, 823e788, 815c688, 815c6b0, 817ab50, 0)
08203230 ???????? (c9a9f760, c9a9f23c, c9a9f3c4, c9a9f9d8, c9a9faac, c9a9f6e8)
c9a9f54c ???????? (892c2474, e818245c, 19fc, dc38c381, 6c890003, f6852424)
8b1c2474 ???????? ()
----------------- lwp# 9 / thread# 9 --------------------
c99d0fe5 __nanosleep (c7d3ef68, c7d3ef60, 0, 0, 0, f4240) + 15
c9ac25b6 xine_usec_sleep (c9aa84a0, c9aaa724, c9aaa738, c9aaa72c, c9aaa7d4, c9aaa118) + 6a
c9aa9fd4 ???????? (4893442, 5a10ff24, 768dc3, 3118ec83, 1bac0, 7c890000)
8b082454 ???????? ()
----------------- lwp# 10 / thread# 10 --------------------
c99cd049 __lwp_park (99f8664, 99f864c) + 19
c99c678d cond_wait_queue (99f8664, 99f864c, 0, c99c6c56) + 60
c99c6cce __cond_wait (99f8664, 99f864c, c7c1eed4, c99c6d13) + 86
c99c6d21 cond_wait (99f8664, 99f864c, 0, c99c6d54) + 24
c99c6d69 pthread_cond_wait (99f8664, 99f864c, 99f8640, 99f8674, c7c1ef10, c99c5258) + 21
c9aaaf08 ???????? (0, 0, 0, 0, 10300, 43560000)
4d580000 ???????? ()
----------------- lwp# 11 / thread# 11 --------------------
c99cd049 __lwp_park (9b6056c, 9b60554) + 19
c99c678d cond_wait_queue (9b6056c, 9b60554, 0, c99c6c56) + 60
c99c6cce __cond_wait (9b6056c, 9b60554, c7b1ff70, c99c6d13) + 86
c99c6d21 cond_wait (9b6056c, 9b60554, c99c56da, c99c6d54) + 24
c99c6d69 pthread_cond_wait (9b6056c, 9b60554, c9adccb8, 9b60554, 9b60550, 1) + 21
c9aaedfc xine_event_wait (0, 0, 300, 43560000, 0, 0) + 38
43560000 ???????? ()
----------------- lwp# 12 / thread# 12 --------------------
c99cd049 __lwp_park (9b6109c, 9b61084) + 19
c99c678d cond_wait_queue (9b6109c, 9b61084, 0, c99c6c56) + 60
c99c6cce __cond_wait (9b6109c, 9b61084, c7a20ed0, c99c6d13) + 86
c99c6d21 cond_wait (9b6109c, 9b61084, 0, c99c6d54) + 24
c99c6d69 pthread_cond_wait (9b6109c, 9b61084, 0, 9b61084, c9adccb8, 9b61070) + 21
c9aa0edc ???????? (0, 0, 82651f0, 9b61070, 0, 9f83cc8)
09b60f60 ???????? (0, 823e788, 815c688, 815c6b0, 817ab50, 0)
08203230 ???????? (c9a9f760, c9a9f23c, c9a9f3c4, c9a9f9d8, c9a9faac, c9a9f6e8)
c9a9f54c ???????? (892c2474, e818245c, 19fc, dc38c381, 6c890003, f6852424)
8b1c2474 ???????? ()
----------------- lwp# 13 / thread# 13 --------------------
c99cd049 __lwp_park (9fa5134, 9fa511c) + 19
c99c678d cond_wait_queue (9fa5134, 9fa511c, 0, c99c6c56) + 60
c99c6cce __cond_wait (9fa5134, 9fa511c, c7921f70, c99c6d13) + 86
c99c6d21 cond_wait (9fa5134, 9fa511c, c99c59b2, c99c6d54) + 24
c99c6d69 pthread_cond_wait (9fa5134, 9fa511c, c9adccb8, fe000, 9fa5118, 1) + 21
c9aaedfc xine_event_wait (0, 0, 300, 43560000, 0, 0) + 38
43560000 ???????? ()
----------------- lwp# 14 / thread# 14 --------------------
c99cd049 __lwp_park (9fa5c64, 9fa5c4c) + 19
c99c678d cond_wait_queue (9fa5c64, 9fa5c4c, 0, c99c6c56) + 60
c99c6cce __cond_wait (9fa5c64, 9fa5c4c, c7822ed0, c99c6d13) + 86
c99c6d21 cond_wait (9fa5c64, 9fa5c4c, 9fa5c38, c99c6d54) + 24
c99c6d69 pthread_cond_wait (9fa5c64, 9fa5c4c, 0, 9fa5c4c, c9adccb8, 9fa5c38) + 21
c9aa0edc ???????? (0, 0, 82651f0, 9fa5c38, 0, a39f158)
09fa5b28 ???????? (0, 823e788, 815c688, 815c6b0, 817ab50, 0)
08203230 ???????? (c9a9f760, c9a9f23c, c9a9f3c4, c9a9f9d8, c9a9faac, c9a9f6e8)
c9a9f54c ???????? (892c2474, e818245c, 19fc, dc38c381, 6c890003, f6852424)
8b1c2474 ???????? ()
----------------- lwp# 15 / thread# 15 --------------------
c99d1d15 __pollsys (c766ebf0, 1, c766eca4, 0) + 15
c997ce11 pselect (7, c766ef40, 0, 0, c766eca4, 0) + 199
c997d1e6 select (7, c766ef40, 0, 0, c766ecd8, 0) + 78
080a4f1c ???????? (0, 0, 0, 0, 0, 0)
00000000 ???????? ()
----------------- lwp# 16 / thread# 16 --------------------
c99cd049 __lwp_park (a3c13f4, a3c13dc) + 19
c99c678d cond_wait_queue (a3c13f4, a3c13dc, 0, c99c6c56) + 60
c99c6cce __cond_wait (a3c13f4, a3c13dc, c756ff90, c99c6d13) + 86
c99c6d21 cond_wait (a3c13f4, a3c13dc, c99cc027, c99c6d54) + 24
c99c6d69 pthread_cond_wait (a3c13f4, a3c13dc, c99cacb8, c9a50000, fe000, 0) + 21
0811cb99 ???????? (c8ed7a00)
c99ccff0 _lwp_start (c8ed7a00, 0, 0, c9a50000, fe000, 0)
----------------- lwp# 17 / thread# 17 --------------------
c99d0fe5 __nanosleep (c6e0ef90, c6e0ef88, 0, 13d5084, 0, 5f5e100) + 15
c9ac25b6 xine_usec_sleep (0, 0, 0, 0, 0, 8ad3e18) + 6a
4d580000 ???????? ()

The same problem shows up with other packages such as Gnucash. I also thought something went wrong during the live upgrade process so I installed SXCE build 110 from scratch on another machine and the problem still appears. I didn't upgrade to build 111 or 112 because of the nVidia problem I read about and I'm now downloading build 113 to see if the problem still persists.

Windows interoperability: sharing folders with the SMB protocol using Solaris CIFS server

Interoperability between Solaris and Windows has improved and is improving very much. In the case of file systems sharing, the situation is now pretty good. There's no need of installing Microsoft Services for UNIX on top of your Windows servers to be able to share folders with Solaris. One of the last additions in the Solaris operating system is the CIFS Server which, as the official project page @ OpenSolaris.org states:

The OpenSolaris CIFS Server provides support for the CIFS/SMB LM 0.12 protocol and MSRPC services in workgroup and domain mode.

The official project page is the ideal starting point to look for information about installing and using the CIFS Server and Client components in Solaris. In this blog I will describe how to quickly configure the CIFS Server to be able to share folder between your Solaris and your Windows environments. I will use the new, and very simple, sharing semantics introduced in the last versions of the ZFS file system.

What's impressive of these tools is the ease of use and administration. Both ZFS commands and CIFS Server commands are few, easy and intuitive. Sharing a ZFS file system is a no brainer and just few one-time configuration steps are necessary to bring your CIFS Server up and running.

Preparing a ZFS file system

We will share a ZFS file system which we usually create with the following command:

# zfs create file-system-name

Once the file system is created, we configure the SMB sharing:

# zfs set sharesmb=on file-system-name

As described in the official ZFS documentation (for Solaris Express) or in the zfs(1M) man page, the sharesmb property can be set to on, off or [options]. The last syntax is useful to pass parameters to the CIFS server. The most useful is the name parameter, which lets you override the automatic name generation for the SMB share:

# zfs set sharesmb=name=smb-name file-system-name

The automatic name generation works fine but sometimes it must change illegal characters which appear in the dataset name.

Setting up CIFS Server in workgroup mode

The CIFS Server can work in both domain and workgroup mode. The domain mode is useful when you connect to a Windows domain and the very flexible configuration is well detailed in the official CIFS service administrator guide. In my case the workgroup mode is fine and that's the configuration I'll detail here.

Starting the service

If it's not started yet, you'll have to start the CIFS server. Please be aware that if you're running Samba in your Solaris box, you'll have to stop it first.

# svcadm enable -r smb/server

Joining a workgroup

To be able to use shares, you have to join a workgroup:

# smbadm join -w workgroup

Configuring password encryption

To be able to authenticate you must configure Solaris to support password encryption for CIFS. To do this, open the /etc/pam.conf file and add the following entry:

other password required pam_smb_passwd.so.1 nowarn

Generating or recreating passwords

Now that CIFS password encryption has been configured, you'll have to regenerate the passwords for the users you want to use with it because the CIFS service cannot use Solaris password encryption, which was used before /etc/pam.conf was reconfigured. The passwd command will take care of that:

# passwd user
[...]

Conclusions

With just these few steps you'll have your CIFS server up and running in workgroup mode. Now you can share whichever ZFS file system you want just setting its sharesmb property.

Enjoy!

Installing Solaris Express Community Edition build 104

Introduction

After many time with / on the venerable UFS file system, I decided to spare a weekend and dedicate it to backing up my data and reinstalling Solaris from scratch and (finally!) having a ZFS root filesystem. My experience with ZFS is so good that I simply could bear no longer the clumsiness of partitioning and slicing. The available Solaris flavors were the following:

• Solaris 10 10/08
• Solaris Express Community Edition
• OpenSolaris 2008.11

I keep on excluding OpenSolaris because of the reasons I detailed many times: I cannot renounce some of Sun's proprietary goodies which are not by default installed on OpenSolaris. I'm speaking about StarOffice and Sun developer tools bundled with Solaris. Being a workstation, I decided to go for Solaris Express.

Choosing a ZFS root pool

Both Solaris 10 and Solaris Express let you use ZFS on the root pool but only if installed with the text-based installer, which may be something not obvious for whoever doesn't read the installation documentation. The installer lets you choose the drives and build the ZFS pool for you. In this pool, other two ZFS volumes will be created: one for swapping and one for dumping. In the root pool, you can decide whether /var should reside on / filesystem or if it should be another one.

Zones on ZFS

This was an unexpected surprise. Before creating the zones I needed, I created a ZFS file system, named /zones, and was preparing another set of ZFS file systems below /zones, one for each zone I was going to create. When I installed the first zone, because of a typo on the path I configured for the zone, I realized on zoneadm console output that it was creating a ZFS file system for me! No need of further configuration to do that! Great.

Homes on ZFS

The installation creates a ZFS file system for locally hosted home directories, which is mounted as usually on /export/home. When I create a user, I create a ZFS file system for it and mount it on /export/home/username. This way, for example, I can control user quotas and snapshots.

ZFS is a great step forward even on desktop installations

I'm not going to blog here about ZFS advantages: it deserves much more space than this. Nevertheless it's worth mentioning that even in a simple desktop install, ZFS benefits are important:

• user disk quotas: having a ZFS file system for every user is very easy for quota management.
• backing up: having separate file systems for /export/home and for every user, snapshotting and backing up individual home directories is straight forward.
• sharing: sharing a ZFS file system is straight forward too, just set ZFS property sharenfs to on.
• time slider: I didn't try this feature (yet), but it seems great. That's what I had been doing with custom script for quite a while, but much cooler (at least because it's SMF managed and has a configuration GUI).
  
• no partitions: a beginner is not going to plan its installation to determine the necessary partitions/slices and their sizes. A zpool on an entire device is a great advantage to take advantage of all of the available space on your disk(s) without concerns about file system layouts.
  

Just one installation glitch

SUNWiwh package does not properly install because something in the package seems to be malformed. I'm installing on a Sun Ultra 24 and WIFI is not an issue for me, but I think that's something to consider if you need such functionality.