Well, actually that's exactly the scenario we're having: one application with several "environments": test, nightly, end-of-sprint and production. And the non-production environments are all hosted on the same server.
Initially we had the same ML users for all applications which caused obviously problems when tearing down one environment or setting up another. So now we have very specific names like kv3-next-sprintly-contents-kv3-reader for each environment (sprintly) and branch (next) and app (kv3). This is how it works right now, but restoring one environment to another server (production to dev, or pre-prod to production) requires us to run scripts to adjust the users' permissions for each and every document. For example, the "nightly" environment is constituted like this: we take the current code base, restore the production databases (documents, schemas, modules, triggers, but not yet security!) and any potential update scripts. The production database has its specific users and permissions that won't work in the dev environment. If we could have a security database for each environment, not only would we not have to reassign the document permissions for each document (which is a lengthy process), but we could also avoid exposing the ML admin account as it would only be available in the principal security database. cheers, Jakob. On Fri, Sep 26, 2014 at 11:18 AM, Jason Hunter <[email protected]> wrote: > If you're going to host multiple independent applications on the same > instance or cluster, you probably want different security databases for > each application. > > The people who are telling you not to change the setting probably realize > that you're not doing that style of deployment, so no need (for you) to > change it. > > -jh- > > On Sep 26, 2014, at 5:10 PM, Ken Tune <[email protected]> wrote: > Hi Jakob > > > > I guess it’s all about giving users choices – even if they’re choices that > aren’t used very much. > > > > You could use a separate security database to ensure your application user > ids are entirely separate from your admin user ids – not such a bad idea. I > admit I’ve never done this myself, though I wouldn’t rule it out. > > > > *And why can't I view and modify a newly created security database as I > can the original one?* > > > > I’m guessing you mean why can’t I put the admin console on top of ANY > security db? You possibly can, by setting up a new appserver with the > modules db = Admin folder on filesystem and content db = ‘new’ security > db. This would be a ‘try it and see’ option. > > > > You can use the sec: calls on *any * Security db however – and I’ve done > this myself when I’ve occasionally had to do ‘creative’ things. > > > > If there’s anyone on the list with a hand in the original design, they’d > be able to give you the actual reasons. > > > > Ken > > > > > > > > > > *From:* [email protected] [ > mailto:[email protected] > <[email protected]>] *On Behalf Of *Jakob Fix > *Sent:* 25 September 2014 14:47 > *To:* General Mark Logic Developer Discussion > *Subject:* [MarkLogic Dev General] security database(s) > > > > Hi, > > > > so we're wondering why in MarkLogic's management UI you have a dropdown > menu to select your security database for a given database. because > everybody we've talked to says to use the generic Security db. > > > > Why am I given a choice if actually I shouldn't (something to do with > clusters)? I know we need several and are currently attempting to recreate > new security databases that in turn have as their security database the > default one ... > > > > And why can't I view and modify a newly created security database as I can > the original one? > > > > Thanks for enlightening us! > > > cheers, > Jakob. > > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > > > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > >
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
