April 2011 - syslog-ng - lists.balabit.hu

Solaris 10_x86 server.
by sramesh.kumar＠wipro.com 27 Apr '11

27 Apr '11

Hi All, Can any body help me. Please????? I hve configured syslog-ng in X86 server. Bellow is the configuration. But Logs are not coming under /syslog-ng folder.....if I am wrong in bellow configuration, can you Please Provide step by step configuration Procedure to configure the same... # cat /etc/syslog-ng/syslog-ng.conf options { sync (0); time_reopen (10); log_fifo_size (1000); long_hostnames (off); use_dns (no); use_fqdn (no); create_dirs (yes); keep_hostname (yes); }; source s_sys { file ("/proc/kmsg" log_prefix("kernel: ")); sun-stream ("/dev/log"); internal(); }; # External Source source s_ext { # Standard Syslog udp(); # All interfaces tcp(); # All interfaces on tcp port sun-stream("/dev/log"); }; destination d_cons { file("/dev/console"); }; destination d_mesg { file("/var/adm/messages"); }; destination d_mail { file("/var/log/syslog"); }; destination d_auth { file("/var/log/authlog"); }; destination d_mlop { usertty("operator"); }; destination d_mlrt { usertty("root"); }; destination d_mlal { usertty("*"); }; destination d_ext { file("/syslog-ng/$HOST/$YEAR/$MONTH/$DAY/$FACILITY$YEAR$MONTH$DAY" \ owner(root) group(root) perm(0650) dir_perm(0750) create_dirs(yes)); create_dirs(yes)); }; filter f_filter1 { level(err) or (level(notice) and facility (auth, kern)); }; filter f_filter2 { level(err) or (facility(kern) and level(notice)) or (facility(daemon) and level(notice)) or (facility(mail) and level(crit)); }; filter f_filter3 { level(alert) or (facility(kern) and level(err)) or (facility(daemon) and level(err)); }; filter f_filter4 { level(alert); }; filter f_filter5 { level(emerg); }; filter f_filter6 { facility(kern) and level(notice); }; filter f_filter7 { facility(mail) and level(debug); }; filter f_filter8 { facility(user) and level(err); }; filter f_filter9 { facility(user) and level(alert); }; log { source(s_sys); filter(f_filter1); destination(d_cons); }; log { source(s_sys); filter(f_filter2); destination(d_mesg); }; log { source(s_sys); filter(f_filter3); destination(d_mlop); }; log { source(s_sys); filter(f_filter4); destination(d_mlrt); }; log { source(s_sys); filter(f_filter5); destination(d_mlal); }; log { source(s_sys); filter(f_filter6); destination(d_auth); }; log { source(s_sys); filter(f_filter7); destination(d_mail); }; log { source(s_sys); filter(f_filter8); destination(d_cons); destination(d_mesg); }; log { source(s_ext); destination(d_ext); }; # isainfo -kv 64-bit amd64 kernel modules # cat /etc/release Solaris 10 10/08 s10x_u6wos_07b X86 Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 27 October 2008 # pkginfo -l SMCsyslng PKGINST: SMCsyslng NAME: syslogng CATEGORY: application ARCH: x86 VERSION: 2.0.5 BASEDIR: /usr/local VENDOR: BalaBit IT Ltd PSTAMP: Steve Christensen INSTDATE: Apr 20 2011 16:24 EMAIL: steve(a)smc.vnet.net STATUS: completely installed FILES: 64 installed pathnames 3 shared pathnames 15 directories 2 executables 2163 blocks used (approx) Thanks & Regards, Ramesh Kumar, Wipro Infotech Hyderabad, Mobile: +91 905 221 3330 * : sramesh.kumar(a)wipro.com <mailto:sramesh.kumar@wipro.com> Intensity to Win Act with Sensitivity Unyielding Integrity Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

3 4

syslog-ng 3.1.2 - Changing location of syslog-ng.pid file causes problems
by Zeek Anow 27 Apr '11

27 Apr '11

We are running Solaris 10 Update 9, syslog-ng 3.1.2 - version details at bottom of this msg. I wanted the syslog-ng.pid file to be located in swap so it would be cleared after a reboot. I also did not like the idea of creating the /usr/local/var/run directories, so: I modified the /lib/svc/method file and then validated and imported the syslog-ng.xml file. I stopped/disabled the syslog-ng process to make this change. So now, I have 3 problems, but syslog-ng is running, and I can't imagine how:)). 1. I cannot find the 2 files syslog-ng.pid or syslog-ng.ctl files anywhere on the system. I did a global find which searches the entire disk. 2. When syslog-ng started up, I got the following msg, and it is true: Error opening control socket, bind() failed; socket='/usr/local/var/syslog-ng.ctl', error='No such file or directory. 3. Before I made the change, a ps was showing: root 5769 1 7 7 0 Apr 21 ? 0:00 /usr/local/sbin/syslog-ng root 5770 5769 5770 5770 13 Apr 21 ? 5618:33 /usr/local/sbin/syslog-ng cat /usr/local/var/syslog-ng.pid 5770 As you can see, the PID is 5770. Shouldn't that be 5769?? ******End of 3 questions ******** I have this same version of syslog-ng on another server, but I have not yet changed the location of the syslog-ng.pid file. The change I made was FROM: PIDFILE=$SYSLOGNG_PREFIX/var/run/syslog-ng.pid TO: PIDFILE=/var/run/syslog-ng.pid The config part of the method file is now: #SYSLOGNG_PREFIX=/opt/syslog-ng SYSLOGNG_PREFIX=/usr/local SYSLOGNG="$SYSLOGNG_PREFIX/sbin/syslog-ng" CONFFILE=$SYSLOGNG_PREFIX/etc/syslog-ng.conf PIDFILE=/var/run/syslog-ng.pid SYSLOGPIDFILE=/var/run/syslog.pid OPTIONS= MAXWAIT=30 [root] # syslog-ng -V syslog-ng 3.1.2 Installer-Version: 3.1.2 Revision: ssh+git://bazsi@git.balabit //var/scm/git/syslog-ng/syslog-ng-ose--mainline--3.1#master#8bf13c304b6ab5fc1a372b49d55c78370efe14ca Compile-Date: Oct 25 2010 23:56:18 Enable-Threads: off Enable-Debug: off Enable-GProf: off Enable-Memtrace: off Enable-Sun-STREAMS: on Enable-Sun-Door: on Enable-IPv6: on Enable-Spoof-Source: on Enable-TCP-Wrapper: off Enable-SSL: on Enable-SQL: off Enable-Linux-Caps: off Enable-Pcre: on [root@ecrsyslg00/usr/local]#

2 6

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