Re: [pmacct-discussion] minor patch for geoip and json output

2014-02-22 Thread Paolo Lucente
Thanks Stig,

Patch applied and committed to CVS. Thanks also for the note about
docs.

I didn't know about geoip2, just had a quick read through it. Should
anybody have a strong view we should add support for geoip2 please
give a shout here - along with a bit of elaboration on a use-case,
benefits, etc.

Cheers,
Paolo

On Fri, Feb 21, 2014 at 06:26:40PM -0800, Stig Thormodsrud wrote:
 Also related to geoip lookups, it might be worth adding to the
 documentation that this is for geoip 1 not geoip2.  I just googled mindmax
 free geoip database and download the free geoip2 database (not know there
 was a geoip1).  When I fire up pmacct pointing to the geoip2 database it
 seg faults in a hurry:
 
 Program received signal SIGSEGV, Segmentation fault.
 INFO ( 10.1.1.205-9996/nfprobe ): Exporting flows to [10.1.1.205]:9996
 0x77f5d7b0 in _GeoIP_seek_record () from /usr/lib/libGeoIP.so.1
 (gdb) where
 #0  0x77f5d7b0 in _GeoIP_seek_record () from /usr/lib/libGeoIP.so.1
 #1  0x77f5e03c in GeoIP_id_by_ipnum () from /usr/lib/libGeoIP.so.1
 #2  0x00425300 in src_host_country_handler (chptr=value optimized out,
 pptrs=0x7fff3c90, data=value optimized out) at pkt_handlers.c:4008
 #3  0x0041c388 in exec_plugins (pptrs=0x7fff3c90) at plugin_hooks.c:252
 #4  0x004581c8 in pcap_cb (user=0x7fff3ee8 , pkthdr=value optimized
 out, buf=value optimized out) at nl.c:80
 #5  0x004137e0 in main (argc=3, argv=0x7fff68f4, envp=0x7fff6904) at
 uacctd.c:830
 
 
 Of course using the right database solves that crash.
 
 
 
 On Fri, Feb 21, 2014 at 5:04 PM, Stig Thormodsrud sthor...@gmail.comwrote:
 
 
  I noticed when using geoip and json output that the country_ip_src was
  displayed but not the country_ip_dst.  This patch seems to fix it:
 
  diff --git a/src/pmacct.c b/src/pmacct.c
  index d62ba44..b29c7a3 100644
  --- a/src/pmacct.c
  +++ b/src/pmacct.c
  @@ -2996,7 +2996,7 @@ char *pmc_compose_json(u_int64_t wtc, u_int64_t
  wtc_2, u_int8_t flow_type, struc
   json_decref(kv);
 }
 
  -  if (wtc  COUNT_DST_HOST_COUNTRY) {
  +  if (wtc_2  COUNT_DST_HOST_COUNTRY) {
   if (pbase-dst_ip_country  0)
 kv = json_pack({ss}, country_ip_dst,
  GeoIP_code_by_id(pbase-dst_ip_country));
   else
 
 

 ___
 pmacct-discussion mailing list
 http://www.pmacct.net/#mailinglists


___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists


Re: [pmacct-discussion] Added support for durable messages to amqp plugin

2014-02-22 Thread Paolo Lucente
Hi Nick,

Thanks for the elaboration, very useful to know. Your patch has
been incorporated in current CVS code. The feature is available
via the amqp_persistent_msg configuration directive.

Cheers,
Paolo

On Fri, Feb 21, 2014 at 09:54:40AM +0100, Nick Douma wrote:
 Hi,
 
 On 20-02-14 16:55, Paolo Lucente wrote:
  Thanks for your patches. Most of the minor issues were already fixed in
  the CVS code; i've fixed the couple remaining. The memory leak is not a
  real one: some structures are not free'd up in amqp_cache_purge() but
  such function is called in a writer, ephemeral processes spawned each
  amqp_refresh_time intervals: once these processes are terminated the OS
  does take back all resources anyway.
  
  About the new feature you implemented: i'm reviewing the code (you did
  a very good job) and i'm happy to commit it to the CVS code. Just one
  question: what is your use-case for durable message support? Something
  like be able to recover un-processed JSON objects in case of reboot/
  restart of RabbitMQ?
 
 We currently have a setup that uses sfacct to read sFlow data, and uses
 rabbitmq with logstash to finally insert it into elasticsearch after
 some filtering by logstash.
 
 We use sFlow/sfacct to monitor and store data usage for all IPs
 traveling through our network. This data is then used to bill our
 customers. In this case, any loss of traffic information is unwanted,
 because that would either be unfair to our customers, or cut our revenue.
 
 By default, the sfacct / rabbitmq / logstash setup will drop any
 messages and clear all queues during reboot/restart. Logstash can create
 a rabbitmq queue as durable, but sfacct could not mark the messages
 durable as well. Both settings are needed to keep messages from being
 dropped in case logstash can't consume them, or any of the services are
 restarted.
 
 Kind regards,
 
 Nick Douma
 



 ___
 pmacct-discussion mailing list
 http://www.pmacct.net/#mailinglists


___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists