wlamb...@gmail.com wrote:
>
> I am fairly new to tcl and was hoping I could get some advice/tips on
> the best way to go about this.
We may be able to offer some help, but as Heinrich said, you don not
have a Tcl problem, you have an algorithm (unrelated to any programming
language) problem.
> I'm trying to parse through the data below using the below proc
> (already existing in tcl script). The whole script tails a log file
> and reads in each line, the below proc looks at each line to see if
> they match certain circumstances -- if they do not, they are added to
> the message payload and an event is sent to a daemon to be processed
> when it encounters a blank line (SendAlert proc).
>
> This proc originally worked fine when a single blank line was used to
> signify the end of the log message, however, now, with the inclusion
> of another blank line, the whole message payload is not sent for all
> log entries.
Ok, so, first, simplest, solution... Is there any way you can have the
"second blank line" removed from the log so that what the proc expects
is what the proc receives?
> Of course, I could use SendAlert whenever I see the "**Alert" line,
> but that would cause one event to not be sent until another was
> written to the log file.
> ----------
>
> Data:
>
> ** Alert 1528724208.1445: - ossec,syscheck,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,
> 2018 Jun 11 13:36:48 wazuh-docker->syscheck
> Rule: 550 (level 7) -> 'Integrity checksum changed.'
> Integrity checksum changed for: '/etc/hostname'
> <this is a blank line>
> File: /etc/hostname
> New size: 22
> New permissions: 100644
> New user: root (0)
> New group: root (0)
> New MD5: 95917fe7436d049af07b5e133389dfbb
> New SHA1: c189919888285e9a6c24680b10dcc779d0470fc2
> Old date: Mon Jun 11 13:31:50 2018
> New date: Mon Jun 11 13:35:03 2018
> New inode: 12197
> <this is a blank line>
>
> Would anyone be able to offer any thoughts or advice on how to check
> if the line after the first blank line exists or contains "**Alert",
> so that I would know to either continue reading the entry or go ahead
> and send the message?
You are thinking about this wrong. You are "tailing" a log file,
therefore as you said in another reply, you may not get a "next" line
for hours or days, because nothing new arrived in the log file.
So you can't "look ahead" (which is what you are asking to do) in the
log file, because that which is "ahead" may not arrive for two weeks.
You can only operate upon the past with a log file. You know what you
have previously received, and what you now have, but you can't
reasonably do something with "future data" that has not yet arrived.
As well, that proc looks like a huge mess that does a lot of unused
work, to then concatenate lines of the log file into a message to this
deamon. Did you remove a lot of other stuff from it for posting it
here? If yes, then that is why. But if not, you might get a good
start by trimming out the unused work.
Next, is this "extra blank line" always present in new log records? So
a log record will begin with "** Alert" and will end after the second
blank line? Then why not look for a line starting with "** Alert",
then accumulate lines until you receive two blank lines, and as soon as
you receive the second blank line, send the accumulated lines as the
alert?
Alternately, if you have any control over the system generating these
log records, can that system be modified to output an explicit "end of
alert" line. I.e.:
** Alert ...
... multiple lines here
** End of Alert
With an explicitly defined end signal, chunking this into individual
records would be a trivial task.