[Savannah-hackers-public] [task #9523] Please delete project YASMINE (Id #9914). Cause empty and no time to work on

[Thomas Harding]

URL:
  <http://savannah.gnu.org/task/?9523>

                 Summary: Please delete project YASMINE (Id  #9914). Cause
empty and no time to work on
                 Project: Savannah Administration
            Submitted by: harding
            Submitted on: mer 01 jui 2009 22:23:59 CEST
         Should Start On: mer 01 jui 2009 00:00:00 CEST
   Should be Finished on: mer 01 jui 2009 00:00:00 CEST
                Category: None
                Priority: 3 - Low
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                  Effort: 0.00

    _______________________________________________________

Details:

project Id : #9914

system name : yasmine

name : YASMINE

group type : non-GNU software & documentation

Hello,

The project is approved and hosted for 1 year, but I'm not able
to find time to work on, I am not an enough experienced coder,
and, more, no such a file have been written nor uploaded to 
Savannah.

Moreover, project is redundant with combination of other Free 
Software (project details below), and would, if eventually developed,
disperse efforts from community.

I apologize for the time consumed.

Regards,
T.Harding

########################################################

Project details:

The project goal was to create a modular, cross platform 
(clients parts), Python written networked systems/network
"monitor".

It would involve a grape of monitor servers, with ability
to upload and manage "modules" to, and fetch data from the 
monitored systems, compute them, and feed a redundant central
server with human/machine readable logs.

Another grape would be in charge of SNMP info collecting, with
same computing/feeding functionalities.

On the log server, a stub would parse the machine readable parts,
triggers automatic actions and alerts in case of emergency,
based on an "events correlation" database, then feeds a  
"consultation" database.

Logs would also be archived in both traditional "flat-files"
and "single-stream-files" ways for security, "scenario replay",
and post-analysis (this is the only trivial part, while handled
by rsyslog, then traditional replication and tape storage ways).

"trigger" station(s) would be in charge to play "safety
scenarios" to the active elements and hosts, via ssh.

"Display" station(s) has to present data in various 
human readable forms ("state grids", sound and mail alerts,
summaries (~logwatch in continuous mode), time/performance
graphs, logs database hunting).

The dialog layer would be a mix of HTTP1/1 (dialog state and "commands") and
RFC822 messages (control and information data),
 in "connected" mode (~SMTP), with ability to "mandatory"
upgrade to TLS certificates-based auth (including LDAP distrib.
of certs).

As you see, it would take about five "years.experienced-man"
to reach a first usable, and maybe safe, state.

YASMINE stands for 'Yet Another System Monitor In Networked
Environment'

I think figure is complete.

TH.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/task/?9523>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/