Distributed Audit Weekly Report
Sergio Ligregni
ligregni at unixmexico.org
Wed Jun 30 16:45:09 UTC 2010
My mistake I have sent the reports to soc-students, (really sorry about
that), but here they are:
#1
This is my report
Distributed Audit
Here are the details of what I've done:
a daemon shipd, it will deliver the trails to the master system, this
daemon already has this logic features:
- three options of tunning (I named it the panic_level)
1: just send the trail when audit closes it
2: search the last correct trail (this is, the trail that is on both
systems) and sync from it to the "present" (for this I perform a quicksort
by name (that is also a chronological because of the naming of the trails,
this can maybe be not so efficient in CPU resources but surely it is
efficient in NETWORK resources).
3: search for all the trails located in the slave system in the master
system and send those what are not there.
- debug option (to no daemonize, it will send messages to stderr,
otherwise, the messages are sent to syslog)
the TO_DO list (for this week):
- to perform the network communication, there is a function that receives
the path of the trail to send, it's just the sending part the one missing
- please check the is_audit_trail(char *) function if you have some ideas
to improve
- do a daemon to receive the trails in the master system, the important
thing is that the daemon will be also tunneable
files:
http://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2010/disaudit&HIDEDEL=NO
shipd.c
shipd.h
ideas.txt
Sergio Ligregni
#2
This is my report
Distributed Audit
Based on the TO_DO list sent last week:
- to perform the network communication, there is a function that receives
the path of the trail to send, it's just the sending part the one missing
- do a daemon to receive the trails in the master system, the important
thing is that the daemon will be also tunneable
I can say both issues are done, the network communication is already
working and there's a master daemon that receives the requests, but in the
"lab" I got a trouble (solvable these days), that is, i.e.:
we can check at master's if there are three files and, since we got that 2
of them are missing, send them:
connect
check for file #1
close connection
connect
check for file #2
close connection
...
connect
send file #1
close connection...
this is a not network efficient solution, so, the logic must be adapted:
connect
check for file #1
check for file #2
check for file #3
close connection
connect
send file #1
...
and so on, much more efficient.
I got help from Garret Cooper telling me where to find the rules about
writing a correct Makefile, I will be take care of that later, now it's
just to simplify the development.
a remaining TO_DO could be:
- once the process is tested and working, integrate to current audit
tools (I think maybe this will be a good idea to do after the project got
approved at Mid-term evaluation, it's just matter of reading from
audit_control file and use audit_warn...)
- the SSL API integration, planned since the beginning to be done at the
second half of the project.
files:
http://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2010/disaudit&HIDEDEL=NO
Sergio Ligregni
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
More information about the soc-status
mailing list