Installing Pidgin For Nexenta

In order to work out these instructions I originally built Pidgin in its own zone, called the pidgin_zone. Since Pidgin requires the X Server graphics libraries, I have installed it in the global zone locally. For any installations that are not officially supported by the Nexenta package manager, I never use the default installation path or any installation path that requires root access. I generally use my $HOME directory as the installation path. This has worked so far when I have installed Opera, for example, and it worked for the Pidgin install, as well. Please keep in mind that since Nexenta's package manager does not have a record of these types of installations, you will be required to upgrade on your own without Synaptic's help.

Step 1: Install Nexenta Libraries

You will need the following packages for extracting and building the Pidgin source:

• timezra@nexentaos:~# sudo apt-get install bzip2
  
• timezra@nexentaos:~# sudo apt-get install libgnomeui-dev
  
• timezra@nexentaos:~# sudo apt-get install make
  
• timezra@nexentaos:~# sudo apt-get install gcc
  

The list of libraries that the Pidgin source depends on was originally taken from this post.

• timezra@nexentaos:~# sudo apt-get install libxml-parser-perl (or else you will see the error "checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool" when you run ./configure)
  
• timezra@nexentaos:~# sudo apt-get install libxml2-dev gettext libnss-dev libnspr-dev libgtkspell-dev
  

Step 2: Build Pidgin From Source

After the Nexenta dependencies are installed, unzipping, building and installing the libraries should be easy.

• timezra@nexentaos:~# mkdir $HOME/build
  
• Download and copy pidgin-2.2.2.tar.bz2 to $HOME/build
  
• timezra@nexentaos:~# cd $HOME/build
  
• timezra@nexentaos:~/build# bunzip2 pidgin-2.2.2.tar.bz2
  
• timezra@nexentaos:~/build# tar -xf pidgin-2.2.2.tar
  
• timezra@nexentaos:~/build# cd pidgin-2.2.2
  
• timezra@nexentaos:~/build/pidgin-2.2.2# ./configure --prefix=$HOME
  
• timezra@nexentaos:~/build/pidgin-2.2.2# make
  
• timezra@nexentaos:~/build/pidgin-2.2.2# make check
  
• timezra@nexentaos:~/build/pidgin-2.2.2# make install
  

You should now have an executable file $HOME/bin/pidgin that will start the IM client!

Step 3: Copy Pidgin Accounts From One Computer To Another

Originally, I had been running Pidgin on my Windows laptop at work, but when I left that job, I had to turn over the computer to IT. I have collected some 6 or 7 IM accounts over the years and I hate to keep track of them. Previously, I had used Trillian to manage my accounts but switched to Pidgin when I registered with gmail (since, at the time, only the for-pay version of Trillian supported Google chat). I did not want to re-create all those accounts for my home install of Pidgin, but I could not find an easy way from inside Pidgin to export the registration / group data. After a quick search, in a local directory of Windows (I believe it was My Documents/Application Data), I stumbled onto a directory called .purple. I copied the resources icons, smileys, accels, accounts.xml, blist.xml, pounces.xml, prefs.xml and status.xml off the Windows machine.
After installing Pidgin into my $HOME directory on Nexenta, I noticed the new directory $HOME/.purple. I copied the contents that I had taken off the Windows machine to this directory, and Voila! It was just that easy to connect to all my IM accounts again and my contacts were properly arranged in all their appropriate folders.

Unix Command to Find And Replace Text in a File

The following is a very simple, one-line command for finding and replacing all instances of a text pattern in a file (or files). There are numerous sources for this short script. It may seem completely trivial, but it comes in handy.

• perl -pi -e 's/<find>/<replace>/' FILE_1 FILE_2 ... FILE_n
  

This will only replace the first occurrence of the pattern per line. If you want to replace all occurrences in every line, then add the 'g' option, like this.

• perl -pi -e 's/<find>/<replace>/g' FILE_1 FILE_2 ... FILE_n
  

If you want the find to be case-insensitive, then use the 'i' option, like this.

• perl -pi -e 's/<find>/<replace>/i' FILE_1 FILE_2 ... FILE_n
  

If you find that you need to replace file path names in text, then instead of back-slashing all the path separators in your pattern, you might want to choose a different s/// separator. I have found that '~' works pretty well (but if your paths contain '~'s, then you should experiment).

• perl -pi -e 's~/path/to/my/file~/new/path/to/file~' FILE_1 FILE_2 ... FILE_n

If you want to replace some text with the contents of an environment variable, then you can access the environment with the hash ENV.

• perl -pi -e 's~some_text~$ENV{environment_variable}~' FILE_1 FILE_2 ... FILE_n

• 
  

Installing Luntbuild With Tomcat For Nexenta

Luntbuild is a continuous integration server and build management tool. I have chosen to use it because it has been so easy to set up builds with it in the past. Their claim that it takes about 1/2 hour to set up an initial build was pretty accurate when I used it before on a Windows machine. I wanted to test out this claim for Nexenta. Since Nexenta already offers a Tomcat 5 package, I thought the initial set-up would be a piece of cake. It became a good learning experience about Java security policies.
The security permissions required for running web applications with the Nexenta Tomcat package provided a big headache for me, as I have not configured Tomcat policy files before, and Terracotta and Spring (which Luntbuild uses) seem to use quite a few restricted actions. Hopefully these instructions will help some other intrepid Agilist who wants to get a CI server up and running quickly on Nexenta or Ubuntu.

Step 1: Create a New Zone

See these instructions for setting up a new zone for Nexenta. I named my zone luntbuild_zone and put it in /export/home/zones/luntbuild_zone.
Do NOT bootstrap tomcat5 with the install as you will need to install the JDK separately before tomcat5.

Step 2: Install JDK 6 in the luntbuild_zone

See these instructions for setting up the JDK in a new base Nexenta zone.
Tomcat requires the JDK, and, unfortunately, Nexenta only provides a JRE package. If you install tomcat5 without a JDK, startup fails with the message

Could not start Tomcat 5 servlet engine because no Java Development Kit
(JDK) was found. Please download and install JDK 1.3 or higher and set
JAVA_HOME in /etc/default/tomcat5 to the JDK's installation directory.

Step 3: Install Tomcat

• root@luntbuild_zone:~# export JAVA_HOME=/usr/opt/jdk1.6.0_02
  
• root@luntbuild_zone:~# apt-get install tomcat5
  
• root@luntbuild_zone:~# vi /etc/default/tomcat5
  add the line JAVA_HOME=/usr/opt/jdk1.6.0_02
  
• root@luntbuild_zone:/usr/opt# /etc/init.d/tomcat5 start
  Starting Tomcat 5 servlet engine using Java from /usr/opt/jdk1.6.0_02: tomcat5.
  
• Navigate to http://192.168.0.111:8180 in a browser and you should see an empty directory listing. This directory corresponds to /var/lib/tomcat5/webapps/ROOT/.
  

Step 4: Install the Luntbuild Web Application

These instructions come primarily from the Luntbuild Installation Guide in the section Installation using zip distribution (without GUI)

Download the luntbuild 1.5.3 zip (NOT the installer-jar).

• root@luntbuild_zone:~# mkdir /usr/opt/luntbuild
  
• Copy luntbuild-1.5.3.zip into /usr/opt/luntbuild
  
• root@luntbuild_zone:~# cd /usr/opt/luntbuild
  
• root@luntbuild_zone:/usr/opt/luntbuild# apt-get install unzip
  
• root@luntbuild_zone:/usr/opt/luntbuild# unzip luntbuild-1.5.3.zip
  
• root@luntbuild_zone:/usr/opt/luntbuild# /etc/init.d/tomcat5 stop
  
• root@luntbuild_zone:/usr/opt/luntbuild# vi web/WEB-INF/web.xml
  Replace $INSTALL_PATH with /usr/opt/luntbuild
  
• root@luntbuild_zone:/usr/opt/luntbuild# vi /usr/opt/luntbuild/log4j.properties (unfortunately, the Luntbuild configuration uses relative paths for these log4j configuration files so you will see File permission errors in the catalina logs if you try to start tomcat from a directory that is not owned by the tomcat5 process; it's best just to change these relative paths to absolute paths)
  Replace luntbuild_log.html with /usr/opt/luntbuild/logs/luntbuild_log.html
  Replace luntbuild_log.txt with /usr/opt/luntbuild/logs/luntbuild_log.txt
  
• root@luntbuild_zone:/usr/opt/luntbuild# vi /usr/opt/luntbuild/web/WEB-INF/classes/log4j.properties
  Replace luntbuild_log.html with /usr/opt/luntbuild/logs/luntbuild_log.html
  Replace luntbuild_log.txt with /usr/opt/luntbuild/logs/luntbuild_log.txt
  
• root@luntbuild_zone:/usr/opt/luntbuild# mkdir /var/lib/tomcat5/webapps/luntbuild
  
• root@luntbuild_zone:/usr/opt/luntbuild# cp -r /usr/opt/luntbuild/web/* /var/lib/tomcat5/webapps/luntbuild
  
• root@luntbuild_zone:/usr/opt/luntbuild# rm /var/lib/tomcat5/webapps/luntbuild/WEB-INF/lib/commons-logging-1.0.4.jar (you will see ClassNotFoundExceptions otherwise since there is also a commons-logging.jar in /java/share that is installed by Nexenta when tomcat5 is installed)
  
• root@luntbuild_zone:/usr/opt/luntbuild# vi /etc/tomcat5/policy.d/05luntbuild.policy (this is the policy file that grants permissions to the luntbuild jsps, classes and libraries, particularly to the Terracotta, Spring and cglib jars which access a number of restricted methods and properties)
  
  

  
    grant codeBase "file:${catalina.home}/webapps/luntbuild/WEB-INF/lib/-" {
      permission java.util.PropertyPermission "*", "read,write";
      permission java.lang.RuntimePermission "shutdownHooks";
      permission java.lang.RuntimePermission "getProtectionDomain";
      permission java.lang.RuntimePermission "accessDeclaredMembers";
      permission java.lang.RuntimePermission "createClassLoader";
      permission java.lang.RuntimePermission "setContextClassLoader";
      permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
      permission java.io.FilePermission "${java.home}/-", "read";
      permission ognl.OgnlInvokePermission "*";
    };
  
    grant codeBase "file:${catalina.home}/webapps/luntbuild/WEB-INF/classes/-" {
      permission java.util.PropertyPermission "*", "read,write";
      permission java.lang.RuntimePermission "shutdownHooks";
      permission java.lang.RuntimePermission "getProtectionDomain";
      permission java.lang.RuntimePermission "accessDeclaredMembers";
      permission java.lang.RuntimePermission "createClassLoader";
      permission java.lang.RuntimePermission "setContextClassLoader";
      permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
      permission java.io.FilePermission "${java.home}/-", "read";
      permission ognl.OgnlInvokePermission "*";
    };
  
    grant codeBase "file:${catalina.home}/webapps/luntbuild/-" {
      permission java.io.FilePermission "${catalina.home}/temp", "read";
      permission java.io.FilePermission "${catalina.home}/temp/-", "read,write,delete";
      permission java.io.FilePermission "/usr/opt/luntbuild", "read,write,delete";
      permission java.io.FilePermission "/usr/opt/luntbuild/-", "read,write,delete";
      permission java.io.FilePermission "/usr/opt/luntbuild/logs", "read,write,delete";
      permission java.io.FilePermission "/usr/opt/luntbuild/logs/-", "read,write,delete";
      permission java.io.FilePermission "/usr/opt/luntbuild/db", "read,write,delete";
      permission java.io.FilePermission "/usr/opt/luntbuild/db/-", "read,write,delete";
      permission java.io.FilePermission "/usr/opt/luntbuild/tmp", "read,write,delete";
      permission java.io.FilePermission "/usr/opt/luntbuild/tmp/-", "read,write,delete";
      permission java.io.FilePermission "/usr/opt/luntbuild/tmp/dummy", "read,write,delete";
    };
  
  

  
  
  
• root@luntbuild_zone:/usr/opt/luntbuild# chown -R tomcat5 /usr/opt/luntbuild (the tomcat process runs as the tomcat5 user)
  
• root@luntbuild_zone:/usr/opt/luntbuild# chown -R tomcat5 /var/lib/tomcat5/webapps/luntbuild
  
• root@luntbuild_zone:/usr/opt/luntbuild# /etc/init.d/tomcat5 start
  
• With a browser, navigate to http://192.168.0.111:8180/luntbuild/ and you should be redirected to the Luntbuild project administration page!
  

Installing JDK 6 in a Nexenta Zone

In the spirit of maintaining and re-factoring this blog, the following instructions have been extracted from a previous entry related to building Eclipse and from a posting that I am currently working on related to installing tomcat with luntbuild.

Get the Sun JDK 6 download. Do NOT get the Solaris x86 packages. Instead get the self-extracting file. If you get the package installation to work, then I would love to get your instructions for this. Personally, I spent quite a bit of time on this task and pretty much had it working after installing a bunch of extra packages like sunwmfrun from the Solaris 11 install CDs and by brute-force trial and error. Eventually I stopped because the self-extracting installer is so much easier and has fulfilled my JDK needs (tomcat, the Eclipse build) so far.
I chose to install write these instructions in the context of JDK 6, but they can probably be easily extended to include JDK 5, JDK 7 or OpenJava.

These instructions are performed from inside a clean, new, base Nexenta Zone. Also see the instructions for setting up a new zone.

Step 1: Install Nexenta Dependencies

To use the self-extracting installer, you will need to make sure you have a couple of Nexenta packages. These commands can be run from a terminal.

• root@my_zone:~# apt-get install sunwesu (if you do not have this package, you will see a checksum error when you run the executable).
  
• root@my_zone:~# apt-get install nevada-compat (if you do not have this package, you will see a libCrun.so.1 error when the script runs unpack200 -- there is a posting in the Nexenta forum with more information about this error.
  

Step 2: Extract the JDK

Copy the JDK 6 self-extracting archive (jdk-6u2-solaris-i586.sh) to /usr/opt (I often use /usr/opt/, but you can choose whatever directory you choose).

• root@my_zone:~# /sbin/sh (use /sbin/sh for executing the self-extracting archive or else you will see a checksum error).
  
• # ./jdk-6u2-solaris-i586.sh
  

Creating a New Zone in Nexenta

In the spirit of maintaining and re-factoring this blog, the following instructions have been extracted from previous entries related to building Eclipse and setting up Subversion on Nexenta.

These instructions were originally take from an article on the main Nexenta site.
I generally choose to install large new components (like web servers or source control systems or IDEs whose build-process takes longer than an hour) in their own zone so that I can figure out their dependencies and so that they do not interfere with any of the existing software in my root zone (or so that my root zone does not interfere with the intended operation of the new component). Mainly, I am just tired of re-installing Nexenta because some packages have caused destruction when I have built them in the past (what in the world did the JDK 1.4 and JDK 5 solaris packages do to my /usr/bin simlink!?) It is easier to re-install a zone than it is to re-install the whole OS. Also, by using zones, I can pretend that my scm and database and web servers all exist on different computers on my home network, and that makes me feel like a bigshot.
I did notice one unfortunate side effect to installing a zone for the first time -- for some reason, in / and in the directories off /, there is only 5GB out of 65GB of space available for files. In /export/home/, however all 65GB are available. So my convention is just to install all my zones and all my 3rd-party software off /export/home and to leave that 5GB of space off / just for core OS packages. I think that is reasonable. If you do not find that to be reasonable, then you might want to re-consider using Nexenta zones for now if you cannot find an acceptable way around this issue.
Creating a zone is not quite as straightforward as in the original article and you can see why that is in threads on the Nexenta forum.
These instructions can be performed from a terminal.

• timezra@nexentaos:~$ sudo zonecfg -z my_zone
  my_zone: No such zone configured
  Use 'create' to begin configuring a new zone.
  
• zonecfg:my_zone> create
  
• zonecfg:my_zone> set zonepath=/export/home/zones/my_zone
  
• zonecfg:my_zone> set autoboot=false
  
• zonecfg:my_zone> add net
  
• zonecfg:my_zone:net> set address=192.168.0.111 (or whatever ip address makes sense on your local network)
  
• zonecfg:my_zone:net> set physical=sfe0
  
• zonecfg:my_zone:net> end
  
• zonecfg:my_zone> remove inherit-pkg-dir dir=/lib
  
• zonecfg:my_zone> remove inherit-pkg-dir dir=/platform
  
• zonecfg:my_zone> remove inherit-pkg-dir dir=/sbin
  
• zonecfg:my_zone> remove inherit-pkg-dir dir=/usr
  
• zonecfg:my_zone> verify
  
• zonecfg:my_zone> commit
  
• zonecfg:my_zone> ^D
  
• timezra@nexentaos:~$ zoneadm list -vc (this will tell you if my_zone is configured)
  
• timezra@nexentaos:~$ sudo vi /usr/lib/nexenta-zones/elatte-unstable.bootstrap
  
• Replace the reference to jkaudio-toolsva8233 in work_out_debs() with sunwvia823x
  
• timezra@nexentaos:~$ sudo zoneadm -z my_zone install
  
• find the directory in / with a name like a UUID
  
• timezra@nexentaos:~$ sudo mv /<UUID>/root /export/home/zones/my_zone/root
  
• timezra@nexentaos:~$ sudo rmdir <UUID>
  
• timezra@nexentaos:~$ sudo zoneadm -z my_zone boot
  
• timezra@nexentaos:~$ zoneadm list -vc (my_zone should now be running)
  
• timezra@nexentaos:~$ sudo zlogin my_zone
  [Connected to zone 'my_zone' pts/2]
  root@my_zone:~#
  

Congratulations, you are now logged into my_zone!

Re-factoring Blog Entries.

As I started to write a blog entry about installing Tomcat with Luntbuild on Nexenta, I noticed that a few themes have started to repeat themselves from previous entries, i.e., the initial setup of a Solaris Zone and the installation of the JDK in a Zone. This presents me with an interesting dilemma: should I simply copy-paste-modify those lines from a previous blog entry, or should I re-factor from the specific to the general, give those their own space and change the original blog to reference the new, generic entry? This seems to raise a question about the nature of this blog: is it an organic journal of the specific steps taken on a journey toward some unknown end, or is each entry a constantly-evolving atom where the posted date represents only the inception of the kernel of the posted idea and not necessarily the finality of the written words?
For now, I have chosen the revisionist path with this restriction: I will try my darndest to ensure that no information is lost as entries are shifted and re-arranged and as the generic is extracted from the specific. As much as a day-to-day linear progression of thought would be personally valuable, in the end the repetition of similar items or the tracking of half-formed ideas interspersed across days could end up being a tedious and convoluted mess that I will ultimately be disinclined to maintain and that no one will want to read. Of course, constant referencing and de-referencing can be equally tedious and convoluted, so I will try as well to be politic in the sections I choose to re-factor.

Installing SVN 1.4 in a Nexenta Zone

Nexenta already provides a package for installing Subversion, but it is SVN 1.3. My goal in this posting is to install SVN 1.4 (the latest is 1.4.5) with Apache in a new Zone. I prefer to use a new Zone because it helps me determine all dependencies that I need to install alongside the primary package I am installing, it will keep my Subversion install free from any side effects of other programs, and a new Zone will look like a different computer with its own ip address on my network.

Step 1: Create a Subversion Zone

See these instructions for setting up a new zone for Nexenta. I named my zone svn_zone and put it in /export/home/zones/svn_zone.
While the Nexenta zones tutorial gives you a shortcut for installing apache2 along with the base zone install, I do NOT recommend this, as my install hung Configuring apache2 when I originally tried. In any case, it is no big deal installing the base zone first and then explicitly installing the apache2 package.

Step 2: Setup the Subversion Dependencies

• root@svn_zone:~# apt-get install apache2
  
• root@svn_zone:~# apt-get install apache2-dev (for apr-util)
  
• root@svn_zone:~# apt-get install libneon25 (for ra WebDAV support)
  
• root@svn_zone:~# apt-get install libneon25-dev (for neon-config)
  
• root@svn_zone:~# apt-get install gcc
  
• root@svn_zone:~# apt-get install make
  
• root@svn_zone:~# apt-get install python (we will use this for running make check)
  

Step 3: Install Subversion 1.4

Download the SVN source code

• copy subversion-1.4.5.tar into /usr/opt and untar it
  
• root@svn_zone:~# cd /usr/opt/subversion-1.4.5
  
• root@svn_zone:/usr/opt/subversion-1.4.5~# ./configure
  
• root@svn_zone:/usr/opt/subversion-1.4.5~# make
  
• root@svn_zone:/usr/opt/subversion-1.4.5~# make install
  
• root@svn_zone:/usr/opt/subversion-1.4.5~# make check
  

Step 4: Create a New Repository

This post helped with some of the following instructions.

• root@svn_zone:~# mkdir /usr/local/svn_repository
  
• root@svn_zone:~# svnadmin create /usr/local/svn_repository
  
• root@svn_zone:~# chown -R nobody /usr/local/svn_repository (apache2 runs as 'nobody')
  

Step 5: Setup Apache for Basic Authentication

• root@svn_zone:~# htpasswd -cm /usr/local/svn_repository/conf/svn_users svn_admin (this sets up a users file with the user svn_admin and will prompt you for a password)
  
• root@svn_zone:~# vi /etc/apache2/httpd.conf

The httpd.conf file should already contain the following two lines
LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so
LoadModule authz_svn_module /usr/lib/apache2/modules/mod_authz_svn.so

Before those two lines add another line to explicitly make sure the dav_module is loaded; otherwise you will get an error similar to this:
Cannot load /usr/lib/apache2/modules/mod_dav_svn.so into server: ld.so.1: apache2: fatal: relocation error: file /usr/lib/apache2/modules/mod_dav_svn.so: symbol dav_xml_get_cdata: referenced symbol not found.

LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so

Add the following section to the end of httpd.conf:
<Location /svn>
DAV svn
SVNPath /usr/local/svn_repository
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /usr/local/svn_repository/conf/svn_users
Require valid-user
</Location>

# restart apache2

• root@svn_zone:~# apache2 -k restart
  

Now try to open http://192.168.0.110/svn in your browser from the root Zone. You should be prompted for a username and password and then you will be brought to a screen with this information:

Revision 0: /
Powered by Subversion version 1.4.5 (r25188).

You now have a Zone dedicated to running Subversion 1.4.5 with Apache using Basic Authentication!

Building Eclipse for solaris gtk x86 on Nexenta

As this is my first post, I wanted to contribute something useful.   Hopefully this post will help someone somewhere.  I am trying to solve the following problems:

• How to install Nexenta and upgrade to the latest version (as of 10-08-2007).  Installation is easy, upgrading is not. 
  
• How to install a zone so that we have a clean area for building Eclipse;  hopefully I will give you enough to get started in the latest version of Nexenta.
  
• How to unpack Java and SunStudio to setup for an Eclipse build.
  
• How to modify the Eclipse build scripts to create a distribution of solaris-gtk-x86 3.3 that runs on Nexenta.  Unfortunately, solaris-gtk-x86 is not a supported Eclipse distribution, and the scripts require a bit of change, but these steps should give you a good starting point and hopefully will give you an understanding of which parts of Eclipse are os-specific.
  

Without further ado, the first step in this process is below.  This should be an easy one, but it will be time-consuming to burn the .iso image and to install the OS.

Step 1: Install Nexenta Alpha 6

• This is my hardware: Intel P3 750 with 1GB RAM and an 80GB hard drive.
  
• Download the Alpha 6 .iso. I have read some postings that the CD install of Alpha 7 may not work and I have not tried to install this version. I prefer to upgrade instead.
  

Step 2: Upgrade Nexenta from Alpha 6 to the latest version in the Testing repository

Unfortunately, this is not quite as straightforward as it should be. There are threads in the Nexenta forums with information about why the upgrade process takes a couple of extra steps.

These instuctions can be performed from a terminal.

• sudo apt-get remove samba (for some reason, when I had tried to upgrade previously with samba installed, I got an error that led to disaster in the form of Nested trap rebooting messages and an inability to reboot because of an incomplete upgrade, so I just took it out of the equation temporarily).
  
• sudo reboot
  
• sudo apt-get clean
  
• sudo apt-get update
  
• sudo apt-get dist-upgrade (by this point, you probably should have seen the dreaded message telling you to do an apt-get install -f).
  
• sudo apt-get install-f (now allow the package manager to remove all your gnome packages but do NOT reboot).
  
• sudo apt-get install gnome gnome-applets gnome-control-center gnome-core gnome-desktop-environment gnome-panel gnome-session gnome-terminal (this should re-install all the removed packages and some more).
  
• sudo apt-get install totem-gstreamer-firefox-plugin (this one does not get re-installed in step 7, so do it manually).
  
• sudo apt-get install dpkg apt (during the upgrade install previously, I had seen errors about the versions of dpkg and apt being incorrect, so I figured I should just upgrade those up front).
  
• sudo apt-get update
  
• sudo apt-get dist-upgrade (now there should be only one package that is getting removed -- libnewt0.51, but it will get replaced -- and a whole lot of other packages that will be upgraded and installed. This upgrade took about 45 minutes for me because a couple of connections timed-out, but it completed successfully and successfully rebooted after the upgrade).
  
• sudo apt-get install samba (we uninstalled this previously).
  
• sudo reboot.
  

Step 3: Create a New Zone

See these instructions for setting up a new zone for Nexenta. I named my zone eclipse_zone and put it in /export/home/zones/eclipse_zone.

Step 4: Install JDK 6 in the eclipse_zone

See these instructions for setting up the JDK in a new base Nexenta zone.

Step 5: Install Sun Studio 12

Even though Nexenta provides installations of gcc and cc, I chose to include a step in here for installing Sun Studio 12. A standalone, non-solaris package version of this is available for download through the Sun Developer Network. It is free to sign up and the download is free.
Again, do NOT download the solaris package version. Instead, download the standalone archive. This will install both Sun Studio and Netbeans 5.5.1.
I use SunStudio in the Eclipse build for its cc compiler, for all native libraries except the SWT (see the script below for the reason). I have not tried to build Eclipse using just the gcc compiler, but I don't see why this would not work with some changes to the build scripts (for example, all -K PIC arguments would need to be changed to -fPIC for gcc). If you have built Eclipse entirely using gcc on Solaris, please send me a link to your instructions as I would be interested in trying this!

• copy SunStudio12-solaris-x86-200705-ii.tar to /usr/opt
  
• root@eclipse_zone:~# cd /usr/opt
  
• root@eclipse_zone:/usr/opt# tar -xf SunStudio12-solaris-x86-200705-ii.tar
  

You should now have SunStudio and Netbeans installed in the eclipse_zone. I have not tried to start SunStudio or Netbeans from inside a zone -- I would guess offhand that this would not work since there is no X server running inside the zone, but it might be worth trying out sometime.

Step 6: Set up Nexenta packages required for Eclipse compilation

There are a few packages that must be installed in the zone before the Eclipse libraries will compile. Some of these packages are installed with the full Nexenta desktop, so if you are installing in the root zone, they may already be available to you. In a different vein, I originally tried to compile the required gtk+ libraries from scratch (along with all the dependencies such as cairo, pango, freetype, etc.). Unfortunately, this turned out to be a rather large time sink for me, as I was able to install the libraries, but I ran into collisions with some of the libraries that already existed from my nexenta install. If you would like all the latest and greatest versions of gtk+, then it might be a good idea for you to contribute those libraries to nexenta's unstable package installation branch. If you are able to do this successfully, I would really like to see some instructions for this. In any case, I did not pursue this because my goal is to get Eclipse 3.3 compiling and running, and the existing nexenta packages fulfill the Eclipse pre-requisites. The following instructions can be performed from a terminal.

• root@eclipse_zone:~# apt-get install libgnomeui-dev
  
• root@eclipse_zone:~# apt-get install libxtst-dev
  
• root@eclipse_zone:~# apt-get install libxt-dev
  
• root@eclipse_zone:~# apt-get install make
  
• root@eclipse_zone:~# apt-get install gcc
  
• root@eclipse_zone:~# apt-get install unzip
  
• root@eclipse_zone:~# apt-get install zip
  

Step 7: Install Apache Ant

Finally, a step that is straightforward and that works as expected!
Download the apache ant binary.

• copy apache-ant-1.7.0-bin.tar to /usr/opt
  
• root@eclipse_zone:~# cd /usr/opt
  
• root@eclipse_zone:/usr/opt# tar -xf apache-ant-1.7.0-bin.tar
  

Step 8: Set your environment variables

These environment variables are necessary for the Eclipse build process.

• root@eclipse_zone:~# export JAVA_HOME=/usr/opt/jdk1.6.0_02
  
• root@eclipse_zone:~# export ANT_HOME=/usr/opt/apache-ant-1.7.0
  
• root@eclipse_zone:~# export CC=/usr/opt/SUNWspro/bin/cc
  
• root@eclipse_zone:~# export PATH=$ANT_HOME/bin:$PATH
  

Step 9: Dig into the Eclipse build scripts

In my original post I included just a laundry list of commands to modify the Eclipse build scripts from the command-line, but in the spirit of continuous improvement, I have since extracted the commands from that original post into a shell script both to automate the process and because the script better conveys the intention of the modifications I made. This script for building Eclipse 3.3 is now in a dedicated post of its own, along with similar scripts for building Eclipse 3.4M4 and for building Eclipse 3.4M5.

The versions of Eclipse that I am currently running (Europa and Ganymede) were built from these scripts in the global zone, not in an eclipse-specific build zone. As with my install of Pidgin, I often find that it is best to perform an initial build of some software in a dedicated zone to work out dependencies. Since Pidgin and Eclipse both use the X Server graphics libraries, I plan to run them in the global zone. In this case, I decided to perform my actual Eclipse build in the global zone. The instructions below assume that you are building Eclipse in its own zone, but you can certainly perform the build in the global zone as I did.

Originally, I found directions that provide a good starting point and good ideas for scripting some of the process outlined below, but I was not completely successful with the instructions because of the dependency the Eclipse build process has on compiling the cde libraries for Solaris.  For a Nexenta Solaris build, we will not be using the cde libraries, but rather the gnome libraries.  The Eclipse Nexenta build is more like a combination of the Linux and Solaris builds than a straight port of the Solaris Sparc build.

Download the eclipse source build eclipse-sourceBuild-srcIncluded-3.3.zip

• root@eclipse_zone:~# mkdir /usr/opt/eclipse
  
• copy eclipse-sourceBuild-srcIncluded-3.3.zip to /usr/opt/eclipse
  
• root@eclipse_zone:~# cd /usr/opt/eclipse
  
• copy the script above to /usr/opt/eclipse and name it build_eclipse.sh
  
• root@eclipse_zone:/usr/opt/eclipse# chmod 755 build_eclipse.sh
  
• root@eclipse_zone:/usr/opt/eclipse# ./build_eclipse.sh
  

After a long time (on my P3 750Mhz, it takes about 110 minutes), there should be a packaged version of eclipse for solaris x86 with the gtk windowing libraries named /usr/opt/eclipse/result/solaris-gtk-x86-sdk.zip

Keep in mind that you will need to run this version of Eclipse with Java 6, or else you will see a nasty stack trace about the incorrect Java version if you try to launch eclipse. For my own setup, I created a desktop launcher that points to a small wrapper script that looks like this:

#!/bin/sh

export JAVA_HOME=/path/to/jdk1.6.0_02
export PATH=$JAVA_HOME/bin:$PATH
/path/to/eclipse/eclipse

So you should now (hopefully) have a working version of Eclipse on Nexenta.  If you have found this helpful, or if you find any improvements that can be made, please let me know.

Note: since first posting this entry, I have received a good amount of feedback and it has developed into the Solipse project.  I am happy this initial post was useful to a number of people and am happy to keep contributing toward an officially-supported eclipse solaris-gtk-x86 distribution.

Statement of Intent

This blog is not an advertisement for what I know, but an exploration of what I do not know. Admitting how much I do not know is the first step in overcoming my fear of looking foolish. I will make mistakes, but my intent is to learn from those mistakes and hopefully to uncover information useful to someone somewhere.
My first post is a laundry list of haphazard steps for bringing a clean computer from a Nexenta Alpha 6 install to a running build of Eclipse for solaris-gtk-x86. I am not a Unix or a Linux guy, but I am interested in the problem that Nexenta is trying to solve (i.e., combining the OpenSolaris kernel with the gnu utilities and the debian package manager). I am only slightly an Eclipse guy in that I have been developing an RCP application for the past 10 months. I am not involved with the Eclipse project.
Subsequent posts in the near future will probably be a reflection of the tips and tricks I encounter while doing Eclipse RCP development or Java development, but they may branch into areas of process (I recently accepted a position at an Agile company) or higher-level software engineering.
Hopefully these future posts will be shorter.