<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="generator" content="Osso Notes">
<title></title></head>
<body>
<p>----- Original message -----
<br>>
<br>> For our own purposes we will be adding a few parsers to the patterndb
<br>> syntax, and will be contributing them back to Balabit, so I wanted to
<br>> choose reasonable/acceptable names for these. Feedback on what these do
<br>> and/or the name of the parser would be appreciated.
<br>>
<br>> HOSTNAME
<br>>
<br>> This is really the same as @STRING:xxx:.-_@ but makes the pattern much
<br>> more readable. I am still considering if any triailing period should be
<br>> consumed but dropped. This would make it easier to parse a hostname that
<br>> comes at the end of a log line where the log line ends in a period, as
<br>> well as forced FQDN names that are logged.
<br>>
<br>
<br>sounds good.
<br>
<br>> EMAIL
<br>>
<br>> email addresses are difficult to parse because they have an @ symbol in
<br>> them. This parser would accept a list of characters that would be
<br>> dropped beginning and end of the match. such as "<a href="mailto:erempel@uvic.ca">erempel@uvic.ca</a>" or
<br>> <<a href="mailto:erempel@uvic.ca">erempel@uvic.ca</a>> and return just the e-mail address <a href="mailto:erempel@uvic.ca">erempel@uvic.ca</a> in
<br>> the specified tag name.
<br>>
<br>
<br>good idea.
<br>
<br>> MACETH
<br>>
<br>> Parse upper/lower case ethernet MAC addresses such as 78:2B:CB:70:49:73
<br>
<br>there's already a parser for this in 3.4, iirc it is called macaddr
<br>>
<br>> MACIB
<br>>
<br>> Parse upper/lower case infiniband addresses such as
<br>> 80:00:00:48:fe:80:00:00:00:00:00:00:00:02:c9:03:00:05:bc:15
<br>>
<br>> MACFC
<br>>
<br>> Parse upper/lower case fibre channel addresses (these are fibre channel
<br>> (w)orld (w)ide (n)ames often refered to as WWN but in keeping with the
<br>> (m)edia (a)ccess (c)ontrol layer names I have chosen for MACETH and
<br>> MACIB I thought that MACFC was more consistent.
<br>>
<br>
<br>I wouldn't use MAC prefix for either of these, only if it's really that usual to call these macs.
<br>
<br>>
<br>> Thanks for your feedback.
<br>>
<br>
<br>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.
<br>
<br>thanks for considering this. these ideas are great</p>
</body>
</html>