[Savannah-hackers] savannah.gnu.org: submission of SMACS

[kiwnix]

A package was submitted to savannah.gnu.org.
This mail was sent to address@hidden, address@hidden


Eduardo Garcia Cebollero <address@hidden> described the package as follows:
License: lgpl
Other License: 
Package: SMACS
System name: smacs
This package does NOT want to apply for inclusion in the GNU project

SMACS:

A project aimed to make the administration of a linux machine with multiple 
front-ends, designed a client-server arch. 

The structure will look like this:

User Interface(1)<--(4)--\\               /-----Config Engine(3) 
                          \\             / 
User Interface(1)<--------->Server(2)<-<>------Config Engine(3) 
                          /             \\ 
User Interface(1)<-------/               \\-(4)-Config Engine(3) 
                        / 
Scripts Interface(5)<--/ 



(1) User Interface: It will be the part of the proyect the end user will use, 
they will be programs (graphical or non-graphical) that will comunicate with 
the Server in all sort of ways (sockets, pipes, CORBA), or by wrappers(4) (by 
example an user interface that uses pipes, will be able to communicate a remote 
server by sockets), it will comunicate with the server by a well defined api. 

(2) Server: The only purpose of the server is communicating the users 
interfaces(1) with the configuration engines(3), it will keep a DataBase of 
what config engines he have connected, and what configuration command comming 
from user interfaces go to what config engine, for example a Firewall config 
interface send a \"drop all packets comming from 10.32.1.3\" and the server 
shoul send this request to the iptables/ipchains/... config engine depending on 
which config engine is connected to the server, if there is no firewall config 
engine attached to the server, the server will send to the client a message 
saying that.

(3) Config Engine: This part of the System will do the real config work, they 
will modify/create the necessary scripts for doing something. For example, if 
you want to configure a apache server, a config engine for apache will be 
necesary (using debconf, using direct-manipulation of config engines, using 
what the programmer of that module want, it will recive requests from the 
server and acording to this requests it will do something. 

(4) Engine Wrappers: This is an optional part of the system, it will do the 
necessary modifications on the communication to the server, if anybody do a 
User Interface that want to comunicate with dcom for example and the server 
does not implement it in the current version the wrapper should convert it to a 
known form by the server. 

(5) Scripts Iface: This kind of interface will be designed to replicate some 
configurations (for example for a PVM cluster), and no need follow a step by 
step process many time. You will feed the Script (Config commands) to the 
interface and it will pass them to the server, returning success or fail 
depending in the state of the operation.