There is a bug in flow-export program included in flow-tools package. When trying to export flow data to postgres or mysql, user gets the error: $ /usr/bin/flow-export -f 5 -m DOCTETS,SRCADDR,DSTADDR,INPUT,OUTPUT,SRCPORT,DSTPORT,PROT -u "user:pass:localhost:5432:flow:raw_traffic" < /var/lib/flows/2008/2008-03/2008-03-18/ft-v05.2008-03-18.061500+0500 flow-export: Missing field in dbaseURI, expecting user:pwd:host:port:name:table. /usr/bin/flow-export: Exported 0 records . This is because it flow-export.c there is a typo(?) in validating dbUri: if (!db_user || !db_pwd || !db_host || !db_tmp || !db_name || !db_table) { And the right line is: if (!db_user || !db_pwd || !db_host || !db_port || !db_name || !db_table) { The same typo is in mysql section. Reproducible: Always Steps to Reproduce: 1.Install flow-tools 2.Try to export flow data to postgresql using flow-export Actual Results: flow-export prints error Expected Results: adding data to database
Created attachment 146478 [details, diff] Patch to fix
Patch applied in flow-tools-0.68-r6. Thanks for reporting. Patch sent upstream.
*** Bug 303395 has been marked as a duplicate of this bug. ***
Reopening because of comments in bug #303395. @Mike Nerone: Please have your say right here where it belongs. Please provide some actual evidence too that this patch is wrong.
Comment on attachment 146478 [details, diff] Patch to fix The original goes like this: 1)db_tmp is initially set to whatever follows a colon after a couple of iterations. 2) Then db_tmp is used in atoi to get at db_port, an interger based on a string. 3) Then instead of db_port, db_tmp is used _again_ when checking if all required fields are initialised. Twice. After the patch it's like this: 1) db_tmp is initially set to whatever follows a colon after a couple of iterations. 2) Then db_tmp is used in atoi to get at db_port, an interger based on a string. 3) Then the calculated db_port is checked along with the other fields. Oh and one more thing. The patch you see here never made it into the tree whole - in the tree it doesn't remove that first line. See [URL].
Wow, still fixed!
Ok, I had assumed that the patch as given was applied. My bad. I'm still at a loss as to why the code works fine for me without the patch, nor do I see why it's invalid to check the string just like all of the other values. But incidentally, in previous instances where I had a comment on an old, closed bug (and not always under an erroneous assumption as happened here ;D ), when I commented on the old bug, a Gentoo dev jumped on me and said, "Don't comment on old, closed bug! Open a new one!"
I see what happened now. There was no bug in the mysql code at all (and the change there should still be reverted): db_tmp was a string and checking the string is fine. It was needed because the connect code needs the port as an int. In the postgresql part of the code, though, there's no need for db_tmp because the connect code wants the port as a string anyway, so db_port gets it as a string. The sanity check line was cut-and-pasted from the mysql code, though, which erroneously checks for db_tmp. Only the line in the postgresql code needed to be fixed. This is why rush.ru hit the error (with postgresql) and I didn't (with mysql).
(In reply to comment #8) > There was no bug in the mysql code at all (and the change there should still be > reverted): db_tmp was a string and checking the string is fine. It was needed > because the connect code needs the port as an int.
OK, I have bumped the revision to -r7 and edited the patch so that users get the pgsql patching applied, and not the mysql patching.
