As a user of OpenSolaris, one of the best ways you can contribute to the community is by taking the time to submit the bugs you find in the product. You may also find that you get better traction with OpenSolaris engineering than raising the same issue in the forums - bug counts are reviewed weekly, forum postings are not.

The OpenSolaris project uses Bugzilla as its tracking system and its home page is at http://defect.opensolaris.org. Note, it uses a separate registration database then opensolaris.org, so you'll have to create a new account.

Before filing a bug you should first search to see if it's already being tracked. If so, feel free to add additional information or just CC yourself on the bug to keep informed of its progress. For example, I've CC'd myself on over 140 bugs.

The advanced search form is very powerful, which also makes it somewhat daunting. I mostly use the simple text based search form on the home page. Here are some basic tips I've found helpful for getting the most out of the simple text search:

• By default, only open bugs are returned. Since the problem you are looking for might very well have already been fixed in a development build, prefix your search with ALL, for example, ALL mouse wheel.
• Don't worry about case - table, Table and TABLE are all the same.
• Substrings are searched - so use localiz instead of localize or localization, which will find both occurrences of the word.
• Use quotes to search for exact words or phrases

See the Bugzilla QuickSearch page for more tips.

You'll notice at the bottom of the search results there's an option to "Remember search as":

This is very handy, especially if you've taken the time to cobble together an advanced search. Saved searches are then set up as links in the page footer. In the image above you can see I currently have 2 saved searches: "My Bugs" and "My CC'd Bugs".

Once you're reasonably sure the bug you've found hasn't been filed yet, click the File a Bug button on the home page. You'll be prompted to select a classification, for which you want to choose Distribution.

This will take you to the Enter Bug form:

Select the Component that is most closely related to your problem. As you select the components you'll see their description in the text box to the right. If you are still unsure, you can look at similar bugs you found during your search. Don't worry if it's mis-classified - it will get corrected.

After selecting the Version of OpenSolaris you are using, select the Severity. Although all bugs may feel like mission critical blockers to you, please try to be realistic with this setting:

Note the Enhancement value. I use this one a lot to request features I'd like to see in the product.

The two most important fields are the Summary and the Description. A good summary will quickly and uniquely identify the bug. Provide as much detail in the description as you can, ideally providing the exact steps on how to reproduce the bug and any possible work-arounds you may have discovered (documented work-arounds are one of the great benefits of searching through the bug database). Finally, don't clutter the Description field with large amounts of output or log text. Rather, use the attachment button to attach the text or log. Likewise, if you can take a snapshot of the problem, attach that as well (there's a screen shot tool in Applications > Graphics > Save Screenshot).

See the Bug Writing Guidelines for more information.

When satisfied, press Commit to submit your bug. And thank you, you've just made a valuable contribution to OpenSolaris.

A little gem included with the Crossbow Virtual Wire Demo Tool is a DTrace script and associated Chime display written by Crossbow engineer Kais Belgaied. I've augmented the script a bit by adding an END clause to format the output, which shows the number of bits transferred over the period of time the script is run:

bleonard@opensolaris:~$ dtrace -s vWireBuilder/VWire/so.d 
Tracing... Hit Ctrl-C to end.
^C
Process              Zone       Protocol   Destination      Port           Bits

pidgin               global     TCP        202.43.216.31    5050             296
firefox-bin          global     TCP        66.196.87.126     443           13968

Trace ran for 29 seconds

The associated Chime display is useful when you want to monitor a system with lots of network traffic. In this example I'm using Netperf to simulate traffic between my global zone and a local zone, which has been configured to run at IP address 10.0.1.50:

In this example you can see we're achieving a throughput of 932,708,352 bits per second, or approximately 933 megabits per second. In my case the local zone is configured using a Crossbow VNIC, myzone0:

bleonard@opensolaris:~$ dladm show-vnic
LINK         OVER         SPEED  MACADDRESS           MACADDRTYPE         VID
myzone0      e1000g0      1000   2:8:20:59:0:b5       random              0

Notice the link speed of myzone0 is 1000 megabits per second, and at the moment it's using just about every bit of that bandwitdh, potentially starving other virtual NICs and the physical NIC itself from the network. Fortunately, Crossbow allows me to put some reigns on my virtual NICs. For example, if I do the following:

pfexec dladm set-linkprop -p maxbw=200 myzone0

Above we can see we're now running just under 200 megabits per second. Or More ridiculously:

pfexec dladm set-linkprop -p maxbw=2 myzone0

We're now under 2 megabits per second.

Now it is also possible to drill down on the Chime display, graphing throughput over time. The above scenario looks like so:

If you want to check this out on your own environment, you only need the D script, Chime and the Network display:

• The DTrace script: so.d
• Chime
  
• The Chime display: Network.xml

 <void property="programFileName">
   <string>/export/home/bleonard/so.d</string>
 </void>

To launch the Chime display:

chime -C ./Network.xml

At the CommunityOne West keynote last June a demo of Crossbow was given using a tool called Virtual Wire. If you haven't seen the demo before, you can watch a 10 minute replay of it here:

Since that time a lot of folks have asked for access to the tool that was used in the demo. Browsing the Crossbow project page recently I noticed the Crossbow Virtual Wire Demo Tool has now been made available.

I'll warn you in advance that I view the tool as alpha quality as it doesn't have some basic functionalities like undo. However, as the names implies, it's perfect for demos (and learning a lot about zones and networking).

When you extract the tool you'll find a couple of screencasts, which I've also made available here. There's no audio, but they do give you the basic idea of the capabilities of the tool.

Demo 1: Creating and Connecting 2 Private Networks

This demo uses the Crossbow Virtual Wire Demo Tool to create 2 private networks. One network contains a web server (192.168.2) while the client is connecting from a separate network (193.168.3). A router is set up to forward packets between the 2 networks. This is a self-contained private network. The demo concludes by using a network load generator along with DTrace to show how easy it is to monitor and configure bandwidth to the server. The details on how to reproduce this demo have been documented here.

Demo 2: Creating a Private Network Connected to the Public Network

This demo uses the Crossbow Virtual Wire Demo Tool to create a private network containing a web server behind a firewall. The IP routing is configured to access the server from the global zone. The demo concludes by using a network load generator along with DTrace to show how easy it is to monitor and configure bandwidth to the server. The details on how to reproduce this demo have been documented here.

I've read that the best way to learn DTrace is to study existing D scripts. However, upon doing so I quickly find myself asking "where is that documented?" And it turns out, with tens of thousands of probes, as is often the case, it's not. So I'd love to hear what others with more DTrace experience do, but these are the steps I seem to have stumbled upon.

As an example, let's take the script /opt/DTT/Proc/rwbytype.d, which shows the bytes read and written by process by vnode type. Here's an example of the output:

bleonard@opensolaris:/opt/DTT/Proc$ rwbytype.d 
Tracing... Hit Ctrl-C to end.
^C
PID    CMD               VTYPE  DIR     BYTES
21124  gnome-terminal      chr    W         1
10523  gnome-power-mana   sock    W         4
10565  gnome-netstatus-   fifo    R         7
10547  gnome-netstatus-   fifo    W         8
4817   conky              fifo    R         9
10634  firefox-bin        fifo    R         9
10634  firefox-bin        fifo    W         9
15379  whoami             fifo    W         9
10547  gnome-netstatus-   fifo    R        20
10565  gnome-netstatus-   fifo    W        20
15377  dtrace              chr    W        31
10412  Xorg                chr    R        32
10469  gnome-settings-d   sock    R        32
10523  gnome-power-mana   sock    R        32
21124  gnome-terminal      chr    R        33
10472  metacity           sock    W        56
10472  metacity           sock    R       200
21124  gnome-terminal     sock    R       220
15379  conky               reg    R       529
15379  ksh93               reg    R       529
4817   conky              sock    R      2720
10412  Xorg               sock    W      3204
4817   conky               reg    R      6696
21124  gnome-terminal     sock    W      6852
4817   conky              sock    W     37952
10412  Xorg               sock    R     44864

And here's the D script that produces that output:

typedef struct vtype2str {
	string code;
};

translator struct vtype2str < int T > {
	/* the order has been picked for performance reasons */
	code =
	    T == 1 ? "reg"   :
	    T == 9 ? "sock"  :
	    T == 4 ? "chr"   :
	    T == 6 ? "fifo"  :
	    T == 8 ? "proc"  :
	    T == 2 ? "dir"   :
	    T == 3 ? "blk"   :
	    T == 5 ? "lnk"   :
	    T == 7 ? "door"  :
	    T == 10 ? "port" :
	    T == 11 ? "bad"  : "non";
};

dtrace:::BEGIN
{
	printf("Tracing... Hit Ctrl-C to end.\n");
}

fbt::fop_read:entry,
fbt::fop_write:entry
{
	self->type = xlate <struct vtype2str *>(args[0]->v_type)->code;
	self->size = args[1]->uio_resid;
	self->uiop = args[1];
}

fbt::fop_read:return
/self->uiop/
{
	this->resid = self->uiop->uio_resid;
	@bytes[pid, execname, self->type, "R"] = sum(self->size - this->resid);
	self->type = 0;
	self->size = 0;
	self->uiop = 0;
}

/* this is delibrately redundant code for performance reasons */
fbt::fop_write:return
/self->uiop/
{
	this->resid = self->uiop->uio_resid;
	@bytes[pid, execname, self->type, "W"] = sum(self->size - this->resid);
	self->type = 0;
	self->size = 0;
	self->uiop = 0;
}

dtrace:::END
{
	printf("%-6s %-16s %6s %4s %9s\n",
	    "PID", "CMD", "VTYPE", "DIR", "BYTES");
	printa("%-6d %-16s %6s %4s %@9d\n", @bytes);
}

First of all, this D script is only enabling 6 probes:

dtrace:::BEGIN
dtrace:::END
dtrace::fop_read:entry
dtrace::fob_read:return
dtrace::fob_write:entry
dtrace::fob_write:return

The BEGIN and END clauses are self-explanatory. Where I get tripped up is looking at the 2nd clause:

fbt::fop_read:entry,
fbt::fop_write:entry
{
	self->type = xlate <struct vtype2str *>(args[0]->v_type)->code;
	self->size = args[1]->uio_resid;
	self->uiop = args[1];
}

First, I see that we're setting 3 thread-local variables, type, size and uiop. All of these variables are set using probe arguments, and this is where things start to get confusing - where are these arguments defined? I can run the following dtrace command to get verbose information on a probe:

bleonard@opensolaris:/opt/DTT/Proc$ dtrace -lv -n fbt::fop_read:entry
   ID   PROVIDER            MODULE                          FUNCTION NAME
17725        fbt           genunix                          fop_read entry

	Probe Description Attributes
		Identifier Names: Private
		Data Semantics:   Private
		Dependency Class: Unknown

	Argument Attributes
		Identifier Names: Private
		Data Semantics:   Private
		Dependency Class: ISA

	Argument Types
		args[0]: vnode_t *
		args[1]: uio_t *
		args[2]: int
		args[3]: cred_t *
		args[4]: caller_context_t *

So I learn that the data semantics of the argument attributes are private, which means this probe is accessing private implementation details of the kernel, but that's the case with most DTrace kernel probes. Of more interest is the argument list:

args[0]: vnode_t *
args[1]: uio_t *
args[2]: int
args[3]: cred_t *
args[4]: caller_context_t 

So I can see there are 5 total arguments available for this probe and I know my clause is accessing args[0] and args[1]. But what now? What exactly is vnode_t and uio_t? As far as I know, there's no further dtrace command to drill down into these data types. At this point I turn to the OpenSolaris Source Browser.

I begin by searching on the probe function fop_read, which returns 2 results, the vnode.h header file and the vnode.c source file:

Searched refs:fop_read (Results 1 -2 of 2) sorted by null

/onnv/onnv-gate/usr/src/uts/common/sys/
vnode.h	[all...]
/onnv/onnv-gate/usr/src/uts/common/fs/
vnode.c	3177 fop_read( function     [all...]

The fop_read function is defined on line 3177 of vnode.c and I can click on that link to be taken directly to the source. Sure enough, the arguments to the fop_read function in vnode.c match what I was told by dtrace:

   3176 int
fop_read(
	vnode_t *vp,
	uio_t *uiop,
	int ioflag,
	cred_t *cr,
	caller_context_t *ct)

Now I can click on vnode_t to see its definition and this returns 3 results - the logical one being the vnode.h header file returned by our first search:

/onnv/onnv-gate/usr/src/uts/common/sys/ vnode.h 257 } vnode_t; typedef in typeref:struct:vnode 800 int (*vop_open)(vnode_t **, int, cred_t *, \ 802 int (*vop_close)(vnode_t *, int, int, offset_t, cred_t *, \ 804 int (*vop_read)(vnode_t *, uio_t *, int, cred_t *, \ 806 int (*vop_write)(vnode_t *, uio_t *, int, cred_t *, \ 808 int (*vop_ioctl)(vnode_t *, int, intptr_t, int, cred_t *, \ 810 int (*vop_setfl)(vnode_t *, int, int, cred_t *, \ 812 int (*vop_getattr)(vnode_t *, vattr_t *, int, cred_t *, \ 814 int (*vop_setattr)(vnode_t *, vattr_t *, int, cred_t *, \ 816 int (*vop_access)(vnode_t *, int, int, cred_t *,     [all...]

Here we see that vnode_t is defined on line 257, which you can click to navigate directly to that section of the source. Our D script above is referencing args[0]->v_type, and we can see v_type is an enum:

typedef struct vnode {
	kmutex_t	v_lock;		/* protects vnode fields */
	uint_t		v_flag;		/* vnode flags (see below) */
	uint_t		v_count;	/* reference count */
	void		*v_data;	/* private data for fs */
	struct vfs	*v_vfsp;	/* ptr to containing VFS */
	struct stdata	*v_stream;	/* associated stream */
	enum vtype	v_type;		/* vnode type */
	dev_t		v_rdev;		/* device (VCHR, VBLK) */

Which you can also click on to see the type definition:

/*
 * vnode types.  VNON means no type.  These values are unrelated to
 * values in on-disk inodes.
 */
typedef enum vtype {
	VNON	= 0,
	VREG	= 1,
	VDIR	= 2,
	VBLK	= 3,
	VCHR	= 4,
	VLNK	= 5,
	VFIFO	= 6,
	VDOOR	= 7,
	VPROC	= 8,
	VSOCK	= 9,
	VPORT	= 10,
	VBAD	= 11
} vtype_t;

Which matches up perfectly to the struct at the beginning of our D script. So, now I've got a better handle of exactly what's going on with this D script.

Now, as a test, see if you can follow the same procedure to find the documented comment in the OpenSolaris source code for arg[1]->uio_resid :-). 

A hidden little gem that comes included with your installation of OpenSolaris is the DTrace Toolkit. You'll find it installed at /opt/DTT.

The DTrace Toolkit is a collection of tools written by volunteers of the DTrace community, led by Brendan Gregg. What I find most impressive is how well it has been put together. There are 230 executable DTrace scripts, each with their own man page. The scripts are organized by type (CPU analysis, I/O analysis, etc.) so they are easy to study, but they've all been symlinked into a Bin directory, so they are easy to put on your path. I've added the following to my ~/.bashrc file:

#
# DTrace Toolkit
#
PATH=$PATH:/opt/DTT/Bin
MANPATH=$MANPATH:/opt/DTT/Man

In addition to their man pages, all of the scrips have a -h help option, for example:

bleonard@os200906:~$ execsnoop -h
USAGE: execsnoop [-a|-A|-ehjsvZ] [-c command]
       execsnoop                # default output
                -a              # print all data
                -A              # dump all data, space delimited
                -e              # safe output, parseable
                -j              # print project ID
                -s              # print start time, us
                -v              # print start time, string
                -Z              # print zonename
                -c command      # command name to snoop
  eg,
        execsnoop -v            # human readable timestamps
        execsnoop -Z		# print zonename
        execsnoop -c ls         # snoop ls commands only

Note, if you want to run the DTrace scripts from your user account, run the following command to add the needed privileges, substituting in your user name:

pfexec usermod -K defaultpriv=basic,dtrace_user,dtrace_proc,dtrace_kernel <user>

To get started learning all that's available, I recommend reading the DTrace Tookkit page. Also, Stefan Parvu has an excellent presentation on DTrace and the toolkit that's worth a look.

With this toolkit there's probably little need to write a DTrace script from scratch - it's literally a treasure chest of material that I've only begun to explore.

There are (at least) 2 big Linux conferences this weekend, the Ontario Linux Fest and the Florida Linux Show. The good news is that you'll find OpenSolaris represented at both of them. In Ontario Canada, Toronto OpenSolaris User Group leader Steven Acres will deliver Why OpenSolaris? In Orlando, Florida, I'll be delivering What's So Cool About OpenSoalaris Anyhow?

If you happen to be nearby (or willing to travel), please stop by and say hello.

When I edit a text file in vi, I find it much easier to read if the syntax is color highlighted. There are 2 steps to enabling this. First, add an alias for vi (or vim) to your ~/.bashrc file as follows:

#
# Enable color support for vi
#
alias vi='TERM=xtermc vim'

You can read the gory details about why this needs to be done in bug 1641 - xterm terminfo entry doesn't support color.

You also need to tell vi to use syntax coloring. Adding the following to your ~/.vimrc file (create one if it doesn't yet exist):

syntax on

Much nicer:

Netperf is a cool little utility that I discovered while working with Crossbow. It's technically a network benchmarking tool, but it's fun to use to hammer your network with load and test out Crossbow's bandwidth control features.

Simply click the link to install netperf , which will launch the Package Manager Web Installer:

To verify the installation, first start the benchmark server:

bleonard@opensolaris:~$ netserver
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC

Then run netperf, which will run a TCP_STREAM test of 10 seconds over the loopback interface:

bleonard@opensolaris:~$ netperf
TCP STREAM TEST from ::ffff:0.0.0.0 (0.0.0.0) port 0 AF_INET to opensolaris (127.0.0.1) port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 49152  49152  49152    10.00    4895.46  

Now that we know Netperf is set up correctly, we can use it to test bulk data transfer performance between 2 hosts (or 2 zones). TCP stream performance is the default test type and it's simply performed by running the command:

netperf -H <remotehost>

which will run a 10 second test between the local and remote system.

So I'm going to use netperf to run some tests between the global zone and a local zone, which has been set up to use a Crossbow virtual NIC exclusively. To create such a configuration on your own, see the blog entry Zones and Crossbow.

The local zone, myzone, is currently up and running:

bleonard@opensolaris:~$ zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   - myzone           running    /zones/myzone                  ipkg     excl 

The first thing I'm going to do is copy the netserver program over to the local zone:

pfexec cp /opt/csw/bin/netserver /zones/myzone/root/var/tmp/.

And then start the netserver:

bleonard@opensolaris:~$ pfexec zlogin myzone /var/tmp/netserver
en_US.UTF-8: unknown locale
en_US.UTF-8: unknown locale
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC

Now let's test the connection between the global and local zone:

bleonard@opensolaris:~$ netperf -H 10.0.1.25
TCP STREAM TEST from ::ffff:0.0.0.0 (0.0.0.0) port 0 AF_INET to ::ffff:10.0.1.25 (10.0.1.25) port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 49152  49152  49152    10.00    1130.01   

Here we can see the throughput between my zones is 1130 Mbit/s. Now let's reduce the max bandwidth of the virtual NIC to 500 Mbit/s and try the test again:

bleonard@opensolaris:~$ pfexec dladm set-linkprop -p maxbw=500 myzone0
bleonard@opensolaris:~$ dladm show-vnic
LINK         OVER         SPEED  MACADDRESS           MACADDRTYPE         VID
myzone0      e1000g0      500    2:8:20:59:0:b5       random              0
bleonard@opensolaris:~$ netperf -H 10.0.1.25
TCP STREAM TEST from ::ffff:0.0.0.0 (0.0.0.0) port 0 AF_INET to ::ffff:10.0.1.25 (10.0.1.25) port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 49152  49152  49152    10.00     486.22   

Or at a ridiculously low 2 Mbit/s:

bleonard@opensolaris:~$ pfexec dladm set-linkprop -p maxbw=2 myzone0
bleonard@opensolaris:~$ netperf -H 10.0.1.25
TCP STREAM TEST from ::ffff:0.0.0.0 (0.0.0.0) port 0 AF_INET to ::ffff:10.0.1.25 (10.0.1.25) port 0 AF_INET
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 49152  49152  49152    10.25       1.09   

Good stuff.

I've just scratched the surface of Netperf, but this simple introduction suits my purposes for testing Crossbow. For more fun check out the Netperf manual.

I've had my local IPS repository mirror running for about 1 month now and I find it extremely beneficial. So much so that I've gone ahead and produced a short 6 minute screencast on the process of creating it (although it takes much longer than that to set up as you need to wait for files to download and copy - the joys of editing screencasts).

 Click the image to play the screencast

Not surprisingly, Sun is a big sponsor at this year's fast approaching Oracle OpenWorld . I used to think JavaOne was a big event, but OOW draws about 3 times the attendance. And with Oracle's renewed focus on Sun, you can bet Solaris has a big presence. For your convenience, we've put together a landing page with all things Solaris at Oracle OpenWorld. At a minimum, if you plan to be in the Bay Area the week of October 11th, consider the Discover package. For $75 ($125 on-site) it gets you access to the keynote sessions as well as the exhibit hall where me and my team will be hanging out all week showing off Solaris.

I recently borrowed one of the 10" netbooks that came out this year, and tested Build 123 on it. Here's a shot of Toshiba's sleek black NB205 displaying a clean Device Driver Utility run.

The NB205 has a keyboard on par with the r500 I use regularly—large for a netbook—and has a superior trackpad. Suspend-resume is reliable; compiz runs well; the extra vertical inch means fewer application compromises over last year's netbook crop. (For instance, rather than rearranging panel to the sides, use of gnome-panel's auto-hide feature is enough to let applications run well when maximized.)

If I don't have to give it back, it'll be my new "netbook for meetings".

Netbook styling credit to Dave Powell.

[ T: OpenSolaris netbook Atom Toshiba ]

NetBeans 6.7, released earlier this summer, has a pretty nifty Python editor. To give it a spin a decided to set up a project for the Image Packaging System. If you want to try it yourself, here's the steps I took:

Install NetBeans

bleonard@os200906:~$ pfexec pkg install netbeans
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                  19/19   5638/5638 165.54/165.54 

PHASE                                        ACTIONS
Install Phase                              6756/6756 
Deleting content cache

Install the NetBeans Python Plugin

Start NetBeans (Applications > Developer Tools) and install the Python plugin (Tools > Plugins):

Create the IPS Project

The IPS Python sources are in /usr/lib/python2.4/vendor-packages/pkg, with the exception of the pkg script, which is in /usr/bin. To keep the NetBeans project simple, I copied the pkg script from /usr/bin to /usr/lib/python2.4/vendor-packages/pkg. I also renamed the script to pkg2.py. Adding the .py extension allows it to be recognized as a Python script by NetBeans. Changing the name to pkg2 prevents it from conflicting with the existing script in /usr/bin:

 pfexec cp /usr/bin/pkg /usr/lib/python2.4/vendor-packages/pkg/pkg2.py

In NetBeans select File > New Project and then select Python Project with Existing Sources:

Give the project a name such as PKG or IPS and set the Python Platform to Python 2.4.4:

Then add /usr/lib/python2.4/vendor-packages/pkg as a source root folder:

To give the project a quick test drive, right-click it and select Properties. Then set the Main Module to pkg2.py and the Application Arguments to something like 'info netbeans':

Then select Run > Run Main Project. You'll see the result in the Output window:

Editor Features

Now that we've got the project set up, let's look at some of the features provided by the editor.

Syntax Highlighting 

The code is easy to read.

Code completion

Ctrl+Space to activate.

Hover Documentation and Hyperlink Navigation

Holding down the control key and hovering over Classes and methods will also show you the documentation:

And clicking on the hyper-link will take you to the class or method.

Navigator Window

Also, the Navigator window is a quick way to find your way around a script:

Go to Type

And Go to Type (Ctrl + O) will quickly take you to any type:

Debugger

And finally, one of the coolest features is the debugger. Select Debug > Debug Main Project to start it:

Variables view:

You can find a summary of features on the NetBeans Python Wiki. Please file issues you find with the NetBeans Python Editor.

Nice to see Oracle starting to come out of the woodwork on a few issues in the interim. Good strong statement for Sun’s existing customer and userbase, and headsup to IBM -

Go digg it!

As I continued to experiment with my local repository mirror, I noticed downloads from the remote repository were running as quickly as from the local repository. Well, I was actually installing and uninstalling the same package to compare speeds and it turns out the files were not actually being downloaded from either repository, but rather copied from a local cache in /var/pkg/download. 

You see, the first time you install a package, it is first copied from the repository to your /var/pkg/download folder and then installed from there. Over time, the size of this folder can grow pretty big. For example, mine was over 3 gigabytes:

bleonard@os200906:~$ du -hs /var/pkg/download/
3.3G    /var/pkg/download/

Note, because there's so many files, the du command takes several minutes to complete.

Fortunately, this cache can be disabled through a property setting. To see the image's current properties, run pkg property:

bleonard@os200906:~$ pkg property
PROPERTY                       VALUE
send-uuid                      True
preferred-publisher            opensolaris.org
require-optional               False
flush-content-cache-on-success False
display-copyrights             True
pursue-latest                  True

Setting the flush-content-cache-on-success property to true will delete your cache on the next successful IPS command:

bleonard@os200906:~$ pfexec pkg set-property flush-content-cache-on-success true
bleonard@os200906:~$ pfexec pkg install SUNWgnome-hex-editor
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                    1/1       28/28     0.21/0.21 

PHASE                                        ACTIONS
Install Phase                                  83/83 
Deleting content cache

After which you will no longer even have a download directory in /var/pkg.

Note, if you're turning off the cache to save space (as I am), you'll also need to delete the cache from any other boot environments you may have. In those cases, assuming you are not actively using those boot environments, you can just delete the /var/pkg/download directory.

The best way to judge the success of any project, open source or not, is the strength of the development community supporting it. Thats why I was happy to come across Murray Blakeman's site today, Solaris Multimedia. Murry runs his own IPS repository with much of the popular multimedia tools the community's been clamoring for. I was hesitant to advertise it here for a couple of reasons. First, Murray only has a 384 kbps link so I'm not sure how much more publicity his site could handle. Second, I don't want to see Murray to suffer the same fate as the the Life with Solaris guys. Ultimately, I decided since he's already out there promoting his site, a little cross-promotion was acceptable. Plus, as I've said, I'm really thankful to the contribution he's making to the OpenSolaris community.

If you decided to try the repository, read his 2009.06 Multimedia Repository post first on how to most effectively use it.

One of the fun events I’m involved in is Software Freedom Day Wellington, as part of the wider SFD effort. We’re planning a really fun day, with a whole bunch of things going on, as Brett’s excellent poster suggests -

Barcamp

At a barcamp attendees govern the agenda. We provide rooms and a flipchart and a schedule of times – the attendees decide on the discussions to be held around a variety of topics (from Education to Government, Communities to Business) that interest them at the start of the day. You can check the list of attendees on the registration page to see who else is attending with similar interests to you.

Tech Talks

This year there will be a separate room for tech talks. Rather than a discussion-based format like the barcamp sessions, the talks give attendees the opportunity to present a technical presentation about free and open source software. The tech talk schedule will be decided on the day, with each session broken into shorter timeslots, if needed.

Hackfest

A hackfest will be organised by SuperHappyDevHouse, One Laptop Per Child, and DigitalNZ – a chance to put the DigitalNZ APIs into action! Come hang out all day on our sofas, drink large amounts of coffee and work on your favourite piece of free and open source software. You can also learn about the work of the amazing team from One Laptop Per Child who will be showcasing their machines, and participate by helping to test them.

Installfest

The installfest is being organised by WellyLUG, the Wellington Linux User Group, for those wishing to install free and open source software on their laptops, or home computers. Bring your own machines/laptops along and get advice and support from a team of experts, while you install software. Copies of some popular free and open source software will be available to take away as well.

Makerspace

Wellington has a growing community of makers who share a lot of the same principles as FOSS, using open source technology to create craft, sharing tools and skills when working on solutions to technical projects. We will have a room set aside for makers, so come along and showcase your creations, whether they are gadgets or open source crafts, or work on something you’ve been dreaming up for months.

Kids Programme

A kids programme for primary school aged children will embrace all that’s going on at Software Freedom Day, giving them the opportunity to participate in a variety of activities – taking the first steps into programming at the installfest, testing OLPC laptops at the hackfest, a barcamp brainstorming session about where they think the future of computing is going, and more! Games, prizes and a treasure hunt included.

As part of the kids programme Nat Torkington will be running an hour long ‘Introduction to programming’ session for parents and kids as part of the installfest. Parents – it would be great if you can prepare for the session by downloading scratch from scratch.mit.edu onto your laptops/machines before you come along.

Students Programme

Students (secondary and tertiary) are encouraged to attend Software Freedom Day. Showcase technology you are interested in by registering to do a techtalk and bring your projects along to the makerspace. Hear from tech heros who will be there to address students about working in the industry and learn about how understanding open source solutions can enhance your job prospects. Bring along your laptop and get experts to help you to install open source software and operating systems on your laptop at the installfest, and learn about the work of One Laptop per Child and DigitalNZ how you could contribute to their projects at the hackfest.

So if you’re coming along, make sure you register for the event – we’ll have free wifi, free coffee and a bunch of great prizes to give away! Thanks heaps to our ever growing list of sponsors.

We've published three of the approximately-six-monthly distribution releases now, and we're starting to refine pkg(5)'s capabilities to handle automatically an ever larger set of configuration scenarios. (Read: "edge cases".) Bart implemented actuators in 2008.11, and that let us handle any resource that could be configured or reconfigured via an smf(5) service instance. In future releases, we'll build out the set of instances that handle standard configuration.

In this post, I'd like to talk about a tool—verexec(1)—to assist with executable version selection. One of the common questions that maintainers of the various language platform packages is "how can I make sure that /usr/bin/[language] points to the latest version of the package?". Attempts to satisfy this goal have led to some of the largest preremove and postinstall script pairs in historical Solaris.

Largest, and most difficult to get completely correct.

We can make this problem much simpler—and scripting free—if we accept the minimal performance penalty of a runtime-based decision.

export VEREXEC_perl=/home/sch/bin/$(uname -p)/perl

In my previous entry I wrote about creating a portable version of the repository using a USB stick. That option is great for taking the repository on the road and even sharing it with folks at conferences where the Internet connection usually sucks.

However, a more practical use of this repository image to many of you may be setting up a local mirror. In this situation, you get the best of both words - fast access to the repository with continued access to updates as they become available.

Setting Up the Local Repository

pfexec mount -F hsfs `pfexec lofiadm -a ~/Download/osol-repo-0906-full.iso` /mnt

In order for the mount to persist across reboots, we'll move it to a new file system, which we first need to create:

pfexec zfs create -o compression=on rpool/repo

Then copy the repository to the file system (this will take a little over an hour to complete):

bleonard@opensolaris:~$ pfexec rsync -aP /mnt/repo /rpool/repo
...
repo/updatelog/2009071315
       67506 100%  150.17kB/s    0:00:00 (xfer#304859, to-check=1/609926)
repo/updatelog/2009071316
       24956 100%   55.26kB/s    0:00:00 (xfer#304860, to-check=0/609926)

sent 6669164656 bytes  received 8537336 bytes  1368521.77 bytes/sec
total size is 6630966532  speedup is 0.99

Configure the package server to use the local repository:

svccfg -s application/pkg/server setprop pkg/inst_root=/rpool/repo/repo
svccfg -s application/pkg/server setprop pkg/readonly=true

You can also choose a port number different from the default of 80, which I did because I'm running Apache on port 80:

svccfg -s application/pkg/server setprop pkg/port=81

Edit the repo/cfg_cache file, changing the origins property from http://pkg.opensolaris.org/release  to http://<domainname>:<port>, where <domainname> is network accessible and <port> is needed if you used something other than the default of 80. For example:

origins = http://opensolaris:81

Then refresh the package server service to pick up the configuration changes and start it:

svcadm refresh application/pkg/server
svcadm enable application/pkg/server

Accessing the Local Repository

Now all those wishing to use the local package server simply need to make the following change:

pfexec pkg set-publisher -m http://opensolaris:81 opensolaris.org

Which will result in the following:

bleonard@opensolaris:~$ pkg publisher
PUBLISHER                             TYPE     STATUS   URI
opensolaris.org          (preferred)  origin   online   http://pkg.opensolaris.org/release/
opensolaris.org          (preferred)  mirror   online   http://opensolaris:81/

If you only want to use the local repository, first remove the mirror:

pfexec pkg set-publisher -M http://opensolaris:81 opensolaris.org 

Then:

pfexec pkg set-publisher -O http://opensolaris:81 opensolaris.org

A snapshot of the OpenSolaris release repository has been made available for download as an ISO image, where it can be mounted directly or transfered to a USB stick. This will certainly come in handy if you plan to travel somewhere with limited network access but would like access to the repository. In this entry I'll review setting up a USB stick, which gives you a portable repository. In a follow-up entry I'll look at creating a mirror on local file system, which would greatly improve IPS performance for users on a local network.

Putting the Repository on the USB Stick

Download the repository image, which is just over 7 GB. Obviously you'll need at least an 8 GB USB stick. Once plugged in run rmformat to get its device name:

bleonard@opensolaris:~$ rmformat
Looking for devices...
     1. Logical Node: /dev/rdsk/c4t0d0p0
        Physical Node: /pci@0,0/pci1179,1@1d,7/storage@3/disk@0,0
        Connected Device: MATSHITA DVD-RAM UJ-844S  1.11
        Device Type: CD Reader
	Bus: USB
	Size: <Unknown>
	Label: <Unknown>
	Access permissions: <Unknown>
     2. Logical Node: /dev/rdsk/c6t0d0p0
        Physical Node: /pci@0,0/pci1179,1@1a,7/storage@1/disk@0,0
        Connected Device: Verbatim STORE N GO       5.00
        Device Type: Removable
	Bus: USB
	Size: 7.6 GB
	Label: <Unknown>
	Access permissions: Medium is not write protected. 

Use the mount command to find the device instance:

bleonard@opensolaris:~$ mount | grep c6t0d0p0
/media/STORE N GO on /dev/dsk/c6t0d0p0:1 read/write/nosetuid/nodevices/hidden/nofoldcase/clamptime/noatime/timezone=18000/dev=9810d0 on Fri Jul 31 11:07:12 200

Then unmount it:

bleonard@opensolaris:~$ rmumount /dev/rdsk/c6t0d0p0:1
/dev/rdsk/c6t0d0p0:1 /dev/dsk/c6t0d0p0:1 unmounted

Now you can copy the ISO to the device:

bleonard@opensolaris:~/Download$ pfexec dd if=osol-repo-0906-full.iso of=/dev/rdsk/c6t0d0p0 ibs=32K obs=32K
234931+1 records in
234931+1 records out
7698249728 bytes (7.7 GB) copied, 759.871 s, 10.1 MB/s

You can see the operation took almost 13 minutes to complete. Optionally you can label the device:

rmformat -b 'repo0906' /dev/rdsk/c6t0d0p0

Using the USB Stick as a Repository

IPS is a network based packaging system, therefore we need to configure an IPS server on the local machine to look at the USB stick as its repository.

Plug the USB stick into the machine that needs access to the repository. It should be automatically mounted into your /media directory.

bleonard@opensolaris:~$ ls /media
0906FULL/

Next configure the local package server with the location of the repository (if you are interested in seeing the existing set of properties, run svccfg -s application/pkg/server listprop):

svccfg -s application/pkg/server setprop pkg/inst_root=/media/0906FULL/repo
svccfg -s application/pkg/server setprop pkg/readonly=true 

Optionally, change the pkg server's port number from the default of 80. I'm already running Apache on port 80, so I'll use 81 for the repository server:

svccfg -s application/pkg/server setprop pkg/port=81

Copy the repo/cfg_cache file to the local file system so it can be edited:

pfexec cp /media/0906FULL/repo/cfg_cache /etc/0906_cfg_cache

Edit the file and change the origins property from http://pkg.opensolaris.org/release  to http://localhost:81. Be sure to include the port number if you changed it (note, if you also want the repository accessible to other machines, then use an IP network-accessible domain name):

origins = http://localhost:81

Configure the package server service to use the local configuration file:

svccfg -s application/pkg/server setprop pkg/cfg_file=/etc/0906_cfg_cache

svcadm refresh application/pkg/server
svcadm enable application/pkg/server

At this point you should be able to browse the local repository at http://localhost:81:

The final step is to configure IPS to access the repository:

pfexec pkg set-publisher -O http://localhost:81 opensolaris.org

You're now free to install packages on a plane. 

For more information, see the README.

Reverting Back

It's simple to switch back to the default release repository:

pfexec pkg set-publisher -O http://pkg.opensolaris.org/release opensolaris.org

pfexec pkg set-publisher -O http://localhost:81 opensolaris.org

Chime has a nifty little feature where you can run it in server mode and then monitor the system remotely using the Chime GUI.

On the server simply run:

bleonard@opensolaris:~$ chime server
Listening for remote DTrace consumers on port 5088
Press the Enter key to stop the server.

Then on the client point chime to the server:

chime 10.0.1.10

At least it's supposed to be that easy, however, there's a small issue with Java RMI that prevents this from working correctly.

I did some research on RMI and discovered you have two options to solve this problem.

Option 1 is to add your server's IP address to /etc/hosts as follows and restart the chime server.

127.0.0.1	opensolaris opensolaris.local localhost loghost
10.0.1.10	opensolaris

Alternatively, you can edit the /opt/OSOL0chime/bin/chime script on the server to include the following JVM property (Of course supplying the proper IP address):

JMX_FLAGS="${JMX_FLAGS} -Djava.rmi.server.hostname=10.0.1.10"

If you're planning to use OpenSolaris as an RMI server, this little tip could save you some time. As a simple test I was following the Getting Started Using Java RMI tutorial. However, when I attempted to connect to the OpenSolaris server from the client, I was getting the following exception:

Client exception: java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: 
        java.net.ConnectException: Connection refused: connect

Why was RMI trying to connect to 127.0.0.1? I wasn't even using a hostname, I was directly connecting with my server's IP address (10.0.1.10). After doing a bit of debugging, it turns out I was successfully connecting to the RMI registy and getting the stub, however, the IP address placed in the remote stub was 127.0.0.1. What's up with that?

After a bit more research it turns out the RMI registry is using InetAddress.getLocalHost() to determine the IP address to put in the stub. This simple program shows what is returned by that method call:

import java.net.InetAddress;

public class Main {
    public static void main(String[] args) throws Exception {
        System.out.println("getLocatHost: " + InetAddress.getLocalHost());
    }
}

And Here's the output:

getLocatHost: opensolaris/127.0.0.1 

Looking at the source code for InetAddress.getLocalHost(), a private method getAddressFromNameService() is called. The /etc/nsswitch.conf file is used by OpenSolaris for configuring the address name service. Looking at my setting for hosts:

hosts: files dns # Added by DHCP

So the name service's first place to look is files, and the file that is being looked at is /etc/hosts, which contains the following for my hostname 'opensolaris':

127.0.0.1	opensolaris opensolaris.local localhost loghost

So one solution to this problem is to add my IP address to the /etc/hosts file as follows:

127.0.0.1	opensolaris opensolaris.local localhost loghost
10.0.1.10	opensolaris

Now running my test class above returns:

getLocatHost: opensolaris/10.0.1.10

Which will also allow my RMI client to successfully connect.

If you don't want to mess with your /etc/hosts file, another option is to tell the RMI server which hostname to use by using the java.rmi.server.hostname JVM property. My complete command to start the server now looks as follows (note, I'm running the script from my build directory):

java -classpath `pwd` -Djava.rmi.server.codebase=file:`pwd`/ -Djava.rmi.server.hostname=10.0.1.10 example.hello.Server

Overall, it's upsetting that the RMI Server isn't initially getting the proper IP address, but at least now I understand why.

Chime is a tool that all users of OpenSolaris should take the time to install. Chime is a graphical user interface for DTrace that makes viewing DTrace output enjoyable. It has traces that can provide valuable feedback on your system (and you don't even have to know DTrace to use it). For example, take this simple script that aggregates the system calls over the period of time the script is run:

bleonard@os200906:~$ cat syscalls_overtime.d 
syscall:::entry
{
	@a[execname] = count();
}

When run from the terminal for a couple of seconds the output looks as follows:

bleonard@os200906:~$ dtrace -qs syscalls_overtime.d 
^C

  devfsadm                                                          2
  updatemanagernot                                                  2
  dhcpagent                                                         3
  gam_server                                                        6
  gvfsd-trash                                                       6
  dlmgmtd                                                           8
  gvfs-hal-volume-                                                  8
  nautilus                                                          9
  clock-applet                                                     12
  gnome-panel                                                      12
  gnome-settings-d                                                 16
  metacity                                                         16
  java                                                             26
  bonobo-activatio                                                 56
  gnome-netstatus-                                                 80
  gnome-terminal                                                   93
  VBoxClient                                                      120
  firefox-bin                                                     160
  Xorg                                                            281

The same script run from Chime is much more useful. The columns are sortable, you can control the interval (I only have a rough estimate of how long the script from the terminal above ran) and you can navigate through the samples.

 You can also drill-down:

To Install Chime

• Download the 10 MB compressed package (i386, SPARC).
• Extract it:
  

  bleonard@os200906:~$ gunzip Downloads/osol0chime-i386-1.4.pkg.gz

• Install it:
  

bleonard@os200906:~$ pfexec pkgadd -d Downloads/osol0chime-i386-1.4.pkg 

The following packages are available:
  1  OSOL0chime     Chime Visualization Tool for DTrace
                    (i386) 1.4.44

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: 
Processing package instance <OSOL0chime> from </export/home/bleonard/Downloads/osol0chime-i386-1.4.pkg>

Chime Visualization Tool for DTrace(i386) 1.4.44
http://www.opensolaris.org/os/project/dtrace-chime/
Using </opt> as the package base directory.
## Processing package information.
## Processing system information.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.

Installing Chime Visualization Tool for DTrace as <OSOL0chime>

## Installing part 1 of 1.
/opt/OSOL0chime/bin/chime
...
Installation of <OSOL0chime> was successful

• Put chime on the path. I'm simply going to add a link to the chime executable in my /usr/bin directory:
  

  pfexec ln -s /opt/OSOL0chime/bin/chime /usr/bin/chime

• Add permissions to execute DTrace scripts:
  

  bleonard@os200906:~$ pfexec usermod -K defaultpriv=basic,dtrace_proc,dtrace_kernel bleonard
  UX: usermod: bleonard is currently logged in, some changes may not take effect until next login.
  

  You can log in again as follows:
  

  bleonard@os200906:$ su bleonard
  Password: 
  

• Run chime:
  
  

Chime as a Learning Tool

DTrace itself can be a bit daunting. A default installation of OpenSolaris has over 54,000 probes available:

bleonard@os200906:~$ dtrace -l | wc -l
54012

And this number only grows as you install additional DTrace enabled software. My base installation of OpenSolaris has almost 70,000!

bleonard@opensolaris:~$ dtrace -l | wc -l
69229

Probes are grouped by:

• provider (a library of related probes)
• module (the module that contains the function)
• function (the function that contains the probe)
• name (the name of the probe)
  

For more information on probes see the Probes topic in the DTrace Topics Guide.

Chime itself comes with over 70 traces. And if you look at the context menu above, one of the options is to look at the DTrace program, which provides an excellent opportunity to learn DTrace by example. Here's the program used for the drill-down into Firefox shown above:

If you're interested in learning more about DTrace, I found the Dynamic Tracing Guide and excellent resource.

Additional Resources

• Chime
• Dynamic Tracing Guide
• DTrace Topics Guide

Installing a zone in OpenSolaris requires a network connection and some patience as a little over 70MB of data is downloaded. Fortunately, after you've got the first zone installed, future zones can be cloned. This is not only quicker than an IPS install but it's also a much more efficient use of disk space. In addition, if you've customized a zone with additional software (or less software), that will also come along with your clone.

The 4 step creation process is almost identical to before. Instead of create, install, boot and configure - we have now have create, clone, boot and configure.

Obviously before we begin you must already have a zone. I'm going to be using the zone, myzone, I created from the Zones and Crossbow entry. I'll call the new zone myzoneclone.

Step 1: Create the Zone

Here's my configuration file for the new zone, with the differences highlighted in bold:

bleonard@opensolaris:~$ cat myzoneclone.config 
create
set zonepath=/zones/myzoneclone	
set ip-type=exclusive	
add net
set physical=myzoneclone0
end

Note the ip-type is exclusive. myzoneclone0 is a VNIC, which I need to create before creating the zone:

pfexec dladm create-vnic -l e1000g0 myzoneclone0

Now create the zone:

pfexec zonecfg -z myzoneclone -f myzoneclone.config

Step 2: Clone the Zone

Instead of installing from IPS, we'll clone the existing myzone, which only takes a couple of seconds:

bleonard@opensolaris:~$ pfexec zoneadm -z myzoneclone clone myzone
sys-unconfig started Thu Jul 16 15:25:10 2009
rm: cannot remove `/zones/myzoneclone/root/etc/vfstab.sys-u': No such file or directory
grep: /zones/myzoneclone/root/etc/dumpadm.conf: No such file or directory
sys-unconfig completed Thu Jul 16 15:25:10 2009

You can safely ignore the warnings from sys-unconfig. You see the zone is installed:

bleonard@opensolaris:~$ zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   - myzone           installed  /zones/myzone                  ipkg     excl
   - myzoneclone      installed  /zones/myzoneclone             ipkg     excl  

Step 3 & 4: Boot & Configure

These 2 steps are identical to before. First we create a sysidcfg file. Again, I've highlighted the differences from myzone in bold:

bleonard@opensolaris:~$ cat sysidcfg
system_locale=C
terminal=xterms
network_interface=myzoneclone0 {
	hostname=myzone
	ip_address=10.0.1.26
	netmask=255.255.255.0
	default_route=NONE
 	protocol_ipv6=no}
security_policy=none
name_service=NONE
nfs4_domain=dynamic
timezone=US/Eastern
root_password=fto/dU8MKwQRI

Ready the zone:

pfexec zoneadm -z myzoneclone ready 

Copy the sysidcfg file to the zone:

pfexec cp sysidcfg /zones/myzoneclone/root/etc/.

Log into the Zone:

bleonard@opensolaris:~$ pfexec zlogin -C myzoneclone
[Connected to zone 'myzoneclone' console]

In another terminal window, boot the zone:

pfexec zoneadm -z myzoneclone boot

Then back in the first terminal you can log into the zone after it completes configuration. If you used the root_password from above it's abc123:

[NOTICE: Zone booting up]


SunOS Release 5.11 Version snv_111b 64-bit
Copyright 1983-2009 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Hostname: myzoneclone
Reading ZFS config: done.
Mounting ZFS filesystems: (5/5)
 network_interface=myzoneclone0 {
myzoneclone0 is not a valid network interface  line 3 position 19
Creating new rsa public/private host key pair
Creating new dsa public/private host key pair
Configuring network interface addresses: myzoneclone0.

myzone console login: root
Password: 
Jul 16 15:52:39 myzone login: ROOT LOGIN /dev/console
Last login: Thu Jul 16 14:41:03 on console
Sun Microsystems Inc.   SunOS 5.11      snv_111b        November 2008
root@myzone:~#

One nice point to note about the cloned zone is that it's a ZFS clone. As such, a snapshot was taken of myzone and then used as the basis for myzoneclone. Therefore, myzoneclone only consumes space where it differs from the snapshot of myzone:

bleonard@opensolaris:~$ zfs list -t all
NAME                                                        USED  AVAIL  REFER  MOUNTPOINT
rpool                                                       112G  34.3G    76K  /rpool
rpool/ROOT                                                 14.2G  34.3G    18K  legacy
rpool/ROOT/opensolaris                                     66.0M  34.3G  7.02G  /
rpool/dump                                                 1.43G  34.3G  1.43G  -
rpool/export                                               43.6G  34.3G    19K  /export
rpool/export/home                                          43.6G  34.3G  40.1G  /export/home
rpool/swap                                                 1.43G  35.6G   212M  -
rpool/zones                                                 142M  34.3G    21K  /zones
rpool/zones/myzone                                          139M  34.3G    22K  /zones/myzone
rpool/zones/myzone/ROOT                                     139M  34.3G    19K  legacy
rpool/zones/myzone/ROOT/zbe                                 139M  34.3G   139M  legacy
rpool/zones/myzone/ROOT/zbe@myzoneclone_snap                   0      -   139M  -
rpool/zones/myzoneclone                                    2.17M  34.3G    22K  /zones/myzoneclone
rpool/zones/myzoneclone/ROOT                               2.15M  34.3G    19K  legacy
rpool/zones/myzoneclone/ROOT/zbe                           2.13M  34.3G   140M  legacy

Note that myzone is using 139M but myzoneclone is only consuming 2MB. Therefore, cloning zones is a very efficient way to create zones on the system.

Note, to remove the zone you still use uninstall:

bleonard@opensolaris:~$ pfexec zoneadm -z myzoneclone halt
bleonard@opensolaris:~$ pfexec zoneadm -z myzoneclone uninstall
Are you sure you want to uninstall zone myzoneclone (y/[n])? y

If you're like me and working with zones on your laptop and/or desktop, you probably only have one network interface card to work with. Therefore, the zones I've created share the single network interface with the global zone (ip-type=shared).

Behind the scenes, OpenSolaris creates a logical interface for the zone to use. The logical interface appears in ifconfig as your physical interface with an instance number. For example:

bleonard@opensolaris:~$ ifconfig -au4
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
	inet 127.0.0.1 netmask ff000000 
lo0:1: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
	zone myzone
	inet 127.0.0.1 netmask ff000000 
e1000g0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2
	inet 10.0.1.10 netmask ffffff00 broadcast 10.0.1.255
e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
	zone myzone
	inet 10.0.1.25 netmask ffffff00 broadcast 10.0.1.255

You can see both the loopback (loO) and physical (e1000g0) have an instance (lo0:1 and e1000g0:1) that was created for the zone myzone. These logical interfaces only exist when the zone is running. If you halt the zone, they disappear.

From inside the zone, I only see the logical interfaces:

root@myzone:~# ifconfig -au4
lo0:1: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.0.1.25 netmask ffffff00 broadcast 10.0.1.255

However, I have no control over them. For example, if I try to bring down e1000g0:1:

root@myzone:~# pfexec ifconfig e1000g0:1 inet down
ifconfig: setifflags: SIOCSLIFFLAGS: e1000g0:1: permission denied 

The global zone is responsible for managing the local zone's network configuration.

Crossbow

Project Crossbow brings virtualization to the network. For example, I can create a virtual network interface card (vnic) that has all the properties of a physical nic.

bleonard@opensolaris:~$ pfexec dladm create-vnic -l e1000g0 myzone0
pfexec dladm create-vnic -l e1000g0 myzone0

bleonard@opensolaris:~$ dladm show-link 
LINK        CLASS    MTU    STATE    OVER
e1000g0     phys     1500   up       --
iwh0        phys     1500   down     --
vboxnet0    phys     1500   unknown  --
myzone0     vnic     1500   up       e1000g0

Now it's as if my laptop has 2 physical network interface cards. Using this "new" card, I can create a zone with an exclusive IP stack. My zone config would look something like follows:

bleonard@opensolaris:~$ cat myzone.config
create
set zonepath=/zones/myzone
set ip-type=exclusive	
add net
set physical=myzone0
end

Note there's now longer an IP address associated with the zone configuration. With a dedicated IP stack the zone will be able to manage its own IP.

Create the zone:

pfexec zonecfg -z myzone -f myzone.config

Install the zone:

bleonard@opensolaris:~$ pfexec zoneadm -z myzone install
A ZFS file system has been created for this zone.
   Publisher: Using opensolaris.org (http://pkg.opensolaris.org/release/).
       Image: Preparing at /zones/myzone/root.
       Cache: Using /var/pkg/download.  
Sanity Check: Looking for 'entire' incorporation.
  Installing: Core System (output follows)
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                  20/20   3021/3021   42.55/42.55 

PHASE                                        ACTIONS
Install Phase                              5747/5747 
  Installing: Additional Packages (output follows)
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                  37/37   5598/5598   32.52/32.52 

PHASE                                        ACTIONS
Install Phase                              7332/7332 

        Note: Man pages can be obtained by installing SUNWman
 Postinstall: Copying SMF seed repository ... done.
 Postinstall: Applying workarounds.
        Done: Installation completed in 148.737 seconds.

  Next Steps: Boot the zone, then log into the zone console
             (zlogin -C) to complete the configuration process 

Create a configuration file for the zone. Note, here we can define the zone's IP configuration (or we could do it later):

bleonard@opensolaris:~$ cat sysidcfg
system_locale=C
terminal=xterms
network_interface=myzone0 {
	hostname=myzone
	ip_address=10.0.1.25
        default_route=NONE
	netmask=255.255.255.0
 	protocol_ipv6=no}
security_policy=none
name_service=NONE
nfs4_domain=dynamic
timezone=US/Eastern
root_password=fto/dU8MKwQRI

Ready the zone (this mounts its file system):

pfexec zoneadm -z myzone ready

Copy the sysidcfg file to the zone:

pfexec cp sysidcfg /zones/myzone/root/etc/.

Log into zone:

bleonard@opensolaris:~$ pfexec zlogin -C myzone
[Connected to zone 'myzone' console]

Open a 2nd terminal and boot the zone:

pfexec zoneadm -z myzone boot

Back in the first terminal you can watch the zone boot and configure itself. Note the message about myzone0 being an invalid network interface. This appears to be benign as a few lines down we see myzone0 getting configured.

bleonard@opensolaris:~$ pfexec zlogin -C myzone
[Connected to zone 'myzone' console]

[NOTICE: Zone booting up]


SunOS Release 5.11 Version snv_111b 64-bit
Copyright 1983-2009 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Hostname: myzone
Loading smf(5) service descriptions: 69/69
Reading ZFS config: done.
Mounting ZFS filesystems: (5/5)
 network_interface=myzone0 {
myzone0 is not a valid network interface  line 3 position 19
Creating new rsa public/private host key pair
Creating new dsa public/private host key pair
Configuring network interface addresses: myzone0.

myzone console login: 

If you used the root_password setting from above, you can log in as root/abc123:

myzone console login: root
Password: 
Jul 14 10:55:32 myzone login: ROOT LOGIN /dev/console
Sun Microsystems Inc.   SunOS 5.11      snv_111b        November 2008
root@myzone:~# 

As with shared IP, you can see the interface using ifconfig:

root@myzone:~# ifconfig -au4
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
myzone0: flags=1000863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.0.1.25 netmask ffffff00 broadcast 10.0.1.255
        ether 2:8:20:59:0:b5 

However, now you can also manage it. For example:

root@myzone:~# ifconfig myzone0 down
root@myzone:~# ifconfig -au4
lo0: flags=2001000849<⁞UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 

And back in the global zone, there's no more logical interfaces cluttering up the ifconfig output:

bleonard@opensolaris:~$ ifconfig -au4
lo0: flags=2001000849<UP,LOOPBACK,⁞RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
	inet 127.0.0.1 netmask ff000000 
e1000g0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2
	inet 10.0.1.10 netmask ffffff00 broadcast 10.0.1.255

If you've preconfigured your zone as I did, you will probably be frustrated that there's no DNS. For example:

root@myzone:~# pkg search glassfish
pkg: Some servers failed to respond appropriately:
    http://pkg.opensolaris.org/release/: node name or service name not known

This is easy enough to fix. First, copy the global zone's /etc/resolve.conf file to myzone:

bleonard@opensolaris:~$ pfexec cp /etc/resolv.conf /zones/myzone/root/etc/.

Then, in the zone, copy /etc/nsswitch.dns to /etc/nsswitch.conf:

root@myzone:~# cp /etc/nsswitch.dns /etc/nsswitch.conf

And you're all set:

root@myzone:~# pkg search glassfish
INDEX      ACTION    VALUE                     PACKAGE
description set       GlassFish                 pkg:/glassfishv2@0.5.11-0.86
description set       GlassFish                 pkg:/glassfishv2@0.5.11-0.86
description set       GlassFish                 pkg:/glassfishv2@0.5.11-0.86
description set       GlassFish                 pkg:/web/glassfish-2@2.1-0.111

In the Zones blog I posted a few weeks back, a couple of the steps required interactive configuration. In this entry I'm going to create the same zone, however in a much streamlined manner.

Step 1: Create the Zone

In this step we can pass a series of settings to the zonecfg command, bypassing the interactive prompts. I've created a file called myzone.config that contains the following:

bleonard@opensolaris:~$ cat myzone.config
create
set zonepath=/zones/myzone
set ip-type=shared
add net
set address=10.0.1.25/24
set physical=e1000g0
end

Using that file I can quickly create the zone as follows:

pfexec zonecfg -z myzone -f myzone.config

Confirm its configuration:

bleonard@opensolaris:~$ zonecfg -z myzone info
zonename: myzone
zonepath: /zones/myzone
brand: ipkg
autoboot: false
bootargs: 
pool: 
limitpriv: 
scheduling-class: 
ip-type: shared
hostid: 
net:
	address: 10.0.1.25/24
	physical: e1000g0
	defrouter not specified

bleonard@opensolaris:/zones$ zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   - myzone           configured /zones/myzone                  ipkg     shared

Step 2: Install the Zone

bleonard@opensolaris:/zones$ pfexec zoneadm -z myzone install
   Publisher: Using opensolaris.org (http://pkg.opensolaris.org/release/).
       Image: Preparing at /zones/myzone/root.
       Cache: Using /var/pkg/download.  
Sanity Check: Looking for 'entire' incorporation.
  Installing: Core System (output follows)
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                  20/20   3021/3021   42.55/42.55 

PHASE                                        ACTIONS
Install Phase                              5747/5747 
  Installing: Additional Packages (output follows)
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                  37/37   5598/5598   32.52/32.52 

PHASE                                        ACTIONS
Install Phase                              7332/7332 

        Note: Man pages can be obtained by installing SUNWman
 Postinstall: Copying SMF seed repository ... done.
 Postinstall: Applying workarounds.
        Done: Installation completed in 171.102 seconds.

  Next Steps: Boot the zone, then log into the zone console
             (zlogin -C) to complete the configuration process

bleonard@opensolaris:/zones$ zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   - myzone           installed  /zones/myzone                  ipkg     shared

Steps 3 & 4: Boot and Configure

This is where things really improve for the better. If you look at the original Zones blog, there were a fair amount of steps involved in configuring the system. Like with creating the zone itself, the settings for these configuration steps can be placed in a file that the zone will read on first boot. The file must be named sysidcfg. Here's a version that matches the configuration settings from the original Zones blog:

bleonard@opensolaris:~$ cat sysidcfg
system_locale=C
terminal=xterms
network_interface=PRIMARY {hostname=myzone}
security_policy=none
name_service=NONE
nfs4_domain=dynamic
timezone=US/Eastern
root_password=fto/dU8MKwQRI

Note, the root_password is supposed to be set to a value from your /etc/shadow file. However, beware of the following issue: Zone Preconfiguration Fails with root_password keyword set. The workaround is to use a value from either Solaris 10 or SXCE. The root password used above is 'abc123', so you can just use that and then change it to whatever you like. Or you can just leave out the root_password keyword and you will be prompted to set one.

To further customize the sysidcfg file, see the sysidcfg man page.

The sysidcfg file must be placed in the zone's /etc directory. The zone must first be readied before its file system can be accessed:

pfexec zoneadm -z myzone ready

Now copy the sysidcfg file:

pfexec cp sysidcfg /zones/myzone/root/etc/.

Now, log into the zone and wait for it to boot:

bleonard@opensolaris:~$ pfexec zlogin -C myzone
[Connected to zone 'myzone' console] 

Open a 2nd terminal window and boot the zone:

pfexec zoneadm -z myzone boot 

Then back in the 1st terminal window you'll see the following:

[NOTICE: Zone booting up]


SunOS Release 5.11 Version snv_111b 64-bit
Copyright 1983-2009 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Hostname: myzone
Loading smf(5) service descriptions: 69/69
Reading ZFS config: done.
Mounting ZFS filesystems: (5/5)
Creating new rsa public/private host key pair
Creating new dsa public/private host key pair
Configuring network interface addresses: e1000g0.

myzone console login: 

You can log in as root. If you used the the root_password setting above, the password is abc123.

myzone console login: root
Password: 
Jul  8 11:09:38 myzone login: ROOT LOGIN /dev/console
Sun Microsystems Inc.   SunOS 5.11      snv_111b        November 2008
root@myzone:~# 

The coffee stations in MPK17 are popular choices for technical discussions. Some go longer than others, and occasionally result in byproducts. I wouldn't want to hazard a guess about how long a discussion resulted in this byproduct, which popped up sometime at the end of last week:

I wonder if the original discussion ever resolved...

[ T: OpenSolaris MPK17 ]

How cool would it be to see this the next time you travel?

I watched Iron Maiden's latest documentary this past weekend, Flight 666. What I found most impressive was that lead singer Bruce Dickinson pilots the tour plane! This is a Boeing 757 - not some simple Cessna. And If you've seen him on stage you'll wonder where he finds the energy to then fly a plane from Tokyo to Los Angeles.

So, what's any of this got to do with OpenSolaris? A friend of mine turned me on to the Iron Maiden font. Unlike the TrueType fonts, it's not in any IPS repository. In order to install it (or any other such font that you download), extract the maiden.ttf from the zip file and copy it to /usr/X11/lib/X11/fonts/TTF.

pfexec cp maiden.ttf /usr/X11/lib/X11/fonts/TTF/ 

Once the font is in place, you'll be able to access it from your editor:

I kinda like this logo: