Hi Tom, that is true, and I think that is the only viable approach. We do however use the database for testing during build, and we do however setup the components that use the data base in the ’sample’ flow with the simulated sensors for our vagrant deploy… and our contrib/docker deploy etc.
So, having the user download their own properly licensed version ( and having the user responsible for the privacy law issues ) is fine, but I think we need to talk through all the ways we are going to change the build, what it means for testing that component ( does it move to contrib ? ), and the default deployment to vagrant/topology. On January 13, 2020 at 13:41:01, Yerex, Tom (tom.ye...@ubc.ca) wrote: Hi Otto, Thank you for raising this in the discussion. It seems to me that Maxmind is proactive about providing instructions and code to deliver updates to the local system. I can recall being surprised that the current Metron solution seemed to do more than I expected, i.e., I thought I would need to get Maxmind files into the local file system where Metron would pick those up and load them into HDFS and instead Metron did it all. Perhaps the approach to simplify Metron and have it load files from the local file system into HDFS, how you get the files to the local file system is up to you? On 2020-01-13, 3:52 AM, "Otto Fowler" <ottobackwa...@gmail.com> wrote: https://issues.apache.org/jira/browse/METRON–2340 https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/ Maxmind has changed the way the distribute and license the geolite2 database that we use in our builds and distribution. Master build is broken, and users are having issues setting up metron ( https://the-asf.slack.com/archives/CB7Q6AN3T/p1578556024012200) We need to fix the build and figure out how we are going to move on from this.
