Cademuir

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
localhost:10.0

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
:0.0

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.

At Home I run windows 7 on my laptop. And in order to run Opensolaris I use virtualbox. Virtualbox in case you dont know about it basically allows you to run an operating system within your main OS. You can also run windows on an opensolaris machine for example.
I had fallen behind a bit with my virtualbox and opensolaris versions so decided to upgrade everything over the past couple of days. First I upgraded virtualbox to 3.1.4 then Opensolaris to build 132. And my graphical login failed to work. Here’s the error from the X log:

(II) LoadModule: “vboxvideo”
(II) Loading /usr/X11/lib/modules/drivers/vboxvideo_drv.so
dlopen: ld.so.1: Xorg: fatal: relocation error: file /usr/X11/lib/modules/drivers/vboxvideo_drv.so: symbol resVgaShared: referenced symbol not found
(EE) Failed to load /usr/X11/lib/modules/drivers/vboxvideo_drv.so
(II) UnloadModule: “vboxvideo”
(EE) Failed to load module “vboxvideo” (loader failed, 7)

Alan Coopersmith helped me work out what was going wrong here. When you install the guest additions on virtualbox they create an xorg.conf file. The existing conf file I had from build 127 and VB 3.1.1 worked fine, and build 127 with vb 3.1.4 worked fine. But due to changes around Xorg 1.7 things broke when I upgraded opensolaris to build 132 – even though virtualbox has support for this.

The solution?

• Remove the guest additions package.
• Remove the xorg.conf file
• Re-install the guest additions
• Reboot

All works fine now!

We’ve had some eventful days. We had fun and we kicked butt as Scott would say. We changed the world. We were part of the greatest technology company the world has ever seen. We changed computing forever – repeatedly.

And in a few minutes we’ll learn what the future holds with Oracle. I hope Oracle is ready for Sun!

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:

Run:

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

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)

<snip>
TCP:
TIME:  ----- 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
Trying 123.156.231.103...
Connected to patchtest-231.
Escape character is '^]'.
Connection to patchtest-231 closed by foreign host.

We are now back to fully automated jumpstart installs!

Recently I had a discussion with some folks about ways to identify
change in a workspace. In particular if there were ways where we could
judge the risk associated with changes without needing to know the
specifics of the changes or being told by the engineers.

In Opensolaris for example there are flag days. These coincide with
putbacks where a project team has identified major change and tells you
about it. We have something similar for Solaris Update releases.
Sometimes this is great, if there is a big zones or zfs change for
example we know to check patching extra carefully on systems using
zones or zfs. However this isn’t always enough. Every now and again
there will be a putack that causes a regression somewhere and catches
us all by surprise.

Before getting to involved in looking into this problem in detail we
did what all good engineers do. Go and see if someone else has solved
the problem already! And that’s when I got distracted. You see I started
wondering if there was some way to visualise the changes to a workspace
and literally see where risk was introduced.

That led me to Michael Ogawa’s page. There he has
several videos produced from code swarm. In the videos the names of the
engineers are displayed and the files that they are hanging are
represented by dots that swarm around them. Now while this isn’t really
what I started out looking for it does allow you to see the number of
files changed over time. More importantly Michael’s videos looked cool
so I thought I’d give it a go for Opensolaris.

Codeswarm is available from http://code.google.com/p/codeswarm . It will generate lots of png files which you can then use ffmpeg to make into a movie.

There was one problem though; it doesn’t work with mercurial workspaces
out of the box. However  Baptiste Lepilleur worked out a way to get a
compatible xml file from a mercurial repository.

Anyway here are a couple of videos I made. The first is of the Image
Packaging System. The music is from Dom The Bear (CC by-sa)

Image Packaging System Code Swarm.

Next up the ON gate! Music this time from Alexander Blu (CC by-sa). Vimeo will
only let me embed the SD version here – visit it’s Vimeo page if
you want to see the HD version; its worth watching in HD imo. While you are there you can search for
other code swarm videos – there are nearly 100 up there.

Opensolaris Code Swarm.

There is a blueprint available on Patching mirrored systems using live upgrade. This document will take you through the steps needed to create an alternate boot environment and how to patch it.

Why bother? Well by using Live Upgrade you can drastically reduce downtime as you are applying patches to a non-running boot environment. You just need one reboot to make everything active. If you run into problems you can easily reboot back into the unpatched environment.

A couple of comments that didn’t make it into the final doc:

1. I would always recommend using the ‘-c’ option to lucreate to label your current boot environment. lucreate will try and give it a sensible name (d0 in the blueprint examples), but naming this yourself makes things clearer.

2. Solaris 10 can order patches automatically for you. So if you just want to add all the patches in a directory you don’t need the order file. ‘cd /path/to/patch; luupgrade -t -n "New_BE" -s /path/to/patch *’ will do the job.

3. The blueprint focusses on the EIS CD, however you can also use LU to just apply a single patch. eg ‘luupgrade -n newroot -t -s /export/patches 987654-32‘

4. If for some reason you need to remove a patch LU can do this for you also using ‘luupgrade -T‘.

Even if you don’t currently use mirrored root filesystems it is worth taking a look at this blueprint as the Live Upgrade methodology is the same for all systems.

There was an interesting segment on RTE’s "Capital D" program tonight about the work that Shamrock Rovers do in the community. The video feed is at http://www.rte.ie/news/2007/0426/capitald.html The initiative from Shamrock Rovers include providing scolarships for payers to gain 3rd level qualifications. Just in case they dont make millions playing football! Also some schoolkids are featured whose training gear, school books and uniforms are paid for by Shamrock Rovers. Shamrock Rovers – Building The Future in Tallaght!

Speaking of Tallaght  the Tallaght Stadium saga rolls on. The next court date is in early May. Since my last blog about the stadium the GAA club Thomas Davis have been making some extraordinary moves. In an 11 page memo they informed their members that the local TD Conor Lenihan was barred from their club. Conor found out about this while members were buying him drinks at the clubhouse to celebrate a €200,000 grant from the government which Conor helped secure! Needless to say banning an elected representative from their club got quite a bit  of media coverage. The coverage prompted this reply in the Independents letters pages:

The Tallaght stadium saga

Unfortunately, for now, it remains to be seen how long they will have to wait before they see Tallaght Community Stadium finally put to good use.

This question came up on the solarisx86 yahoogroup recently:

What about a patch for a large package, say the video drivers. Might some files patched in an earlier release not have needed further patching and thus have been skipped over by applying the most current release?

So if you apply say rev-03 of a patch are you getting all the fixes from -01 and -02 also?

The answer is yes. All patch revisions are cumulative so the files and fixes from previous revisions will be in the latest revision.

This also holds for accumulated/obsoleted patches. If a patch obsoletes another patch it will then contain all the files that the obsoleted patch contains. Not only that but if there are any scripts that need to be ran the obsoleting patch will have to merge in these scripts.

This was actually the source of a lot of problems for the latest s10 KU patch,  118833-36. It had accumulated so much change from other patches that it was almost impossible to get it to install. Many of the patches that comprised the KU were easy enough (relatively!) to install on their own, but once they all accumulated into the KU it became much harder to get the patch to work. A Quick glance at the readme of KU-36 will give you an idea of the complexity involved. There are good reasons why all these other patches get accumulated into the KU and they most boil down to interdependencies – a zones patch for example will need the KU but changes in the KU will only work if the zones patch is installed also – so if you use zones you need to merge the patches. We are working on ways to ensure that adding a patch like 118833/55-36 will not be so painful for customers in future!

This situation became rather silly in Solaris 8 when we had a situation where almost everything was included in the KU. When your Kernel Update patch starts patching apache you know things are going out of control. At that point we decided to split the KU back up again in a process called rejuvenation.

With rejuvenation the KU is effectively split into smaller patches again, but each requires the previous KU. The new patches have new patchid’s. So you will have to install the latest KU, but subsequent KU’s will have different patchid’s and require that the old KU be running on the system. The catch is that it is not possible to ever uprev the old KU since we would risk overwriting files delivered in the rejuvenated patches.