Symbolic

Project Members

• fcrippa?
• dpanelli?
• mmornati?
• lfoppiano?
• spucci?

Features

* Database to store users informations and authorizations (with machine user can call, with services on that machine, ...) * WYSIWYG interface

Architecture's illustration

Database (TO UPDATE!!)

As we have seen before, symbolic database is used to store information about users and their authorizations on the func structure. Here a-very-symple definition of what database could contain

Roles Table

This table contains the list of main roles that will be assigned to the users. The real utility by now is to know if a user is an administrator or not. In the future could be a more hierarchical role definition.

	ROLE
		id (long)
		description (varchar)

Users Table

This table contains list of func-users with their main informations: username, email, role, ... This informations are not really required by func but could be useful for a future logging area.

	USER
		id (long)
		uname (varchar)
		email (varchar)
		role_id (long)

As you can see, in this table we don't need to store any information about authentication because we will directly use func authentication (See Authentication Chapter)

Machines Table

A simple list of machine certified for func uses. We could really ignore this table because we can optain informations about certified machines directly calling func (inspecting the func folder), but improve database legibility For Symbolic Administrotor will be a function to refresh the content of this table.

	MACHINE
		id (long)
		host_name (varcahr)
		ip (varchar)
		enabled (boolean) --> Used for logical deletion of data

Machine Operations Table

Is a list of func operations that we can invoke on a single controlled machine

	MACHINE_OPERATION
		id (long)
		description (varchar)

Granted Machines Table

This table, managed by Symbolic Administrator, contains all informations about users privileges about machine that user can control.

	GRANTED_MACHINE
		machine_id (long)
		user_id (long)

Granted Machine Operations Table

A list of operation enabled for a specific user on a single machine

	GRANTED_OPERATIONS
		user_id (long)
		machine_id (long)
		operation_id (long)
		

Authentication

Before Symbolic use we need to be authenticated on server, but not all of the needed operations could be done directly from web (right now!). In fact we need to generate a "user certificate" on the server machine that enable user to run func operations; at the end all we need to do is to be authenticate on our system (for example an LDAP authentication in Byte-Code network). We delegate this procedure to PAM (with JPAM ??) so we don't need to know how our network works.

• Check JPAM
• Something Better?

Web Definition

The first step we will do in web definition will be a graphical interface to shown enalbed machine for logged users and for each one a list of permitted operations. Selecting one of them we will call Symbolic core (an interface for Func) that run a selected operation.

Core

This group of class is the 'working core' of Symbolic. We have a series of tpw Jobs (made with Quartz) used to create and run func command on remote machines:

* CommandRunnerJob?

Woke up every 3 seconds search in database if there are new inserted or scheduled operations to run. For each of them will be a simple web-server thread used to launch the correct func operation (all operation will be called in Async mode!!)

* CommandControllerJob?

Another thread used to check if there are a running operation in database and, for each one, checks func process status (simple colling a func function). With func response it will provide to change database status and result.

The following description shown function schema, with relevant actors, of symbolic engine. 1) User connected selects machine(s) and operation to run (any operation could be a list of operations), this causes a database entry with the provided information. In this step user could decide the scheduling time and the queue status.

2) CommandRunnerJob? wakes up and finding a new operation to be done, it creates a new thread that can handle.

3) New temp-thread created changes the status on the database record (from ready to running) and call the concerning func function. Since we are not able to establish a priori if our commands will be 'long execution' or not, all the func executed function will be call in "async" mode. This means that runner thread has been a response from func containing the process ID that it stores on database.

4) When CommandControllerJob? wakes up it checks for running operations in database and, for each one it calls the func check-function, using process id stored, to verify the current status of the process and, in a pinch, it updates database records.

In any time of this process users could check the operations status going on the correct symbolic page.