Firstly, THANKS for such a great replacement to syslog! I'm quite happy with the ease of configurability and the use of the tcp() source and destinations -- very nice for tunnelling over OpenSSL. Next thing to ask for is a feature request that would make our use of syslog infintely more flexible: a string formatter module. Take this hypothetical syslog-ng.conf entry as an example: --------- START EXAMPLE ----------- # First, set some global options. options { long_hostnames(off); sync(0); }; source remotehost { tcp( 192.168.1.1, 514 ); }; # sql batch file destination sql_output { file ("/var/log/log.sql" owner ("root") group("adm") perm(0640)); }; destination xml_output { file ("/var/log/log.xml" owner ("root") group("adm") perm(0640)); }; # Now, the format string using printf style placeholders where %h == # host, %d == date, %t == time, %f == facility, %l == level, and %m == # message format o_sql { printf( "INSERT mytable ( host, date, time, facility, level, message )\nVALUES ( '%h', '%d', '%t', '%f', '%l', '%m' );\n" ); }; # Or, we could specify template files for the printf driver # # Where the file would contain character literals rather than escapes # (for things such as tab and newline): # # INSERT mytable ( host, date, time, facility, level, message ) # VALUES ( '%h', '%d', '%t', '%f', '%l', '%m' );\n" ); # format o_sql { printf(template("/usr/share/syslog-ng/sql.tmpl")); }; format o_xml { printf(template("/usr/share/syslog-ng/xml.tmpl")); }; # Now, out to the log log { source(remotehost); format(o_sql); destination(sql_output); }; log { source(remotehost); format(o_xml); destination(xml_output); }; --------- START EXAMPLE ----------- The reason I suggest having format as a separate module instead of a file option is for instance you want to have a real-time process to log INSERT statements into a database. You could specificy your destination as a named pipe source s_host{ tcp( 192.168.1.1, 514 ); }; format o_sql{ printf(template("/etc/syslog-ng/custom_sql.tmpl")); }; destination d_sqlpipe{ file("/dev/log_sql" owner ("root") group("adm") perm(0640)); }; log{ source(s_host); format(o_sql); destination(d_sqlpipe); }; to which your database client is listening, waiting for input. Let's hypothise for a moment that psql, the PostgreSQL command line client, can open up a named pipe as an input file -- as I'm not sure if it really can. A command like the following is all you'd need for real-time database logging: bash$ whoami syslogd bash$ nohup psql -h localhost -d sysylogdb /dev/log_sql& bash$ We preserve the UNIX philosophy in that you let your tools do only one job, but one job done VERY well. Why reimplement the wheel and embed an SQL client into syslog-ng? No reason at all. What do we have to do to change the output format? Change the output template in the log rule. Simple, clean, efficient. What do you think? -- Chad Walstrom <chewie@wookimus.net> | a.k.a. ^chewie http://www.wookimus.net/ | s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD