Brief Notes on Installing OpenSolaris in VMWare Fusion

These notes pertain specifically to OpenSolaris build 105 and VMWare Fusion v.2.01 on MacOS Leopard 10.5.6 ~ The host machine is a 13″ macbook with 2GB ram.

When initially creating a new virtual machine for Solaris 10 the default memory size is set to 580Mb.   At  this setting the install  either hangs or progresses so slowly that it might as well be hanged.  Increasing the memory to 1024Mb solves this problem and the install progresses and enters the graphical (X-windows) install for OpenSolaris.

Getting past the memory issue, the install continues but eventually fails due to lack of disk space.  The failure does not show up until  all questions have been answered from within the graphical install portion and the installer attempts to partition the provided disk space.  The default hard drive size is set to 8GB.  Setting this to 12GB does not prevent the failure of the installation.  Pre-allocating the disk space as a single file (not broken into 2GB chunks) was also ineffective; the installation still failed due to lack of disk space.  The install fails and the diagnostics appear to show that there was little to no disk space available.  This can be circumvented by manually partitioning the disk space.

Once the install process has reached the graphical portion, I was able to open a new terminal window and used the ‘fdisk’ command to create a new disk label (using solaris defaults) for the disk space provided within VMWare.  Once the disk was labeled and written, the install procedure was able to identify the disk space correctly and the install continued to completion.

Free online backups for home use

Just a quick note this morning to remind everyone to make sure that you’re making plenty of backups of your data.   I’m a bit paranoid when it comes to data loss, so I like to take extra precautions.  Since all of our computers are macs every machine here has an external drive attached for using Apple’s Time Machine to make automatic backups.  I also archive my data to a shared location on the network.  The only problem with either of these approaches (as implemented) is that it doesn’t get the data offsite.   To solve that problem, I’ve been using Mozy for the last two months.  Mozy offers 2GB of free online storage for home use per account.  It’s not enough to back up everything, but it goes a long way to backup my most important or timely documents.  I may consider upgrading my account and pay the $4.95 a month to get unlimited storage.

I haven’t tried the Windows client so I can’t vouch for it, but so far the Mac client has worked with no problems.

::Full Disclosure::

And if you decide to try it out I’d appreciate it if you used my link here.  It’s a referral program and I get an extra 256MB of space for each person that signs up through the link.   For a short time, their bumping that up to 512MB per sign up, so I thought I’d plug the product here and maybe earn myself a bit of extra backup storage!

Solaris : Creating a Software Package for Distribution to Multiple Servers

(This article assumes that the reader is at least somewhat familiar with the inner workings of the Sun Solaris operating system. Specifically, the tutorial at the end is geared towards, and has been tested on Solaris 8 and 9. While it may also work for Solaris 10, it has not been tested on that platform)

Are you a Sun Solaris sysadmin? Have you ever downloaded a package from SunFreeware.com? (If you haven’t, you really should take a look! There are a lot of really nice pre-compiled software packages to choose from)

The great advantage of using the package format comes from the control of installing, verifying and removing the software. To install a package that’s been downloaded the sysadmin simply executes a ‘pkgadd -d <pkgname>’ and answers a few simple prompted questions, and viola’ the software is installed and (theoretically) ready to use! To view any software on your system that has been installed as a package, just run ‘pkginfo’ to get a complete listing. And to remove a particular installation is just as simple: run ‘pkgrm <package name>’ and it’s removed!

The downside (and it’s a biggee, if you ask me) to using someone else’s pre-compiled package is that you are stuck with the settings that someone else felt you needed to use. When the package was originally created someone made some assumptions on your behalf regarding what they felt constituted a ‘typical’ installation. Now from their perspective, this does make some sense. They’re compiling this software for you and packaging it up for distribution to you out of the kindness of their hearts. They want this noble deed to benefit as many people as possible! How nice.

Now, I don’t know about you, but I have yet to see a ‘typical’ server configuration. Each company (and to some extent, each installation) has its own unique set of requirements. Do you really want to install the Apache web server with all of those various options pre-compiled? Perhaps if you are a small shop and have very few people viewing some static pages on a small server then all those options won’t really bother you. But if you are a larger shop hosting multitudes of dynamic sites with huge Oracle database back-ends, then it behooves you to investigate each and every setting so that you can fully optimize your installation and thereby squeeze every last bit of usage from your company’s (most likely) large infrastructure investment.

And that’s where creating your very own custom software package comes in! The first step is to download the source code of the software you wish to use. This usually comes in the form of a ‘tarball’ (that is to say that the various files have been ‘tarred’ together into a single archive file, and then usually compressed with either gzip or bzip2) that will need to be exploded. Typically, you would download the file to a test server that is separated from the corporate network by robust firewalls.

Once the file have been extracted from the archive (typically with ‘gzip -cd package_archive.tgz’ ), make sure to read the README and INSTALL files that are typically included with source code. Run the configure script with the –help option and scrutinize the output. This will show you each and every possible compile-time option for that particular software. By running the configure script with various command line options, you can control things like where the software will get installed, what libraries to use, and many other options.

Now that you have the software configured, go ahead and run the ‘make’ command to actually compile the software into machine specific executables. (this assumes that you already have a compiler installed and working on this particular server) Next, run the ‘make install’ command to install the software into your previously defined directory. I like to install into a centralized location such as /usr/local/pkgs/

Once the software is installed into /usr/local/pkgs/<pkgname> it is time to actually create the package that you can use to distribute your customized software to each machine in your environment.

The following steps outline the creation of your very own package!

1) cd /usr/local/pkgs/<pkgname>
2) find . -print | pkgproto > prototype
3) vi prototype
-remove line with prototype file name
-add “i pkginfo=./pkginfo”
4)create a pkginfo file with the following contents:
PKG=”{JKPprogname}”
NAME=”{progname}”
ARCH=”sparc”
VERSION=”{prog_version}”
CATEGORY=”application}”
VENDOR=”{Xionic Technologies}”
EMAIL=”{pkgcreater@pkgcreatorcompany.com}”
PSTAMP=”{Jeff Pickell}”
BASEDIR=”/usr/local”
CLASSES=”none”
(replace bracketed {} information with appropriate company-specific information)

5) pkgmk -r `pwd`
6) cd /var/spool/pkg
7) pkgtrans -s `pwd` /tmp/progname-1.00

You can then gzip the resulting file in /tmp if so desired. You can now move your newly created package to each of the target systems that it is to be installed on. On the target system, run “pkgadd -d progname-1.00″ to install the package. It really is a very simple process, and once you get the hang of it, you’ll wonder why you ever did it any other way!

Once you get the hang of this process, there are more advanced tricks to learn such as pre and post install scripts that you can utilize for various things such as changing permissions on a file, or moving a file to different directory. But I’ll save that for another article!