Thursday Sep 09, 2010

Leaving Oracle

I'll no longer be at Oracle from today. You can find me at Google in London from next Monday. There's probably loads more to say, but it's also a big world and we can all get along just fine if we try. My new personal blog is at http://tekgrrl.wordpress.com, my opinions are of the "strong opinions, weakly held" variety but I don't consider myself wise other than I tend not to leave my keys in the trunk of my car like I did when I was young. If I do express strong opinions feel free to put me right on them, tell me if I wimp out. I plan to keep learning until I "pop my clogs" and I'm happy to be told that I'm wrong.

See ya! 

Monday Feb 08, 2010

Faban at Fosdem

Thanks to those that attended my talk on Faban at FOSDEM on Saturday. If you want to know more then post a comment here and we can work out how to best to talk. In the meantime here are my slides from the talk.

Tuesday Dec 22, 2009

Ruby and Lighttpd updates in OpenSolaris

As of build 129 of OpenSolaris Ruby, Lighttpd and RubyGems have been updated to the following versions:

  • Ruby 1.8.7 patch level 174
  • RubyGems 1.3.5 
  • Lighttpd 1.4.23

Lighttpd is a couple of revs behind, when we started the update 1.4.24 had just been released and had a couple of issues which we would have needed to patch. At that time darix and stbeuhler weren't sure if they would release a 1.4.25 to fix theses issues so we took an executive decision to go with 1.4.23 and update to a later version via the OpenSolaris /dev repository after the release of OpenSolaris 2010.03. 1.4.25 made it out before we integrated but given the processes we have to ensure component and build quality it's not a good idea to change versions at the 11th hour. We'll probably push Lighttpd 1.4.25 out via the /webstack repo.

These same version updates are going into WebStack 1.6 which will be available around the same time as OpenSolaris 2010.03

Monday Dec 21, 2009

Alfresco on Glassfish revised for 3.2r2

This is a walkthrough of installing Alfresco 3.2r2 on Glassfish v2 on OpenSolaris. I decided to start with the smallest delta from the original walkthrough so as to better get up to speed with the changes. Next I'll do the same for Glassfish v3 on OpenSolaris, CentOS and Windows. We can also look at deploying the share and mobile war files as well.

This walkthrough was performed on an OpenSolaris 2009.06 VM running in VirtualBox 3.0.12 on a Mac Book Pro running Snow Leopard. To run both MySQL, the App Server and Firefox you'll probably need at least 1.5GB of (v)RAM.

First you need to install the infrastructure, so install Glassfish v2 and MySQL 5.1 from the OpenSolaris repository:

$ pfexec pkg install glassfishv2 
$ pfexec pkg install SUNWmysql51

We are going to assume that you are running as a user with the root role, so many of the commands are prefixed with pfexec. If you are doing this as root then you don't need to type pfexec.

Create a glassfish domain:

$ pfexec asadmin create-domain --adminport 4848 domain1

Download the MySQL JDBC connector from http://dev.mysql.com/downloads/connector/j/

Untar or unzip the bundle and from the extracted directory copy the mysql-connector-java-x.x.x-bin.jar file to the newly created glassfish domain's lib directory:

$ pfexec cp mysql-connector-java-5.1.10-bin.jar /var/appserver/domains/domain1/lib

There are some issues with MySQL in 32-bit mode on OpenSolaris so change the installed MySQL package to use 64-bit mode:

$ pfexec svccfg -s mysql:version_51 setprop mysql/enable_64bit=true
$ svcadm refresh mysql:version_51 
$ svcadm enable mysql:version_51   (or restart it if it's already running)

Now create the 'alfresco' db and the 'alfresco' user using the mysql client:

$ /usr/mysql/bin/mysql -u root
mysql> create database alfresco;
mysql> grant all on alfresco.\* to 'alfresco'@'localhost' identified by 'alfresco';

Now download the Alfresco War file bundle which at the time of writing was named alfresco-community-war-3.2r2.tar.gz (there's also a .zip version) and was available from http://wiki.alfresco.com/wiki/Community_Edition_file_list_32r2

Create a new directory and untar/unzip the downloaded bundle into it. Change into that directory, here you'll find the alfresco.war file along with other optional parts of the Alfresco app. The Alfresco war file has a WEB-INF/web.xml deployment descriptor that doesn't comply with the DTD, you need to replace this file and add a Glassfish specific deployment descriptor that will allow Alfresco to use MyFaces instead of JSF. The two files are available here:

web.xml

sun-web.xml

Create a new directory named WEB-INF and copy these files into it. Now update the alfresco.war file using the Java jar command:

$ jar -uvf alfresco.war WEB-INF/\*.xml

The jar command should output something similar to the following:

adding: WEB-INF/web.xml(in = 25157) (out= 3836)(deflated 84%)
adding: WEB-INF/sun-web.xml(in = 317) (out= 237)(deflated 25%)

In this setup, by default Alfresco will create the alf_data directory in /var/appserver/domains/domain1/config which isn't the best place for it. To change the location you need to provide a configuration file that Alfresco can use at startup. First create the following directory:

$ pfexec mkdir -p /var/alfresco/alf_data

We'll use this directory for the walkthrough, feel free to replace /var/alfresco/alf_data with a path of your chosing.

Then (assuming you are in the same directory in which you untared/unzipped the Alfresco War file bundle)  edit the file extensions/extension/alfresco-global.properties

$ vim extensions/extension/alfresco-global.properties

Near the top of the file is a line for 'dir.root' change that line as necessary for the path you are using, in our example case:

dir.root=./alf_data

becomes:

dir.root=/var/alfresco/alf_data

If you need to at any point, you can also specify alternative information for the MySQL DB in this file. Save the file and then copy it to the /var/appserver/domains/domain1/lib/classes which is on the Glassfish global classpath

$ pfexec cp extensions/extension/alfresco-global.properties /var/appserver/domains/domain1/lib/classes

Now start the Glassfish domain and deploy the alfresco.war:

$ pfexec asadmin start-domain
$ asadmin deploy alfresco.war
Please enter the admin user name>admin
Please enter the admin password> 
Command deploy executed successfully

You should now be able to connect to http://localhost:8080/alfresco

Summary

This really just covers the basics and uses a clean OpenSolaris install just to show what actually needs to be done to get it working. Hopefully it can be extrapolated from to help install Alfresco on Glassfish in more complicated scenarios.

At some point it would be nice to show how to get the PDF to Flash functionality working as currently that's missing,

Troubleshooting

Check that it's using the MySQL database that you created by connecting to MySQL through the mysql command and looking to see if the Alfresco database has a bunch of tables. Also check that /var/alfresco/alf_data contains directories if it doesn't then it probably hasn't picked up the configuration in /var/appserver/domains/domain1/lib/classes/alfresco-global.properties. Check that you've put the file in the correct path and that the changes that you made to to the file are correct.

If during setup you make a mistake and end up with a populated DB and an empty 'dir.root' or vice versa then stop the app server and drop the database and empty out dir.root (obviously don't do this if you have data store in Alfresco that you want to keep). Then restart the app server.

Alfresco will complain via the app server logs that it doesn't have the minimum amount of memory it requires to run (499 instead of 512), if you want to increase the amount of memory available to Glassfish take a look at the Glassfish docs.

If you see any issues or mistakes then post a comment on this blog.



        
    

Friday Dec 11, 2009

Excited about new software much?

Well I am excited, having just attended and presented at Tech Days in Sao Paulo (more on that later) how could I not be :o) Glassfish v3, Java EE 6, JPA 2.0, more grizzly than you can shake a stick at, Servlet 3.0, EJB 3.1, Atmosphere and NetBeans 6.8 are just some of the things that are causing my excitement.

You can get Glassfish v3 from here and NetBeans 6.8 from here

Some NB 6.8 bundles include Glassfish v3 so if you need both go get NetBeans first. You can get all the background on Glassfish v3 on the Aquarium blog

More later


Thursday Nov 12, 2009

SourceJuicer at London OpenSolaris User Group meetup

I'll be giving a talk on SourceJuicer at the London OpenSolaris User Group meeting on Wednesday 18th November. On before me is Owen Roberts from the Solaris Sustaining group, and he'll be talking about how the core of OpenSolaris will move to being built from source directly to IPS packages (yay!).

So if you are interested,  register in advance here and then come along to the Sun Customer Briefing Centre at:

45 King William Street
London, EC4R 9AN
Map

Doors open at 6PM and the talking starts at 6:30PM, there'll be food and socialising afterward.

While on the subject of SourceJuicer, George Drapeau the OSS core team lead here in ISV-Engineering at Sun has just published a video blog on installing Acquia Drupal on OpenSolaris from the /contrib repository. You can find it on George's Blog, it's very slick :o)

Wednesday Nov 11, 2009

Time for a new Alfresco on Glassfish walkthrough

My Alfresco on Glassfish Walkthrough is over a year old now and is creaking at the seams a little so I plan to update it. Feel free to comment here on what the new walkthrough should cover, Glassfish v2.1 or v3? Solaris or OpenSolaris? Linux or Windows? Which DB (just MySQL or some other OSDB)?

In fact feel free to comment on anything you would like to see to do with running Alfresco (or any other (E)CMS app) on Sun gear.

Original blog entry: http://blogs.sun.com/mandy/entry/alfresco_on_glassfish_on_opensolaris

Cheers

Amanda

Thursday Nov 05, 2009

autoconf weirdness

configure.ac files (configure.in in the old days) are used as input to autoconf which miraculously (it's all miraculous to me) expands the macros in the configure.ac file and creates a runnable configure shell script. Autoconf macros may be system dependent so if you decide to regenerate a configure script, it's the job of autoconf, in conjunction with aclocal, to locate all of the macro definitions that it's going to need to get the job done. These macro definitions may be supplied by the local installation of autoconf, by other packages via aclocal or actually supplied by the package you are building in a file named acinclude.m4

Due to some changes in the way Lighttpd is built I found that for Lighttpd 1.4.23 in WebStack we had to regenerate the configure script, I did this using the autogen.sh script that ships with the lighttpd source code. autogen.sh calls libtool, aclocal, automake, autoconf and autoheader. On Solaris 10 autoconf generated an error:

configure.ac:67: error: possibly undefined macro: AC_DEFINE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

But AC_DEFINE is a standard autoconf macro so why can't it be found? We dug around and found mention of it being to do with pkg-config but couldn't work out why that would be. So We stripped down the lighttpd configure.ac bit by bit and found that the problem went away when we removed the lines referencing a macro named PKG_CHECK_MODULES. The file aclocal.m4 in the lighttpd build directory contains any additional macros required by autoconf to process configure.ac and is generated by aclocal. The lighttpd source distribution includes the aclocal.m4 file that was used to create the original configure script, but when you run aclocal, a new aclocal is generated from macros that have been registered with aclocal on the local system. On this system, after running aclocal, aclocal.m4 didn't contain a macro named PKG_CHECK_MODULES :o/

Further research showed that PKG_CHECK_MODULES is usually supplied in a file named pkg.m4 which is installed as part of pkg-config. It usually installs to /usr/share/aclocal which is the default location used by aclocal to locate macros. In this case though we were using a tool set specifically created by the WebStack team for building WebStack on Solaris 10. In this tool set (wstools),  aclocal lives in /export/wstools/bin and it looks for macro definitions in /export/wstools/share/aclocal. wstools doesn't include pkg-config so there's no pkg.m4. That explains why it couldn't find the PKG_CHECK_MODULES macro, but why the error about AC_DEFINE?

In configure.ac you'll find:

  if test "x$FAM_LIBS" = x; then
    PKG_CHECK_MODULES(FAM, gamin >= 0.1.0, [
      AC_DEFINE([HAVE_LIBFAM], [1], [libfam])
      AC_DEFINE([HAVE_FAM_H], [1], [fam.h])
    ])
  fi

So you can kind of see why the AC_DEFINEs passed to the PKG_CHECK_MODULES macro could be affected, but autoconf indicated that the error came from a line of code not related to PKG_CHECK_MODULES, i.e.:

AC_CHECK_MEMBER(struct tm.tm_gmtoff,[AC_DEFINE([HAVE_STRUCT_TM_GMTOFF],[1],[gmtoff
in struct tm])],,[#include <time.h>])

Here AC_DEFINE is used with another standard autoconf macro (AC_CHECK_MEMBER) and if you look at the generated configure script you find:

if test "x$ac_cv_member_struct_tm_tm_gmtoff" = x""yes; then

cat >>confdefs.h <<\\_ACEOF
#define HAVE_STRUCT_TM_GMTOFF 1
_ACEOF

fi

Which shows that it didn't actually fail where it said it did. Turns out the time it failed to process AC_DEFINE were where it was used with PKG_CHECK_MODULES. The error from autoconf actually referenced the first use of AC_DEFINE and not where it failed. Best of all, rather than emit a warning about PKG_CHECK_MODULES being missing, it just adds this to the configure script:

  if test "x$FAM_LIBS" = x; then
    PKG_CHECK_MODULES(FAM, gamin >= 0.1.0,
      AC_DEFINE([HAVE_LIBFAM], [1], [libfam])
      AC_DEFINE([HAVE_FAM_H], [1], [fam.h])
    )
  fi

Which is the un-expanded macro calls from configure.ac. These aren't valid shell commands, so the generated configure script will fail. In this case the best way to fix the problem is by adding pkg-config to the WebStack build tool set.  I've also heard that this problem can occur on systems with older versions of pkg-config, I guess that they may not define a PKG_CHECK_MODULES with the signature required by the configure.ac script.

Thursday Oct 29, 2009

Installing OpenSolaris packages from /contrib and /pending

The OpenSolaris /contrib package repository has a whole bunch of packages contributed by members of the OpenSolaris community or just by those who had a particular need for a certain package and who decided to submit it themselves.

You can install any of these packages either using the pkg command or via the package manager, you can even just go to the /contrib repository's catalog page and click on the 'install' link for the package(s) that you want to install.

To set up /contrib as a valid publisher for use with the package manager or the pkg command do the following as a user with the root role (or Software Installation profile):

pfexec pkg set-publisher -O http://pkg.opensolaris.org/contrib  contrib

Or you can add /contrib via the package manager through the File -> Manage Repositories pull down. If installing from the "install" link at http://pkg.opensolaris.org/contrib/en/catalog.shtml  the package manager will automatically add /contrib to the list of publishers.

To install packages using pkg, do the following:

pfexec pkg refresh
pfexec pkg install <package name>

You don't have to run 'pkg refresh' before installing every package, but it is probably best to do it reasonably regularly just to make sure that pkg has an up to date view of the repositories that it knows about.

There is also a /pending repository which is used to stage packages for testing while they are being made ready for promotion to /contrib. I wouldn't recommend arbitrarily using packages from /pending but you may want to provide feedback on a package, or as in the case with the ruby-mysql package, it maybe that the owner has suggested that you get it from /pending due to some issue getting it into /contrib.

To setup /pending as a publisher, you do much the same as you do for /contrib:

pfexec pkg set-publisher -O http://jucr.opensolaris.org/pending  pending

Or use the package manager File -> Manage Repositories menu.

To list the repositories that pkg knows about, run:

% pkg publisher 
PUBLISHER                             TYPE     STATUS   URI
opensolaris.org          (preferred)  origin   online   http://pkg.opensolaris.org/
contrib                               origin   online   http://pkg.opensolaris.org/contrib/
pending                               origin   online   http://jucr.opensolaris.org/pending/
mypkgs                                origin   online   http://localhost:80/
webstack                              origin   online   http://pkg.opensolaris.org/webstack/

If you have both /contrib and /pending added as publishers, when you install packages you'll need to qualify the package name with the name of the publisher from which you want to install it as follows:

pfexec pkg install pkg://pending/ruby-mysql

Which will install the 'ruby-mysql' package from the publisher name pending. Note that this is the publisher name, not the URI of the repository.

In the list of repositories above are a couple of other repositories that we've not talked about. The /webstack repository has packages that the WebStack team feel might be useful, but for which they are unable to offer support. This has packages for Web Tier applications such as Varnish and Nginx. We also sometime publish packages that are in the process of being integrated into OpenSolaris but are not yet available in the main repositories. The mypkgs repository is a repository local to our test system. It is very easy to set up a build environment for building your own packages from Spec files and then to publish them to a local repository. If you're going to do that though, you might as well publish them to /contrib via SourceJuicer.

Here's some other links that you might find useful:

Spec Files Extra is a project centered around the pkgbuild tool that builds Solaris SVR4 and/or IPS packages from spec files (and which is used by SourceJuicer)

The Genunix site has a page describing how to setup a SourceJuicer like environment

If you'd rather not get involved in submitting spec files to SourceJuicer but would like to see a package in OpenSolaris, drop us an email at sw-porters-discuss@opensolaris.org.

Ruby MySQL nearly in OpenSolaris

One of the big pain points when installing Native Ruby Gems is the need to have various build packages installed. Packages that deliver the likes of gcc, gmake and ginstall. You also need to know where the libraries and C header files that you want to build against are located. On OpenSolaris the last part should be a no-brainer at least with packages installed from the repository, but some packages such as MySQL don't install to /usr/lib and /usr/include and the mysql_config that the MySQL package ships is not on the default $PATH and even if it was, it emits Compiler and Linker information for Sun Studio, not for gcc.

What this means is that you have to install all of the tools above and then install the MySQL gem with options telling the build where to find the MySQL libs and the MySQL headers.

Making the MySQL gem available as an OpenSolaris package, means you don't have to worry about any of that. You just run:

pfexec pkg install ruby-mysql

and voila!, you have MySQL support in Ruby... But it doesn't work :o(

The ruby-mysql package was promoted to the /contrib repository this week. Unfortunately it was promoted before I had tested it fully (which shows we have some major holes in the processes used to get packages into /contrib). The version that's there currently is unusable as it causes a segmentation violation when running with Rails. If you want to use this package today then you can get it from the /pending repository. Details of how to make use of OpenSolaris repositories can be found on a separate blog entry here.

Wednesday Oct 28, 2009

Nagios, Octave and SilverStripe in OpenSolaris

Several interesting packages were published to the OpenSolaris /contrib repository yesterday. They include Octave, SilverStripe and the 3 packages that make up Nagios. 

Nagios is a leading Open Source infrastructure monitoring tool that can monitor networks, hosts and even services, in fact it can monitor pretty much anything and it being Open Source it's fairly straightforward to add your own plugins. The main Nagios package is simply named nagios and delivers version 3.0.6 currently. In addition there is the nagios-plugins package which you'll install on systems that you want to monitor. A third package is nrpe (Nagios Remote Plugin Executor), which allows a centralised deployment of Nagios to execute and monitor plugins on other systems.

Octave is a GNU project, it's a high level language and runtime whose main use is for numerical computations. It's mainly command line driven, but can hook up with the likes of gnuplot in order to present graphs and other visual forms of mathematical data. I've tested it and it looks like it could be really useful for someone say, studying for a maths degree... like me for instance :o)

SilverStripe is a popular Open Source Content Management System, it's one of a number of such applications that OpenSolaris users have been clamouring for. Interestingly we did have some problems getting it to play nicely with MySQL 5.1 on OpenSolaris. When you are setting up the MySQL database prior to configuring SilverStripe modify the MySQL SMF service as follows:

svccfg -s mysql:version_51 setprop mysql/enable_64bit=true
svcadm refresh mysql:version_51
svcadm restart mysql:version_51

You'll either need to do this as root or as a user with the root role. These changes cause MySQL 5.1 to run in 64-bit mode.

You can install any of these packages either using the pkg command or via the package manager, you can even just go to the /contrib repository's catalog page and click on the 'install' link for the package(s) that you want to install.

To set up /contrib as a valid publisher for use with the package manager or the pkg command do the following as a user with the root role (or Software Installation profile):

pfexec pkg set-publisher -O http://pkg.opensolaris.org/contrib  contrib

Or you can add /contrib via the package manager through the File -> Manage Repositories pull down. If installing from the "install" link at http://pkg.opensolaris.org/contrib/en/catalog.shtml  the package manager will automatically add /contrib to the list of publishers.

To install packages using pkg, do the following:

pfexec pkg refresh
pfexec pkg install <package name>

These packages are great additions to the growing list of packages available via the /contrib repository. If you would like to contribute a package to /contrib visit the SourceJuicer page on OpenSolaris.org. If you'd rather not get involved in submitting spec files to SourceJuicer but would like to see a package in OpenSolaris, drop us an email at sw-porters-discuss@opensolaris.org.

Wednesday Oct 14, 2009

Rake should be on the default PATH...

I can convince myself of anything. When we updated from RubyGems 0.9.4 to 1.3.5 I decided that it was ok for the 'rake' command to be in the $GEM_HOME/bin which then translated to /var/ruby/1.8/gem_home/bin. I justified it because users could run 'gem env', look at the "EXECUTABLE DIRECTORY" and see that they had to add /var/ruby/1.8/gem_home/bin to their $PATH env var. Having had to install and then run rake several times on different systems over the last few days I can see that this is wrong. I want to 'gem install rake' and then run 'rake <some rake task>' without the need to update my PATH. I'm certain that others will agree that this is how it should be.

I could easily change the way that we build RubyGems such that the "EXECUTABLE DIRECTORY" defaults to /usr/bin but I have no way of being certain that when the end user runs 'gem install <some gem with an executable>' that /usr/bin will actually be writable even by root (or the root role as used by pfexec). We have the Rails package in the /contrib repository that also delivers the Rake gem. This package installs the 'rake' executable to /usr/bin, but it's a bit much to ask you to install Rails just to get Rake. I seem to have the following options:

  1. With the SUNWruby18 package on OpenSolaris, provide wrapper scripts in /usr/bin for the popular gems that deliver executables. These would emit a message saying to install the require Gem should it not already be installed and run as normal if it is. This has a few corner cases that have to be considered
  2. Provide a /contrib package that provides wrapper scripts for popular gems which would work as described in (1)
  3. Change "EXECUTABLE DIRECTORY" to /usr/bin and modify RubyGems to detect the writability of /usr/bin. It does this by default but would end up installing any affected gems in root's ~/.gem directory.

I favour option 3, but only if it can be done without significant changes to RubyGems.


Friday Sep 25, 2009

Rails: Setting selected options in a ListBox

 
  

I really struggled with this yesterday. I'm writing a Rails CRUD app and when creating a new entry one of the fields presented is a ListBox that allows multiple selections. That was straightforward, but i had problems when editing an existing entry. What didn't want to work for me are the recognised methods for having the current items for the entry being edited be selected in the ListBox.

The way that I understand that it should work is like this:

collection_select(:user, :group_ids, Group.find(:all), :id, :name,{},{:multiple=>,:name=>'user[group_ids][]'})

But needless to say it didn't. In the end I found this from Wes Gamble (weyus on Ruby Forum). It's a bit more DIY but it works a treat. I'm reproducing it here in case it's useful to anyone else (thanks Wes!)

<select id="user_roles" name="roles[]" multiple="multiple">
<% Role.find(:all).each do |r| %>
     <option value="<%= r.id %>" <%= @user.roles.include?(r) ? 
"selected=\\"selected\\"" : '' %>"><%= r.name %></option>
<% end %>
</select>

Other packages in /contrib

Just following on from my last post, we've also added FreeImage to the OpenSolaris /contrib repository. This is pretty useful as FreeImage is used by the image_science ruby gem for manipulating images, particularly creating Thumbnails from uploaded images. FreeImage can be difficult to build on OpenSolaris and the 'freeimage' OpenSolaris package is fully built and includes both a static library and a shared library that can be used to build against when developing applications. You can install this package with the following commands (the first isn't needed if you've already added /contrib as a publisher) :

% pfexec pkg set-publisher -O http://pkg.opensolaris.org/contrib  contrib

% pfexec pkg refresh

% pfexec pkg install freeimage

If you then install the image_science gem (along with the RubyInline gem that is used to dynamically build the image_science native library) you won't need to provide additional flags in order to locate the FreeImage library.

FreeImage and ImageScience are used in the Apache Olio Rails applications

Our group also recently integrated WordPress into /contrib (as 'wordpress'). Installing this package will pull in all of the Apache and PHP packages required to run WordPress. It leaves the DB to you as you might chose to run MySQL locally or on a completely different system. It actually really makes installing WordPress and getting up and running really easy. We are also working on adding Drupal, Moveable Type, Joomla!, SilverStripe, Cacti, Ganglia, Nagios, the GNU Linear Programming Kit and Octave.


Rails 2.3.3 in OpenSolaris /contrib repo

A while back an OpenSolaris repository called /contrib was introduced to basically allow anyone with an account on opensolaris.org to submit Open Source applications/libraries to an OpenSolaris repo. The details of how to go about doing this are best saved for another blog entry (add to ToDo list). This new repository gave us a real opportunity to package up Ruby on Rails and make it available to OpenSolaris users in the package format that they are familiar with. We'd avoided the main /release and /dev repositories because Rails rev'd too frequently for us to be able to keep up with the changes given that the processes for getting into those repositories are fairly lengthy. Besides there was always the 'gem install' command.

So we've now added Ruby on Rails 2.3.3 and it's dependent Gems to the /contrib repository. Since then Rails 2.3.4 has been released, more on that later.

To install the rails package on a system with OpenSolaris 2009.06 or later you need to run the following commands:

% pfexec pkg set-publisher -O http://pkg.opensolaris.org/contrib  contrib

% pfexec pkg refresh

% pfexec pkg install ruby-rails

% pfexec gem install rack

The first command gives you access to the /contrib repository and all of the packages that it contains and is worth doing anyway as there's lots of great packages there besides Ruby on Rails. It's a one off command, once you've added /contrib it will remain in your list of package publishers. The second command isn't strictly necessary the first time, but it's useful to remember as /contrib updates on a weekly basis and your local cache of package names and versions doesn't refresh automatically.

The next command installs the 'ruby-rails' package and if it's not already installed, installs the SUNWruby18 package which contains Ruby 1.8.7 and RubyGems 1.3.1 (versions correct at the time of writing). The last command installs rack, which is now required by Rails, something we didn't find out until the last moment we moved to Rails 2.3.3. We are looking to package rack and add it as a dependency to the ruby-rails package. The ruby-rails package installs to what is effectively the vendor gem location in /usr and the rails and rake executables install to /usr/bin (as symbolic links). You can still use the gem command to install Ruby on Rails versions later than 2.3.3 if you need to and the /usr/bin/rails command will pick up the later Rails version.

At the moment the benefits of using 'pkg' to install Rails over using 'gem' are mainly just the convenience of having dependencies pulled in automatically and having the 'rails' command on the PATH. In the future, we'll add native gems that are used to provide infrastructure to Ruby on Rails, gems that usually require a compiler to build, along with knowledge of the location of any dependent libraries. Ultimately we'll be able to provide a single package that installs a complete, optimised, Ruby on Rails infrastructure.


About

Bloggity, blog

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today