Document id


Content and structure of \greed databases


Matevz Tadel


Start date: 8.5.2008

Document status

Half-cooked, quarter-written. Need feedback.

Main emphasis, so far, is on:


Databases are needed to store \greed state and history.

They are accessed by:

In the following, let us assume that there is a single \greed, with a single set of databases. These databases could actually be distributed in a hierarchical or cloud-like manner, but this should mainly concern internals of the system and not the actual data content, structure and mechanics of change.

User / identity database

\greed-user is a person that participates in the activities of \greedhome or \greedworld. Different avatars that a user can have in \greedworld are not an issue at this point, although the following discussion has some impact on this topic as well. Here we primariliy try to detrmine the attributes of a user that are needed for the operation of \greed.

User struct


Unchangeable. GUID or just an integer.

e-mail address

Any pair {account-name, e-mail address} must be unique within \greed. Thus it might be better to combine them into one entity, as in account@name@some.domain, and call it account name.

These values can be changed by account admin.

encryption certificate

Used to encrypt private communications to the user.

list of accepted certificate DNs
list of adimin certificate DNs
research credit status

Changed by internals of the \greed. Users consume the credits in \greedworld and can also do transfers to other accounts.

By considering the implications of the above structure, one should notice the following points.

\greed encourages schizophrenia and chaoss.

Nevertheless, the user records should be considered sacred: they will only be changed via authorized means and if the change was admisable by the rules, it is irrevocable. Thus, if certain person misuses the trust of a shared-account admin, this has nothing to do with \greed, it's a personal matter between people sharing the account.

I am not sure about secrecy of these data. It seems reasonable to only expose person/admin DNs and credit status to those, who can login into the account.

Any certificate issued by a CA that \greed trusts can be used. As a fall-back solution, \greed-CA issues its own certificates. The only requirement is to have a working e-mail account that can process encrypted messages. [Is this too severe? Does, say, google-mail support it?]

\greed should also provide jabber service based on account-name. Is it possible: a) to replace authentication mechanism; and b) to have several simultaneous sessions with the same jabber identity?

In principle, the same structure could also be used for machines, services, virtual-machines and virtual machine images. Then, probably, main purpose field should be added to the user struct.

Connection to identity in \gled

\gled has a well defined concept of identity that can be mapped directly to the \greed user. See the gled-auth paper.

\gled also supports trivial group-identities - it is just a list of user-identities that can add the group-identity to the list of their active identities.

Open issues

V0 database

V0 account status: how many credits can it give away.

VM images

Available job-types: mem/cpu/io consumption, required file-sets, and bonus credit information.

File servers / catalogs.


Predrag proposes to look at BOINC.

\greed-state databases


Active VOs, available jobs.

Running jobs. Do we care? Transaction by VO that used the resources should be enough. But if we have this info, we can show it to the users and use it to monitor \greed operation.

Here it is really unclear what part should be done by VOs and what by \greed.


Running worlds.

Active MEEs for each account.

File catalog & \bittorrent gateway

Let us first consider types of data-files presen

Data-files in \greed.

Files for \greedhome

In principle, \greedhome client.

All other files should be made available by VOs themselves.

If \greed starts to use user CPU for \greedworld simulations, we should provide the VM images.

But, users will be able to contribute also by holding data-files on their disk (and sharing them via bittorrent). So this should be accounted for and file availability checked periodically.

Files for \greedworld

\greedworld client

\greedworld client binaries.

Models, textures, sounds, etc.

Basic World data - accessible to everybody.

Detailed world data - result of world exploration. Regional maps, resource availability, detailed data about heavenly bodies (including their trajectories), man-world observation results (e.g, playbacks / images from orbital or aerial surveillance), etc. These data are owned by a user and he can choose to give them to someone alse or to sell them. Are they copiable / sharable? I'd say: a) copiable by the original NPC researcher / lab; and b) yes, sharable.

\greedworld server

\greedworld server binaries and credential balls.

True world data. This should be kept private.

MIR backlogs, state snapshots.

File catalog organization

To think about: What's in file catalog and where.

Storing of data in local caches

To think about:

History / statistcs databases

Transaction logs.

Job logs. Should VOs do at least some of this?

Various stuff about each account, world, etc. This includes production and mining results and allows us to control we are not being cheated by a hacked world.

What you can do to help

  1. Set up \greed CA.

  2. Set up user-db, try accessing it from \root via TSQLXyzz. I'd go for postgres, via TPgSQLXyzz.

    Note that do not have documentation generated for postgres.

  3. Prepare perl-scripts (or sth) that allow an account admin to change account properties.

  4. Learn about \gled authentication.

  5. Find out how a system service can be started so that it has an active certificate available for use.