mbolli
commented
4 years ago I support the general case made here, a few points:
- perhaps the
NfDumpclass would better be moved to aprocessordirectory - a
Processorinterface could be added to the same directory,NfDumpwould implement it - any other
Processorlike your customNfDumpimplementation could either extend the defaultNfDumpor create something new, but implementing theProcessorinterface NewNfDump()would additionally check if the class specified in settings implementsProcessorNewNfDump()would default to the existingNfDumpclass for backward compatibilityNewNfDump()being renamed with lowercase N at the beginning, andstatickeyword added
I could probably do the first two, although you'd need to rebase...
nrensen
This diff adds support for custom NfDump implementation by specifying an nfdump class in settings (similarly to the way custom databases are supported). I use this to allow nfsen-ng to run in a php chroot without direct access to the nfcapd files. The original nfsen supports this.
My custom nfdump model (not included here), which is similar to the original nfsen, is to run a separate nfsend daemon and have nfsen-ng communicate via a fifo. This could also work using a socket which would allow nfsen-ng to run on a different host from that where the nfcapd files reside.
You may consider this too obscure to support within the nfsen-ng code base, although the additional complexity is minimal. If you are concerned that existing nfsen-ng users will be required to add the nfdump entry in the general settings then I can alter NewNfDump() to default to the normal nfsen-ng NfDump implementation if there is no nfdump class specified in settings.