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.



        
    

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 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

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.


Wednesday Mar 25, 2009

Ruby 1.8.7 and RubyGems 1.3.1 on OpenSolaris

Last week, all of the work that Chris Zhu, Prashant Srinivasan and I did on integrating Ruby 1.8.7 p72 and RubyGems 1.3.1 into OpenSolaris bore fruit as the packages became available in the /dev repository of OpenSolaris.

You can still use Ruby 1.8.6 as that's the version that was in the 2008.11 release of OpenSolaris, these packages won't get promoted to the main repository until the next release of OpenSolaris in May/June. 

In order to upgrade to Ruby 1.8.7 in OpenSolaris in the meantime you need to upgrade all of the packages so that they are at the same level. Once you have upgraded you'll no longer have Ruby 1.8.6 available to you, so make sure that's really what you want to do. Prashant wrote a brief guide on how to update Ruby in OpenSolaris a while back and you can find that here.

We'd be happy to receive any feedback on your experiences in upgrading and your thoughts on what you really would like to see for Ruby and RubyGems in OpenSolaris. As Ruby/RubyGems is part of Sun WebStack you can ask questions and post comments on the webstack-discuss@opensolaris.org  alias (you need to subscribe first at http://opensolaris.org) or you can post a comment on either of our blogs.

Monday Mar 23, 2009

Building eventmachine on OpenSolaris and Solaris Nevada

If you are installing the eventmachine Ruby Gem on OpenSolaris (which you do whenever you install Thin). Make sure that you use GNU 'make' and not Solaris 'make' otherwise the installation will fail. You can do this by making sure that you have the SUNWgmake package installed and that /usr/gnu/bin is in your PATH and is before /usr/bin and/or /usr/ccs/bin

GNU 'make' implicitly sets the CXX variable used in the eventmachine Makefile to 'g++' and as g++ is in /usr/bin (assuming you have the SUNWgcc package installed)  you don't have to set it yourself. eventmachine will build with the Solaris version of 'make' but you would need to set CXX manually before installing the gem, i.e.:

CXX=/usr/sfw/bin/g++ gem install eventmachine

On Solaris Nevada Distributions (SXCE) GNU make is only available as 'gmake' and so by default eventmachine will use /usr/bin/make which is the Solaris make. In that case you need to set CXX as described above.

Remember: four is the number of Make commands available on OpenSolaris and the number of Make commands available on OpenSolaris is four, no more no less.


Monday Feb 16, 2009

Thin on OpenSolaris

Since the start of the year we've been testing with the Apache Olio Rails application on OpenSolaris. Early on we found that when using Thin as our Rails runtime, every now and then a Thin instance would abort and core dump after an assertion failure in EventMachine. This really only happened under high loads and was hard to recreate. The problem is detailed here: https://issues.apache.org/jira/browse/OLIO-38

We talked to the EventMachine folks on the eventmachine-talk alias and after a couple of days they were able to come up with a fix that we then tested at length. The fix is now available in EventMachine 0.12.4 . The support that they gave us was really fantastic and helped us resolve a problem that really threatened to hold up our project. Thanks particularly to Aman Gupta.

So if you are using or planning on using Thin and EventMachine on OpenSolaris, EventMachine 0.12.4 is the way to go.

Friday Oct 10, 2008

Alfresco on Glassfish (short version)

I posted a complete walkthrough on how to get Alfresco up and running on Glassfish earlier . Here's a version for those who don't need all the detail.

Glassfish has an undocumented property that when used in conjunction with the Classloader Delegate feature will allow MyFaces libraries to be loaded before the JSF libraries. You set both of these in the server specific deployment descriptor which is named sun-web.xml and which lives in the WEB-INF directory of the War file. The complete file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 8.1 Servlet 2.4//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_4-1.dtd">
<sun-web-app>
 <class-loader delegate="false"/>
 <property name="useMyFaces" value="true"/>
</sun-web-app> 

So create the file, place it in a directory named WEB-INF and then add it to the alfresco.war file:

$ jar uvf alfresco.war WEB-INF/sun-web.xml
adding: WEB-INF/sun-web.xml(in = 316) (out= 236)(deflated 25%)

Then deploy the alfresco.war file. If you've done everything else that's needed, you should be able to fire up a browser and connect to Alfresco at http://localhost:8080/afresco

Alfresco on Glassfish

I recently posted an updated version of this walkthrough that covers Alfresco 3.2r2.

This walkthrough is for OpenSolaris, it was made on the b98 development build but I'd expect it to work on the release version of 2008.05. It probably works on all other platforms as well with some changes to the pathnames and some of the commands. I'll work on something similar for Solaris, Ubuntu and for Windows.

I've posted a shorter version for those who have previously tried to get it working but were just missing the vital ingredient.

Initial Setup

I'm going to assume you are doing this as a non-root user. If you do this as root, just drop the pfexec statement from any commands you issue.

First install Glassfish and MySQL:

$ pfexec pkg refresh 
$ pfexec pkg install glassfishv2 
$ pfexec pkg install SUNWmysql5

Unlike with the best tutorials, I won't first remind you to turn your system on or not to install the packages if they are already installed.

OpenSolaris has this nifty feature called SMF but we haven't yet managed to hook the installation of packages up such that Services are automatically registered with it yet although that should be there in the November release. For now run the following to register it:

$ pfexec svccfg import /var/svc/manifest/application/database/mysql.xml

and then start the MySQL service:

$ pfexec svcadm enable mysql

This will do all of the work required to get MySQL up and running for the first time. Now create a DB and a user to access it with.

$ /usr/mysql/50/bin/mysqladmin -u root create alfresco
$ /usr/mysql/50/bin/mysql -u root
mysql> grant all privileges on alfresco.\* to 'alfresco'@'%' identified by 'alfresco';
Query OK, 0 rows modified (0.00sec) 
mysql> grant all privileges on alfresco.\* to 'alfresco'@'localhost' identified by 'alfresco';
Query OK, 0 rows modified (0.00sec) 

Now setup a Glassfish domain:

$ pfexec /usr/sbin/asadmin create-domain --adminport 4848 domain1

You need a JDBC MySQL driver:

$ wget http://mysql.osuosl.org/Downloads/Connector-J/mysql-connector-java-5.1.6.tar.gz

The URL used for the MySQL JDBC driver is just one of many mirrors. You might be better off going to http://dev.mysql.com/downloads/connector/j/5.1.html and choosing where to get it from.

Unpack this somewhere and copy mysql-connector-java-5.1.6-bin.jar to the Glassfish domain's lib directory:

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

While you are doing this you may as well create an alfresco directory in the same place, you'll need it later.

$ pfexec mkdir /var/appserver/domains/domain1/lib/classes/alfresco

Alfresco War file and configuration

This testing was done with Alfresco labs 3b, it should work with other versions, but if it doesn't post a comment on this blog and I'll look into it.

Next we'll need the Alfresco War file, which you can probably get like this:

$ wget http://us.dl.alfresco.com/build-1164/alfresco-labs-war-3b.tar.gz

But as that looks like a URI than might have been created by SkyNet a machine, you may need to fallback to going here:

http://wiki.alfresco.com/wiki/Installing_Labs_3#Linux_download_and_installation

Once you have it, extract the bundle somewhere, you won't need it after the setup is finished.

You now need to setup the Alfresco bits that aren't contained in the WAR file. From the directory in which you unpacked the Alfresco bundle, copy the entire contents of the extensions directory to the directory you created earlier:
$ pfexec cp -r extensions/\* /var/appserver/domains/domain1/lib/classes/alfresco

You don't want to copy over the extensions directory itself, just it's contents (extension and messages directories).

Alfresco needs somewhere to keep all of it's documents and indexes. This is usually named alf_data, if you don't specify a path to alf_data or the path doesn't exist it will create one for you... somewhere. Let's not leave things to chance and create one and then configure Alfresco to find it:

$ pfexec mkdir /var/alfresco/alf_data

Now cd to /var/appserver/domains/domain1/lib/classes/alfresco/extension and modify the config files so that Alfresco can find alf_data and can find the database. The files that need changing are:

custom-repository.properties 
custom-hibernate-dialog.properties

In custom-repository.properties do the following:

Uncomment the dir.root line and change it's path to /var/alfresco/alf_data

#dir.root=/srv/alfresco/alf_data

becomes:

dir.root=/var/alfresco/alf_data

Uncomment the db.username and db.password lines

#db.username=alfresco
#db.password=alfresco 

becomes:

db.username=alfresco
db.password=alfresco 

The last part of the file has sections for specific databases, by default it's setup to use Derby. Comment out the lines for derby and uncomment the lines for MySQL

db.driver=org.apache.derby.jdbc.EmbeddedDriver
db.url=jdbc:derby:data/derby_data/alfrescocreate=true
...
...
#db.driver=org.gjt.mm.mysql.Driver
#db.url=jdbc:mysql://localhost/alfresco

becomes

#db.driver=org.apache.derby.jdbc.EmbeddedDriver
#db.url=jdbc:derby:data/derby_data/alfrescocreate=true
...
...
db.driver=org.gjt.mm.mysql.Driver
db.url=jdbc:mysql://localhost/alfresco

In custom-hibernate-dialog.properties, comment out the line for Derby and uncomment the line for MySQL

The Glassfish specific deployment descriptor

Now for the fun bit. Go to the directory in which you unpacked the Alfresco bundle, create a directory called WEB-INF and in that create a file called sun-web.xml with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 8.1 Servlet 2.4//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_4-1.dtd">
<sun-web-app>
 <class-loader delegate="false"/>
 <property name="useMyFaces" value="true"/>
</sun-web-app> 

and then add that file to the alfresco.war file:

$ jar uvf alfresco.war WEB-INF/sun-web.xml
adding: WEB-INF/sun-web.xml(in = 316) (out= 236)(deflated 25%)

You're now ready to start Glassfish and deploy alfresco.war to the Glassfish domain:

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

Now you should be able to fire up a browser and connect to Alfresco at http://localhost:8080/afresco

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. I'll post this on the Alfresco forums once I'm happy that nothing silly creeped in. Hopefully we can extend this to cover different setups and configurations.

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/extensions. Check that you've used the correct path and that the changes that you made to custom-repository.properties and custom-hibernate-dialog.properties are correct.

Remember to stop and start MySQL (if you need to) using svcadm.

The sun-web.xml file has along line in it, if you cut and paste make sure that it doesn't get split across multiple lines.

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


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