Skip to content

Please note - the details in this post no longer work. I am leaving the post, though, partly to see if I can come back to it at some stage or to encourage others to try this. It would be great to have Omeka running in an even more really lightweight, slimmed down mode.


Omeka is interesting digital archiving software in that it combines the storage requirement with interpretive and presentational capabilities.  This can be a two-edged sword, but for some requirements, Omeka is attractive. Omeka is also Free Software and is published under the General Public Licence. It is much simpler to install than, say, DSpace, in that it is written in PHP, which most servers support easily and which is well understood for ease of use.  And I would suggest that simplicity is of real value when running long-living archives. Omeka is a good example, along with WordPress. of such an application, often running on a "LAMP" software stack - Linux, Apache web server, MySQL database and PHP.

One of the beauties of Free Software is that it is often possible to alter software specifics, as the same service is provided by other software.   This is important, because it means, for example, that a very busy web site can use better performing software to the same end, or, as may be the case for community archives, a lower specification machine or virtual machine may use software that performs adequately with fewer resources.  One example of this is to replace the Apache2 web server with a more nimble alternative, such as Nginx or Lighttpd.  So the "LAMP" stack becomes "LLMP" or "LNMP". The use case of Omeka running on a little Raspberry Pi springs to mind, and that may be worth an article here later.

But in fact, the way Omeka is written, in actually requires the LAMP stack, which is unusual for a PHP application. The reason for this is that it includes a file called .htaccess. a facility that the Apache2 web server uses to instruct the server to behave in particular ways, and which, in Omeka's case, makes the server rewrite some parts of the web address, the URL.  The upshot is that, although there is no technical reason for requiring Apache as the web server, the fact is that it is written with that requirement.

It should be possible to apply Omeka's .htaccess file to Lighttpd's configuration file. But web references to this don't have anything definitive.  Now I must point out that I have not run this on a fully operational live server, but the following configuration does work with Omeka, so ensure to your own satisfaction that this works for you. Add this to your lighttpd.conf file.

############Omeka####
## At last - this works -
##info from https://www.drupal.org/node/43782
##and other sources
url.rewrite-once = (
##admin pages
  "^/omeka/admin([^.?]*)\?(.*)$" => "/omeka/admin/index.php?q=$1&2",
  "^/omeka/admin([^.?]*)$" => "/omeka/admin/index.php?q=$1",
##Main pages
  "^/omeka/([^.?]*)\?(.*)$" => "/omeka/index.php?q=$1&$2",
  "^/omeka/([^.?]*)$" => "/omeka/index.php?q=$1",
)
# Ensure ini files are excluded, Change the "static-file.exclude-extensions"
# higher up this config file, to look like this
##static-file.exclude-extensions = ( ".php", ".pl", ".fcgi", ".ini", ".htaccess" )
### End of Omeka section

I am not a Lighttpd or Omeka expert, but I thought I would post this here in the hope that this helps others who may wish to run Omeka in this way.

Addendum - I see Omeka has retweeted my tweet about this article. If you can improve this config, please email me so that we get some info on how to run Omeka under Lighttpd (or Nginx, for that matter) accessible.

One of the constant themes you will find on this web site is the concept of taking a long view regarding running a digital archive.  This truism is sometimes in conflict with the world in which it operates, the technological and digital world, which is driven by constant expectations of "upgrades", "features", "faster" and other implications of improvement.  In the consumer digital world, we are used to the short life spans of technology, but in the world of systems providing particular services, such as a community archive, change for the sake of change is not always welcome.

But we must live in the real world, and the reality is that, after a while, the developers no longer wish to support older systems.  This is fully understandable; if you have spent time improving your software and solving bugs, you don't want to have to deal with those bugs in older versions when you have already fixed them in newer versions.  The Free Software world does give you the option of providing your own support, so you are not bound by the services your supplier wishes to offer.  But sooner or later, part of the longevity equation means keeping reasonably up to date.

In the case of the Assynt Community Digital Archive, we received an email at the beginning of 2014 pointing out that the version of DSpace that we were running was considered to be at the end of its life, and it was recommended that we upgrade.    We chose not to do that at the time for a variety of reasons, but summer is a good time to work on the systems, as in communities like ours, a lot of voluntary effort happens in the slower-paced winter months.

One of the beauties of the way in which the Assynt Archive is implemented is that it uses the concept of virtualisation.  This type of technology, and the reasons for t suiting a community project so well, are explained elsewhere on this website.  Virtualisation allows one to run an entire system independently of the physical hardware that underlies it.  In the case of doing an upgrade, this means that it was possible to take a copy of the entire virtual machine, and work on that, such that the live Archive was not in any way at risk as part of the process.  It also means that, as you go through a complex update procedure, you can take "snapshots" along the way, so that any oopsies do not mean hours of wasted effort.

An update to something like DSpace is not always easy for lay people to understand,  Updating systems software such as DSpace is not like updating productivity software on a laptop or desktop, where it;s a case of inserting a CD or downloading a zip file, and clicking "Setup.exe" or an "Installer" icon.  DSpace needs a runtime framework and a build framework which consists of the Java runtime system and various other components.  In addition, it needs am industrial-strength database.  So it is the type of process that only suitably skilled people should undertake.

Another early design decision was to do the least amount of customisation possible, ideally restricting the customisation to a logo and naming.  This pays dividends when it comes to upgrading.  It means simply following the processes outlined for the upgrade: download and unpack the new version, build it using the supplied tools, make the required changes to the database, deploy the new system and start it all up.  The bits of customisation., if they are restricted to the minimum, need not affect that ideal process too much.

In our case, though, we needed to go through upgrades from version 1.7.2 to version 4.1.  As this is not advisable in one step, it meant carrying out the upgrade process from version 1.7.2 to version 1.8, then 1.8 to 3.0. then 3.0 to 4.1.  At each step, it is necessary to carry out a battery of tests to ensure that each step is working.  The skills involved are a mixture of Linux/Unix skills, some Java development skills, PostgreSQL database skills and some experience as to how these types of things work.  Verison 4.1 also required updates to the deployment system, tomcat, as well as the build mechanism, maven, and ideally to the database, PostgreSQL.  This meant that one step was also to upgrade the operating system running the virtual machine from Debian 6 "squeeze", to Debian 7, "wheezy".  Fortunately, this is a well documented and bullet-proof procedure.   But with all that work, we are now.... I nearly said "future-proof," but maybe immediate-furture-proof would be more accurate - until the end of 2016 or maybe 2017 anyway, when we expect the next steps to be very similar to these.

The virtual machine can then be transferred back to the live Archive, and it will magically be running the new version.

The Assynt Field Club, as reported here, set up a project to begin the process of archiving digitally a huge set of physical collections of sighting records and other information they have accumulated over many years.  Key to these collections is the work of two local residents, Pat and Ian Evans.  Through the North Highland Initiative, funds were made available to employ an archivist to carry out a pilot project.  The pilot seeks to establish whether the Assynt Community Digital Archive is a suitable an practical repository for digitised information of this kind, and whether the collections are amenable to such processing.

Avril Haines was appointed as the Archivist.  Her first responsibilities were working with Pat and Ian Evans, as well as the Filed Club chairman, Andy Summers, to work out what part of the collection to use for the pilot.  It had to be manageable but also representative section of the whole.  The reptile collection was chosen as well as the material and a full copy of Pat and Ian's unique book, Flora of Assynt.

This project is now coming to an end.  To date, Avril has added about 400 records to the Assynt Community Digital Archive.  The quality of the metadata and the consistency of recording are especially noteworthy regarding this project.  Avril has also used the project to demonstrate to other groups in the area the value of the Archive as a ready-made legacy for their work, in the present as well as older material.

On Friday 9th May 2014, the Field Club had an Open Day to demonstrate to members and others in the community the work that this pilot has achieved.  Refreshments were provided by the newly re-opened Mission Café.

DSC_4111 Field Club Open Dat

The funders for this project were represented by Eilidh Todd.  Eilidh has been especially helpful in easing the administrative burden of such a project, which relies otherwise on voluntary commitments.   While Avril was the Archivist, the project relied on others, including Eilidh, Andy Summers, and, of course, Pat ad Ian Evans.

Avril will now complete the project, including writing a report to examine the project, document any specific learnings and use it to inform the development of  future such archival projects.  From the point of view of the Assynt Community Digital Archive, this has been a wonderful project, professionally completed, and further demonstrates the way in which community archives can drive direct as well as more oblique value in a community.

Contact Stevan for more information.

If you have read something of the history of the Assynt Community Digital Archive on this site or elsewhere, you will know that the Archive was set up as part of the project that brought the old Fishermen's Mission building into community ownership as a bunkhouse and café in 2009, opening in 2011.  The Assynt Community Association, a long-standing umbrella body for various Assynt initiatives, took the lead in this, and the building is owned by that charity.  The Archive was given its own Archive Room upstairs in the Mission building, appropriately wired and equipped for its purpose.  A trading company was formed to run the café and bunkhouse, but late in 2013, the trading company ceased to trade.  It has now been wound up.

Now one of the issues that concerned us when the Archive was set up was to ensure that there was a complete legal separation between the trading entity and the long-term initiative which is the Archive, which was seen to be a possible issue as they both occupied the same building.  Further, the temptation must exist to see the Archive as a short term exploitable asset rather than the long term proposition with societal rather than purely economic value.  So effort went into ensuring a separation both legally and practically between the two.  This separation was sometime over-effective, with a perception developing that the trading company staff were not allowed to direct visitors to the Archive, though improved communication helped that issue.

When the trading company ceased to trade, the bills that were paid to keep the heat and power and connections on also stopped, causing the Archive some short term problems.  However, these were overcome over the winter, and now the Community Association is taking a different view on how to gain community value from the asset which is the building.  One of the effects of this was the possibility that the Archive may be required to move.  This is technically possible, and indeed, the initial design foresaw this eventuality, but of course, the question was where it could conceivably go.  Other building in Assynt were not suitable.  The upshot was that the Archive was asked to move from one location in the Mission building to another, which would easily have been possible.

But eventually the plans have worked out that there would no longer be a requirement to move, and a new trading company has been formed which will follow a slightly different business model.  We wish Assynt Community (Trading) Ltd all the very best for a long and fulfilling existence and we look forward to working with the trading company in future, though, of course, remaining separate.

The point of this is that it is very important to get the legal framework right when setting up a community archive.  It could easily have happened that the Archive may have had a legal connection to a trading company, exposing the archive to the vagaries of the market and the risks of commerce.

A group of folk from a number of museums and cultural  collections in the Highlands gathered at Ironworks in Inverness on Monday 10th March 2014.  Folk from Inverclyde. Aberdeen, Gairloch, Applecross, Skye and Ullapool were there, keen to see how to improve communication with their audiences using digital options.  The workshop was arranged by AmbITion Scotland and presented by Diane Greig and Deborah Hair.

Workshop particpants
Workshop particpants

The workshop provided insights into aspects of marketing principles required to develop a coherent approach to communicating with different groups who may have, or should have, an interest in the museums and collections represented. It was important to have a measurement of success to determine how best to communicate, and one method was not sufficient.

Almost al participants had stories of how it was often quite difficult to communicate consistently with those nearest their projects, as well as those in the broader sphere.  It was at times difficult to create a connection between commercial approaches to communication and the realities of life in very small, rural communities, but there is no doubt that a better-understood, orderly method of communicating holds real benefits.

It was also very good to be able to meet other folk engaged in similar tasks.  The sense of being engaged in the cultural and heritage sectors for a greater good was a welcome one, and finding others with shared highs and lows was great. Face to face communication to learn about digital communication?  Yes, ideal.

tsheaderl.jpgTinSlave-093131-12032014

Thanks to Diane and Deborah and all from Ambition Scotland for a helpful day.