Hi Michael,
I cannot answer for others, but some of my answers are below.
On 2014-06-10, at 19:03 , Michael <m5mu...@gmail.com> wrote:
> Why is one of the goals to move away from snmptrapd? You can do direct perl
> integration. In some of the other applications I have written, I take the
> trap messages from snmptrapd, build them into a hash, convert them into json
> using JSON::XS and store them in a redis array. I then have another
> application processing those traps. It takes the work off of snmptrapd but
> utilizes the fact that it is written in c and can encode/decode packets
> faster and more efficiently.
We are actually working on something close to that. What we are currently
testing is using snmptrapd to receive the traps and sending them to an http API
that records the event and then deals with it asynchronously.
The initial goal for that API is to replace the use of snmptraps as IPC
internally and then move to replace all traps coming from network equipment.
That part will take longer and we will have to be careful not to break existing
support for network devices.
Ultimately we want to do away with the pfsetvlan daemon altogether.
> Have we considered using Redis instead of memcached? It is faster, supports
> more datatypes, can be persistent, and supports replication.
Yes. I should let others write about that since I did not do it myself but I
know that there have been some discussion about it and it is indeed looking
like it may be a valid replacement.
> Any consideration on moving from mysql to postgresql or supporting both?
My personal opinion is that the SQL code is in sore need of a good
rewrite/refactor with the possible use of an ORM.
Changing database and/or supporting more than MySQL does not seem to me to be
the most important issue at the moment.
OTOH the use of an ORM might make it easier to support more than one.
> Can someone please outline the challenges in implementing and active/active
> setup? From what I can think of we would need an external loadbalancer,
> external database (could replicate as well), and some way to sync
> configuration.
TIMTOWTDI. There are also I suppose many ways to do it wrong :-)
I wish those who are actually working on it would chime in (hint…) but I think
your assumptions are mostly correct.
Other thing to consider are DHCP, DNS and SNMP (if required).
Regards,
--
Louis Munro
lmu...@inverse.ca :: www.inverse.ca
+1.514.447.4918 *125 :: +1 (866) 353-6153
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
PacketFence-devel mailing list
PacketFence-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-devel
