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