14. August 2012 · 2 comments · Categories: Solaris · Tags: , , ,

I’ve forgotten this several times now so it’s time I wrote a short post to help me remember in future! In Solaris 11 we use the Image Packaging System to maintain the software on the system. This is written in python and uses libcurl and for non zoned systems setting the http_proxy is sufficient to allow the system to communicate with the repo. More »

06. June 2012 · Write a comment · Categories: Solaris · Tags: , ,

… or Overcoming Your Fear of Repositories as the OTN Garage puts it! My colleagues Glynn Foster, Pete Dennis and I have put three articles on Oracle Tech Network that we hope will help you keep your Solaris 11 systems up to date. Here’s why these documents may be of interest to you administering Soalris 11.

More »

‘boot -L’ will give you the list of boot environments to boot from. So then you can just use the -Z option to boot the corresponding root fs.

Handy when you screw up boot environment activation 🙂 More »

I’ve been using my tonidoplug as a home NAS server for almost a couple of years now. It’s performed as well as can be expected for 2 mirrored 1.5TB disks attached on a USB hub.

One evening recently though I noticed that it was unreachable. A quick look at the box showed that all was not well, both lights on the network interface were on as was the green light on the box. After trying to reflash the unit I contacted support but they would not replace a nearly 2 year old unit. Though to be fair to them they did offer to sell me a replacement at a discount.

So with the unit dead and no chance of a replacement the ‘void if removed’ sticker was quickly discarded. Here’s the box in its faulted state with the LEDs on:

From experience the most likely thing to die in electronics is the power supply. It clearly isn’t dead here since the lights come on, but a quick check of the outputs with a multimeter showed that what should have been a +5V output was actually +2.5V. Luckily I have a sheevaplug that I use for another home project that uses an equivalent power supply so after a quick swap the Tonido was booting again.

Looking a plug computer forums it appears that there are known issues with some of these power supplies. The Tonidos original power supply was contained in a metal box, as was the original sheevaplug ones that are mentioned in the forums, but my sheevaplug has the circuit board glued to the case with protective black plastic around it. Whether that is to try to reduce the heat build up I can’t say.

Anyway the unit powered back up and the disks and mirror seem to be working fine.

[email protected]:~# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[0] sdb1[1]
1465135936 blocks [2/2] [UU]

unused devices:
[email protected]:~#

This does mean that my plans to build a mini-ITX Atom based Solaris ZFS NAS box are now on hold. But at least so are my plans to spend about €500 on it when I can just by a £20 power supply to fix what I have!

This post originally appeared at http://blogs.sun.com/ford/entry/using_nat_in_the_global

Since sun.com is going away soon (thank a bunch Oracle…) I’m going to mirror it here because I found it useful.

20050927 Tuesday September 27, 2005

Using NAT in the Global Zone

There have been requests to use IPFilter on Solaris 10 as a tool to allow use of networking by non-global zones without allocating an IP address for each zone. The general idea is to use network address translation (NAT) so that packets sent from a non-global zone configured with only a private IP address are modified before leaving the machine to use the global zone’s public IP address. Each zone will be assigned a private IP address that will never be used “on the wire” and has no meaning in the public internet.

I set out to see if this can be accomplished with the existing IPFilter implementation in Solaris 10. My experiments showed that it is possible with some unorthodox system configuration hacks. Special configuration of IP is needed to trick the system into sending this traffic through the right paths so that it is

  • allowed by the zones networking restrictions,
  • passes through IPFilter,
  • is transmitted on the correct interface, and
  • ultimately reaches the proper next-hop router.

My experiment was done using a Solaris 10 (FCS) system with only a DHCP-based connection to the net. My physical network interface was bge0.

This technique requires the use of a block of private IP addresses expressible as an address prefix. I refer to this block as the “imaginary network.” For my experiment I chose Two special addresses in the block are allocated: one for the global zone (I chose and one for the imaginary router (I chose It is assumed that the all-zeroes and all-ones node addresses, and, are unusable. All other addresses in the block are available for assignment to non-gobal zones (each zone will need one address).

The configuration steps were:

(0) Configure the system (global zone) with normal networking connectivity.

(1) Enable IPFilter.

  ed /etc/ipf/pfil.ap
	svcadm enable svc:/network/ipfilter
	shutdown -y -i6 -g0

(2) Configure NAT

	echo "map bge0 -> 0" | ipnat -f -

(3) Assign the global zone’s imaginary address to the physical interface:

ifconfig bge0 addif up

(4) Add a default route to the imaginary router.

route  add default

(5) Create a fake ARP entry for the imaginary router using the real router’s MAC address.

	netstat -r | grep default
	arp therouter.my.org			# Look up the real router.
	arp -s 0:0:c:7:ac:6c	# Use the imaginary router's
						# IP address and the real
						# router's MAC address.

(6) Create one (or more) zone(s) with the same physical net interface as the global zone’s physical interface, and an address on the imaginary network.

zonecfg -z neutral
	add net
	set address=	# a different address for each zone
	set physical=bge0

(7) Boot and use the zone(s).

I have only done light testing. Of course it only works with things for which NAT works. If you do something wrong, like forget to enable IPFilter or fail to create the fake ARP entry, you will probably be sending strange packets onto your LAN and network admins may hunt you down and give you dirty looks. The sample commands I list above were typed into this document and may have typos or be rough approximations. Some of the example commands are not persistent across reboot and require other steps to store them persistently. My experiment was on a single user system with simple network connectivity; in a more complex environment the steps to configure it would be very different and it may not work at all.

Conclusion: The technique I used is a hack. I think using it in a production system should be viewed with suspicion, not just because NAT is inherently dubious, but also because of the complex dependencies of the various bits of configuration that are required to make it work. But no doubt it can be useful as an interim technique for some users or applications and maybe a more polished form of the underlying technique can be added to the zones networking tool set eventually.

I came across a strange little networking problem earlier today.

The client in question had needed to be rebooted earlier in the day. The server had had no changes made to it. The problem only started occurring after the reboot of the client.

We had an NFS directory on the server that the client’s subnet had access to. However when we tried to mount the directory (via the automounter) it failed with a permission denied error. I should point out at this stage that the client is multihomed, that it it has several network interfaces onto different subnets and only one of these was allowed to access the share.

A little snooping showed that while the requests were mostly going out from the correct interface, some packets were coming out on an interface for another subnet. This shouldn’t occur since there is only one route packets can take out and its through the default router on the main interfaces subnet. It turns out however that we have 3 default routers on this machine – all active. This is likley a remnant of how the machine was installed, we copy in a defaultrouter file with multiple entries and since hosts usually only have one interface the rest get ignored. In the case of this system though the interface had been manually added over time and the routes were not activated, until the reboot then they all became active.

This meant that the system had 3 interfaces to contact the server on, but that the server would only authorise one of these interfaces. Since the interfaces had routes to the server the portmapper (rpcbind) was happily mapping ports on interfaces that we’d rather it didn’t.

Delete the routes, and delete the defaultrouter entries, restart rpcbind, and all works again.

Another ‘damn! I keep forgetting how to do that!’ post…

When you want to display something from one unix box to another there are two ways of doing it.
1. Use ssh. You need to use ‘ssh -X’ specifically which will allow X11 forwarding. ssh takes care of setting the DISPLAY variable for you. You also need to ensure that the server is configured for X forwarding:

# X11 tunneling options
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

This just works if you are a regular user, but if you need to display something as another user then you run into problems. For example you may need to run a gui installer that can only run as root.
So heres how to get it to work as root.
Firstly, as your normal user get your DISPLAY variable and the corresponding xauth entry. This can be a little tricky

$ echo $DISPLAY

Now search the xauth list for the corresponding entry. If you got localhost above, then search for the actual hostname. On some systems ‘xauth list $DISPLAY’ may work fine, others you’ll need to search:

$ xauth list|grep :10|grep server
server/unix:10  MIT-MAGIC-COOKIE-1  99410f7406b0f93e6117ae55a72a7eca

Next become the root user, or whatever user you need to be.
Set the display variable and add the xauth entry:

# DISPLAY=localhost:10
# export DISPLAY
# xauth add server/unix:10  MIT-MAGIC-COOKIE-1  99410f7406b0f93e6117ae55a72a7eca

You should now be able to fire up an xterm on the system as the new user and it will appear on your desktop.

2. Use xhosts. This is the more traditional way, but does have a gotcha for newer versions of solaris, which are more secure than previously.
On your desktop do:

$ xhost +
access control disabled, clients can connect from any host
$ echo $DISPLAY

Now log onto the remote system and set the display variable and try an xterm. It will probably fail:

$ DISPLAY=desktop:0.0
$ export DISPLAY
$ xterm
xterm Xt error: Can't open display: desktop:0.0

Whats happening here is that although you have allowed the xserver access control to accept connections from any host, the X server itself isnt actually listening for connections. To change that you need to do the following on your desktop:

 svccfg -s svc:/application/x11/x11-server setprop options/tcp_listen = true 

Then restart the Xserver.
This method will work for all users, so you can log in, become root, then just set your display.

3 ok there are alternative methods if you are really stuck. For example start up a VNC session on the server and view it on your desktop. Though thats only worth doing if you need someone else to be able to view what you are doing.

Every now and again an install on a new machine fails for me and I have to google to remember how to change the label. So this time I’m writing it down!

Docs.sun.com has some information on the differences between the two formats http://docs.sun.com/app/docs/doc/817-5093/disksconcepts-47761?l=en&a=view

But suffice to say that you cant install Solaris on an EFI disk, you need to change it to an SMI label. Thats done using ‘format -e’.

Select the label option, and then SMI Label. Once you have done that you can check the partition table as normal and your install can progress.

06. May 2009 · 3 comments · Categories: Solaris · Tags: ,

Opensolaris users may be familiar with browsing repositories in firefox. To look through the latest Develpoment repo for example you just open up http://pkg.opensolaris.org/dev in your browser.

Things are a little more complicated for the extras and support repos though.

Firstly you need to register to get access to these repos. Anyone can get access tot he extra repo, only supported customers can get access to the support repo. Go to http://pkg.sun.com/register and follow the instructions there to get your key and certificate and verify that you can connect to the repo through the pkg command.

To set up firefox to be able to browse the repo take a little more work. Danek Duvall from the IPS team provided these instructions on how to do it:


openssl pkcs12 -in /var/pkg/ssl/OpenSolaris_extras.certificate.pem \
-inkey /var/pkg/ssl/OpenSolaris_extras.key.pem -export > \

In the case of the support repo use the support key and cert in place of the extras ones above instead. That will prompt you for a password with which to encrypt the pkcs12 file.

Now in firefox add the  pkcs12 file: Edit -> Preferences -> Advanced -> Encryption -> View Certificates ->
Your Certificates -> Import -> choose file (/tmp/OpenSolaris_extras.certificate.pkcs1) -> enter password.

Then point your browser at https://pkg.sun.com/opensolaris/extra/ (or https://pkg.sun.com/opensolaris/support for the support repo).  There’s
a dialog box that pops up saying that the site has requested you identify
yourself with a cert, and gives you a list of possible certs to use.
Choose the right one, click OK, and then you can browse the repo.

I hit an interesting problem tonight with jumpstart. Or old timeserver has gone away and the jumpstart clients are now going into interactive installs asking for the user to set the time. We rely heavily on automated installs so this needed to be fixed.

The solution was obvious I thought. I’ll just set up one of our servers as a ntp server and tell the jumpstart clients to query that in the sysidcfg files.

The only problem is that jumpstart doesn’t query ntp. After snooping on the server for a while it was clear that the packets reqesting the time were not NTP, they were TIME.

Heres how I diagnosed it.

First snoop the install.

snoop -v -o /tmp/snoop.op clientname

Then once your install has gone interactive you can convert that to a readble format:

snoop -i /tmp/snoop.op -v > /tmp/snoop.op.as

Examining the file you can find the time request:

TCP:  Source port = 32773
TCP:  Destination port = 37 (TIME)
TIME:  ----- TIME:   -----
TIME:  ""

So, whats port 37 exactly? /etc/services tells us that the time server runs there. (duh!)

The service that runs this is in Solaris 10 svc:/network/time:stream

On solaris 10 you need to do

svcadm enable svc:/network/time:stream

To check that is working ok you can telnet to the server and see if you get any output; if its not running you will get connection refused. This is basically what your jumpstart client is doing.

$ telnet patchtest-231 37
Connected to patchtest-231.
Escape character is '^]'.
Connection to patchtest-231 closed by foreign host.

We are now back to fully automated jumpstart installs!