RODA

RODA plans to support LTS releases of Ubuntu, the next one will be Lucid Lynx. The requirements of RODA are quite flexible, but the automatic installation and configuration of them isn't. Nevertheless, we are always available to help the installing on other systems, and document it here.

About accessibility, there are plans to use ARIA (http://www.w3.org/TR/wai-aria/) to add accessibility to RODA Web User Interface, as it is supported by the technology used to create it (Google Web Toolkit). Unfortunately, I can't give you a time frame of when it would be available.

It is possible to use an existing installation of Fedora, but it would be tricky and 'foreign objects' would be ignored. Integration of Fedora with the LDAP server would have to be done, and also it would need some changes on the Fedora's configuration. Furthermore, RODA uses a very specific data-model, using Fedora objects and relations, so the objects already inside fedora would need to follow this data model to be recognizable.

Thanks for the answers. I think that initially my institution will keep the archive 'dark', so accessibility is less of an issue just now. It is good to know that you're thinking about it for the future. Do you foresee releasing an new version of RODA, once Lucid Lynx comes out?

I found a couple of things which didn't work when I tried installing RODA without the installer script. One was the maximum number of files that could be open by one application. JBoss has 1600+ files open, and on Arch Linux, at least, the default was set to 1024. I noticed this also on the VM version of RODA. Adding the following to /etc/security/limits.conf solved the problem:

* soft nofile 2048
* hard nofile 2048

Also, when loading the SQL schema into MySQL, I got errors to do with the maximum size of a key (1K) being exceeded. The offending columns used in keys were declared as VARCHAR(500). This is OK if the default is for the tables to use latin1 for encoding. But if the default is UTF8, then the columns must be declared VARCHAR(500) CHARACTER SET latin1, otherwise their size in bytes is 1.5K, even if their size in characters is still 500.

Have you had any reports of people using Postgres instead of MySQL?

Having gone through the installation procedure, I saw that Tomcat isn't needed, if you use JBoss instead. JBoss was needed in order to run PhpMyAdmin. But is it possible to use a regular installation of Apache and PHP (maybe on a different machine), rather than getting the php5servlet to work? The VM version of RODA seems to work fine without PHP working in JBoss. Is PhpMyAdmin only needed as a graphical tool for administering MySQL, or does RODA use it behind the scenes?

Has anyone had an experience of making RODA work with an institutional LDAP server? When I've worked on other web applications which used LDAP, they didn't need the admin's DN and password in order to authenticate users. Can RODA cope without having these, if it is only authenticating users (read only access)?

A new version of the installer is scheduled to be released when Lucid Lynx is considered stable.

There are some known problems, like file limits, there were not well documented, thank you for creating the issues, I'll add them to the documentation next time I revise it.

RODA wasn't tested with other DBMS, and some code would need to be changed, but I think all code is in one class, so adding support wouldn't be so difficult.

Tomcat is just there to show how to run RODA in tomcat, but JBoss is used by default. But if you use tomcat you wouldn't be able to use the php5servlet. The php5servlet is used by the database previewer, and must be inside JBoss so the session credentials are sent to service. The database previewer wraps a version of PhpMyAdmin optimized for readonly mode.

You only need the LDAP admin DN for administering LDAP: create and delete users and groups. If you use institutional LDAP server and you don't want to share the admin DN you won't be able use the RODA's user administration features.

Again, thanks for answering all my questions. Sorry to come back with more. You said that RODA wouldn't necessarily recognise objects in Fedora that had been ingested by other front-ends. One advantage of using Fedora is that several Fedora archives can be integrated, for searching, presumably. Would ROAD's very specific data-model have any effect on this, do you think?

I'm not sure how much difference there is between Fedora 2.2.4 (version currently used by RODA), and 3.3, which is the most recent release. Is RODA tied to particular versions of Fedora, or would there only be problems if Fedora changed its APIs?

It might be too early to ask this, but have you thought about what would be involved in an upgrade of RODA? If I had an instance running with lots of objects ingested, would it mainly be the usual issue of migrating from one database version to another (like moving from MySQL 4 to MySQL 5), if I was to upgrade to a future version of RODA? Or would it be better to create a new RODA instance, and somehow import the old objects into the new instance?

RODA uses the content model to distinguish between its objects and foreign ones. It uses the "roda" prefix to identify content model pertaining to the RODA system, so it should be no problem adding object of other systems. Also, relationships used in RODA also always use the "roda" prefix, so it would be no problem adding relationships from other systems.

The API from Fedora 2.2.4 change a bit, and moreover some of the data model also changed. But RODA design was almost the same as the design afterwards for Fedora 3.0, for example, disseminators are defined for content model, and not related to objects (as done in Fedora 2.2.4 and changed in 3.0). Nevertheless, a lot of work was done in RODA to workarround some Fedora bugs, that now should have cease to exist. But all the code that connects to Fedora is very well contained in some packages, so it should be easy to identify the code that must be updated.

About system update or migration (as in moving from one system to another), a lot of thought was given to it from the very beginning, as it is one of the requisites for being a trustworthy repository and compliant with TRAC (http://www.crl.edu/archiving-preservation/digital-archives/metrics-assessing-and-certifying). The RODA data model is very stable but also flexible, and also all components use web services, so updating to a newer RODA version would be quite easy. Creating a new RODA instance (or any other repository system) and importing the old objects would mean that they would need to be re-ingested and that would have to be registered in the preservation metadata. Both ways are valid and have different purposes and effort. I would say that you would not want to import all objects because you want to be sure not to lose data or to have a clean system update, the system is created to be continuously updated and you would only want to do a system migration on a very different version or system.