- syslog-ng - lists.balabit.hu

versioning and maintenance
by Balazs Scheidler 26 Apr '11

26 Apr '11

Hi, First of all, sorry for being absent from this forum for the past couple of weeks. I've tried to focus here too sometimes, but due to health issues, I sometimes simply have too little time to do too much. But anyway, I haven't stopped thinking about the way forward, and I've thought I'd share my thoughts about those with you. Please note that this is not an official announcement, but rather a way to gather feedback on my plans. Everything can be changed, and after we get to an agreement, an "official" announcement will be sent out on the conclusions. First of all, some status information: ====================================== * syslog-ng 3.0, 3.1 and 3.2 have all produced stable versions, and were all maintained in parallel. * syslog-ng 3.3 is in development, with the primary aim at scaling syslog-ng to multiple CPUs. It has produced two alpha releases so far. * syslog-ng team in BalaBit is busy merging the OSE and PE editions of syslog-ng, in order to use a common core. * the team is basing their work on OSE 3.3, which has been available as two alpha releases and the git tree, also their tree is also published as a git repository. * while they were porting the PE functionality, they were also busy porting the new core to new platforms and also of course fixing bugs, they've found. * I've been helping the team in case they've found something that affected the open source edition as well. Then some news about my future plans on syslog-ng versions: =========================================================== * I feel that maintaining 3 releases while doing development of a 4th one is too much for me. * I originally planned to employ the same stable/feature release structure that BalaBit's commercial products are using. There, a stable release is maintained for a longer time (similar to Ubuntu LTS), while incremental feature releases are published, with shorter support periods (e.g. like normal Ubuntu releases). * The stable/feature release breakdown would mean, that 3.0 is a long term release, and 3.1 & 3.2 are short term releases. * However, this doesn't match real-life expectations, distributions use newer versions (and I really applaud this), but this also means that dropping support for versions included in major Linux distributions would cause disruptions. * I'm really happy that distributions can move faster, and I'd really like to speed up syslog-ng development. Instead of sticking to an old release and stuffing in bugfixes and minor features; publish a major release more often, so that features don't cause problems in stable releases. * Therefore, I plan to abandon the feature/stable release breakdown altogether. One release will be the same as the other. I'm pledging support for major releases as long as: - there's only one release to be maintained in parallel to the development tree. - I plan to support a given major release for about a year. * This means, that syslog-ng support for OSE 3.0 & 3.1 will be discontinued, in the not too distant future. I'm planning on a 3 month period, in order to let people have time to prepare for the upgrade. E.g. I'd like to announce that these versions are going to be supported until 31th July, 2011. * The definition of "support" is of course vague, I can't provide SLAs or anything, but I'll do my best to help anyone who has issues with those versions. * Also, if a distribution which carries this version has an issue, I'll try to help, even past that EOL date, but general questions and problems found in those versions by users, will be advised to upgrade to a newer release, or to backport a specific fix themselves. Going forward: ============== * I plan to announce a feature freeze for 3.3 and publish a beta version. And at the same time open the 3.4 branch for integrating all the stuff which has accumulated on the mailing list. * Hopefully we can have a stable 3.3 by the time the previous two releases hit their end-of-life in July. What if you disagree: ===================== * Until now, I didn't really publish "hard" EOL dates for syslog-ng OSE, simply because there were not that many of the parallel branches. However with the increase in development pace, I simply cannot keep up, and I hate to do a substandard job. Backporting fixes to 3 branches, is simply too much effort. * I'm happy to help building up the proper infrastructure outside of BalaBit if someone wants to help in maintenance, and release engineering. But this requires real effort from members of the community. Now, having written this down, please give your feedback, and I'm trying to work down my backlog and start integrating patches. Thanks for listening. -- Bazsi

3 6

duplicated log lines
by Len Conrad 22 Apr '11

22 Apr '11

FreeBSD sl1.hctc.net 8.2-RELEASE syslog-ng 2.0.10 I filter the mail flow into per-mail-sever files. I start with the FreeBSD syslog-ng.conf which emulates the system syslog.conf and add my stuff. The problem is that all maillog files have duplicate lines. After modifying a bunch of stuff, no success. Either I get no maillog traffic at all, or the dupes remain. How to debug? thanks Len

2 1

Info about owner() options
by Cosmin Neagu 22 Apr '11

22 Apr '11

Hello, New around here, i'm trying to use the owner option when logging into file. My configs: source s_udp { udp();}; destination df_hosts { file("/home/cosmin/SYSLOG/HOSTS/$HOST/$YEAR/$MONTH/$DAY/$FACILITY$YEAR$MONTH$DAY" owner(cosmin) group(cosmin) perm(0600) dir_perm(0700) create_dirs(yes)); }; log { source(s_udp); destination(df_hosts); }; The only problem is that files, are owned by root, not by cosmin. cosmin@DellCosmin:~/SYSLOG$ sudo ls -l HOSTS/ total 8 drwx------ 3 root root 4096 2011-04-22 10:41 10.90.0.252 drwx------ 3 root root 4096 2011-04-22 10:41 192.168.156.100 So, can someone tell me if i'm doing something wrong? I would like the files to be created and owned by cosmin:cosmin not root:root The process is running as root: cosmin@DellCosmin:~/SYSLOG$ ps -ef | grep syslog-ng root 3448 1 0 10:41 ? 00:00:00 /usr/sbin/syslog-ng -p /var/run/syslog-ng.pid -- Cosmin Neagu NOC Team Leader Str. I. G. Duca nr. 36 Otopeni, Judetul Ilfov, 075100 Romania Tel: 021 303 3159 / 0732 669 193 www.omnilogic.ro

1 1

Cacti's syslog plugin - How to remove a host
by Wagner Pereira 19 Apr '11

19 Apr '11

Hi, folks. First, I'm sorry if this is not the right mailing list to handle this, but...here we go: I need to remove a host from my Select host(s) list, in the Cacti's syslog plugin tab. I'm using the CactiEZ solution. Regards, -- Wagner Pereira PoP-SP/RNP - Ponto de Presença da RNP em São Paulo CCE/USP - Centro de Computação Eletrônica da Universidade de São Paulo http://www.pop-sp.rnp.br Tel. +55 11 3091-8901 fone@RNP: 10158902

2 1

Re: [syslog-ng] [PATCH RFC] Use cap_syslog when it is available (v3)
by Gergely Nagy 18 Apr '11

18 Apr '11

Serge Hallyn <serge.hallyn(a)canonical.com> writes: > (A-ha - great idea from Andrew - we *can* figure out whether the > kernel knows about CAP_SYSLOG, using the bounding set API) > > If cap_syslog exists, the kernel will complain (once) that we only > have cap_sys_admin. Additionally, using cap_syslog instead of > cap_sys_admin significantly lowers the unneeded privs we are > using. > > Changelog: > v2: At startup, detect whether libcap knows about CAP_SYSLOG. > (Thanks to Gergely Nagy for pointing out that case) > v3: Andrew Morgan pointed out a nice way to detect whether > the kernel has CAP_SYSLOG. Thanks, Andrew! > > Signed-off-by: Serge Hallyn <serge.hallyn(a)ubuntu.com> Looks good to me! -- |8]

1 0

[PATCH RFC] Use cap_syslog when it is available
by Serge Hallyn 18 Apr '11

18 Apr '11

If cap_syslog exists, the kernel will complain (once per boot) that we only have cap_sys_admin. Ideally, we would detect whether the kernel knows about cap_syslog, and not use cap_sys_admin if it does. However, there is no good way to deduce that. We can only detect whether userspace knows about it, and kernel may not match userspace. I will work to get such polling into the kernel and, when successful, will provide a syslog-ng patch to use that, so that when CAP_SYSLOG is supported by the kernel, we can reduce the amount of privilege we needlessly take. Signed-off-by: Serge Hallyn <serge.hallyn(a)ubuntu.com> --- lib/gprocess.c | 35 ++++++++++++++++++++++++++++++++++- lib/gprocess.h | 2 +- modules/affile/affile.c | 3 +++ syslog-ng/main.c | 10 +++------- 4 files changed, 41 insertions(+), 9 deletions(-) diff --git a/lib/gprocess.c b/lib/gprocess.c index d9a2dfb..0884237 100644 --- a/lib/gprocess.c +++ b/lib/gprocess.c @@ -416,7 +416,7 @@ g_process_set_working_dir(const gchar *cwd) * capability set. The process will change its capabilities to this value * during startup, provided it has enough permissions to do so. **/ -void +static void g_process_set_caps(const gchar *caps) { if (!process_opts.caps) @@ -879,6 +879,39 @@ g_process_change_dir(void) } /** + * g_process_setup_caps(void) + * + * NOTE: polling /proc/kmsg requires cap_sys_admin, otherwise it'll always + * indicate readability. Enabling/disabling cap_sys_admin on every poll + * invocation seems to be too expensive. So I enable it for now. + * + * If CAP_SYSLOG exists, add that to our list of capabilities alongside + * CAP_SYS_ADMIN. Ideally we would *replace* it. However, we currently + * have no reliable way to check whether the kernel - which may not + * match userspace - supports it. If it doesn't, there is no harm in + * adding CAP_SYSLOG, but we of course still need CAP_SYS_ADMIN for + * /proc/kmsg. + * + * Once the kernel supports polling for the number of capabilities, we + * can drop CAP_SYSLOG after detecting whether CAP_SYSLOG exists. + */ +void +g_process_setup_caps(void) +{ +#ifdef CAP_SYSLOG + gchar * capsstr = "cap_net_bind_service,cap_net_broadcast,cap_net_raw," + "cap_dac_read_search,cap_dac_override,cap_chown,cap_fowner=p " + "cap_syslog,cap_sys_admin=ep"; +#else + gchar * capsstr = "cap_net_bind_service,cap_net_broadcast,cap_net_raw," + "cap_dac_read_search,cap_dac_override,cap_chown,cap_fowner=p " + "cap_sys_admin=ep"; +#endif + + g_process_set_caps(capsstr); +} + +/** * g_process_send_result: * @ret_num: exit code of the process * diff --git a/lib/gprocess.h b/lib/gprocess.h index cda35b0..4ad0866 100644 --- a/lib/gprocess.h +++ b/lib/gprocess.h @@ -66,7 +66,7 @@ void g_process_set_chroot(const gchar *chroot); void g_process_set_pidfile(const gchar *pidfile); void g_process_set_pidfile_dir(const gchar *pidfile_dir); void g_process_set_working_dir(const gchar *cwd); -void g_process_set_caps(const gchar *caps); +void g_process_setup_caps(void); void g_process_set_argv_space(gint argc, gchar **argv); void g_process_set_use_fdlimit(gboolean use); void g_process_set_check(gint check_period, gboolean (*check_fn)(void)); diff --git a/modules/affile/affile.c b/modules/affile/affile.c index a713bfc..b11b7ac 100644 --- a/modules/affile/affile.c +++ b/modules/affile/affile.c @@ -59,6 +59,9 @@ affile_open_file(gchar *name, gint flags, if (privileged) { g_process_cap_modify(CAP_DAC_READ_SEARCH, TRUE); +#ifdef CAP_SYSLOG + g_process_cap_modify(CAP_SYSLOG, TRUE); +#endif g_process_cap_modify(CAP_SYS_ADMIN, TRUE); } else diff --git a/syslog-ng/main.c b/syslog-ng/main.c index 7e81f2f..5e62c1f 100644 --- a/syslog-ng/main.c +++ b/syslog-ng/main.c @@ -167,13 +167,9 @@ main(int argc, char *argv[]) g_process_set_argv_space(argc, (gchar **) argv); - /* NOTE: polling /proc/kmsg requires cap_sys_admin, otherwise it'll always - * indicate readability. Enabling/disabling cap_sys_admin on every poll - * invocation seems to be too expensive. So I enable it for now. */ - - g_process_set_caps("cap_net_bind_service,cap_net_broadcast,cap_net_raw," - "cap_dac_read_search,cap_dac_override,cap_chown,cap_fowner=p " - "cap_sys_admin=ep"); + /* Set up the minimal privilege we'll need */ + g_process_setup_caps(); + ctx = g_option_context_new("syslog-ng"); g_process_add_option_group(ctx); msg_add_option_group(ctx); -- 1.7.4.1

2 1

Problem with Squid logs
by Matias Banchoff 15 Apr '11

15 Apr '11

Hello, I have a problem with remote logging for Squid logs. Our setup is the following: - syslog-ng server: syslog-ng 3.1.3. It is a dedicated server for logging. From now on, the server. - syslog-ng in Squid: syslog-ng 2.0.9. From now on, the client. The Squid process writes three log files: access.log, store.log and cache.log. I have configured the client syslog-ng to send those files to the log server. The problem is that the content of those files are sent only when syslog-ng starts on the client side. So: 1) The syslog-ng client writes all the information to the local files (access, cache and store). So, locally, it works. 2) The information is sent, but only when the client syslog-ng process restarts. So it is not a networking problem. 3) And, I've left the default config for all the other log stuff (like messages, syslog, etc.). That information is also sent to the log server. And, in this case, the information is sent constantly. I mean, I don't have to restart the syslog-ng client to make the Squid machine send the "messages", "syslog", "mail" and other logs. I've googled a while, but the only thing I found was some article about delayed logs, but it was due a bad timestamp. The thing here is Squid writes its logs with a strange timestamp: "1302699202.239", for example. Is there any way to translate that Squid timestamp into a more readable one, so I can probe if that is the problem? In addition, I've started syslog-ng client y debug mode (with -d -F), but nothing appears in the screen, although the logs are being written. Thank you for any answer or comment you might have :-) ----- CeSPI Centro Superior para el Procesamiento de la Información Universidad Nacional de La Plata ------------------------------------------------------------------------------- Proteja el Medioambiente. No imprima este mail si no es absolutamente necesario

4 4

Current stable version of syslog-ng
by Yu Watanabe 15 Apr '11

15 Apr '11

Hello all. I would like to ask a question regarding to the version of syslog-ng. Which version would be the most stable version for now? v 3.0.10 v 3.1.4 v 3.2.2 I asked the same question before but I didn't recieve a reply so I would like to ask again. Thanks, Yu Watanabe

3 2

syslog-ng Insider - April 2011
by Peter Czanik 14 Apr '11

14 Apr '11

Dear syslog-ng users, This is the second issue of the syslog-ng Insider, a monthly newsletter that brings you syslog-ng related news. Your feedback and news tips about the next issue is welcome at documentation(a)balabit.com <mailto:documentation@balabit.com> FEATURED NEWS syslog-ng OSE 3.3 development ----------------------------- The next syslog-ng release is developed at rocket speed. The second alpha release brought in support for MongoDB as destination, and threading for increased performance and scalability. Community involvement in the development process is increasing, with many patches and detailed bug reports, which helped to fix correlation problems. Direct SMTP support is also available as a not yet merged patch. There were also long discussions about JSON and name value pairs with value-pairs() and tfjson() available as patches. One can download the alpha2 release, or if impatient also check it out from git, which has regular updates at http://git.balabit.hu/?p=bazsi/syslog-ng-3.3.git;a=summary Alpha2 release: https://bazsi.blogs.balabit.com/2011/03/the-2nd-alpha-for-syslog-ng-3-3-is-… Mailing list archive with many patches: https://lists.balabit.hu/pipermail/syslog-ng/ A blog, how to get started with coding: http://algernon.blogs.balabit.com/2011/01/howto-write-a-simple-template-fun… syslog-ng called open source project of the year ------------------------------------------------ IDG hold its first Open Source conference on the 24th of February in Hungary. A new award was established for open source projects, and it was first given to syslog-ng OSE. Blog series on web GUIs for syslog-ng ------------------------------------- Web based GUIs for syslog-ng is a hot topic recently, so a new blog series was started. Loganalyzer, Loggly and Logzilla are already covered and a few more reviews (ELSA, Octopussy) are already under way. If you have any suggestions what else to cover, please let us know! Logzilla (formerly php-syslog-ng): http://czanik.blogs.balabit.com/2011/04/logzilla-brings-syslog-ng-and-cisco… Loganalyzer: https://czanik.blogs.balabit.com/2011/02/loganalyzer/ Loggly: https://czanik.blogs.balabit.com/2011/03/logging-to-the-cloud/ Support the syslog-ng project with your testimonial! ---------------------------------------------------- We send syslog-ng T-Shirts for the best use-cases and testimonials. We are especially interested in how you use syslog-ng: your environment, performance metrics, the UNIX platforms that you use and anything that you deem interesting about your setup. This is your possibility to influence the syslog-ng development process and to help the syslog-ng project. http://www.balabit.com/testimonials/send OTHER SHORT NEWS * openSUSE 11.4 comes with syslog-ng 3.2: https://czanik.blogs.balabit.com/2011/03/opensuse-11-4-with-syslog-ng-and-s… * FreeBSD 8.2 comes with syslog-ng 3.2: https://czanik.blogs.balabit.com/2011/02/freebsd-8-2-released/ * Intrusion prevention based on syslog-ng and patterndb: https://bazsi.blogs.balabit.com/2011/02/another-nice-hack-with-syslog-ng/ * ELSA (Enterprise Log Search and Archive Project) had its first public release: http://code.google.com/p/enterprise-log-search-and-archive RECENT WHITEPAPERS * http://www.balabit.com/whitepaper?wp=8988187171444164966624785 This document aims at briefly demonstrating the technological and business processes that led to the revaluation of log information to such an extent that its collection and procession has become one of the most essential tasks of contemporary corporate IT. Furthermore, we attempt to identify those critical points of a central logging management project that determine its success the most. We hope that taking our six pieces of advice relating to these six points will substantially contribute to the successful professional activities of our readers. ARCHIVE http://insider.blogs.balabit.com/ -- Peter Czanik (CzP) <czanik(a)balabit.hu> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/

1 0

Openssl SSL3_WRITE_PENDING error correction
by Juhasz Viktor 12 Apr '11

12 Apr '11

Hi All! We've found a bug in the log_proto_framed_client. The bug is the following: - using ssl communication between the server and client. - using syslog protocol - If client send messages faster than the server can process messages, then the client go into the SSL3_WRITE_PENDING openssl error and close the connection. partial message handling correction: the flush is called only if proto have partially sent message after flush is called log_proto_text_client_post have to return because the post send one message per call it is important in case of framed messages diff --git a/lib/logproto.c b/lib/logproto.c index d821275..7f2f897 100644 --- a/lib/logproto.c +++ b/lib/logproto.c @@ -145,9 +145,13 @@ log_proto_text_client_post(LogProto *s, guchar *msg, gsize msg_len, gboolean *co g_assert(self->super.convert == (GIConv) -1); *consumed = FALSE; - rc = log_proto_flush(s); - if (rc == LPS_ERROR) - goto write_error; + if(self->partial) + { + rc = log_proto_flush(s); + if (rc == LPS_ERROR) + goto write_error; + return rc; + } /* OK, partial buffer empty, now flush msg that we just got */ @@ -1774,6 +1778,7 @@ log_proto_framed_client_new(LogTransport *transport) self->super.super.prepare = log_proto_text_client_prepare; self->super.super.post = log_proto_framed_client_post; + self->super.super.flush = log_proto_text_client_flush; self->super.super.transport = transport; self->super.super.convert = (GIConv) -1; return &self->super.super; Best Regards, Viktor

3 4