General Questions About RIB

This section seeks to answer some of the basic questions regarding RIB.

What does RIB stand for?

RIB is short for Repository in a Box.

What kind of built-in security is there for repositories built with RIB?

Currently, RIB provides simple username/pwd pairs for access to the administrative interface. Additional security features (eg., Kerberos authentication) are being reviewed.

What if I don't want to use the BIDM, can I use another data model?

Yes. However, on the initial repository set-up screen, only the BIDM or its extensions are allowed. You can use your own model but you will need to do one of two things: replace the contents of the confg.xml file (once you have created your repository) with an object oriented model that follows the syntax currently used by RIB, OR use the Data Model Editor in the RIB Admin interface (once you have created your repository) to make the desired changes.

What does RIB give me that I can't get by creating my own db application using something like Microsoft Access?

1) RIB is open source and works on multiple platforms.
2) RIB requires little to no understanding of how a database works.
3) RIB uses a Java interface accessed through a browser, which allows remote operation and easy access to enter, edit, and delete data.
4) RIB creates a WWW accessible, fully functional catalog complete with a search mechanism.
5) Repositories created with RIB can share information easily.
6) RIB is designed to create a single virtual repository containing objects managed remotely from multiple repositories by different administrators.

How do I copy/paste in the administration applet?

To be able to copy and paste data from outside of the applet you need to grant permissions to the java applet.

To set permissions, you need to edit the java.policy file. You can find the java.policy at: lib\security\java.policy

The actual location of java.policy depends on your operating system. Below are example locations on Linux and Windows:

Linux: /usr/local/java1.4/jre/lib/security/java.policy

Windows: C:\\Program Files\Javaj2re1.4.1_03\lib\security\java.policy

You may have multiple JRE's installed, make sure all your changes are made to the JRE your web brower is using.

Edit java.policy so it contains the following: [replace your.rib.server.hostname with your actual name]

grant codeBase "http://your.rib.server.hostname/java/-" { permission java.security.AllPermission; };

Do I have to use the Apache, Perl and MySQL that are included in the RIB installation or may I install them by myself?

These are only included if using v2.x. In which case RIB is designed to do the installation and configuration of Apache, Perl and MySQL itself using the copies shipped with RIB. However you can use versions of these applications already installed or install them yourself. It is recommended that you are familiar with the setup and configuration of Apache/Perl/MySQL before trying to do this. The configurations needed for each application to run RIB can be found from reading the install.sh script.

What applications are bundled with RIB version 2.2?

RIB version 2.2 includes;

When using this version you should check the vendors web site for any known security issues.

What applications are bundled with RIB version 2.1?

RIB version 2.1 includes;

When using this version you should check the vendors web site for any known security issues.

Questions About Interoperation

Here are some questions and answers specific to the interoperation of RIB repositories.

Do I have to use the interoperation feature?

No. RIB functions quite well as a standalone metadata cataloging tool.

What if I want to interoperate with another repository but our domain hierachies don't exactly match?

During interoperation, RIB checks domain hierarchies for the repositories being interoperated and looks for matches. If a match is not found, RIB ignores the domains of the repository being interoperated with and simply lists that repository's assets. Example; repository 1 has a single top-level domain called Debuggers with multiple assets (debugger software applications). Repository 2 has a single top-level domain called Utilities containing two utililty applications; foo and foobar. If repository 1 initializes an interoperation with repository 2, the catalog entry that will be created for repository 1 will appear as below:


Because the domain called Utilities was not in the data model of repository 1, repository 1 ignores that domain name and concatenates the assets (by name) of Utilities (from repository 2) in the web catalog for repository 1.

What is the difference between interoperating with and importing objects?

During interoperation, changes made to a repository propagate to repositories that initialized the interoperatoin. In other words, if repository1 establishes an interoperation with repository2, changes made to repository2 will reflect in the catalog of repository1. If objects are imported, the repository initializing the import just gets a static picture of the repository it imported from and changes made over time will not appear unless another import is manually performed.