I'm looking at trying to roll this in to a set of tools my team uses to manage a medium sized network at my organization.
One question I had while looking over what you've done - is there any particular reason you selected to use string based IP addresses instead of integers?
The MySQL functions inet_aton and inet_ntoa make this very easy, and save a lot of space in the database - especially if you are looking at storing a reasonably large dataset (ie weekly scan results for a corporate sized network over a 52 or 104 week period).
The fun you can have with integer based indexes (query by subnet using bitshifts in your WHERE clause, etc) also allow tremendous flexibility and performance gains over storing IP as a string.
I can modify your code to do this for my purposes, if you intend to leave the string based IP in future versions, but would ask you to at least consider the change.
Great work on this - I wish I'd thought of doing it myself at some point in the past! ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While playing with nmap-3.48-with-sql-0.0.3.tar.gz tonight, I noticed a small issue with nmaplog.sql that may make it easier for those starting out (not in release notes)...
Alternatively, could add a section to release notes discussing DB creation.
[...MySQLDump Header...]
CREATE DATABASE IF NOT EXISTS nmaplog;
USE nmaplog;
[...MySQLDump output...]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for a great product!
I'm looking at trying to roll this in to a set of tools my team uses to manage a medium sized network at my organization.
One question I had while looking over what you've done - is there any particular reason you selected to use string based IP addresses instead of integers?
The MySQL functions inet_aton and inet_ntoa make this very easy, and save a lot of space in the database - especially if you are looking at storing a reasonably large dataset (ie weekly scan results for a corporate sized network over a 52 or 104 week period).
The fun you can have with integer based indexes (query by subnet using bitshifts in your WHERE clause, etc) also allow tremendous flexibility and performance gains over storing IP as a string.
I can modify your code to do this for my purposes, if you intend to leave the string based IP in future versions, but would ask you to at least consider the change.
Great work on this - I wish I'd thought of doing it myself at some point in the past! ;)
While playing with nmap-3.48-with-sql-0.0.3.tar.gz tonight, I noticed a small issue with nmaplog.sql that may make it easier for those starting out (not in release notes)...
Alternatively, could add a section to release notes discussing DB creation.
[...MySQLDump Header...]
CREATE DATABASE IF NOT EXISTS nmaplog;
USE nmaplog;
[...MySQLDump output...]
I'm hoping to use integer IP addresses from the next release onwards. I'm sure it'll be a hell of a lot of fun for some people :)
thanks for the hint on the nmaplog.sql file. I'll add it to the next release.