<!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>> Hi!
<br>>
<br>> Csaba Major <<a href="mailto:csaba.major@balabit.com">csaba.major@balabit.com</a>> writes:
<br>>
<br>> > I have a system where I have a lot of logs with IP addresses
<br>> > (typically firewall logs), and the requirement was to also include the
<br>> > country name in the logs. I found that a geoip based template function
<br>> > would be an easy way for this, so I created a PoC for that.
<br>>
<br>> This sounds very interesting, thanks for the PoC!
<br>
<br>indeed, it is.
<br>
<br>>
<br>> > The created patch is attached (based on 3.3.5), some may find it
<br>> > useful :) (It requires libgeoip, and a geoip database, of course)
<br>>
<br>> See my comments below. The idea is wonderful, and I'll prep up an
<br>> improved version for 3.4. Since you want it for 3.3, I'll also create a
<br>> patch for that branch too, but it's 3.4 where it can be merged, if Bazsi
<br>> likes the idea too.
<br>>
<br>> > --- /dev/null
<br>> > +++ b/modules/tfgeoip/Makefile.am
<br>> > @@ -0,0 +1,11 @@
<br>> > +moduledir = @moduledir@
<br>> > +export top_srcdir
<br>> > +
<br>> > +#if ENABLE_UUID
<br>> > +AM_CPPFLAGS = -I$(top_srcdir)/lib -I../../lib $(GEOIP_CFLAGS)
<br>> > +module_LTLIBRARIES = libtfgeoip.la
<br>> > +
<br>> > +libtfgeoip_la_SOURCES = tfgeoip.c
<br>> > +libtfgeoip_la_LIBADD = $(MODULE_DEPS_LIBS) $(GEOIP_LIBS)
<br>> > +libtfgeoip_la_LDFLAGS = $(MODULE_LDFLAGS)
<br>> > +#endif
<br>>
<br>> I assume s/UUID/GEOIP/ :)
<br>>
<br>> > diff --git a/modules/tfgeoip/tfgeoip.c b/modules/tfgeoip/tfgeoip.c
<br>> > new file mode 100644
<br>> > index 0000000..eeea330
<br>> > --- /dev/null
<br>> > +++ b/modules/tfgeoip/tfgeoip.c
<br>> [...]
<br>> > +static void
<br>> > +tf_geoip(LogMessage *msg, gint argc, GString *argv[], GString *result)
<br>> > +{
<br>> > +  GeoIP * gi;
<br>> > +  const char * returnedCountry;
<br>> > +
<br>> > +  if (argc != 1)
<br>> > +  return;
<br>> > +  gi = GeoIP_open("/usr/share/GeoIP/GeoIP.dat", GEOIP_STANDARD);
<br>
<br>probably some caching would make sense here. perhaps even enhancing the dns cache code with the ability to store such information. template functions can be invoked for every message, opening and parsing the geoip database is probably very expensive.
<br>
<br>> > +
<br>> > +  returnedCountry = GeoIP_country_code_by_addr(gi, argv[0]->str);
<br>> > +  g_string_append_printf (result, "%s", returnedCountry);
<br>> > +}
<br>>
<br>> As you mentioned in person, it would be nice if the template function
<br>> could be configured, preferably globally, so that one wouldn't have to
<br>> repeat the same parameters over and over again in every template where
<br>> it would be used.
<br>
<br>I'm not sure, templates can be declared as objects, referenced from multiple locations in the config. it is true though that this would probably be used in the naming of files which can't be declared in advance. what kind of settings would this be about?
<br>
<br>>
<br>> Things like returning country vs country code, the location of the
<br>> database and so on and so forth should be configurable.
<br>>
<br>
<br>hmmm. isn't the database location fixed?
<br>
<br>I think when naming files, the country code should be enough.
<br>
<br>what about using global @define based variables for this purpose? that would probably be simple to access from within the template function and is global.
<br>
<br>the con of this is that nothing else uses @define yet.
<br>
<br>> The best would be to have a geoip() option in the global option space,
<br>> but I'm not sure a plugin can hook into that.
<br>>
<br>
<br>The syslog-ng team added some mechanisms to hook into the global options block though, but last time I looked I wasn't very happy about the implementation.
<br>
<br>let's talk about this the coming monday.
<br>
<br>> I suppose the first thing would be to add commandline handling to
<br>> tf_geoip first, so at least it's configurable. Then figure out a way to
<br>> make global configuration possible. I have no idea whether this latter
<br>> is possible with current syslog-ng 3.4, but this is a great opportunity
<br>> to make it possible to do this.
<br>>
<br>> Unless you want to work on this yourself further, I'll spice it up with
<br>> error handling and basic configurability in the next few days.
<br>>
<br>> Come to think of it, perhaps it would make sense to introduce a new
<br>> rewrite command, something along the lines of:
<br>>
<br>> rewrite r_geoip {
<br>>  apply(geoip("SRCIP"), "GEOIP");
<br>> };
<br>>
<br>> This would apply the "geoip" function to the value of the "SRCIP" key,
<br>> and place the result in ${GEOIP}. The advantage of this is that it's
<br>> perhaps faster to do this than parsing a template function and using
<br>> g_string_append_printf to reassemble another string.
<br>>
<br>
<br>I'm not sure why this would be faster than the set() rewrite op.
<br>
<br>> Similarly, this same apply() thing could be used to permanently modify
<br>> the name-value pairs: similar to what value-pairs() does, but instead of
<br>> returning a different, entirely independent set of name-value pairs, we
<br>> could apply the same transformations and filtering within a rewrite
<br>> rule:
<br>>
<br>> rewrite r_vp {
<br>>  apply(value-pairs("*" rekey(subst(".", "_"))));
<br>> };
<br>>
<br>> This would take all keys, and replace leading dots in key names with an
<br>> underscore instead, and it would modify the stuff in-place, so that
<br>> anything that works with the message from this point onward, would see
<br>> the rewritten names.
<br>
<br>this is a more interesting use-case.
<br>
<br>>
<br>> In essence, apply() would have a syntax like
<br>>  apply(FUNCTION(...)[, OUTPUT_VARIABLE])
<br>>
<br>> The function could either modify the LogMessage object itself, or return
<br>> a value. Functions would need to signal which one they do, and the
<br>> config parser would not allow using a function with an output value
<br>> without specifying a destination, etc.
<br>>
<br>> ...but I guess I'll draft up an RFC about this instead with a few more
<br>> possible use cases, advantages & disadvantages and the rest.
<br>>
<br>
<br>good ideas, but I would be careful to introduce another programmable mechanism in this syntax. so the usecases are interesting, I'm not sure about the proposed solutions.</p>
</body>
</html>