msyslog-2.0 (versiunea pre-alpha) se muta in CVS pe SourceForge. Cine crede ca are ceva de zis in limba C :-) e invitat sa se exprime!
http://sourceforge.net/projects/msyslog/ P.S.: msyslog (v1.0x) a devenit de curind engine-ul principal de remote logging la SGI (pus peste o baza de date care, cind va contine suficienta informatie, va deveni o scula misto de network forensics), iar VALinux cica lucreaza si ei in directia asta. ;-) -----Forwarded Message----- From: Alejo Sanchez <[EMAIL PROTECTED]> To: Msyslog Users <[EMAIL PROTECTED]> Cc: Msyslog Development <[EMAIL PROTECTED]> Subject: [msyslog-usr] sourceforge, 2.0, etc Date: 31 Oct 2001 19:33:49 -0300 Hi, As stated here before, version 2.0 is getting closer to something functional. Some were asking what features does it have, and if it makes sanse to keep developing for 1.X versions. Well, the entire CVS has been uploaded to sourceforge, and anybody who is interested in join our work with the project will be more than welcome. Be it documenting, reporting bugs, asking for features, project support, and even coding! Source will all be soon accesible at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/msyslog/ Since the work was done on both versions, and 2.X is a complete rewrite, it'd have been crazy to have tags all around, so version 2.X is under "msyslog" directory. Now back with 2.0, here are the main aspects: 1- the system is planned to be powerful one of the main ideas is to leave the user to control as much as possible. it will have as consequence to be a bit 2- performance is also a main goal. msyslog is aimed to be a major log centralization agent. nowadays with gigabit networks, this means many MB/s. in a few years it could mean GB/s! it is a well known fact that network speed has a more accelerated improvement curve than any other computer system part. so there were many things to simplify from our 1.X versions: - filters using only regex. now you could do plain strcmp() if you want just to check a string (ie. host = "jabba"). also, now you can direct outputs of a filter both matched and unmatched. (before you had to repeat a line) - i/o speed. i/o is slow, SQLs are slow. having a threaded environment with as many threads as admin wants. 3- ease of use, simplicity. the configuration file was changed a lot, but the main goal was to keep it as simple as possible. as users of msyslog are admins, we also don't want them to be treated as novices, and instead give them more control over what is going on. 4- information veracity and reliability. there is a major problem on current syslogs: no checks are done on user and pid checks. even though there are ways to get them! (ie. user credential passing, identd). the only thing wich is usually checked is plain users not impersonating the kernel. but even auth messages could be inserted! unix input will check it by default. (it is a bit tricky since no 2 OSs have the same user credential struct) 5- new protocols for syslog transporting there are a couple of IETFs coming on the way, that even though I am personally not impressed on the way they were handled, will become mainstream. there are flaws on that, so I belive it is quite possible there will be other protocols around. the main idea is to support all of them in a similar way. 6- data representation xml, sgml, etc. there is a major move towards the xml way of information representation. even tough from many long discussions with Claudio, it was clear that the message parsing was not to be done by msyslog, the format of the message must be. the plan is to leave it to the user. 7- Data protection. the start point in Core's involvement with logset software was the early log protection algorithms designed by founders since 1996. those algorithms were aimed to protect stored logsets, but they could easily be used to protect log transfers too. we address this on 2.X. Also there is the problem on the message fields used... we plan to have it available so further checks could be done naturally (ie from a SQL wich has fields shuffled and in a different format) 8- logset repository handling audit[d] should be able to handle 9- portability. we plan to have most msyslog 2.0 features ported to NT plataform, so the non-ansi functions are isolated for easier porting. 10- config file changes checked with a hash instead of always reparsing it, or checking changes of modify date. 11- buffering and queueing. now it is done in a module wich could be plugged to any other module. so this way you can buffer before sending to network or to an sql (ie. doing bulk update instead of one insert per transaction) Yes, the project is ambitious, but achievable. This all started back in March as there was a major change on goals for Core. I was given trust, and resources by my superiors, and the most important thing: freedom. I had to say that, since this isn't so common nowadays. Also a major boost is the EXCELLENT response by users. It is very nice to hear all the good vibes ppl. have, specially in this rough times. STATUS (yes, at last! ;) The daemon code is working. Configuration parsing is working in a really nice way: it generates a bytecode stack wich the interpreter parses very VERY fast. The engine (unix engine), is mostly working, needs a little tweaks here and there because of latest config and module changes (and win32 compat). Most important modules (file, net, unix, format) are mostly focused, and work is more kind of automatic. All other modules shouldn't be hard (there are examples very handy, and msyslog 1.X code). DOCUMENTATION IS LACKING. On Nov I am going to give 2 weeks for documentation. As usual, all feedback is more than welcome :) Cheers, Alejo -- Alejo Sanchez - Developer mailto:[EMAIL PROTECTED] Core SDI S.A. http://www.alejo.com.ar "Don't worry about a thing, 'Cause ev'ry little thing gonna be alright" --- Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to unsubscribe from this list.
