Random ramblings

Wednesday September 05, 2007

Quagga support

I'm not a sales person but, when I see people in urgent need of help, to the degree they're offering bug bounties on the Quagga lists, and who apparently already have some kind of support relationship with Sun, then it seems it might be useful to quote from the README.Solaris file included with the SUNWzebrar/SUNWquaggar packages which ships with Solaris (10 onwards), installed to either /etc/zebra or /etc/quagga:

Support Level of Quagga Software
================================

The contents of SUNWzebrar, SUNWzebrau are provided with full Level
1 support in accordance with your current software support agreement. This
support includes Sun's global 24/7 sustaining model.

The versions of Quagga shipped are:

• Solaris 10 RR: GNU Zebra, patched equivalent to Quagga 0.96ish for ospfd.
• Solaris 10 8/07 (aka Update 4): Quagga 0.99.5 + a few CVS patches.

Tuesday February 14, 2006

Solaris Xen preview bits released

Early previews bits of the Solaris Xen 3.0 port have been made available, as well as build/install guides. Early days, but: Yay!

Sunday January 29, 2006

JS blogs on GPLv3 and OpenSolaris

Jonathan Schwartz has blogged about the GPLv3, including the possibility of dual-licencing OpenSolaris under both it and the CDDL:

we've begun looking at the possibility of releasing Solaris (and potentially the entire Solaris Enterprise System), under dual open source licenses. CDDL (which allows customer IP to safely comingle with Solaris source code) and under the Free Software Foundation's GPL3. It's early days, but we're looking at two things as we make that decision.

Interesting .

The patent-pooling features introduced with the CDDL were some of the key restrictions missing from the GPLv2, as well as one of the crucial incompatibilities between the CDDL and the GPLv3. On that count at least, the GPLv3 thankfully has introduced language to make the GPL compatible with the CDDL. I don't know myself if the GPLv3 and CDDL are fully compatible in all other respects, but it seems closeish. Even if they are not, dual-licencing would settle the issue - presuming the GPLv3 works for Sun. A question which, one can safely assume from JS's post, is being examined very carefully at the moment.

Wednesday November 30, 2005

GNU libtool, Sun Studio and 64bit builds

Many free software projects, particularly ones which use autoconf/automake build files, use GNU libtool as a wrapper around compiler and linker. Unfortunately libtool doesn't pass the "-xtarget= " (e.g -xtarget=generic64), nor most other SOS10 specific link+compile flags, to ld when linking. This then will cause the build to fail if the objects were built 64bit, as the linker will try link against 32bit system libraries. A quick workaround is to set CC to 'cc -xtarget=....'. Other flags which must be passed at link stage can also be put here (-xipo, -xildoff, etc.). This apparently is fixed in libtool 1.5.20. Another workaround is to pass these flags using -Wl.

Course, all too often Free software projects will not build at all with anything but GCC, sadly.

Thursday November 03, 2005

Git SCM

Been playing with Git recently. It's pretty good. The documentation isn't bad, and despite appearing a bit daunting to use initially actually is quite straight-forward and easy to use if you follow the tutorial (unlike, e.g., the initially promising and attractive GNU Arch, which you discover can be hard to use at times and very "quirky": bad UI and its author decided Arch should enforce his preferred way to categorise and name branches of projects).

The plan for OpenSolaris apparently is to use SVN initially for a RO, centralised, public SCM of the ON code, I gather. What to use in order to open up OpenSolaris to full distributed development is still an open question (SVNK? Teamware?). SVN (and hence SVNK) I have reservations about, I find the Apache APR which it is coded in to be, well, jarring - bit like when you first log in to a VMS system and try to figure out how to 'ls'. Also, it uses a Berkely DB backend as storage, which has not been unknown to cause problems. It also had pretty severe performance problems last I checked (a long time ago). Finally, the preferred network access daemon is Apache, and the configuration can be complicated and error-prone (last I checked the standalone 'svnserve' daemon was a second-class citizen and missing stuff like authentication (cause running it over ssh is good enough for everyone)).

Teamware is really nice (the original distributed SCM?), but shows its age in places, even if you use the excellent 'wx' wrapper (e.g. try pulling per-putback changesets from Teamware - not easy, particularly when the SCCS files used for "backend storage" use localtime for timestamps).

Git though, from some initial use, would fit reasonably well with the workflow currently in use with Teamware. It's essentially a content-addressable filesystem. It features:

• Log messages for both commits and merges. Hence if you want a per-file log message, commit the changesets for the files concerned individually (or whatever granularity is desired). You still then will specify a log message for the 'putback' to the upstream gate to cover the whole putback
• Push and/or pull merging between gates
• Space efficient sharing of repository files between different local branches, even between different local repositories on the same local filesystem.
• Hence quite good (ie fast) local branch/clone support.
• Transport agnostic. Can work over any "dumb" file sharing protocol, rsync, NFS, can work over remote shell interfaces (ssh) or with a native protocol.
• All the usual hooks
• Very granular, tool-per-task orientated. Very suited to layering a more cohesive SCM toolset on top of it (see, e.g. 'cogito'. One could imagine also 'wx' ported to work with git instead of Teamware).
• Surprisingly easy to work with. If you do get confused, there's always "git reset" to undo things (either back to 'master', or to an arbitrary changeset).

Initially written by Linus Torvalds of course, but then he'd been using Larry McVoy's Bitkeeper for many a year, and before Larry did Bitkeeper he had been working on Teamware at Sun.

There's also Mercurial / Hg, which is what the Xen project switched to after bitkeeper. Also a 'pure' distributed SCM. But havn't checked that out.

Sunday August 21, 2005

RMS on CDDL: "a free software licence"

See this OpenSolaris forum thread, where Richard M. Stallman replies:

"The current license of Solaris is a free software license, which means it is basically ethical. But it would be a more useful contribution to the free software commnuity if it had a GPL-compatible license, and I wish Sun would make that change."

Maybe now some of the FUD slung at the CDDL in certain quarters can finally die. Whether his wish can be fulfilled is a different matter though, eg, the GPL and LGPL lack the patent-commons provisions which the CDDL has. Also the GPL tries its best to prevent closed-source making use of code licenced under it, whereas the CDDL doesn't mind such use (bit like the LGPL, but the CDDL achieves it with far simpler language than the LGPL). As work on the next revision of the GPL is underway, it might be a better idea to make the GPLv3 compatible with the CDDL instead.

Tuesday June 14, 2005

condensation

Lots of stuff appearing saying/speculating/hinting that OpenSolaris is about to go live. Interesting, but, surely, it couldn't be true given that OpenSolaris is just vapourware?

Friday June 03, 2005

dtrace

Saw this blog entry on Planet GNOME. Seems like what Michael Zucchi really needs is to install Solaris 10 and try out Dtrace. Maybe some Dtrace guru should give him some examples on how to collect timing information..

Thursday May 12, 2005

Solaris x86 new boot architecture / GRUB

Casper Dik blogged about the Solaris x86 new boot architecture. It's quite nifty, gone is the old boot environment of real mode drivers, replaced with the quite useful GRUB booting the Solaris kernel via multiboot, pulling in drivers and miniroots as multiboot modules along the way. GRUB also supports network boots via RARP, BOOTP and DHCP and is generally quite flexible. So: Yay!. The next Solaris Express release should have the newboot bits.

However, there's something noticably missing from blogs.sun.com regarding newboot: A screenshot. So here it is:

Tuesday March 15, 2005

Solaris netinstall with ISC dhcpd

Notes on configuring ISC dhcpd 3.0 to provide the requisite information to allow Solaris to be net-installed. Culled mostly from a post to a mailling list somewhere (I dont have a reference), along with reading of S10 install docs and dhcpd man pages.

Define the various DHCP options which can be recognised by the Solaris x86 nbp / SPARC PROM and early boot, somewhere near the top of dhcpd.conf, in global scope:

############## Solaris JumpStart Vendor Options #########################
#
option space SUNW;

# SrootOpt, NFS mount options for the client's root file system
option SUNW.root-mount-options code 1 = text;                       #optional

# SrootIP4, IP address of root server
option SUNW.root-server-ip-address code 2 = ip-address;             #required

# SrootNM, Host name of root server
option SUNW.root-server-hostname code 3 = text;                     #required

# SrootPTH, Path to the client's root directory on the root server
option SUNW.root-path-name code 4 = text;                           #required

# SswapIP4, IP address of swap server 
option SUNW.swap-server-ip-address code 5 = ip-address;             #unused

# SswapPTH, Path to the client's swap file on the swap server
option SUNW.swap-file-path code 6 = text;                           #unused

# SbootFIL, Path to the client's boot file, optional
option SUNW.boot-file-path code 7 = text;                           #optional

# Stz, Time zone for client 
option SUNW.posix-timezone-string code 8 = text;                    #unused

# SbootRS, NFS read size used by standalone boot program when
#          loading the kernel 
option SUNW.boot-read-size code 9 = unsigned integer 16;            #optional

# SinstIP4, IP address of JumpStart install server
option SUNW.install-server-ip-address code 10 = ip-address;         #required

# SinstNM, Host name of install server
option SUNW.install-server-hostname code 11 = text;                 #required

# SinstPTH, Path to installation image on install server
option SUNW.install-path code 12 = text;                            #required

# SsysidCF, Path to sysidcfg file, in the format server:/path
option SUNW.sysid-config-file-server code 13 = text;                #optional

# SjumpsCF, Path to JumpStart configuration file in the format server:/path
option SUNW.jumpstart-config code 14 = text;                        #optional

# Sterm, Terminal type  
option SUNW.terminal-name code 15 = text;                           #unused

# SbootURI, Path to the standalone boot file or path to the WAN boot file.
#           standalone: tftp://inetboot.sun4u
#           wan boot:   http://host.domain/path-to-file
option SUNW.standalone-boot-uri code 16 = text;                     #optional

# SHTTPproxy, IP address and port number of the proxy server for 
#             WAN boot, :
option SUNW.standalone-boot-http-proxy code 17 = text;              #optional
#
#######################################################################


## Class to match the Sun nbp
# Other vendor-classes included SUNW.Ultra-1, SUNW.Ultra-30. Consult Sun documentation.
class "SUNW.i86pc" {
  match if option vendor-class-identifier = "SUNW.i86pc";
  vendor-option-space SUNW;
  #option SUNW.jumpstart-config "nfs-server:/exports/path/to/solaris/jumpstarts";
  option SUNW.install-server-hostname "nfs-server";
  option SUNW.install-server-ip-address ;
  option SUNW.install-path "/exports/path/to/solaris";
  option SUNW.root-server-hostname "nfs-server";
  option SUNW.root-server-ip-address ;
  option SUNW.root-path-name "/exports/path/to/solaris/Tools/Boot";
  #option SUNW.root-mount-options "rsize=8192,wsize=8192,noxattr";
  option SUNW.boot-file-path "/home/tftp/SUNW.i86pc";
  #option SUNW.standalone-boot-uri "tftp://home/tftp/SUNW.i86pc";
  #option SUNW.sysid-config-file-server "hibernia:/exports/s10x/s10_70/Solaris_10/Misc/sheen.sysidcfg";
  #filename "/home/tftp/nbp.x86";
}

## 

That should be it. All that is required to have the desired i86 hosts (by MAC, by PXE boot class identifier - whatever) be told to boot the Sun 'nbp' network boot utility from a tftp server with the 'filename' directive ('next-server' is required if tftp server is not on same host as the DHCP server). Sparc hosts should already have network-boot built-in, and do not need to be initially boot an nbp (AFAIK).