I've been coming across a number of organisations who are blocked from installing Metron by the MySQL auth database.
The main problems with our MySQL default are: * What? Un-ecrypted passwords?!? - which frankly is embarrassing in a security platform and usually where the deployment conversation ends for me * MySQL install varies from platform to platform * An additional database to manage, backup, etc. so now I have to talk to a DBA * Harder to maintain HA for this without externalising and fighting against our defaults * There are a lot of dependencies for just storing a table of users (Eclipse Link, JPA, the MySQL server and the need to get clients installed and pushed separately because of licence requirements) * Organisations don't want to have to manage yet another user source of truth since this leads to operational complexity. In short, managing our own user store makes very little sense to operations users. Some of these (licence and inconsistency for example) could be solved by changing our default DB to something like Postgres, which has easier terms to deal with. We could start encrypting passwords, but there would still be a lot of dependencies to store users, which is a problem much better solved by LDAP. Now that we have the option to use LDAP for user storage, I would suggest that we deprecate and ultimately remove all the RDBMS and ORM dependencies, which significantly reduces our dependencies and simplifies deployment and long term management of Metron clusters. So I propose that we deprecate the RDBMS use in the next Apache release, and then strip out the RDBMS stuff in the following. We would continue to use LDAP for users and HBase for non-LDAPy user settings (as we currently do). We should also provide a small demo LDAP for full dev. Since we are looking at adding Knox into the stack, that project provides a convenient mini-LDAP demo service which would do this job without the need to add additional components. Thoughts? Anyone relying on MySQL for users (if so, are you aware that your passwords are all plaintext? How do you currently handle the shortcomings and admin overhead?) Any objections? Simon
