Solipse for Eclipse on solaris-gtk-x86

Many thanks to Hugo Garcia for setting up the Solipse project to house our progress in creating a distributable build of Eclipse for solaris-gtk-x86. The scripts that I had previously posted on this blog have now been moved to the downloads area of the project site. We have successfully been able to build fully-functional Eclipse distributions (sans the internal browser and OpenGL support) from 3.3 to 3.4 on OpenSolaris and Nexenta, and our goal is currently to iron out the last details of the SWT browser component, OpenGL support and the p2 SDKProfile and to contribute the binaries back to eclipse to make the build official.
Thanks to everyone who sent suggestions and who found some use for the initial scripts, and please feel welcome on the Solipse community site!

Eclipse 3.4M5 solaris-gtk-x86 Build Script for Nexenta

Last week I finally installed NexentaCP Beta since the Gnusolaris Alpha apt repository has been taken offline. I probably could have found an indirect way to upgrade from Alpha to Beta but opted to wipe the window clean. The re-install was completely painless. Getting the nexenta-gnome desktop required adding the unstable repository to my /etc/apt/sources.list. Upgrading to the unstable repository gave me a small taste of the new Nexenta and the power of ZFS. The ease of the debian-based update manager had always impressed me, but adding ZFS to the mix makes the entire process worry-free as well. If an upgrade ever goes wrong, rolling back to a previous state is easy.

My Nexenta upgrade coincided nicely with the release of Eclipse 3.4M5. Because I had to re-install Eclipse anyway, and because a shiny new Nexenta install deserves nothing less than the latest-and-greatest Eclipse release, I downloaded the M5 source, installed the Eclipse build dependencies, ran my 3.4M4 modification script and with a few minor tweaks was quickly able to get Ganymede up and running, Java editor bread-crumb saccharine and all.
The script for building Eclipse 3.4 M5 for solaris-gtk-x86 can be downloaded from the solipse downloads page. Please be aware of the Nexenta-specific instructions for building the SWT library with gcc instead of SunStudio cc.
 



Breadcrumbs in the Java Editor are one of the sauciest additions to this latest release. Even though they do not add functionality that is not already in the workbench and they occupy precious screen real estate, they are great eye candy.

Eclipse 3.4M4 solaris-gtk-x86 Build Script for Nexenta

The following script is based on another script for compiling Eclipse 3.3 for Nexenta (solaris-gtk-x86). The build process changed slightly from version 3.3, particularly in the native compilation of the eclipse launcher. If you are curious to see what needed to change, you can diff the 3.4M4 and 3.3 scripts. I have not used Eclipse 3.4M4 extensively yet, but from some initial trials, the version I have built with this script seems to be working well. As always, if this post has been of any use, please let me know.
You should be able to drop the script into a directory that contains the eclipse-sourceBuild-srcIncluded-3.4M4.zip, execute it, and it will decompress the archive, modify the build scripts to support nexenta with gtk on x86, and create a distibutable file in the result directory.

The script can now be downloaded from the solipse downloads page.  Be aware of the Nexenta-specific configurations for compiling the SWT libraries.

The Ganymede splash-screen on nexenta solaris-gtk-x86.


The Ganymede workbench on nexenta solaris-gtk-x86.

Eclipse 3.3 solaris-gtk-x86 Build Script for Nexenta

The following script was extracted from another blog posting about compiling Eclipse 3.3 for Nexenta (solaris-gtk-x86). I have separated it out and modified the original post because most of the steps for figuring-out dependencies are valid for building Eclipse 3.4M4 and building Eclipse 3.4M5, but the build itself is slightly different.
I have used this script to build Eclipse 3.3 for myself, have since programmed a bit with my version so I know it has worked for my basic needs and would be curious to know if anyone else has gotten any use out of it.
The script itself makes extensive use of the simple command-line find-and-replace syntax I wrote about here.
You should be able to drop the script into a directory that contains the eclipse-sourceBuild-srcIncluded-3.3.zip, execute it, and it will decompress the archive, modify the build scripts to support nexenta with gtk on x86, and create a distibutable file in the result directory.
The script can now be downloaded from the solipse downloads page.  Be aware of the Nexenta-specific configurations for compiling the SWT libraries.
 



The Europa splash-screen on nexenta solaris-gtk-x86.


The Europa workbench on nexenta solaris-gtk-x86.

Nexenta and the Eclipse Debugger

A few nights ago, when I tried to start the Eclipse debugger on Nexenta, I received the following error:

UTF ERROR ["../../../src/solaris/npt/utf_md.c":49]: Failed to complete iconv_open() setup

This seems to be similar to the known Nexenta javaws bug and to a Nexenta Netbeans debugger problem.

Thanks very much to Jeff Moguillansky for helping me to get up and running with this! I replaced my /usr/lib/iconv with the non-open-source files, as he suggested, and was soon running a new Eclipse instance in debug mode.

Building Ruby From Source On Nexenta

Currently Nexenta's package manager provides installations of Ruby 1.8.2 (the ruby package) and Ruby 1.8.4 (the ruby1.8 package). If you would like to build the latest version (1.8.6 as of this writing), these are instructions for the steps that I took beyond what is currently posted on the rubyonrails website. Keep in mind that your custom installation will not be available for update with the Synaptic package manager and may cause conflicts if you choose to install the version from the Nexenta repository, so you might want to consider overriding the default installation directory (in the directions, I specify --prefix=/usr/opt in the ruby_zone, but for the global zone, I tend to use $HOME as my installation path for non-Synaptic installations).

Install a Ruby on Rails Zone

Install a new zone called ruby_zone and login.

Build and Install Ruby From Source

• root@ruby_zone:~# mkdir /usr/opt/sources
  
• root@ruby_zone:~# cd /usr/opt/sources/
  
• root@ruby_zone:/usr/opt/sources# wget http://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6.tar.gz
  
• root@ruby_zone:/usr/opt/sources# gunzip ruby-1.8.6.tar.gz
  
• root@ruby_zone:/usr/opt/sources# tar -xf ruby-1.8.6.tar
  
• root@ruby_zone:/usr/opt/sources# cd ruby-1.8.6
  
• root@ruby_zone:/usr/opt/sources/ruby-1.8.6# apt-get install make gcc
  
• root@ruby_zone:/usr/opt/sources/ruby-1.8.6# apt-get install zlib1g-dev (or else you will see an error that looks like remote_fetcher.rb:4:in `require': no such file to load -- zlib (LoadError) error when installing ruby gems)
  
• root@ruby_zone:/usr/opt/sources/ruby-1.8.6# ./configure --prefix=/usr/opt --with-zlib-include=/usr/include --with-zlib-lib=/usr/lib
  
• root@ruby_zone:/usr/opt/sources/ruby-1.8.6# make
  
• root@ruby_zone:/usr/opt/sources/ruby-1.8.6# make test (expect to see a test succeeded message)
  
• root@ruby_zone:/usr/opt/sources/ruby-1.8.6# make install
  

Setup Ruby Gems

• root@ruby_zone:/usr/opt/sources/ruby-1.8.6# cd ..
  
• root@ruby_zone:/usr/opt/sources# wget http://rubyforge.org/frs/download.php/20989/rubygems-0.9.4.tgz
  
• root@ruby_zone:/usr/opt/sources# gunzip rubygems-0.9.4.tgz
  
• root@ruby_zone:/usr/opt/sources# tar -xf rubygems-0.9.4.tar
  
• root@ruby_zone:/usr/opt/sources# cd rubygems-0.9.4
  
• root@ruby_zone:/usr/opt/sources/rubygems-0.9.4# /usr/opt/bin/ruby setup.rb
  
• root@ruby_zone:/usr/opt/sources/rubygems-0.9.4# /usr/opt/bin/gem update (or else you may see Could not find rails (> 0) in any repository)
  

Install the Rails Gem

• root@ruby_zone:/usr/opt/sources/rubygems-0.9.4# /usr/opt/bin/gem install rails --include-dependencies
  
• root@ruby_zone:/usr/opt/sources/rubygems-0.9.4# mkdir /tmp/test_rails
  
• root@ruby_zone:/usr/opt/sources/rubygems-0.9.4# /usr/opt/bin/rails /tmp/test_rails
  
• root@ruby_zone:/usr/opt/sources/rubygems-0.9.4# cd /tmp/test_rails
  
• root@ruby_zone:/tmp/test_rails# /usr/opt/bin/ruby script/server (expect WEBrick to start)
  

From a browser, open http://ipaddress.of.ruby_zone:3000 (I chose 192.168.0.115 as the ipaddress)

You should now see the Rails "Welcome aboard" screen!

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.

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!

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.