- syslog-ng - lists.balabit.hu

[RFC]: Pattern matching & corellation ideas
by Gergely Nagy 11 Sep '12

11 Sep '12

In the past few months, I talked a lot about patterndb and related things with colleagues - during coffee break, over a beer, etc -, and last night, I got as far as drafting a proof of concept tool that realizes some of the ideas we've had. Some of these might have been discussed on this list too, in the past, I really can't remember all the influences I'm afraid. Anyway! I like the concept of patterndb, but I absolutely hate XML. It's not a natural format for describing how to match patterns, and what to do with them. Not for me, anyway. I'd like something that is much closer to how I normally think, something that feels more like a programming language, a domain specific one, engineered for this task only, but still somewhat familiar. I also want it to be fast. For a long time, I also wanted to play with developing both a Domain Specific Language (DSL for short) and a compiler, but never had the opportunity. Pattern matching is one now! How about a small language, that we'd compile down to C, automatically add some boilerplate, and we'd get a syslog-ng parser plugin in return? That would mean the language is fairly easy to extend, it produces native code, which will hopefully run as fast - if not faster - than patterndb, and we skip the entire XML pile too! To demonstrate, this is what I've been thinking of: ,---- | (cond :message | (match "foo (bar) ([:number:])") | (do | (set! :bar "$1") | (set! :stuff "$2") | (conj! :tags "test stuff"))) | | (deftest message-match | "this is a foo bar 1234 message!" | | (== :bar "bar") | (== :stuff "1234") | (contains? :tags "test stuff")) `---- This would compile down to roughly the following C code (with the test excluded, for now): ,---- | gboolean | m_something(LogMsg *message, GString *subject) | { | GString *m1; /* ([:number:]) */ | | /* The subject must be at least as long as the static strings in the | pattern, if it's shorter, we don't match */ | if (subject->len < 8) | return FALSE; | | /* If we don't find part of the pattern, bail out. */ | if (strncmp(subject->str, "foo bar ") != 0) | return FALSE; | | if (!find_number(subject->str + 8, &m1)) | return FALSE; | | /* The whole stuff matched, yay! Lets fill in the fields. */ | | /* "bar" is a static string, fill it in as-is, no need to extract it | from the subject. */ | log_msg_set_value(msg, "bar", "bar", 3); | | /* :stuff is a number, so that needs to come from the | subject. Thankfully find_number() already did the extraction for | us. */ | log_msg_set_value(msg, "stuff", m1->str, m1->len); | | log_msg_set_tag_by_name(msg, "test stuff"); | | return TRUE; | } `---- I believe this is pretty efficient, the code generator can comment the the generated source nicely too. If we add named capture-groups, then the variables used can have meaningful names too! For example: (match "this (?<object>[:qstring:]) is good") In this case, the variable would be called m_object. However, the pattern-string is a bit awkward, when the rest is lispy, it also complicates the generator, so I was thinking of turning the pattern into a lispy syntax too: ,---- | (match "foo " (capture "bar") " " (capture :number)) `---- Or, with named capture groups added: ,---- | (match "this " (capture :qstring :as "object") " is good") `---- Of course, the action to take on a match can also contain another cond+match pair, so it can be nested as deep as one wishes to, the compiler will compile each cond into a separate function, and just call the appropriate one. Or perhaps inline them - that's an implementation detail, and doesn't really matter. The big advantage I see, is a DSL that is much closer to how I think, one that has the potential to produce a compact parser, one that is also easy to debug with conventional tools (gdb ;) because it compiles down to C. There is less run-time overhead too. Also, if implemented correctly, the generator would have the parser and the code generator entirely independent, so adding a different syntax would be as easy as writing a parser that produces the same abstract syntax tree the generator works with. This way, for those who're more familiar with C-like languages, the above matcher could be rewritten like this: ,---- | switch ($message) | { | case match("foo ", capture("bar"), " ", capture(:number:)) | { | set("bar", "$1"); | set("stuff", "$2"); | append($tags, "test stuff"); | } | } `---- And it would compile down to the exact same C code, accompanied by an appropriate autotools-based build system, so all you'd have to do in the end is to write the matcher, and issue the following commands: ,---- | $ matcher-generate test-patterns.pm | $ cd test-patterns | $ autoreconf -i && ./configure && make && make install `---- And finally, modify your syslog-ng.conf: ,---- | @module test-patterns | parser p_test { parser(test-patterns); }; `---- It does have downsides, though, namely that you need to regenerate & recompile the module and restart syslog-ng each time you modify the source, which is less convenient than just restarting syslog-ng itself. One also needs to learn a 'new' language to write pattern matchers in (but one has to learn patterndb too, anyway, so this isn't that big a disadvantage, especially since a more language-like thing is, in my opinion, easier to learn :). However, I believe that the advantages are worth it. For me, they certainly do, so I already started to hash out a proof of concept. So far, my PoC code can generate C functions, and supports a small subset of the DSL explained below. Do note that all this does not include corellation, because I believe that corellation should be separate from parsing, and a similar technique could be used to write advanced corellation setups - I will go into detail once I have a working proof of concept compiler for the parser. As a start, the DSL would support the following constructs: Top-level constructs: --------------------- * (cond :field condition action ...) Where :field can be any field, condition is a single condition function (see below) and action is a single action too (see even further below). Any number of condition-action paris can be specified, the first one matching will win, and the rest won't be tried. These two must always be paired together. * (deftest test-name "source string" test-conditions) Right now, lets ignore this. But in the long run, I want to be able to write down reasonably complex tests too. Not entirely sure yet what I need it to do though. Condition functions: -------------------- * (match pattern-spec) Matches a pattern-spec, simple as that. See below for the definition of the pattern-spec! * (not-match pattern-spec) The opposite of (match): action is triggered if the pattern does not match. * (exists?) Triggers the action if the field in the condition exists. * (not-exists?) Opposite of (exists?). * :default or (always) Always triggers, so one can do catch-all actions. Action functions: ----------------- * (set! :field value) * (clear! :field) These two should speak for themselves, I believe. * (conj! :field values) Conjoin (append) values to the specified field. Some fields (:tags) that need to be, will be treated specially, otherwise it just appends a separator (",") and the values. * (do actions...) Does all the specified actions. Pattern spec: ------------- The pattern can be built up from the sequence of the following things, in any order: * A plain string * (capture pattern-spec [:as name]) This just marks the pattern-spec as something to capture. While the implementation may produce code that captures things anyway, the only guarantee that something will be available for the actions, is to wrap it in (capture). The pattern-spec can be anything, it can contain nested captures. If :as name is specified, the capture will be named, and actions can refer to the captured thing by name. Otherwise, they need to refer it by a number. Each capture - named or anonymous - has a different number, starting from one, increasing with each occurrence of (capture). * Any of the following special keywords: * :number * :string * :qstring * :ipv4-address * :ipv6-address * :mac-address Future ideas ------------ Later, once the basics are ready and work, it would make sense to introduce a way to share common blocks of code: functions and perhaps variables. Conclusion ========== XML sucks, DSL rocks. Feedback appreciated, be that on the syntax, or the initially proposed features/functions/etc, or anything else. -- |8], who perhaps spent a little too much time near LISP-y stuff

4 8

Syslog-NG/Log Analyzer
by James McDonald 11 Sep '12

11 Sep '12

I finally got my syslog-ng servers to pass logs to the MySQL db, but was having some problems getting LogAnalzyer to access the db. I re-installed Log Analyzer but now I am getting an access denied error: Connection to the database server failed. Access denied for user 'syslog'@'FQDN_for_mysql_server.com' (using password: YES). Here is the output of the grants for the 'syslog' user: CODE: <http://kb.monitorware.com/> SELECT ALL mysql> show grants for 'syslog'@'FQDN_for_mysql_server.com'; +--------------------------------------------------------------------------- ---------+ | Grants for syslog(a)FQDN_for_mysql_server.com | +--------------------------------------------------------------------------- ---------+ | GRANT USAGE ON *.* TO 'syslog'@'FQDN_for_mysql_server.com' | | GRANT ALL PRIVILEGES ON `Syslog`.* TO 'syslog'@'FQDN_for_mysql_server.com' | +--------------------------------------------------------------------------- ---------+ 2 rows in set (0.00 sec) And here is what my config.php looks like: $CFG['DefaultSourceID'] = 'Source1'; $CFG['Sources']['Source1']['ID'] = 'Source1'; $CFG['Sources']['Source1']['Name'] = 'Syslog'; $CFG['Sources']['Source1']['ViewID'] = 'SYSLOG'; $CFG['Sources']['Source1']['SourceType'] = SOURCE_DB; $CFG['Sources']['Source1']['DBTableType'] = 'syslogng'; $CFG['Sources']['Source1']['DBType'] = DB_MYSQL; $CFG['Sources']['Source1']['DBServer'] = 'ustc-mysql'; $CFG['Sources']['Source1']['DBName'] = 'Syslog'; $CFG['Sources']['Source1']['DBUser'] = 'syslog'; $CFG['Sources']['Source1']['DBPassword'] = 'pTRl819ELI0viRmXaEUO'; $CFG['Sources']['Source1']['DBTableName'] = 'SystemEvents'; $CFG['Sources']['Source1']['DBEnableRowCounting'] = false; Thanks, James McDonald System Administrator RHCSA, Security+ jmcdonald(a)lce.com

2 3

[Bug 161] New: Syslog-ng stops processing after reload
by bugzilla＠bugzilla.balabit.com 10 Sep '12

10 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=161 Summary: Syslog-ng stops processing after reload 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: bugzilla.syslogng(a)feystorm.net Type of the Report: --- Estimated Hours: 0.0 syslog-ng version: 3.3.4 OS: RHEL 6.2 Whenever I issue a reload to our syslog-ng instance syslog-ng stops processing messages and sits there doing nothing. The issue only seems to occur when the server is processing a high log volume. This server is part of a 2-node active/passive HA group. So we have 2 servers with the exact same configuration. Whenever I issue the reload on the server that is not currently active, it works fine. I can issue a failover and the server that was able to reload fine now hangs. The active server in this HA group processes around 35,000 messages per second. I havent posted the config because it is fairly large, however I can if desired. The most notable thing in it is that threading is enabled. Below is the backtrace of syslog-ng stuck in this state. I took a gcore, so I can gather any additional information that is needed. Also, if I try to do a full backtrace ('where full') in gdb on any thread other than thread 5, gdb segfaults. Not sure if that has any relevance or not. (gdb) info threads 5 Thread 0x7fb9c654ab00 (LWP 11040) 0x000000353cedd967 in writev () from /lib64/libc.so.6 4 Thread 0x7fb9c25fb700 (LWP 11049) 0x000000353cee5d03 in epoll_wait () from /lib64/libc.so.6 3 Thread 0x7fb9c2ffc700 (LWP 11048) 0x000000353cee5d03 in epoll_wait () from /lib64/libc.so.6 2 Thread 0x7fb9c39fd700 (LWP 11046) 0x000000353cee5d03 in epoll_wait () from /lib64/libc.so.6 * 1 Thread 0x7fb9c43fe700 (LWP 11045) 0x000000353cee5d03 in epoll_wait () from /lib64/libc.so.6 (gdb) where #0 0x000000353cee5d03 in epoll_wait () from /lib64/libc.so.6 #1 0x00007fb9c65cfa3e in iv_epoll_poll (numfds=1, active=0x7fb9c43fb9a0, msec=10000) at iv_method_epoll.c:73 #2 0x00007fb9c65cf1bb in iv_main () at iv_main.c:265 #3 0x00007fb9c65d3c36 in iv_work_thread (_thr=0x14fc610) at iv_work.c:196 #4 0x00007fb9c65d42a8 in iv_thread_handler (_thr=0x14fc6e0) at iv_thread.c:100 #5 0x000000353d2077f1 in start_thread () from /lib64/libpthread.so.0 #6 0x000000353cee570d in clone () from /lib64/libc.so.6 (gdb) thread 2 [Switching to thread 2 (Thread 0x7fb9c39fd700 (LWP 11046))]#0 0x000000353cee5d03 in epoll_wait () from /lib64/libc.so.6 (gdb) where #0 0x000000353cee5d03 in epoll_wait () from /lib64/libc.so.6 #1 0x00007fb9c65cfa3e in iv_epoll_poll (numfds=1, active=0x7fb9c39fa9a0, msec=10000) at iv_method_epoll.c:73 #2 0x00007fb9c65cf1bb in iv_main () at iv_main.c:265 #3 0x00007fb9c65d3c36 in iv_work_thread (_thr=0x14fc8e0) at iv_work.c:196 #4 0x00007fb9c65d42a8 in iv_thread_handler (_thr=0x14fc9b0) at iv_thread.c:100 #5 0x000000353d2077f1 in start_thread () from /lib64/libpthread.so.0 #6 0x000000353cee570d in clone () from /lib64/libc.so.6 (gdb) thread 3 [Switching to thread 3 (Thread 0x7fb9c2ffc700 (LWP 11048))]#0 0x000000353cee5d03 in epoll_wait () from /lib64/libc.so.6 (gdb) where #0 0x000000353cee5d03 in epoll_wait () from /lib64/libc.so.6 #1 0x00007fb9c65cfa3e in iv_epoll_poll (numfds=1, active=0x7fb9c2ff99a0, msec=10000) at iv_method_epoll.c:73 #2 0x00007fb9c65cf1bb in iv_main () at iv_main.c:265 #3 0x00007fb9c65d3c36 in iv_work_thread (_thr=0x15635c0) at iv_work.c:196 #4 0x00007fb9c65d42a8 in iv_thread_handler (_thr=0x14fc380) at iv_thread.c:100 #5 0x000000353d2077f1 in start_thread () from /lib64/libpthread.so.0 #6 0x000000353cee570d in clone () from /lib64/libc.so.6 (gdb) thread 4 [Switching to thread 4 (Thread 0x7fb9c25fb700 (LWP 11049))]#0 0x000000353cee5d03 in epoll_wait () from /lib64/libc.so.6 (gdb) where #0 0x000000353cee5d03 in epoll_wait () from /lib64/libc.so.6 #1 0x00007fb9c65cfa3e in iv_epoll_poll (numfds=1, active=0x7fb9c25f89a0, msec=10000) at iv_method_epoll.c:73 #2 0x00007fb9c65cf1bb in iv_main () at iv_main.c:265 #3 0x00007fb9c65d3c36 in iv_work_thread (_thr=0x1566d20) at iv_work.c:196 #4 0x00007fb9c65d42a8 in iv_thread_handler (_thr=0x1566a70) at iv_thread.c:100 #5 0x000000353d2077f1 in start_thread () from /lib64/libpthread.so.0 #6 0x000000353cee570d in clone () from /lib64/libc.so.6 (gdb) thread 5 [Switching to thread 5 (Thread 0x7fb9c654ab00 (LWP 11040))]#0 0x000000353cedd967 in writev () from /lib64/libc.so.6 (gdb) where #0 0x000000353cedd967 in writev () from /lib64/libc.so.6 #1 0x00007fb9c65820f8 in log_proto_file_writer_flush (s=0x171b5a0) at logproto.c:270 #2 0x00007fb9c658c403 in log_proto_flush (s=0x171b5a0) at logproto.h:86 #3 0x00007fb9c658ec3e in log_writer_flush (self=0x171adb0, flush_mode=LW_FLUSH_QUEUE) at logwriter.c:1032 #4 0x00007fb9c658f006 in log_writer_deinit (s=0x171adb0) at logwriter.c:1106 #5 0x00007fb9c63399d6 in log_pipe_deinit (s=0x171adb0) at ../../lib/logpipe.h:254 #6 0x00007fb9c633b3cd in affile_dw_deinit (s=0x171ac20) at affile.c:627 #7 0x00007fb9c63399d6 in log_pipe_deinit (s=0x171ac20) at ../../lib/logpipe.h:254 #8 0x00007fb9c633c211 in affile_dd_deinit_writer (key=0x171ad60, value=0x171ac20, user_data=0x0) at affile.c:974 #9 0x000000353e22a7a3 in g_hash_table_foreach () from /lib64/libglib-2.0.so.0 #10 0x00007fb9c633c349 in affile_dd_deinit (s=0x1539990) at affile.c:996 #11 0x00007fb9c6575d86 in log_pipe_deinit (s=0x1539990) at logpipe.h:254 #12 0x00007fb9c65761b4 in log_dest_group_deinit (s=0x1539ef0) at dgroup.c:76 #13 0x00007fb9c656f54c in log_pipe_deinit (s=0x1539ef0) at logpipe.h:254 #14 0x00007fb9c657078c in log_center_deinit (self=0x14f35c0) at center.c:576 #15 0x00007fb9c6571296 in cfg_deinit (cfg=0x14f1ca0) at cfg.c:261 #16 0x00007fb9c6590cac in main_loop_reload_config_apply () at mainloop.c:494 #17 0x00007fb9c6590aab in main_loop_io_worker_job_complete (self=0x156d160) at mainloop.c:417 #18 0x00007fb9c65d3ccc in iv_work_event (_pool=0x14f1bf0) at iv_work.c:221 #19 0x00007fb9c65d2862 in iv_event_run_pending_events (_dummy=0x0) at iv_event.c:67 #20 0x00007fb9c65d2cb5 in iv_event_raw_got_event (_this=0x7fb9c654aa18) at iv_event_raw.c:82 #21 0x00007fb9c65cefec in iv_run_active_list (active=0x7fff33ed17b0) at iv_main.c:219 #22 0x00007fb9c65cf1cc in iv_main () at iv_main.c:269 #23 0x00007fb9c65913e9 in main_loop_run () at mainloop.c:731 #24 0x00000000004016d0 in main () -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 7

[Bug 195] New: syslog 3.3.6.90 stats for src. unix-dgram do not show filesystem name
by bugzilla＠bugzilla.balabit.com 10 Sep '12

10 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=195 Summary: syslog 3.3.6.90 stats for src.unix-dgram do not show filesystem name 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 When using the syslog-ng-ctl to get statistics from syslog-ng the source stats look like; src.unix-dgram;local#1;;a;processed;2025 src.internal;local#0;;a;processed;54 src.file;local#2;/proc/kmsg;a;processed;273 for a configuration of source local { internal( tags("syslog.internal") ); unix-dgram("/dev/log" max_connections(10000) log_iw_size(1000000) ); file("/proc/kmsg" program_override("kernel") ); }; The file name of /proc/kmsg shows in the stats line for it, but the file name of /dev/log does not show in the stats line related to it. I think this is a bug and the /dev/log should show in the stats line. Evan. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 5

[Bug 144] New: incremental statistics and on reload and stop
by bugzilla＠bugzilla.balabit.com 07 Sep '12

07 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=144 Summary: incremental statistics and on reload and stop Product: syslog-ng Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: mdione.ext(a)orange.com Type of the Report: --- Estimated Hours: 0.0 syslog-ng log statistics in /var/log/messages (or some other defined destination), but it does it accumulatively. this makes it harder to make graphs, because the data collector must detect reloads and stop/starts. this most probably should not be done if the statistics are asked via syslog-ng-ctl. also, it does not print statistics on reload or stop, so the last values before the reload or stop are lost. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 2

[Bug 61] udp6 source declaration causes syslog forwarding to assume IPv6
by bugzilla＠bugzilla.balabit.com 07 Sep '12

07 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=61 --- Comment #4 from Gergely Nagy <algernon(a)balabit.hu> 2012-09-07 15:45:20 --- For what its worth, the quick workaround mentioned above is available here: https://github.com/algernon/syslog-ng/commit/edd84a5fcedb998949beccc18794b9… -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 61] udp6 source declaration causes syslog forwarding to assume IPv6
by bugzilla＠bugzilla.balabit.com 07 Sep '12

07 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=61 Gergely Nagy <algernon(a)balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #3 from Gergely Nagy <algernon(a)balabit.hu> 2012-09-07 15:39:23 --- The straightforward fix is to add a { last_addr_family = AF_INET; } to dest_afsyslog, similarly how it is done for the source part. But then we need syslog6() to use the protocol over IPv6, and we might need syslog(transport(udp6)) too (although, syslog6(transport(udp)) should be the same). I could send a patch - against 3.4 - that turns syslog() ipv4-only, and introduces syslog6(). On the other hand, the best would be if we didn't need the ipv4/ipv6 distinction at all, and whichever resolves would be used. I'd rather see that done. I'll try to see if the PE core has this, the team did some refactoring in the area. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 61] udp6 source declaration causes syslog forwarding to assume IPv6
by bugzilla＠bugzilla.balabit.com 07 Sep '12

07 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=61 Gergely Nagy <algernon(a)balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |algernon(a)balabit.hu AssignedTo|bazsi(a)balabit.hu |algernon(a)balabit.hu --- Comment #2 from Gergely Nagy <algernon(a)balabit.hu> 2012-09-07 15:14:09 --- This is still present in 3.3, and that is unfortunate since it just bit me. I'll see what I can do about it. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

Syslog-NG/MySQL question
by James McDonald 07 Sep '12

07 Sep '12

Here is the output of /opt/syslog-ng/sbin/syslog-ng -V: [root@ustc-syslog2 ~]# /opt/syslog-ng/sbin/syslog-ng -V syslog-ng-premium-edition 4 F2 (4.2.3) Installer-Version: 4.2.3 Revision: ssh+git://folti@git.balabit//var/scm/git/syslog-ng/syslog-ng-core--mainline- -4.2#master#725fff94b398b564b71f9de88808148b0dd2fc8d Compile-Date: Jul 4 2012 14:01:24 Default-Modules: affile,afprog,afsocket,afuser,basicfuncs,csvparser,dbparser,syslogformat,afl ogstore,disk-buffer,confighash,convertfuncs,basic-proto,rltp-proto,afsql,afs qlsource Available-Modules: afsql,license,afsocket-tls,afuser,tfjson,csvparser,affile,dbparser,rltp-prot o,afsocket-notls,dummy,confgen,aflogstore,basicfuncs,basic-proto,afsqlsource ,snmp,afsocket,syslogformat,disk-buffer,afprog,convertfuncs Enable-Debug: off Enable-GProf: off Enable-Memtrace: off Enable-IPv6: on Enable-Spoof-Source: on Enable-TCP-Wrapper: off Enable-Linux-Caps: on Enable-Pcre: on Does anyone know what needs to be edited/installed to have the line "Enable-SQL: on" be included in that output? I installed the following MySQL rpms on this server but I'm not sure what else needs to be done to have that line appear. MySQL-client-5.5.14-1.rhel5.x86_64.rpm MySQL-server-5.5.14-1.rhel5.x86_64.rpm MySQL-shared-compat-5.5.14-1.rhel5.x86_64.rpm MySQL-devel-5.5.14-1.rhel5.x86_64.rpm MySQL-shared-5.5.14-1.rhel5.x86_64.rpm MySQL-test-5.5.14-1.rhel5.x86_64.rpm Thanks, James McDonald System Administrator RHCSA, Security+ jmcdonald(a)lce.com

2 3

[Bug 188] New: Syslog-ng 3.3.5.90-20120810 problems: undefined symbol and ld.so library path
by bugzilla＠bugzilla.balabit.com 06 Sep '12

06 Sep '12

https://bugzilla.balabit.com/show_bug.cgi?id=188 Summary: Syslog-ng 3.3.5.90-20120810 problems: undefined symbol and ld.so library path Product: syslog-ng Version: 3.3.x Platform: PC OS/Version: Mac OS Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi(a)balabit.hu ReportedBy: jpo(a)di.uminho.pt Type of the Report: --- Estimated Hours: 0.0 Linux distro: Fedora 17 x86_64 Syslog-ng source tarball: syslog-ng-3.3.5.90-20120810-v3.3.5-43-g19f6c.tar.gz we have encountered a couple of problems when running syslog-ng-3.3.5.90-20120810 under Fedora 17 x86_64: 1) ld.so library path 2) undefined symbol: tls_context_setup_session Steps to reproduce the problem: 1) just run "/usr/sbin/syslog-ng --version" ---------- # /usr/sbin/syslog-ng --version syslog-ng 3.3.5.90 Installer-Version: 3.3.5.90 Revision: Compile-Date: Aug 17 2012 22:09:52 Default-Modules: affile,afprog,afsocket,afuser,basicfuncs,csvparser,dbparser,syslogformat,afsql Error opening plugin module; module='afsocket', error='libsyslog-ng-crypto.so: cannot open shared object file: No such file or directory' Error opening plugin module; module='afsocket-notls', error='//usr/lib64/syslog-ng/libafsocket-notls.so: undefined symbol: tls_context_setup_session' Error opening plugin module; module='afsocket-tls', error='libsyslog-ng-crypto.so: cannot open shared object file: No such file or directory' Available-Modules: dummy,afsql,tfjson,dbparser,csvparser,convertfuncs,afuser,basicfuncs,afmongodb,confgen,syslogformat,affile,afprog Enable-Debug: off Enable-GProf: off Enable-Memtrace: off Enable-IPv6: on Enable-Spoof-Source: on Enable-TCP-Wrapper: on Enable-Linux-Caps: on Enable-Pcre: on ---------- The library path problem can be solved by creating the file "/etc/ld.so.conf.d/syslog-ng.conf" containing the syslog-ng module directory ( /usr/lib64/syslog-ng in this particular case ). Running syslog-ng under strace without touching the ld.so library paths produces: ---------- # # strace -e trace=file /usr/sbin/syslog-ng --version ... access("//usr/lib64/syslog-ng/libafsocket.so", F_OK) = 0 stat("//usr/lib64/syslog-ng/libafsocket.so", {st_mode=S_IFREG|0755, st_size=103560, ...}) = 0 open("//usr/lib64/syslog-ng/libafsocket.so", O_RDONLY|O_CLOEXEC) = 4 open("/lib64/tls/libsyslog-ng-crypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib64/libsyslog-ng-crypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/x86_64/libsyslog-ng-crypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/tls/x86_64", 0x7fff0f81fcb0) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/libsyslog-ng-crypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/tls", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 open("/usr/lib64/x86_64/libsyslog-ng-crypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/x86_64", 0x7fff0f81fcb0) = -1 ENOENT (No such file or directory) open("/usr/lib64/libsyslog-ng-crypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64", {st_mode=S_IFDIR|0555, st_size=49152, ...}) = 0 Error opening plugin module; module='afsocket', error='libsyslog-ng-crypto.so: cannot open shared object file: No such file or directory' ... ----------- Note that all syslog-ng modules with the exception of libsyslog-ng-crypto.so are loaded from the syslog-ng modules directory. Output of "syslog-ng --version" after creating the file "/etc/ld.so.conf.d/syslog-ng.conf" ---------- # /usr/sbin/syslog-ng --version syslog-ng 3.3.5.90 Installer-Version: 3.3.5.90 Revision: Compile-Date: Aug 17 2012 22:09:52 Default-Modules: affile,afprog,afsocket,afuser,basicfuncs,csvparser,dbparser,syslogformat,afsql Error opening plugin module; module='afsocket-notls', error='//usr/lib64/syslog-ng/libafsocket-notls.so: undefined symbol: tls_context_setup_session' Available-Modules: dummy,afsocket,afsql,tfjson,dbparser,csvparser,convertfuncs,afuser,basicfuncs,afmongodb,afsocket-tls,confgen,syslogformat,affile,afprog Enable-Debug: off Enable-GProf: off Enable-Memtrace: off Enable-IPv6: on Enable-Spoof-Source: on Enable-TCP-Wrapper: on Enable-Linux-Caps: on Enable-Pcre: on ---------- /jpo -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 13