Bug 6818 - [PATCH] Add MySQL support to vfs_full_audit
[PATCH] Add MySQL support to vfs_full_audit
Status: RESOLVED WONTFIX
Product: Samba 3.6
Classification: Unclassified
Component: VFS Modules
unspecified
All Linux
: P3 enhancement
: ---
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-16 02:26 UTC by Adam Nielsen
Modified: 2012-04-24 19:47 UTC (History)
0 users

See Also:


Attachments
Patch (11.31 KB, patch)
2009-10-16 02:27 UTC, Adam Nielsen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Nielsen 2009-10-16 02:26:17 UTC
I am creating a Bugzilla entry here to assist with tracking - this was posted to the Samba developers list on 2009-08-28.

The patch I am about to attach adds MySQL support to the vfs_full_audit module in Samba 3.4.  I hope you consider it worthwhile to include in the main Samba distribution.

The patch is against the source3 module in git as of a couple of weeks ago (when the patch was first posted) however the code was developed with Samba 3.4.0 and it works well.

There are two outstanding issues:

  1. The patch has been designed so that MySQL support can be compiled
in or out to avoid a dependency, but I'm not familiar enough with the
Samba build process to fully integrate this.  (I just added
-lmysqlclient to the Makefile and it worked fine for testing.)  I hope
somebody can help out in the form of a --with-mysql configure option.

  2. I have a sample PHP script (one file) which provides an easy web
interface to the collected data.  I would like to include this somewhere
in the distribution so that people can easily install it on their
webserver, but I'm not sure where it would fit best.
Comment 1 Adam Nielsen 2009-10-16 02:27:21 UTC
Created attachment 4860 [details]
Patch
Comment 2 Karolin Seeger 2009-10-16 08:50:33 UTC
Thanks for the patch!

Raising product as enhancements will go into 3.5 or newer.
3.4 is already in the bug fix only mode.

Are there any volunteers for code review?
Comment 3 Karolin Seeger 2010-01-25 05:36:39 UTC
Too late for 3.5. Raising version.

Any volunteers for code review??
Comment 4 Chetan Chauhan 2012-04-19 08:30:32 UTC
I'm not sure if this is necessary . rsyslog already does an excellent job of converting syslog to mysql.
For example the below .conf works great for me with rsyslog w/mysql support+repl and it is flexible , i.e i am able to record logs in the format/fields that my mysql table is designed for -


$Template smbtpl_open,"INSERT INTO smb_logs (FromHost,Facility,Priority,Importance,SysLogTag,DeviceReportedTime\
,Program,smb_user,smb_hostname,smb_machine,smb_share,smb_operation,smb_status,\
smb_filemode,smb_file) VALUES ('%HOSTNAME%','%syslogfacility%','%syslogpriority%',\
'%syslogseverity%','%syslogtag%', '%timereported:::date-mysql%','%programname%',\
'%msg:R,ERE,1,DFLT:(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)--end%',\
'%msg:R,ERE,2,DFLT:(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)--end%',\
'%msg:R,ERE,3,DFLT:(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)--end%',\
'%msg:R,ERE,4,DFLT:(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)--end%',\
'%msg:R,ERE,5,DFLT:(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)--end%',\
'%msg:R,ERE,6,DFLT:(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)--end%',\
'%msg:R,ERE,7,DFLT:(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)--end%',\
'%msg:R,ERE,8,DFLT:(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)\|(.*)--end%'\
)", SQL

if $syslogfacility-text == 'local6' and $msg contains '|open|' then :ommysql:localhost,smb_audit,rsyslog,12345;smbtpl_open
Comment 5 Adam Nielsen 2012-04-19 11:09:43 UTC
That's interesting - but it relies on the machine running rsyslog.  Those who run less capable alternatives will likely still need a patch such as this.  I'm also not sure how efficient all that string searching and regex code would be on a high load server?
Comment 6 Volker Lendecke 2012-04-24 19:47:34 UTC
I have a few issues with this patch.

I don't know anybody in the Samba Team willing to maintain this for the future. We have had similar issues with pdb_sql, nobody in the Team is running SQL databases. We don't have people with a proper test environment handy all-day, so this will definitely bit-rot.

Then I have a technical argument against the patch: To me it seems that mysql_stmt_execute is a synchronous command. You don't want that. You can't afford to wait for an SQL server, even if it's local and really really fast to do its job inserting data into a table. This will completely kill your performance. The least you need to do is to asynchronously write the data into a pipe and asynchronously retrieve errors when you happen to come back later. This will kill instant error reporting, but it is the only way to retain any speed.

I'm marking this as wontfix. Please don't hesitate to re-open with a different patch, but be aware that we need to overcome the long-term maintenance issue.

With best regards,

Volker Lendecke