I am currently trying to get my web development environment all set up. While I like using vi, I really do prefer TextMate on my Mac OS X to do the real heavy lifting and all of the editing.

As I was working on getting my homedir on my zone to be shared over NFS I was getting errors that NFS was not a valid protocol from sharemgr, the program that is used to add new shares to the system.

xistence@webdev.network.lan:~# sharemgr create -P nfs homedir  
Invalid protocol specified: nfs

A little bit of Googling brought me to a mailling list message saying that some server packages may be missing. This is entirely possible since my Zone was created with a minimal set of packages, so I log into the global host where NFS sharing does work and run the following:

xistence@Keyhole.network.lan:~# pkg list | grep nfs
SUNWnfsc                                      0.5.11-0.101    installed  ----
SUNWnfsckr                                    0.5.11-0.101    installed  ----
SUNWnfss                                      0.5.11-0.101    installed  ----
SUNWnfsskr                                    0.5.11-0.101    installed  ----

Ah, so those are probably not installed in the zone, quick pkg install later:

xistence@webdev.network.lan:~# pkg install SUNWnfsc SUNWnfsckr SUNWnfss SUNWnfsskr
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                    3/3       17/17     0.28/0.28 

PHASE                                        ACTIONS
Install Phase                                  55/55 
PHASE                                          ITEMS
Reading Existing Index                           9/9 
Indexing Packages                                3/3

Now, lets re-run the sharemgr command again and see if this time we do indeed get our group created:

xistence@webdev.network.lan:~# sharemgr create -P nfs homedir
xistence@webdev.network.lan:~# sharemgr show -vp
default nfs=()
zfs
homedir nfs=()

Yes, there we go. Now I can add a share to that group. Until more errors start showing up:

xistence@webdev.network.lan:~# sharemgr add-share -s /export/home/xistence/ homedir
NFS: Cannot share remote filesystem: /export/home/xistence
NFS: Service needs to be enabled by a privileged user
Failed to enable share for "nfs": system error

This time Google does not help out, instead it gives me the option to search without quotes around the search terms which gives me absolutely nothing.

Well, lets see if the services are running in the first place:

xistence@webdev.network.lan:~# svcs -a | grep nfs    
disabled       22:19:04 svc:/network/nfs/client:default
disabled       22:24:26 svc:/network/nfs/server:default
online         22:24:20 svc:/network/nfs/rquota:default
online         22:24:20 svc:/network/nfs/status:default
online         22:24:20 svc:/network/nfs/mapid:default
online         22:24:20 svc:/network/nfs/cbd:default
online         22:24:21 svc:/network/nfs/nlockmgr:default

Nope, for some reason the nfs server keeps being disabled eventhough I did enable it using svcadmin.

Okay, lets take a look with svcs what is going on:

xistence@webdev.network.lan:/# svcs -l nfs/server
fmri         svc:/network/nfs/server:default
name         NFS server
enabled      false (temporary)
state        disabled
next_state   none
state_time   Fri Feb 20 22:25:26 2009
logfile      /var/svc/log/network-nfs-server:default.log
restarter    svc:/system/svc/restarter:default
contract_id  
dependency   require_any/error svc:/milestone/network (online)
dependency   require_all/error svc:/network/nfs/nlockmgr (online)
dependency   optional_all/error svc:/network/nfs/mapid (online)
dependency   require_all/restart svc:/network/rpc/bind (online)
dependency   optional_all/none svc:/network/rpc/keyserv (disabled)
dependency   optional_all/none svc:/network/rpc/gss (absent)
dependency   optional_all/none svc:/network/shares/group (multiple)
dependency   require_all/error svc:/system/filesystem/local (online)

Ah, it has a log file, lets see what that log file says:

xistence@webdev.network.lan:/# cat /var/svc/log/network-nfs-server\:default.log 
[ Feb 20 22:11:07 Disabled. ]
[ Feb 20 22:11:07 Rereading configuration. ]
[ Feb 20 22:18:43 Enabled. ]
[ Feb 20 22:19:04 Enabled. ]
[ Feb 20 22:24:21 Executing start method ("/lib/svc/method/nfs-server start"). ]
The NFS server is not supported in a local zone

Eh? What? That seems weird, but it is off course plausible. Zones are new to Solaris and thus not everything may be virtualised yet. Taking that query to google brings me to a web page asking the same question I am asking: Local zone as NFS server. Taking a look it brings me to a bug report and ultimately to: Bug ID: 4964859 RFE: Zones should be able to be NFS servers. Well, I guess that ends that little stunt. I will be sharing it from the global zone. While this is acceptable to me, I do not believe that it is acceptable to most other people using Zones, and while it is unfortunate but it does not look like there is a whole lot of activity on the bug, as apparently there are no resources available.

Well, I learned something new, and wasted a few minutes of my time attempting to set this up. While generally I don't post my failures I find it important as other people may run into the same errors and have the same issue with getting things up and running.

I ended up doing the following:

sharemgr create -P nfs webdev-homedir

Then I followed that up with some servers that should be allowed access, and others that should not:

sharemgr set -P nfs -S sys -p 'rw=10.10.10.226 none=*' webdev-homedir

And then finally I added the share I wanted to share all along:

sharemgr add-share -r "homedir" -d "xistence home dir" -s /storage/zones/dev-web/root/export/home/xistence webdev-homedir

This creates a long NFS share to type in, since the full path now becomes:

nfs://keyhole/storage/zones/dev-web/root/export/home/xistence

Which is not that big of a problem for me, especially since I just save it in my favourites in Mac OS X and everything is peachy. It works like a charm.

Recently I was working on my OpenSolaris machine (file server, ZFS rocks, will write more on that later), and I have one non-global zone, one that use for web development, which is aptly called dev-web.

So the following shows up when I run zoneadm:

xistence@Keyhole.network.lan:~# zoneadm list -iv
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   4 dev-web          running    /storage/zones/dev-web         ipkg     shared

The thing is, I had upgraded the global zone with the latest update available for the version (snv_101b):

pkg image-update -v

This had not upgraded my one none-global zone. And running pkg image-update from within the zone itself is not possible, because you can't do an upgrade on a "live" system, mainly because the image-update wants to create a new bootable environment, something that was already created when I upgraded the global zone. So what we have to do is mount the non-global zone to /mnt and tell pkg with -R where to find it and upgrade it anyway!

First we are going to halt the current zone, since I am mean and nothing important is running on the test bed system, I just used:

zoneadm -z dev-web halt

However, the better way is to off course use the shutdown command:

zlogin dev-web shutdown

and then for good measure a halt!

Next up, looking at what we are going to be mounting.

zfs list
NAME                               USED  AVAIL  REFER  MOUNTPOINT
rpool                             11.9G  42.7G    75K  /rpool
rpool/ROOT                        2.93G  42.7G    18K  legacy
rpool/ROOT/opensolaris            7.34M  42.7G  2.74G  /
rpool/ROOT/opensolaris-1          2.92G  42.7G  2.74G  /
rpool/dump                        1.87G  42.7G  1.87G  -
rpool/export                      5.27G  42.7G    19K  /export
rpool/export/home                 5.27G  42.7G    21K  /export/home
rpool/export/home/guest           5.24G  14.8G  5.24G  /export/home/guest
rpool/export/home/xistence        37.0M  42.7G  37.0M  /export/home/xistence
rpool/swap                        1.87G  43.0G  1.51G  -
storage                            493G  3.08T  35.1K  /storage
storage/media                      398G  3.08T   398G  /storage/media
storage/virtualbox                2.10G  3.08T  2.10G  /storage/virtualbox
storage/xistence                  91.7G  3.08T  91.7G  /storage/xistence
storage/zones                      957M  99.1G  30.4K  /storage/zones
storage/zones/dev-web              957M  19.1G  32.0K  /storage/zones/dev-web
storage/zones/dev-web/ROOT         957M  19.1G  28.8K  legacy
storage/zones/dev-web/ROOT/zbe    1.60M  19.1G   936M  legacy
storage/zones/dev-web/ROOT/zbe-1   955M  19.1G   935M  legacy

When pkg image-update was run on the global zone it created a new bootable environment named opensolaris-1, the cool thing is, that beadm at the same time will also create a new bootable environment for your zones. That way you can upgrade your zones afterwards, and if stuff does not work, you can revert the ENTIRE machine back to the previous state (ZFS is cool like that), thereby also making sure that your zones are reverted so that there are no incompatibilities.

So what we are looking for in this case is a zbe-1, this is the new root for the zone that we need to update, so we now need to mount it.

mount -F zfs storage/zones/dev-web/ROOT/zbe-1 /mnt

Note, that there is no / in front of storage, this is because we are specifying a pool name, since there is no "real" path that is defined as /storage/zones/dev-web/ROOT/zbe-1. Now that it is mounted, we are able to pass the -R flag to pkg, to get it to update our zone:

xistence@Keyhole.network.lan:~# pkg -R /mnt image-update -v
Creating Plan / Before evaluation:     
UNEVALUATED:
+pkg:/entire@0.5.11,5.11-0.101:20081204T010954Z

After evaluation:
pkg:/entire@0.5.11,5.11-0.101:20081119T235706Z -> pkg:/entire@0.5.11,5.11-0.101:20081204T010954Z
Actuators:

None
PHASE                                        ACTIONS
Update Phase                                     1/1 
PHASE                                          ITEMS
Reading Existing Index                           9/9 
Indexing Packages                                1/1 

---------------------------------------------------------------------------
NOTE: Please review release notes posted at:
   http://opensolaris.org/os/project/indiana/resources/relnotes/200811/x86/
---------------------------------------------------------------------------

xistence@Keyhole.network.lan:~# umount /mnt

Voilá, and the deed is done. The last command is to off course unmount the zone, that we can then issue a zoneadm boot command to start it back up:

zoneadm -z dev-web boot

And then on the zone after we log into it (over SSH in my case):

xistence@webdev.network.lan:~# pkg list -u
No installed packages have available updates

Which is exactly what we wanted!