----- Original message -----

For our own purposes we will be adding a few parsers to the patterndb syntax, and will be contributing them back to Balabit, so I wanted to choose reasonable/acceptable names for these. Feedback on what these do and/or the name of the parser would be appreciated.

HOSTNAME

This is really the same as @STRING:xxx:.-_@ but makes the pattern much more readable. I am still considering if any triailing period should be consumed but dropped. This would make it easier to parse a hostname that comes at the end of a log line where the log line ends in a period, as well as forced FQDN names that are logged.

sounds good.

EMAIL

email addresses are difficult to parse because they have an @ symbol in them. This parser would accept a list of characters that would be dropped beginning and end of the match. such as "erempel@uvic.ca" or <erempel@uvic.ca> and return just the e-mail address erempel@uvic.ca in the specified tag name.

good idea.

MACETH

Parse upper/lower case ethernet MAC addresses such as 78:2B:CB:70:49:73

there's already a parser for this in 3.4, iirc it is called macaddr

MACIB

Parse upper/lower case infiniband addresses such as 80:00:00:48:fe:80:00:00:00:00:00:00:00:02:c9:03:00:05:bc:15

MACFC

Parse upper/lower case fibre channel addresses (these are fibre channel (w)orld (w)ide (n)ames often refered to as WWN but in keeping with the (m)edia (a)ccess (c)ontrol layer names I have chosen for MACETH and MACIB I thought that MACFC was more consistent.

I wouldn't use MAC prefix for either of these, only if it's really that usual to call these macs.

Thanks for your feedback.

some refactoring in the parser area is dearly needed, the pattern parsing code is ugly. I'm not sure when I get there to refactor that, i just wanted to warn you :) or if you could split that huge function to smaller ones and use a lookup table instead of the if-else-if mess, that would be appreciated. thanks for considering this. these ideas are great

These set of patches are cumulative and require the dbparser SET patch. They have been build againstthe 3.3 release but should be fairly clean on the 3.4 branch They should be applied in the order of EMAIL HOSTNAME LLATTR -- Evan

Evan Rempel <erempel@uvic.ca> writes:

The last set of patches I posted contained an error that would result in segmentation fault. I forgot to check if the parameter was defined before using it.

These fixed patches don't have the error.

I only had a quick glance, but I liked what I saw, thanks! However, since 3.4 already has a MACADDR parser, I was thinking it'd make sense to move that over to be a light wrapper around LLADDR, appropriately parameterised? (I can do that once I get around to pull your patches into my sandbox tree, but if it was done before I merge the patches, that'd make my life a tiny bit easier :) -- |8]

Evan Rempel <erempel@uvic.ca> writes:

These set of patches are cumulative and require the dbparser SET patch. They have been build againstthe 3.3 release but should be fairly clean on the 3.4 branch

I ported these to 3.4 (was fairly clean indeed), applied a few coding style changes, and made it so that MACADDR is an alias to LLADDR:16. All tests pass (I wrote a few simple ones for LLADDR:20 and HOSTNAME). The result is currently on my feature/3.4/dbparser-additions branch, I'll merge it into merge-queue/3.4 and sandbox/3.4 once I've done some code cleanups. There are a few things I believe could be done better (eg, the MACADDR parser we have in 3.4 now is, I believe a tiny bit more efficient than the LLADDR parser, so I want to fix that and make the latter perform just aswell). Thanks for the patches! -- |8]

Balazs Scheidler <bazsi@balabit.hu> writes:

If I understand correctly you still want to do some stuff on these patches. I'll wait for them then.

Yes. I wanted to finish it up today, but a few more 3.3 blockers fell in :( I'll merge them to the merge-queue/3.4 branch once I'm happy with them (either tomorrow, or next friday). -- |8]

Pulled, thanks. On Sat, 2012-10-27 at 16:46 +0200, Gergely Nagy wrote:

Gergely Nagy <algernon@balabit.hu> writes:

...

Balazs Scheidler <bazsi@balabit.hu> writes:

...

If I understand correctly you still want to do some stuff on these patches. I'll wait for them then.

Yes. I wanted to finish it up today, but a few more 3.3 blockers fell in :(

I'll merge them to the merge-queue/3.4 branch once I'm happy with them (either tomorrow, or next friday).

Time traveller reporting in!

Reworked the LLADDR parser a bit, fixing a few bugs I introduced (in the MACADDR emulation, as well as in LLADDR itself). It is pretty much the exact same code MACADDR was, except the length is configurable, and MACADDR is a very light wrapper around it.

I updated the tests to actually test what they're supposed to, and not accept invalid results. They now pass, and I'm happy with the code, pushed out a merge-queue/3.4 with these patches applied.

-- Bazsi