ok so i loged in as root sudo would not work for ti to find the path I am rusty and not sure on the setting of the EVTLOG_CFLAGS and such under root i get the config but in my make now i get errors on the make make all-recursive Making all in lib make all-am /bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/usr/local/include/eventlog -DHAVE_SOCKADDR_SA_LEN -DLIBNET_BSDISH_OS -DLIBNET_BSD_BYTE_SWAP -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -MT misc.lo -MD -MP -MF .deps/misc.Tpo -c -o misc.lo misc.c mv -f .deps/misc.Tpo .deps/misc.Plo mv: rename .deps/misc.Tpo to .deps/misc.Plo: No such file or directory make[3]: *** [misc.lo] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 On Sat, Jun 4, 2011 at 7:36 AM, <syslog-ng-request@lists.balabit.hu> wrote:
Send syslog-ng mailing list submissions to syslog-ng@lists.balabit.hu
To subscribe or unsubscribe via the World Wide Web, visit https://lists.balabit.hu/mailman/listinfo/syslog-ng or, via email, send a message with subject or body 'help' to syslog-ng-request@lists.balabit.hu
You can reach the person managing the list at syslog-ng-owner@lists.balabit.hu
When replying, please edit your Subject line so it is more specific than "Re: Contents of syslog-ng digest..."
Today's Topics:
1. Re: [PATCH 6/7] [system source]: Bail out on unknown systems, and use a clean environment. (Balazs Scheidler) 2. Re: 3.3b1: "EOF occurred while idle" (Balazs Scheidler) 3. Re: [Fw: keep_hostname (yes); and source file] (Balazs Scheidler) 4. [Bug 122] [3.2.4]: mixed linking broken for libsyslog-ng.so.* (bugzilla@bugzilla.balabit.com) 5. Re: syslog-ng Digest, Vol 73, Issue 37 (Balazs Scheidler) 6. Re: Fwd: Re: Question (Balazs Scheidler) 7. Re: issues with syslog-ng install of new version or running older version on mac osX 10.6.7 (Balazs Scheidler) 8. Re: Syslog-ng error while using TSL (Balazs Scheidler)
----------------------------------------------------------------------
Message: 1 Date: Sat, 04 Jun 2011 12:54:54 +0200 From: Balazs Scheidler <bazsi@balabit.hu> Subject: Re: [syslog-ng] [PATCH 6/7] [system source]: Bail out on unknown systems, and use a clean environment. To: Syslog-ng users' and developers' mailing list <syslog-ng@lists.balabit.hu> Message-ID: <1307184894.15963.195.camel@bzorp> Content-Type: text/plain; charset="UTF-8"
On Fri, 2011-06-03 at 10:14 +0200, Pal Tamas wrote:
On Thu, Jun 02, 2011 at 08:49:05PM +0200, Balazs Scheidler wrote:
On Mon, 2011-05-23 at 11:56 +0200, Gergely Nagy wrote:
From: Tamas Pal <folti@balabit.hu>
Force using OS's own uname implementation, over whatewer found in PATH. Die with error on an unsupported system or uname error.
Signed-off-by: Tamas Pal <folti@balabit.hu> --- scl/system/generate-system-source.sh | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/scl/system/generate-system-source.sh b/scl/system/generate-system-source.sh index d89fd33..6f5af70 100755 --- a/scl/system/generate-system-source.sh +++ b/scl/system/generate-system-source.sh @@ -23,6 +23,14 @@ #
#############################################################################
+# DO NOT REMOVE!!! +# We have to force the script to use the OS's own utilities, instead
of some
+# random stuff found in path. This is needed when PATH points to a uname binary +# with some missing dependencies, due to LD_LIBRARY_PATH/LIBPATH settings. In those case, it's possible, that uname doesn't work... +PATH=/bin:/usr/bin:$PATH +LIBPATH= +LD_LIBRARY_PATH= +export PATH LIBPATH LD_LIBRARY_PATH
os=${UNAME_S:-`uname -s`} osversion=${UNAME_R:-`uname -r`}
Hmm... I really don't get this, what if the admin really want to change the uname binary? Can you explain when this is needed? It was an AIX specific bug. On the test system, there are another uname from GNU binutils under /opt/freeware/bin which depends on their own libintl library located in /opt/freeware/lib. Due to AIX's own shared library handling(see below: [1]), this conflicted with our libintl implementation, rendering the uname binary inoperable.
Because the script didn't handle the case when uname returns nothing or unsupported OS info, it returned neither system log sources nor warning to the user(other than catching the dynamic linker's error message on console).
Other systems have more sane dynamic linkers and shared library handling policies, so it wouldn't cause the same problem, unless the system in question really messed up, but we can't do much about that. If your system's uname is broken (located in /bin or in case of UNIXes, /usr/bin - where /bin is a symlink to /usr/bin), then you have bigger problems than syslog-ng not working.
Other possible future problems, if the system have some AppArmor or SELinux like security suite installed, which would prevent executing binaries in non-standard paths, unless configured otherwise. This can be a problem for SCL's own scripts too.
[1]: AIX shared library handling:
On AIX the .so files themselves are packaged into .a archives and the dynamic linker's default behaviour is to look for them in there. In this case, the GNU uname depended on libintl.so.1 in a file libintl.a. Due to the limitations of the dynamic linker, it only looks into the first <libname>.a file found on path, if that one doesn't contain the needed .so it fails. In that case, the first libintl.a it found (due to inheriting LIBPATH from syslog-ng) was our own in /opt/syslog-ng/lib containing only a libintl.so.8.
+ *) + # need to notify the user that something gone
terribly wrong...
+ echo "$0: FATAL: unsupported OS ($os) or uname(1) error. Please call BalaBit's support" >&2 + exit 1 + ;;
hmm... most syslog-ng users would probably not have a support policy in place, so the error message should not advise that. Umm yes, I only the PE version in mind when I write that message.
If you have information on the first question, I'll integrate the patch with a slight change in the message, so no need for an updated patch.
A better solution would be to remove the syslog-ng specific portion of LD_LIBRARY_PATH env variable before executing user-supplied programs (confgen, program source & destination). The issue is that it's not easy to identify these points, and sometimes the exec() call itself is buried under several layers (popen for instance). This issue only happens if the env wrapper is enabled (--enable-env-wrapper), which is needed to run syslog-ng in /opt/syslog-ng and is used by both the PE and OSE binaries that we build.
Hmm... I think I'll just apply the patch, fixing the error message.
Thanks guys.
Here's the patch I've committed:
commit b7d46bc094215fa80f93e0dc46a3caa83e8a24b8 Author: Balazs Scheidler <bazsi@balabit.hu> Date: Sat Jun 4 12:54:07 2011 +0200
Bail out on unknown systems, and use a clean environment.
Force using OS's own uname implementation, over whatewer found in PATH. Die with error on an unsupported system or uname error.
Signed-off-by: Tamas Pal <folti@balabit.hu> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
-- Bazsi
------------------------------
Message: 2 Date: Sat, 04 Jun 2011 13:06:23 +0200 From: Balazs Scheidler <bazsi@balabit.hu> Subject: Re: [syslog-ng] 3.3b1: "EOF occurred while idle" To: Syslog-ng users' and developers' mailing list <syslog-ng@lists.balabit.hu> Message-ID: <1307185583.15963.197.camel@bzorp> Content-Type: text/plain; charset="UTF-8"
On Sun, 2011-05-29 at 22:02 +0100, Nix wrote:
On 29 May 2011, nix@esperi.org.uk outgrape:
(It also just coredumped, but this led to an autoreboot and the log was not preserved across the reboot :( )
I have several hundred coredumps on another system, all with the same backtrace:
#0 0x00007f3ad7c71aca in affile_dd_open_writer () from /usr/lib/syslog-ng/libaffile.so #1 0x00007f3ad7c73d16 in affile_dd_queue () from /usr/lib/syslog-ng/libaffile.so #2 0x00007f3ad9725850 in log_dest_group_queue () from /usr/lib/libsyslog-ng.so.0 #3 0x00007f3ad972b8b5 in log_multiplexer_queue () from /usr/lib/libsyslog-ng.so.0 #4 0x00007f3ad972b924 in log_multiplexer_queue () from /usr/lib/libsyslog-ng.so.0 #5 0x00007f3ad972b8b5 in log_multiplexer_queue () from /usr/lib/libsyslog-ng.so.0 #6 0x00007f3ad973fc87 in log_source_group_queue () from /usr/lib/libsyslog-ng.so.0 #7 0x00007f3ad9734d37 in log_source_queue () from /usr/lib/libsyslog-ng.so.0 #8 0x00007f3ad973310e in log_reader_work_perform () from /usr/lib/libsyslog-ng.so.0 #9 0x00007f3ad9733231 in log_reader_io_process_input () from /usr/lib/libsyslog-ng.so.0 #10 0x00007f3ad9752e04 in iv_main () from /usr/lib/libsyslog-ng.so.0 #11 0x00007f3ad973a40b in main_loop_run () from /usr/lib/libsyslog-ng.so.0 #12 0x00000000004016e9 in main ()
I have reverted to 3.0.x (which I was previously running) for now.
Hmm... sorry to have caused disruptions. The problem with this backtrace, is that it lacks a lot of information, debug symbols would be needed to properly analyze it. Can you help in that regard?
Thanks.
-- Bazsi
------------------------------
Message: 3 Date: Sat, 04 Jun 2011 13:11:36 +0200 From: Balazs Scheidler <bazsi@balabit.hu> Subject: Re: [syslog-ng] [Fw: keep_hostname (yes); and source file] To: Syslog-ng users' and developers' mailing list <syslog-ng@lists.balabit.hu> Message-ID: <1307185896.15963.200.camel@bzorp> Content-Type: text/plain; charset="UTF-8"
On Fri, 2011-05-27 at 18:44 -0400, Steven Blatchford wrote:
There seems to be no hostname associated with file() so it uses the first word of the message. The first word of the log message is 'DEBUG'. On the central log server I added 'DEBUG' to the filter host and it worked.
Is there a way to set the hostname when the source uses file() ?
That happens because syslog-ng tries to parse the file as if it was in syslog format. You can disable parsing with
flags(no-parse).
With that the content of each line will become part of $MSG and syslog-ng will prepend a syslog header when sending it to the server.
-- Bazsi
------------------------------
Message: 4 Date: Sat, 4 Jun 2011 13:14:49 +0200 (CEST) From: bugzilla@bugzilla.balabit.com Subject: [syslog-ng] [Bug 122] [3.2.4]: mixed linking broken for libsyslog-ng.so.* To: syslog-ng@lists.balabit.hu Message-ID: <20110604111449.B269211E081@lists.balabit.hu> Content-Type: text/plain; charset="UTF-8"
https://bugzilla.balabit.com/show_bug.cgi?id=122
--- Comment #5 from Balazs Scheidler <bazsi@balabit.hu> 2011-06-04 13:14:49 --- Can you attach the patch here, so that I could add it to the syslog-ng configure script if it makes sense?
Although I'm quite reluctant to add LDFLAGS/CFLAGS filtering, I'd say that if the compiling user supplies those arguments, then she knows what she's doing, so IMHO the best place to filter those arguments is the packaging files (be them .spec files or debian/ directories or anything else).
Anyway, it'd make the decision easier if you could attach the patch.
-- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
------------------------------
Message: 5 Date: Sat, 04 Jun 2011 13:15:33 +0200 From: Balazs Scheidler <bazsi@balabit.hu> Subject: Re: [syslog-ng] syslog-ng Digest, Vol 73, Issue 37 To: Syslog-ng users' and developers' mailing list <syslog-ng@lists.balabit.hu> Message-ID: <1307186133.15963.201.camel@bzorp> Content-Type: text/plain; charset="UTF-8"
On Wed, 2011-06-01 at 10:09 +1100, Scott Rochford wrote:
Hi Frank,
Someone must have used a so-called "smart" editor to edit this file, since it seems to have used fancy quotes on the console line.
#destination console_all { file("/dev/tty12"); }; destination console_all { file(?/dev/console?); }; #destination loghost { udp("loghost" port(999)); };
Notice how they are different from those on the line above? Word processors often replace quotes with matching pairs like that automatically; only plain text editors should be used to edit config files like this.
Check for this kind of thing with a hex dumper or 'cat -vet':
$ cat frank #destination console_all { file("/dev/tty12"); }; destination console_all { file("/dev/console"); }; #destination loghost { udp("loghost" port(999)); };
$ cat -vet frank #destination console_all { file("/dev/tty12"); };$ destination console_all { file(M-bM-^@M-^\/dev/consoleM-bM-^@M-^]); }; $ #destination loghost { udp("loghost" port(999)); };$
I can confirm that if this is the case, it'll certainly confuse syslog-ng.
-- Bazsi
------------------------------
Message: 6 Date: Sat, 04 Jun 2011 13:20:52 +0200 From: Balazs Scheidler <bazsi@balabit.hu> Subject: Re: [syslog-ng] Fwd: Re: Question To: Syslog-ng users' and developers' mailing list <syslog-ng@lists.balabit.hu> Cc: Costa Farber <costaf@wix.com> Message-ID: <1307186452.15963.203.camel@bzorp> Content-Type: text/plain; charset="UTF-8"
Hi,
Thanks for bringing this up. The description was certainly familiar and that was the reason. 3.3 OSE is the first affected branch, older code didn't use the hand-coded number parsing functions.
This is the commit-id of the new patch:
commit 4df06a3c8d7c37b06db41be4695522c73ec925a5 Author: Balazs Scheidler <bazsi@balabit.hu> Date: Sun Apr 10 10:28:31 2011 +0200
Fixed BSD timestamp parsing when the day is padded with spaces in front (fixes: D-03717)
Although the bugreport contained info that it'd be 'no-hostname' related, in reality it isn't. The unit tests couldn't cover this case as the timestamp that can typically contain such fields do not contain year information.
This patch fills this whole in the unit test and also fixes the problem itself. It was caused by one of the performance improvement patches, but doesn't affect PE 4.0 or older OSE versions.
Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
On Thu, 2011-06-02 at 12:41 +0200, Gergely Nagy wrote:
Copying this to the syslog-ng@ list aswell, as this might be interesting to others aswell, and the patch should be picked up for 3.3 too.
On 2011-06-01 17:20, Costa Farber wrote:
Hello.
I use syslog-ng 3.3 beta. It was working up today perfect. Today I got the following result: my config */source s_network { udp(); tcp(); }; destination d_local_prospero { file("/var/log/messages_prospero" template("$ISODATE#$HOST#$MSGONLY\n") ); }; log { source(s_network); destination(d_local_prospero); };/*
source message is /*Jun 1 17:50:11 ubnct lighttpd-1.5[24730]: DEBUG wix.c:send_wixfs_file:345 will send file: /var/www/ static.wix.com/media/3d/44/3d4433_34a5623f12940907668b5ee9b72d23a3.jpg_600 < http://static.wix.com/media/3d/44/3d4433_34a5623f12940907668b5ee9b72d23a3.jp... */
result is /*2011-06-01T17:50:03+03:00#ubnct# 1 17:50:11 ubnct lighttpd-1.5[24730]: DEBUG wix.c:send_wixfs_file:345 will send file: /var/www/ static.wix.com/media/3d/44/3d4433_34a5623f12940907668b5ee9b72d23a3.jpg_600 < http://static.wix.com/media/3d/44/3d4433_34a5623f12940907668b5ee9b72d23a3.jp... */
It seems like parser has a bug and can not pars one digit day (it has 2 spaces between month and day). I need help to clear is it bug or any ather problem.
This is a known problem, but for some reason the fix did not make it into 3.3 yet.
Attached is a patch that fixes the problem.
differences between files attachment (0001-Fixed-BSD-timestamp-parsing-when-the-day-is-padded-w.patch) From 72733f3b3fd0d29a58dc1f3601e0c2a4b3577747 Mon Sep 17 00:00:00 2001 From: Balazs Scheidler <bazsi@balabit.hu> Date: Sun, 10 Apr 2011 10:28:31 +0200 Subject: [PATCH] Fixed BSD timestamp parsing when the day is padded with spaces in front (fixes: D-03717)
Although the bugreport contained info that it'd be 'no-hostname' related, in reality it isn't. The unit tests couldn't cover this case as the timestamp that can typically contain such fields do not contain year information.
This patch fills this whole in the unit test and also fixes the problem itself. It was caused by one of the performance improvement patches, but doesn't affect PE 4.0 or older OSE versions.
Signed-off-by: Balazs Scheidler <bazsi@balabit.hu> --- lib/str-format.c | 3 +- tests/unit/test_msgparse.c | 54 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+), 1 deletions(-)
diff --git a/lib/str-format.c b/lib/str-format.c index 27a292a..a033b43 100644 --- a/lib/str-format.c +++ b/lib/str-format.c @@ -1,6 +1,7 @@ #include "str-format.h"
#include <string.h> +#include <ctype.h>
static gchar digits[] = "0123456789abcdef";
@@ -82,7 +83,7 @@ scan_uint32(const gchar **buf, gint *left, gint field_width, guint32 *num) { if ((**buf) >= '0' && (**buf) <= '9') result = result * 10 + ((**buf) - '0'); - else + else if (!isspace(**buf)) return FALSE; (*buf)++; (*left)--; diff --git a/tests/unit/test_msgparse.c b/tests/unit/test_msgparse.c index 3a60175..069cc37 100644 --- a/tests/unit/test_msgparse.c +++ b/tests/unit/test_msgparse.c @@ -59,6 +59,33 @@ check_value(gchar *msg, LogMessage *logmsg, NVHandle handle, const gchar *expect TEST_ASSERT(strcmp(p, expected) == 0, "%s", p, expected); }
+/* This function determines the year that syslog-ng would find out + * given the timestamp has no year information. Then returns the UTC + * representation of "January 1st 00:00:00" of that year. This is to + * be used for testcases that lack year information. ts_month is the 0 + * based month in the timestamp being parsed. + */ +time_t +get_bsd_year_utc(int ts_month) +{ + struct tm *tm; + time_t t; + + time(&t); + tm = localtime(&t); + + if (tm->tm_mon > ts_month + 1) + tm->tm_year++; + + tm->tm_hour = 0; + tm->tm_min = 0; + tm->tm_sec = 0; + tm->tm_mday = 1; + tm->tm_mon = 0; + tm->tm_isdst = -1; + return mktime(tm); +} + int testcase(gchar *msg, gint parse_flags, @@ -182,6 +209,33 @@ main(int argc G_GNUC_UNUSED, char *argv[] G_GNUC_UNUSED) NULL, "2499", NULL, NULL );
+ testcase("<15>Jan 1 01:00:00 bzorp openvpn[2499]: PTHREAD support initialized", LP_EXPECT_HOSTNAME, NULL, + 15, // pri + get_bsd_year_utc(0) + 3600, 0, 3600, // timestamp (sec/usec/zone) + "bzorp", // host + "openvpn", // openvpn + "PTHREAD support initialized", // msg + NULL, "2499", NULL, NULL + ); + + testcase("<15>Jan 10 01:00:00 bzorp openvpn[2499]: PTHREAD support initialized", LP_EXPECT_HOSTNAME, NULL, + 15, // pri + get_bsd_year_utc(0) + 3600 + 9 * 24 * 3600, 0, 3600, // timestamp (sec/usec/zone) + "bzorp", // host + "openvpn", // openvpn + "PTHREAD support initialized", // msg + NULL, "2499", NULL, NULL + ); + + testcase("<13>Jan 1 14:40:51 alma korte: message", 0, NULL, + 13, + get_bsd_year_utc(0) + 60 * 60 * 14 + 40 * 60 + 51, 0, 3600, + "", + "alma", + "korte: message", + NULL, NULL, NULL, NULL + ); + testcase("<7>2006-11-10T10:43:21.156+02:00 bzorp openvpn[2499]: PTHREAD support initialized", LP_EXPECT_HOSTNAME, NULL, 7, // pri 1163148201, 156000, 7200, // timestamp (sec/usec/zone)
______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
-- Bazsi
------------------------------
Message: 7 Date: Sat, 04 Jun 2011 13:26:45 +0200 From: Balazs Scheidler <bazsi@balabit.hu> Subject: Re: [syslog-ng] issues with syslog-ng install of new version or running older version on mac osX 10.6.7 To: Syslog-ng users' and developers' mailing list <syslog-ng@lists.balabit.hu> Message-ID: <1307186805.15963.208.camel@bzorp> Content-Type: text/plain; charset="UTF-8"
On Fri, 2011-06-03 at 12:37 -0400, Frank Scalzo wrote:
I have tried the dmz installed it still not logging
i am tryng to upgrade to version 3.2.4 from 3.0.8 to see if that might fix my issue
I have installed eventlog 2.12 but when i try to do my config it still says i have event log 2.0.9
the configure script detects eventlog using the pkg-config command, something like:
pkg-config --cflags eventlog
pkg-config uses so named .pc files to find out where things are located, and uses PKG_CONFIG_PATH as a list of directories where it looks for .pc files. By default it uses /usr/lib/pkg-config
If you have multiple eventlog versions (because the OS supplied you one, and then you installed one from source), they are probably located at different locations. The system supplied one usually lives under /usr, the locally installed one in /usr/local
So it all depends on your PKG_CONFIG_PATH if it does find the new version, or not.
You can either explicitly set PKG_CONFIG_PATH to contain the directory with the new eventlog .pc, or you could also use the "low-level" environment variables to substitute .pc files completely. Quoting the configure help about environment variables:
EVTLOG_CFLAGS C compiler flags for EVTLOG, overriding pkg-config EVTLOG_LIBS linker flags for EVTLOG, overriding pkg-config
just to see if i could bypass it I changed the the min eventlog to the version it says i have in the configure file
do a config no problem but now fail on the make with
mv:rename .deps/misc.tpo .deps/misc.plo no such file or dir make [3]: *** [misc.lo] error 1 make [2]: *** [all] error 2 make [1]: *** [all-recursive] error 1 make: *** [all] error 2 all done in SU
if i could get the other version to log I would be good and until i prove it works for us i can not tell them i want the pe version
Compiling syslog-ng can be tricky at times, but it's quite straightforward if you know the standard build tools on Linux. (so nothing tricky, syslog-ng has a lot of external dependencies).
-- Bazsi
------------------------------
Message: 8 Date: Sat, 04 Jun 2011 13:35:16 +0200 From: Balazs Scheidler <bazsi@balabit.hu> Subject: Re: [syslog-ng] Syslog-ng error while using TSL To: Syslog-ng users' and developers' mailing list <syslog-ng@lists.balabit.hu> Message-ID: <1307187316.15963.211.camel@bzorp> Content-Type: text/plain; charset="UTF-8"
On Thu, 2011-05-26 at 22:25 +0530, Pramod Pillai wrote:
Hi Bazsi
We are still unable to resolve the issue . I see this error. CN=Generic_Int_CA_1', error='unable to get local issuer certificate', depth='0' SSL error while writing stream; tls_error='SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed'
I am attaching the config file and the certificates which might be helpful to debug the issue.
The question is what the directory
ca_dir("/certificates/ca.d")
contains. It should be populated with symlinks pointing to the X.509 certificates. The symlink name must be the hash of the X.509 subject name, to be produced by
openssl x509 -hash -in xxxx
There's also an openssl utility to perform this symlink stuff, named c_rehash. Here's a manual page for that:
http://www.tin.org/bin/man.cgi?section=1&topic=c_rehash
I'm quite certain that TLS and X.509 key validation works well, and the error message really seems to indicate a local setup problem.
Regards Pramod
On Sun, May 22, 2011 at 4:44 PM, Balazs Scheidler <bazsi@balabit.hu>
wrote:
On Wed, 2011-05-04 at 18:11 +0530, Pramod Pillai wrote:
Hi
I have not yet resolved the issue -:( Few questions This is the error from the client side error='self signed certificate in certificate chain', depth='2'
Our certificates are not self signed . But why is it showing as self signed in the log.
everything is self-signed at the end. an official CA is a self-signed certificate, they just happen to be trusted for one reason or another.
this probably means that the CA certificate is not trusted by syslog-ng, probably because syslog-ng has to be told which CA you trust.
There's a chapter in the documentation on how to set that up, here:
http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-v3.2-guid...
Is syslog-ng internally configured as self-signed certificate. If Yes where is it stored. Or how to modify it.
Is it possible to configure the depth ?
IIRC no, there's currently no way to configure that, syslog-ng will
just
accept any certificate depth.
-- Bazsi
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html
______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html
-- Bazsi
------------------------------
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
End of syslog-ng Digest, Vol 74, Issue 7 ****************************************