UNIX OE from scratch: No need to always install development tools and libs

Sunday Mar 27, 2005

You may recall that one of the early steps in my building-a-system-from-scratch project was to add 31 packages on top of the foundation layer. These packages contain things like development tools and libraries which are needed to enable the pkgsrc system to do it's thing -- auto-build open-source apps from source.

But do we always need to install these 31 packages? In a real-life scenario, we probably wouldn't be doing compiles on every system. Instead there would be two types of systems: a) some build machines (or maybe just one in a small deployment), and b) some production machines. The production machines would simply be "consumers" of the binary packages built by the build machine(s).

There are two common alternatives in this scenario.

Propagating binary packages

Although pkgsrc and portage (by gentoo.org) are often referred to as "from-source" distros, they have full support for binary package management as well (installing, updating, etc.).

With pkgsrc, the tool for installing binary packges is called pkg_add, and it's used like this:

# pkg_add /path/to/package.tgz 

or

# pkg_add ftp://path/to/package_dir/package.tgz

So it's very easy to simply install the binaries on various systems, with the build system serving as the central repository.

(By the way, pkg_add knows how to automatically solve missing dependencies when installing/updating binary packges just like a pkgsrc build-system does for source packages)

Network Filesystem Mounting

Alternatively, if we don't want to propagate the contents of /usr/pkg to every box, there's always filesystem sharing technology. For example, we can set up the pkgsrc build-server to double as an NFS or Samba server, "export" the /usr/pkg filesystem, and mount it over the network on the other machines as needed.

Bottom Line...

So getting back to those 31 packages.

As described above, in a pkgsrc-supported environment, there are usually systems that are "producers" (of pkgsrc builds) and others that are "consumers".

On the consumer systems, you don't need to install any of those 31 packages!

Next I'll take yet another look at the 31 packages, and explain how, even on "producer" systems, many of them aren't really required.

---

Email: Eric dot Boutilier at Sun dot com

GNU versions of common UNIX commands and their affect on booting (SMF)

Sunday Mar 27, 2005

Just for the fun of it I did an experiment on my "from-scratch" UNIX system to see if boot-time service initialization would break if I forced it to use the GNU versions of a bunch of common commands & tools. (Boot-time service initialization is now done by SMF -- Service Management Facility -- which is one of the major new features of Solaris 10.)

As far as I could tell, everything still worked. Here's what I did:

First I compared the set of GNU commands & tools available on this box to the contents of the standard bin and sbin directories. As a result, I found 66 Sun commands & tools had corresponding GNU versions.

Then, using foreach loops, I did the following:

• Renamed the Sun versions from filename to snfilename like this:

  # cd /usr/bin
  # mv sort snsort

• And linked to the GNU versions like this:

  # ln -s /usr/pkg/bin/gsort /usr/bin/sort 

[ Note: This is a pkgsrc-supported box (for details see my previous blog entries about this), meaning the open-source packages are locally built and installed in /usr/pkg ]

Next I saved the state of SMF in a "before" file like this:

# svcs -o STATE,FMRI | sort > svcs.before

(There were 47 services running.)

Then I rebooted and watched for errors. There were none.

Finally I compared the after-boot state of SMF to the before-boot state to see if it had degraded in any way:

# svcs -o STATE,FMRI | sort > svcs.after
# diff svcs.before svcs.after

They were identical.

A logical conclusion to draw from this is that on a base (minimized) Solaris 10 system there are far fewer critical dependencies on the native versions of common commands and tools. Therefore it's feasible to consider replacing them with (possibly) more modern versions.


P.S. To learn more about SMF, check out The SMF Quickstart Guide
Also, do a search for "SMF" on blogs.sun.com

---

Email: Eric dot Boutilier at Sun dot com