Re: [Nfsen-discuss] Nfcapd fails to update graphs: "Can't get statinfo!"
Netflow visualisation and investigation tool
Brought to you by:
phaag
|
From: Peter H. <ha...@sw...> - 2006-08-16 09:02:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Giles, - -------- Original Message -------- From: "Giles Coochey" <Gi...@Ca...> To: ha...@sw... Subject: Re:[Nfsen-discuss] Nfcapd fails to update graphs: "Can't get statinfo!" Date: Wed Aug 16 2006 08:28:49 GMT+0200 (CEST) > Hi Peter, > >> nfsen runs the command nfdump -I .. to retrieve statinfo from >> data files. For any unobvious reason, this command could not be >> completed. You may change line 481 in libexec/NfSen.pm and add >> '$!' so the line looks like: >> >> >> $Log::ERROR = "$name/$source/nfcapd.$tstamp: Can't get >> statinfo: $!"; >> > > I've edited that line, so we'll see if it happens again, and if it does > I'll relay the information back to you. Ok - do not forget to reload nfsen after the change: 'bin/nfsen reload' > >> This should give you more information about the reason why the >> command failed. >> >> >> Did you change any settings/permissions/users/groups in the >> meantime? Did you manipulate any files as root? - just possible >> sources for this error. >> > > Well, something interesting, though perhaps unrelated - when I created > the profile via the web interface the first few capture files were owned > by the apache user and group, but when I restarted the nfcapd the next > time via the init script the files are owned by netflow user and apache > group, the group has read access, while the user has read write access. > I'm keeping 35 days of data presently for each profile, so it should not > be attempting to expire anything yet. The is explainable: When you start a profile with a timestamp back in history - and even it's only 5min because in the meantime another slot was added, these files are profiled as apache user, as apache starts the profiling process. New files in a continuous profile are created from nfcapd user ( netflow user), therefore files with different uid may exists. As this is not particular nice, and due to new nfcapd daemon in upcoming release 1.3 any files will be owned by the netflow user. The $www_uid will no longer be needed and therefore will be dropped in nfsen. This should also solve some ugly permission problems, happened sometimes. > > Other than that the box is still in testing (probably until the end of > the month, when I'll switch our accounting over to nfsen/nfdump from > September - I'm the only one with access to the box, and from that no > one would have been making any changes at that time in the morning. > >> I run nfsen-1.2,4 on our production server without any problems >> since ever. Maybe you can figure why this happened. I'd be >> interested in that. > > I'm glad to hear it, perhaps it was just a blip. Any info I get I'll let > you know. > > One other thing, I notice that the dump files are relatively > uncompressed - would that be a feature that might be implemented in the > future? Another option would be to use a compressed filesystem to store > the files on, does such a filesystem exist under Linux? I always have mixed feelings when talking about compressed flows. On one hand, it saves you space, but burns your CPU. This may not be an issue under a large multiprocessor system, but can impact a single CPU machine with large ( 100MB + ) files. Anyway, as already other people requested compressed files, future nfdump releases will have options to switch on/off bzip compression for the flow files. - Peter > > Many Thanks > > Giles > - -- _______ SWITCH - The Swiss Education and Research Network ______ Peter Haag, Security Engineer, Member of SWITCH CERT PGP fingerprint: D9 31 D5 83 03 95 68 BA FB 84 CA 94 AB FC 5D D7 SWITCH, Limmatquai 138, CH-8001 Zurich, Switzerland E-mail: pet...@sw... Web: http://www.switch.ch/security -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBROLe//5AbZRALNr/AQKMYwP8Dk5bTmDuQKHuf0unJSC3W4mSYQVJQ65/ lXECBkZAloH00eqYk3/gFtz+OrSlbD4WM0j2SovaVnxXiX70f3DWKa5u9C/GC7ue SxYtnlyjHtCjM73+v2gC0kJyr2buGduPcal0j6B4eIiSE0+sfnDiN/INrZy2mjt0 dhA6lyESrQA= =SoCr -----END PGP SIGNATURE----- |