January 2012 - syslog-ng - lists.balabit.hu

[Bug 154] New: Processes forked via program() do not properly terminate
by bugzilla＠bugzilla.balabit.com 23 Mar '12

23 Mar '12

https://bugzilla.balabit.com/show_bug.cgi?id=154 Summary: Processes forked via program() do not properly terminate Product: syslog-ng Version: 3.2.x Platform: Other OS/Version: Solaris Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: hendrik.volker(a)de.verizonbusiness.com Type of the Report: --- Estimated Hours: 0.0 I am using a SyslogNG 3.2.4 build for our company internal version of Solaris 10 on some SUN V245 SPARC servers. In a project I am using the following config: ---8<--- source s_whsvoipgwv2_ngrep_bge1 { program ( "/prod/tools/ngrep -d bge1 -t -q -W single SIP port 5060" flags (no-parse) tags ("IF1") ); }; parser p_whsvoipgwv2_ngrep { csv-parser ( columns ("NGREP.PROTO" "NGREP.DATE", "NGREP.TIME", "NGREP.SRCADDR", "NGREP.DUMMY", "NGREP.DSTADDR", "NGREP.MSG" ) flags (drop-invalid, escape-none, greedy, strip-whitespace) delimiters (" ") ); }; template t_whsvoipgwv2_ngrep { template ( "$MONTH_ABBREV $DAY ${NGREP.TIME} $HOST ${NGREP.PROTO} ${NGREP.SRCADDR} ${NGREP.DSTADDR} ${ NGREP.MSG}\n" ); }; destination d_whsvoipgwv2_sip_voipslp { file ("/var/home/voipslp/sip/sip.$YEAR$MONTH$DAY$HOUR.log" owner("voipslp") group("voipsl") perm(0644) template(t_whsvoipgwv2_ngrep) ); }; log { source(s_whsvoipgwv2_ngrep_bge1); parser(p_whsvoipgwv2_ngrep); destination(d_whsvoipgwv2_sip_voipslp); flags (final); }; ---8<--- With the log file rotation every hour it seems that SyslogNG is starting new instances of ngrep, while not terminating the old instances. This results in lots! of running but unused ngreps. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 11

[Bug 150] New: Possible memory leak for TLS connections
by bugzilla＠bugzilla.balabit.com 23 Mar '12

23 Mar '12

https://bugzilla.balabit.com/show_bug.cgi?id=150 Summary: Possible memory leak for TLS connections Product: syslog-ng Version: 3.3.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: eric(a)sevenscale.com Type of the Report: --- Estimated Hours: 0.0 I've noticed that memory usage seems to grow as clients using TLS connect and disconnect. I ran syslog-ng under valgrind while I caused a number of clients to connect and disconnect a few times and saved the leak summary from valgrind: https://gist.github.com/893a9687bf98dc53f0e7 -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 152] New: Vers 3.3.3 pipe source does not parse host from input line
by bugzilla＠bugzilla.balabit.com 14 Feb '12

14 Feb '12

https://bugzilla.balabit.com/show_bug.cgi?id=152 Summary: Vers 3.3.3 pipe source does not parse host from input line Product: syslog-ng Version: 3.3.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: erempel(a)uvic.ca Type of the Report: --- Estimated Hours: 0.0 Try as I might, I can not get a pipe source to maintain the hostname. Syslog-ng includes the hostname as the $MSGHDR (or the $PROGRAM). my config # ----------------------------------- source patterndb { pipe("/var/log/syslog.pipes/patterndb" log_fetch_limit(500) log_iw_size(100000) ); }; source int { internal(); }; template t_standardfile { template("$S_ISODATE $FULLHOST $FACILITY.$LEVEL $MSGHDR][$PROGRAM][$MESSAGE\n"); template_escape(no); }; destination d_var_patterndb { file("/var/log/patterndb.$R_YEAR$R_MONTH$R_DAY.000000" owner("root") group("syslogs") perm(0640) template(t_standardfile)); }; log { source(patterndb); destination(d_var_patterndb); }; # ----------------------------------- data I write tothe pipe # ----------------------------------- <12>2011-11-25T00:00:30-08:00 somehost.uvic.ca mmfs: Fri Nov 25 00:00:29.618 2011: Accepted and connected to 172.20.102.38 hermes0080 <c0n350> <12>2011-11-25T00:00:30-08:00 somehost.uvic.ca mmfs: Fri Nov 25 00:00:29.620 2011: Connecting to 172.20.107.23 nestor0167 <c0n200> <12>2011-11-25T00:00:30-08:00 somehost.uvic.ca mmfs: Fri Nov 25 00:00:29.621 2011: Connected to 172.20.107.23 nestor0167 <c0n200> # ----------------------------------- The output file # ----------------------------------- 2011-11-25T00:00:30-08:00 patterndb(a)catamount.comp.uvic.ca user.warning somehost.uvic.ca ][somehost.uvic.ca][mmfs: Fri Nov 25 00:00:29.618 2011: Accepted and connected to 172.20.102.38 hermes0080 <c0n350> 2011-11-25T00:00:30-08:00 patterndb(a)catamount.comp.uvic.ca user.warning somehost.uvic.ca ][somehost.uvic.ca][mmfs: Fri Nov 25 00:00:29.620 2011: Connecting to 172.20.107.23 nestor0167 <c0n200> 2011-11-25T00:00:30-08:00 patterndb(a)catamount.comp.uvic.ca user.warning somehost.uvic.ca ][somehost.uvic.ca][mmfs: Fri Nov 25 00:00:29.621 2011: Connected to 172.20.107.23 nestor0167 <c0n200> # ----------------------------------- I would expect the output file to read # ----------------------------------- 2011-11-25T00:00:30-08:00 somehost.uvic.ca user.warning mmfs: ][mmfs][Fri Nov 25 00:00:29.618 2011: Accepted and connected to 172.20.102.38 hermes0080 <c0n350> 2011-11-25T00:00:30-08:00 somehost.uvic.ca user.warning mmfs: ][mmfs][Fri Nov 25 00:00:29.620 2011: Connecting to 172.20.107.23 nestor0167 <c0n200> 2011-11-25T00:00:30-08:00 somehost.uvic.ca user.warning mmfs: ][mmfs][Fri Nov 25 00:00:29.621 2011: Connected to 172.20.107.23 nestor0167 <c0n200> # ----------------------------------- -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 2

syslog-ng hangs with high message volume to sqlite database
by Patrick Hemmer 10 Feb '12

10 Feb '12

I seem to have run into a situation where syslog-ng (3.3.4) will hang when sending a high message volume to an sqlite3 database. When I run the `loggen` utility with a high message rate, syslog-ng writes out the following error: Jan 28 22:58:12 storm.feystorm.net syslog-ng[22839]: Error running SQL query; type='sqlite3', host='', port='', user='syslog-ng', database='/syslogtest/logs.sql3', error='5: database is locked', query='COMMIT' Jan 28 22:58:12 storm.feystorm.net syslog-ng[22839]: SQL transaction commit failed, rewinding backlog and starting again; Syslog-ng will sit stuck like this for a minute and then log the error again. Sometimes it'll write a few more entries to the database before it errors, but its never more than a few. I'm not sure if this issue is a problem with libdbi or syslog-ng, which is why I'm here and not the bug tracker. I came across this issue trying to track down another issue where syslog-ng seems to hang completely and will never recover (wont respond to anything other than a `kill -9`). Whether this is the same issue or not, I do not know. I was able to trigger this with the following loggen command: loggen -r 60 -I 1 --active-connections=2 -x ./socket This server is a fairly low power server (its a central log collector for my home network), so it you might have to significantly bump up the message rate to duplicate the issue. Config: @version: 3.3 options { keep_hostname(yes); chain_hostnames(no); normalize_hostnames(yes); use_dns(no); use_fqdn(yes); stats_freq(0); mark_freq(0); }; source s_socket { unix-stream("/syslogtest/socket"); }; source s_internal { internal(); }; destination d_internal { file("/syslogtest/internal.log"); }; log { source(s_internal); destination(d_internal); }; destination d_sqlite { sql( type('sqlite3') database("/syslogtest/logs.sql3") table("logs") columns("time", "time_r", "host", "facility", "priority", "program", "pid", "tag", "message") values("$S_UNIXTIME", "$R_UNIXTIME", "$FULLHOST", "$FACILITY_NUM", "$LEVEL_NUM", "$PROGRAM", "$PID", "$DBTAG", "$MSG") null("") flags(explicit-commits) flush_lines(10) flush_timeout(200) ); }; filter f_test1 { message('^prg00000') or program('syslog-ng'); }; filter f_test2 { message('^prg00001') or program('syslog-ng'); }; log { source(s_internal); source(s_socket); destination(d_sqlite); }; #log { source(s_internal); source(s_socket); filter(f_test1); destination(d_sqlite); }; #log { source(s_internal); source(s_socket); filter(f_test2); destination(d_sqlite); }; Database schema: CREATE TABLE logs (id integer primary key autoincrement, time unsigned integer not null, time_r unsigned integer not null, host text not null, facility unsigned integer not null, priority unsigned integer not null, program text not null, pid unsigned integer, tag text, message text not null); CREATE INDEX host on logs (host, time); CREATE INDEX program on logs (program, time);

2 6

Format-json scope
by Vámos Balázs 03 Feb '12

03 Feb '12

Hi, Version: syslog-ng ose 3.3.3 Error message in log: error in template: $(format-json --scope soft-macros) Config: destination d_json{ file("/var/log/messages.json" template("$(format-json --scope soft-macros)\n") ); }; The 'all-macros' and 'selected-macros' are working. Thanks, Balazs

2 4

[PATCH (3.4)] tfuuid: New template function to generate UUIDs.
by Gergely Nagy 03 Feb '12

03 Feb '12

This patch adds a new template function: $(UUID) (also available as $(uuid)), which can be used to generate Universally Unique IDentifiers. The use case for this is to add an UUID to each message as soon as they're received, so that they can be identified later, accross destinations. This allows me to pre-generate an ID for messages going into mongodb, and send those messages to a different destination too, with the same ID included. Use it like this: rewrite r_add_uuid { set("$(UUID)" value("UUID")); }; log default { source(s_network); rewrite(r_add_uuid); destination(d_mongo); destination(d_program); }; The module uses the widely available libuuid library to generate the UUIDs. Signed-off-by: Gergely Nagy <algernon(a)balabit.hu> --- configure.in | 16 ++++++++++- modules/Makefile.am | 2 +- modules/tfuuid/Makefile.am | 11 ++++++++ modules/tfuuid/tfuuid.c | 62 ++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 89 insertions(+), 2 deletions(-) create mode 100644 modules/tfuuid/Makefile.am create mode 100644 modules/tfuuid/tfuuid.c diff --git a/configure.in b/configure.in index 734d703..83b81ac 100644 --- a/configure.in +++ b/configure.in @@ -182,6 +182,10 @@ AC_ARG_ENABLE(systemd, [ --enable-systemd Enable systemd support (default: auto)] ,,enable_systemd="auto") +AC_ARG_ENABLE(uuid, + [ --enable-uuid Enable UUID support (default: auto)] + ,,enable_uuid="auto") + AC_ARG_WITH(compile-date, [ --without-compile-date Do not include the compile date in the binary] ,wcmp_date="${withval}", wcmp_date="yes") @@ -930,6 +934,14 @@ if test "x$enable_systemd" = "xyes"; then fi fi +if test "x$enable_uuid" = "xyes" || test "x$enable_uuid" = "xauto"; then + PKG_CHECK_MODULES(UUID, uuid, with_uuid="yes", with_uuid="no") + if test "x$with_uuid" = "xno" && test "x$enable_uuid" = "xyes"; then + AC_MSG_ERROR([Could not find libuuid, and uuid support was explicitly enabled.]) + fi + enable_uuid="$with_uuid" +fi + dnl *************************************************************************** dnl default modules to be loaded dnl *************************************************************************** @@ -1087,6 +1099,7 @@ AM_CONDITIONAL(ENABLE_PACCT, [test "$enable_pacct" = "yes"]) AM_CONDITIONAL(ENABLE_MONGODB, [test "$enable_mongodb" = "yes"]) AM_CONDITIONAL(ENABLE_JSON_FORMAT, [test "$enable_json_format" = "yes"]) AM_CONDITIONAL(ENABLE_JSON_PARSE, [test "$enable_json_parse" = "yes"]) +AM_CONDITIONAL(ENABLE_UUID, [test "$enable_uuid" = "yes"]) AM_CONDITIONAL(WITH_LIBSYSTEMD, [test "$with_libsystemd" = "yes"]) # substitution into manual pages @@ -1153,6 +1166,7 @@ AC_OUTPUT(dist.conf modules/pacctformat/Makefile modules/basicfuncs/Makefile modules/tfjson/Makefile + modules/tfuuid/Makefile modules/jsonparser/Makefile scripts/Makefile scripts/update-patterndb @@ -1204,5 +1218,5 @@ echo " SQL support (module) : ${enable_sql:=no}" echo " PACCT module (EXPERIMENTAL) : ${enable_pacct:=no}" echo " MongoDB destination (module): ${enable_mongodb:=no}" echo " JSON support (module) : parser=${enable_json_parse:=no}, formatter=${enable_json_format:=no} (using ${with_json})" - +echo " UUID support (module) : ${enable_uuid:=no}" diff --git a/modules/Makefile.am b/modules/Makefile.am index 0d0594b..72c005f 100644 --- a/modules/Makefile.am +++ b/modules/Makefile.am @@ -1 +1 @@ -SUBDIRS = afsocket afsql afstreams affile afprog afuser afmongodb csvparser confgen syslogformat pacctformat basicfuncs dbparser tfjson jsonparser dummy +SUBDIRS = afsocket afsql afstreams affile afprog afuser afmongodb csvparser confgen syslogformat pacctformat basicfuncs dbparser tfjson tfuuid jsonparser dummy diff --git a/modules/tfuuid/Makefile.am b/modules/tfuuid/Makefile.am new file mode 100644 index 0000000..9d96fe1 --- /dev/null +++ b/modules/tfuuid/Makefile.am @@ -0,0 +1,11 @@ +moduledir = @moduledir@ +export top_srcdir + +#if ENABLE_UUID +AM_CPPFLAGS = -I$(top_srcdir)/lib -I../../lib $(UUID_CFLAGS) +module_LTLIBRARIES = libtfuuid.la + +libtfuuid_la_SOURCES = tfuuid.c +libtfuuid_la_LIBADD = $(MODULE_DEPS_LIBS) $(UUID_LIBS) +libtfuuid_la_LDFLAGS = $(MODULE_LDFLAGS) +#endif diff --git a/modules/tfuuid/tfuuid.c b/modules/tfuuid/tfuuid.c new file mode 100644 index 0000000..c426cb8 --- /dev/null +++ b/modules/tfuuid/tfuuid.c @@ -0,0 +1,62 @@ +/* + * Copyright (c) 2012 BalaBit IT Ltd, Budapest, Hungary + * Copyright (c) 2012 Gergely Nagy <algernon(a)balabit.hu> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "plugin.h" +#include "templates.h" +#include "cfg.h" + +#include "config.h" + +#include <uuid/uuid.h> + +static void +tf_uuid(LogMessage *msg, gint argc, GString *argv[], GString *result) +{ + uuid_t uuid; + gint i; + + uuid_generate (uuid); + + for (i = 0; i < sizeof (uuid); i++) + g_string_append_printf (result, "%02x", uuid[i]); +} + +TEMPLATE_FUNCTION_SIMPLE(tf_uuid); + +static Plugin tfuuid_plugins[] = + { + TEMPLATE_FUNCTION_PLUGIN(tf_uuid, "UUID"), + TEMPLATE_FUNCTION_PLUGIN(tf_uuid, "uuid"), + }; + +gboolean +tfuuid_module_init(GlobalConfig *cfg, CfgArgs *args) +{ + plugin_register(cfg, tfuuid_plugins, G_N_ELEMENTS(tfuuid_plugins)); + return TRUE; +} + +const ModuleInfo module_info = +{ + .canonical_name = "tfuuid", + .version = VERSION, + .description = "The tfuuid module provides a template function to generate UUIDs.", + .core_revision = SOURCE_REVISION, + .plugins = tfuuid_plugins, + .plugins_len = G_N_ELEMENTS(tfuuid_plugins), +}; -- 1.7.7.3

2 4

Bazsi's blog: syslog-ng flexibility improvements
by Balazs Scheidler 03 Feb '12

03 Feb '12

syslog-ng flexibility improvements syslog-ng is often referred as a very flexible application when it comes to processing logs. Over the years however, I began to feel that some things are a bit more difficult to achieve in the configuration language than it should be. For instance it is sometimes too rigid when you need a combination of parsers (patterndb with db-parser) and rewrite rules to achieve the goal you wanted. Parsers and rewrite rules are distinct part of the configuration, it is not possible to combine them into a single functionality. Also, declaring objects first and then referencing them later, makes the configuration easy to read, however sometimes it is quite cumbersome, when you only need to invert the result of an already existing filter. To solve this situation, I’ve set out to implement an idea I had on mind for some time now. It is quite difficult to describe the feature in clear and concise words, as it is a combination of various changes that together makes syslog-ng configuration more flexible and easier to use, without sacrificing readability. Curious? Please read on. In-line objects Perhaps the simplest of all features is that you can now define the contents of a given object right on the spot, without having to use a separate statement. For example, earlier you had to write: log { source(s_local); filter(f_postfix); destination(d_postfix); }; Sometimes, f_postfix filter is only used once and is trivial. This can now be written as: log { source(s_local); filter { program("^postfix/"); }; destination(d_postfix); }; Furthermore both the source() and destination() options can be written in-line, you simply use braces instead of parentheses. The same functionality applies to everything: sources, destinations, filters, parsers and rewrite rules. Junctions A limited form of junctions has been supported since syslog-ng 3.0 in the form of “embedded log statements”, which has been generalized now. Within syslog-ng, when a message is received it is dispatched to a log processing path or pipeline, which carries out the task at hand. A junction is a point in the log processing path where the processing is performed on multiple independent branches, each doing its own specific thing with the message. The limited functionality in 3.0 only allowed the processing tree to split (or fork) into independent branches, each of the branches was a “sink”, where processing also ended. Configuration example: log { source(s_all); filter(f); log { filter(f1); destination(d1); }; log { filter(f2); destination(d2); }; }; This sample forks the processing path into two branches starting with the “log” keyword within the top-level log statement. The first branch evaluates the filter f1 and the writes matching messages to the d1 destination, effectively sending all messages that match (f AND f1) to d1. Likewise, d2 receives all messages that match (f AND f2). The limitation of the embedded log statement concept was simple: it could only be listed at the very end of a log statement, and the end-result of the branches couldn’t be processed further. Effectively the message at the end of each branch “fell off”. Junctions on the other hand makes it possible to do things to messages once the branches converge to the same point again. Repeating the sample above, it is now possible to write: log { source(s_all); filter(f); junction { log { filter(f1); destination(d1); }; log { filter(f2); destination(d2); }; }; destination(d_all); }; The new thing is that you can now add processing after the branches finish their processing. A bit more useful example would be: log { source(s_apache_files); source(s_syslog); junction { log { filter(f_apache_files); rewrite(r_apache_remove_file_header); parser(p_apache); flags(final); }; log { filter(f_apache_syslog); parser(p_apache); flags(final); }; }; destination(d_files); }; This example does an alternative processing of incoming logs based on where the message came from. Everything is a log expression This feature is probably the most complicated, however provides very nice properties and expressiveness to the configuration. From now on, not just the well known log statement allows the specification of log processing rules, but all the objects in the syslog-ng configuration file can use the same expressive power. It is now possible to use embedded log statements, junctions and in-line object definitions within source, destination, filter, rewrite and parser definitions. Huh, you could ask: what does it bring to me as a benefit? Well, until now, objects of different types were separate entities, connected using log statements, with this change a source can also specify a rewrite rule and that combination used as a log source in a log statement. For instance, a usual source definition looked like this: source s_apache { file("/var/log/apache/error.log"); }; If you wanted to process this log file in a specific way, you needed to define the accompanying processing rules (parsers and rewrite expressions) and combine them in a log statement. But how about this: source s_apache { log { source { file("/var/log/apache/error.log"); }; parser(p_apache_parser); }; }; }; log { source(s_apache); ... }; Can you see? The s_apache source used a file source and the reference of a specific parser and all messages read from the apache error log file would be processed by that parser. The log statement is just as simple as if s_apache would be a “normal” source definition. This feature allows pairing the essential log preprocessing functionality very close to the source itself, making it very easy to write and read the log statements. As an added bonus, it becomes very easy to distribute application specific source & parser definitions as an SCL configuration snippet. Where? This stuff is available in the syslog-ng 3.4 git tree, on master. It passes the included regression test, so it is at least dogfoodable. The nice thing about the implementation is that it only slightly increased the code size, but brought a lot of new features. If you have trouble getting the code from git, let me know, I’m willing to create an alpha release, so that it becomes easier to play with it. Feedback I see a lot of potential in this functionality, however my examples may have not been the best ones. I would really appreciate any kind of feedback, please be sure to send those to the syslog-ng mailing list or post me as a private email.

4 13

Patch for tests/loggen.c (bind src addr and full SendQ sleep)
by Russell Tait Milne 03 Feb '12

03 Feb '12

A colleague of mine has patched the loggen utility to allow for: - binding to a particular source address - adding a usleep() when the SendQ is full This patch was applied and tested on syslog-ng-3.3.3 found in the FreeBSD ports tree. I apologize in advance if this is not the proper way to submit a patch. (See attached patch) Best, Russ This communication, including any attachments, does not necessarily represent official policy of Seccuris Inc. Please see http://www.seccuris.com/Contact-PrivacyPolicy.htm for further details about Seccuris Inc.'s Privacy Policy. If you have received this communication in error, please notify Seccuris Inc. at info(a)seccuris.com or at 1-866-644-8442.

2 3

kernel logging feature requests
by Patrick H. 01 Feb '12

01 Feb '12

While setting up a new server at home I've come across 2 feature requests that would be fairly nice to have (and not that hard to implement I would think). 1) When the 'kernel' flag is set on a file() source (like for reading /proc/kmsg), look for the printk time (eg "[ 1234.567890]") and calculate when the message would have occurred instead of just using when the line was read off the file. Basically check to see the number of seconds the system has been up, subtract the printk time, and then subtract that from current time. 2) I grab all kernel messages with priority of crit or higher and send it to the usertty() destination, but this destination doesnt support templates. It'd be nice to be able to define the template. I mostly just want to change the time format and remove the hostname (since these will only come from localhost on my setup).

4 8

Relicensing syslog-ng man pages
by Fekete Robert 01 Feb '12

01 Feb '12

Hi, to make the syslog-ng manual pages more consistent with the source code and also to make the life of package maintainers a bit easier, we have relicensed the man pages of syslog-ng under the GPLv2 license. Bazsi will add source of the manual pages (docbook xml) to the syslog-ng source code as well. Please find attached the xml sources of the current man pages of syslog-ng OSE 3.3. I will also update the adminguide to include the relicensed man pages. Generating the man pages from the sources is relatively simple, just dump them into a directory and execute the following: (you need to have xsltproc and docbook-xsl installed, and might have to adjust the path for your environment) for i in *.xml; do xsltproc /usr/share/xml/docbook/stylesheet/docbook-xsl/manpages/docbook.xsl $i; done Sidenote: the syslog-ng.8 man page contained outdated information about chrooting syslog-ng, I have corrected that as well. Regards, Robert

2 1