3.7.4-1 CentOS 7 syslog only logs a number

[ethansutcliffe]

Version 3.7.4-1 of cb-event-forwarder only logs numbers when configured to syslog

Example:
06 21 2021 14:02:41 redacted_ip <KERN:INFO> 2021-06-21T14:02:41+01:00 redacted_hostname /usr/share/cb/integrations/event-forwarder/cb-event-forwarder[19675]: 0
Most of the logs just contain 0 however some are higher:
06 21 2021 13:51:36 redacted_ip <KERN:INFO> 2021-06-21T13:51:36+01:00 redacted_hostname /usr/share/cb/integrations/event-forwarder/cb-event-forwarder[31640]: 26

The issue is resolved by downgrading to 3.7.3-1.
I haven't tested for the issue on EL6 or EL8.

The Event Forwarder config was default settings on Events, with output set to syslog to UDP on port 514, LEEF format.

[schroray]

We are experiencing issues when running cb-event-forwarding v3.7.4-1 with cb-enterprise v7.4.2.
Followed your downgrade path using cb-event-forwarding v3.7.3-1, but this did not resolve the issue though...

Our other unproblematic installations use: cb-enterprise v7.2.1 and cb-event-forwarding v3.7.3-1

[schroray]

We are experiencing issues when running cb-event-forwarding v3.7.4-1 with cb-enterprise v7.4.2.
Followed your downgrade path using cb-event-forwarding v3.7.3-1, but this did not resolve the issue though...

Our other unproblematic installations use: cb-enterprise v7.2.1 and cb-event-forwarding v3.7.3-1

For some reason and after even rebooting the complete HW servers - suddenly the local JSON files get filled wit useful information again...

One colleague was testing a backup script already several times and many hours after my downgrade.... Backup script is doing the documented backup steps based on the user guide: Cluster stop, run lokal backups on each member, cluster start, restart Event Forwarder...

Now after one of these complete service stop, backup, and service start cycles the Event Forwarder v3.7.3-1 with CB EDR v7.4.2 is working again...

[jtwiborg]

Have the same issue here. Logging to file, and frequently we see lots of lines with only 0, or another number. Sometimes we see it count upwards like this:
0
0
0
1
2
3
4
5
6
7
8
9
10
11

Have cb-event-forwarder-3.7.4-1.el8.x86_64.

[schroray]

Have the same issue here. Logging to file, and frequently we see lots of lines with only 0, or another number. Sometimes we see it count upwards like this: 0 0 0 1 2 3 4 5 6 7 8 9 10 11

Have cb-event-forwarder-3.7.4-1.el8.x86_64.

What CB EDR version are you running?

[jtwiborg]

Hi Ray. We are running version EDR 7.5.0 and we see this issue both on a 5 machine cluster and 1 standalone machine. On another 5 machine cluster, we don’t see this behavior but this has an older version of the cb-event-forwarder (v3.6.0) While I don’t think it matters, last one runs on RHEL 6.x, but the other on CentOS 8.4 (sadly). Thanks Thomas.

…

5. okt. 2021 kl. 13:31 skrev Ray ***@***.***>: Have the same issue here. Logging to file, and frequently we see lots of lines with only 0, or another number. Sometimes we see it count upwards like this: 0 0 0 1 2 3 4 5 6 7 8 9 10 11 Have cb-event-forwarder-3.7.4-1.el8.x86_64. What CB EDR version are you running? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIX7IUQKWT7FFAQE7MBZBADUFLOXTANCNFSM47BSE7KQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[schroray]

We have EDR v7.4.x and v7.5.1 clusters running on CentOS 7.

With the v7.4 based I had to downgrad the Event Forwarder as initially described.

I have installed v7.5.1 wit a new deployment from scratch last week - VMs, CentOS 7. Not shure about the version of Entent Forwarder though but we had again the issue with missing logs in our SIEM altough all services have been runnung. Even stopped and started eveything multiple times. All worked after a complete reboot of all cluster nodes...