Syslog-ng loggen
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
Here's the situation:
I have syslog-ng version 3.15. I've noticed that when using TLS and non-TLS transmission, the logs are different.
I have noticed that, when sending logs using the loggen -i
(non-TLS, old RFC3164 format) command, I receive the following messages:
Jun 26 18:19:39 localhost prg00000[1234]: seq: 0000000000, thread: 0000, runid: 1530026379, stamp: 2018-06-26T18:19:39 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADD
When using the loggen -i -P
(non-TLS, newer RFC5424 format) command the messages look like this:
Jun 26 18:19:28 192.168.1.10 256 <38>1 2018-06-26T18:19:26+03:00 localhost prg00000 1234 - - <U+FEFF>seq: 0000000000, thread: 0000, runid: 1530026366, stamp: 2018-06-26T18:19:26 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD
When using the TLS loggen -i -U
(TLS, old RFC3164 format) command it's not working:
[root@localhost ~]# loggen -i -U 192.168.1.7 6514
Send error Connection reset by peer, results may be skewed.
average rate = 606.59 msg/sec, count=7, time=0.011, (average) msg size=256, bandwidth=151.56 kB/sec
When using the TLS loggen -i -P -U
(TLS, newer RFC5424 format) command the logs look like this:
Jun 26 18:19:13 localhost prg00000[1234]: seq: 0000000000, thread: 0000, runid: 1530026353, stamp: 2018-06-26T18:19:13 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD
I know the $HOST macro uses the second column to split the logs by host. Having localhost
in the second column when using TLS instead of the IP-address
can be frustrating when switching between TLS and non-TLS. Can this situation be avoided somehow?
centos logs ssl syslog-ng
add a comment |Â
up vote
0
down vote
favorite
Here's the situation:
I have syslog-ng version 3.15. I've noticed that when using TLS and non-TLS transmission, the logs are different.
I have noticed that, when sending logs using the loggen -i
(non-TLS, old RFC3164 format) command, I receive the following messages:
Jun 26 18:19:39 localhost prg00000[1234]: seq: 0000000000, thread: 0000, runid: 1530026379, stamp: 2018-06-26T18:19:39 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADD
When using the loggen -i -P
(non-TLS, newer RFC5424 format) command the messages look like this:
Jun 26 18:19:28 192.168.1.10 256 <38>1 2018-06-26T18:19:26+03:00 localhost prg00000 1234 - - <U+FEFF>seq: 0000000000, thread: 0000, runid: 1530026366, stamp: 2018-06-26T18:19:26 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD
When using the TLS loggen -i -U
(TLS, old RFC3164 format) command it's not working:
[root@localhost ~]# loggen -i -U 192.168.1.7 6514
Send error Connection reset by peer, results may be skewed.
average rate = 606.59 msg/sec, count=7, time=0.011, (average) msg size=256, bandwidth=151.56 kB/sec
When using the TLS loggen -i -P -U
(TLS, newer RFC5424 format) command the logs look like this:
Jun 26 18:19:13 localhost prg00000[1234]: seq: 0000000000, thread: 0000, runid: 1530026353, stamp: 2018-06-26T18:19:13 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD
I know the $HOST macro uses the second column to split the logs by host. Having localhost
in the second column when using TLS instead of the IP-address
can be frustrating when switching between TLS and non-TLS. Can this situation be avoided somehow?
centos logs ssl syslog-ng
1
You need to make it clear what situation that is. This question is largely inpenetrable to readers. I know what you are getting at and even I had to read the question twice.
â JdeBP
Jun 26 at 23:48
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Here's the situation:
I have syslog-ng version 3.15. I've noticed that when using TLS and non-TLS transmission, the logs are different.
I have noticed that, when sending logs using the loggen -i
(non-TLS, old RFC3164 format) command, I receive the following messages:
Jun 26 18:19:39 localhost prg00000[1234]: seq: 0000000000, thread: 0000, runid: 1530026379, stamp: 2018-06-26T18:19:39 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADD
When using the loggen -i -P
(non-TLS, newer RFC5424 format) command the messages look like this:
Jun 26 18:19:28 192.168.1.10 256 <38>1 2018-06-26T18:19:26+03:00 localhost prg00000 1234 - - <U+FEFF>seq: 0000000000, thread: 0000, runid: 1530026366, stamp: 2018-06-26T18:19:26 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD
When using the TLS loggen -i -U
(TLS, old RFC3164 format) command it's not working:
[root@localhost ~]# loggen -i -U 192.168.1.7 6514
Send error Connection reset by peer, results may be skewed.
average rate = 606.59 msg/sec, count=7, time=0.011, (average) msg size=256, bandwidth=151.56 kB/sec
When using the TLS loggen -i -P -U
(TLS, newer RFC5424 format) command the logs look like this:
Jun 26 18:19:13 localhost prg00000[1234]: seq: 0000000000, thread: 0000, runid: 1530026353, stamp: 2018-06-26T18:19:13 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD
I know the $HOST macro uses the second column to split the logs by host. Having localhost
in the second column when using TLS instead of the IP-address
can be frustrating when switching between TLS and non-TLS. Can this situation be avoided somehow?
centos logs ssl syslog-ng
Here's the situation:
I have syslog-ng version 3.15. I've noticed that when using TLS and non-TLS transmission, the logs are different.
I have noticed that, when sending logs using the loggen -i
(non-TLS, old RFC3164 format) command, I receive the following messages:
Jun 26 18:19:39 localhost prg00000[1234]: seq: 0000000000, thread: 0000, runid: 1530026379, stamp: 2018-06-26T18:19:39 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADD
When using the loggen -i -P
(non-TLS, newer RFC5424 format) command the messages look like this:
Jun 26 18:19:28 192.168.1.10 256 <38>1 2018-06-26T18:19:26+03:00 localhost prg00000 1234 - - <U+FEFF>seq: 0000000000, thread: 0000, runid: 1530026366, stamp: 2018-06-26T18:19:26 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD
When using the TLS loggen -i -U
(TLS, old RFC3164 format) command it's not working:
[root@localhost ~]# loggen -i -U 192.168.1.7 6514
Send error Connection reset by peer, results may be skewed.
average rate = 606.59 msg/sec, count=7, time=0.011, (average) msg size=256, bandwidth=151.56 kB/sec
When using the TLS loggen -i -P -U
(TLS, newer RFC5424 format) command the logs look like this:
Jun 26 18:19:13 localhost prg00000[1234]: seq: 0000000000, thread: 0000, runid: 1530026353, stamp: 2018-06-26T18:19:13 PADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPADDPAD
I know the $HOST macro uses the second column to split the logs by host. Having localhost
in the second column when using TLS instead of the IP-address
can be frustrating when switching between TLS and non-TLS. Can this situation be avoided somehow?
centos logs ssl syslog-ng
edited Jun 27 at 11:48
JdeBP
27.9k459133
27.9k459133
asked Jun 26 at 15:37
Aiurea Adica tot YO
14
14
1
You need to make it clear what situation that is. This question is largely inpenetrable to readers. I know what you are getting at and even I had to read the question twice.
â JdeBP
Jun 26 at 23:48
add a comment |Â
1
You need to make it clear what situation that is. This question is largely inpenetrable to readers. I know what you are getting at and even I had to read the question twice.
â JdeBP
Jun 26 at 23:48
1
1
You need to make it clear what situation that is. This question is largely inpenetrable to readers. I know what you are getting at and even I had to read the question twice.
â JdeBP
Jun 26 at 23:48
You need to make it clear what situation that is. This question is largely inpenetrable to readers. I know what you are getting at and even I had to read the question twice.
â JdeBP
Jun 26 at 23:48
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
I found out that the problem is framing. syslog() driver in syslog-ng and loggen as well sends RFC5424 formatted messages with framing: message length + msg
E.g.
"256 <13>1 2018-07-09T16:23:25+02:00 localhost ...."
tcp() or network() driver on the other hand does not expect framing, although it can parse RFC5424 formatted messages(when flags(syslog-protocol) option is used).
The solution is to disable framing in loggen (use the "-F" option of loggen) and use "flags(syslog-protocol)" option in your network() source.
However this only solves your problem with loggen, if your log source sends its log messages with framing it will cause the same problem with your tcp() source driver.
Using syslog() source driver would handle (and expect!) framing from loggen or syslog().
Btw let me inform you, that the tcp(), upd() drivers are obsolete and it is recommended to use the newer network() driver as per syslog-ng's documentation.
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
I found out that the problem is framing. syslog() driver in syslog-ng and loggen as well sends RFC5424 formatted messages with framing: message length + msg
E.g.
"256 <13>1 2018-07-09T16:23:25+02:00 localhost ...."
tcp() or network() driver on the other hand does not expect framing, although it can parse RFC5424 formatted messages(when flags(syslog-protocol) option is used).
The solution is to disable framing in loggen (use the "-F" option of loggen) and use "flags(syslog-protocol)" option in your network() source.
However this only solves your problem with loggen, if your log source sends its log messages with framing it will cause the same problem with your tcp() source driver.
Using syslog() source driver would handle (and expect!) framing from loggen or syslog().
Btw let me inform you, that the tcp(), upd() drivers are obsolete and it is recommended to use the newer network() driver as per syslog-ng's documentation.
add a comment |Â
up vote
0
down vote
accepted
I found out that the problem is framing. syslog() driver in syslog-ng and loggen as well sends RFC5424 formatted messages with framing: message length + msg
E.g.
"256 <13>1 2018-07-09T16:23:25+02:00 localhost ...."
tcp() or network() driver on the other hand does not expect framing, although it can parse RFC5424 formatted messages(when flags(syslog-protocol) option is used).
The solution is to disable framing in loggen (use the "-F" option of loggen) and use "flags(syslog-protocol)" option in your network() source.
However this only solves your problem with loggen, if your log source sends its log messages with framing it will cause the same problem with your tcp() source driver.
Using syslog() source driver would handle (and expect!) framing from loggen or syslog().
Btw let me inform you, that the tcp(), upd() drivers are obsolete and it is recommended to use the newer network() driver as per syslog-ng's documentation.
add a comment |Â
up vote
0
down vote
accepted
up vote
0
down vote
accepted
I found out that the problem is framing. syslog() driver in syslog-ng and loggen as well sends RFC5424 formatted messages with framing: message length + msg
E.g.
"256 <13>1 2018-07-09T16:23:25+02:00 localhost ...."
tcp() or network() driver on the other hand does not expect framing, although it can parse RFC5424 formatted messages(when flags(syslog-protocol) option is used).
The solution is to disable framing in loggen (use the "-F" option of loggen) and use "flags(syslog-protocol)" option in your network() source.
However this only solves your problem with loggen, if your log source sends its log messages with framing it will cause the same problem with your tcp() source driver.
Using syslog() source driver would handle (and expect!) framing from loggen or syslog().
Btw let me inform you, that the tcp(), upd() drivers are obsolete and it is recommended to use the newer network() driver as per syslog-ng's documentation.
I found out that the problem is framing. syslog() driver in syslog-ng and loggen as well sends RFC5424 formatted messages with framing: message length + msg
E.g.
"256 <13>1 2018-07-09T16:23:25+02:00 localhost ...."
tcp() or network() driver on the other hand does not expect framing, although it can parse RFC5424 formatted messages(when flags(syslog-protocol) option is used).
The solution is to disable framing in loggen (use the "-F" option of loggen) and use "flags(syslog-protocol)" option in your network() source.
However this only solves your problem with loggen, if your log source sends its log messages with framing it will cause the same problem with your tcp() source driver.
Using syslog() source driver would handle (and expect!) framing from loggen or syslog().
Btw let me inform you, that the tcp(), upd() drivers are obsolete and it is recommended to use the newer network() driver as per syslog-ng's documentation.
answered Jul 17 at 7:46
Aiurea Adica tot YO
14
14
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f452042%2fsyslog-ng-loggen%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
You need to make it clear what situation that is. This question is largely inpenetrable to readers. I know what you are getting at and even I had to read the question twice.
â JdeBP
Jun 26 at 23:48