{"action":"created","issue":{"url":"https://api.github.com/repos/apache/couchdb/issues/1781","repository_url":"https://api.github.com/repos/apache/couchdb","labels_url":"https://api.github.com/repos/apache/couchdb/issues/1781/labels{/name}","comments_url":"https://api.github.com/repos/apache/couchdb/issues/1781/comments","events_url":"https://api.github.com/repos/apache/couchdb/issues/1781/events","html_url":"https://github.com/apache/couchdb/issues/1781","id":385903559,"node_id":"MDU6SXNzdWUzODU5MDM1NTk=","number":1781,"title":"Cluster Setup doesn't set consistent admin user","user":{"login":"wohali","id":112292,"node_id":"MDQ6VXNlcjExMjI5Mg==","avatar_url":"https://avatars2.githubusercontent.com/u/112292?v=4","gravatar_id":"","url":"https://api.github.com/users/wohali","html_url":"https://github.com/wohali","followers_url":"https://api.github.com/users/wohali/followers","following_url":"https://api.github.com/users/wohali/following{/other_user}","gists_url":"https://api.github.com/users/wohali/gists{/gist_id}","starred_url":"https://api.github.com/users/wohali/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wohali/subscriptions","organizations_url":"https://api.github.com/users/wohali/orgs","repos_url":"https://api.github.com/users/wohali/repos","events_url":"https://api.github.com/users/wohali/events{/privacy}","received_events_url":"https://api.github.com/users/wohali/received_events","type":"User","site_admin":false},"labels":[{"id":594290317,"node_id":"MDU6TGFiZWw1OTQyOTAzMTc=","url":"https://api.github.com/repos/apache/couchdb/labels/bug","name":"bug","color":"EE3F46","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":16,"created_at":"2018-11-29T20:02:09Z","updated_at":"2018-12-10T21:18:22Z","closed_at":null,"author_association":"MEMBER","body":"Similar to #1752, if you use the cluster setup wizard to create admin users on new nodes in the cluster, the created admin user will not use an identical salt on every node, meaning Fauxton fails to obtain a valid `_session` unless you manually distribute the ini file `[admins]` user yourself using a config management tool.\r\n\r\n## Expected Behavior\r\nSetup wizard creates a real server admin user that is usable from Fauxton immediately.\r\n\r\n## Current Behavior\r\nSetup wizard creates an admin user that cannot be load balanced because the salt is different.\r\n\r\n## Possible Solution\r\nPass the salt along as part of the cluster setup API endpoint?\r\n\r\n/cc @janl "},"comment":{"url":"https://api.github.com/repos/apache/couchdb/issues/comments/445977015","html_url":"https://github.com/apache/couchdb/issues/1781#issuecomment-445977015","issue_url":"https://api.github.com/repos/apache/couchdb/issues/1781","id":445977015,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0NTk3NzAxNQ==","user":{"login":"wohali","id":112292,"node_id":"MDQ6VXNlcjExMjI5Mg==","avatar_url":"https://avatars2.githubusercontent.com/u/112292?v=4","gravatar_id":"","url":"https://api.github.com/users/wohali","html_url":"https://github.com/wohali","followers_url":"https://api.github.com/users/wohali/followers","following_url":"https://api.github.com/users/wohali/following{/other_user}","gists_url":"https://api.github.com/users/wohali/gists{/gist_id}","starred_url":"https://api.github.com/users/wohali/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wohali/subscriptions","organizations_url":"https://api.github.com/users/wohali/orgs","repos_url":"https://api.github.com/users/wohali/repos","events_url":"https://api.github.com/users/wohali/events{/privacy}","received_events_url":"https://api.github.com/users/wohali/received_events","type":"User","site_admin":false},"created_at":"2018-12-10T21:18:22Z","updated_at":"2018-12-10T21:18:22Z","author_association":"MEMBER","body":"So there's 2 things you've left unaddressed here that I think need to be explained before I can discuss your response.\r\n\r\n1. Why are we bothering to pass in both a `username/password` and `remote_current_user/password` pair if we require everything to be identical on all nodes? I would have thought that the `username/password` pair is the admin user we are trying to create everywhere, and the `remote_current_user/password` pair is the pre-existing admin user on that remote node we need to use to affect change on that node.\r\n\r\n    1. In an ideal world, assuming these two pairs of data are allowed different, why couldn't the `remote` version be some unique auto-generated set of creds on every node? I'm looking towards CouchDB 3.0 where we intend to completely remove admin party. In this situation, nodes will stand up with an arbitrarily generated admin/password pair, and there is no way (short of pre-seeding your own `local.ini` file) that Couch could possibly know `a priori` what the eventual cluster's admin/password pair would be. **But**, if it printed out its randomly generated u/p on startup (similar to how `dev/run` does it), that info could be gathered by a script or a human and plugged into the cluster wizard on setup. These would be the `remote` credentials, and the primary `username/password` pair passed in via JSON would be the newly created admin user, with the unified salt. (The wizard could then *also* remove the autogenerated u/p credentials, as a bonus feature to be added later.)\r\n\r\n    2. Assuming for whatever reason we don't want to do 1, why are we even bothering to pass in 2 sets of credentials, if the only way this works is if we forcibly manually set the creds on every node to be identical at the start? I notice you've removed the second set of credentials in your example, but that still has confusion with the difference between the two sets of creds - if we're forcing it via the first step, why bother even supporting passing them in?\r\n\r\n2. The situation where a different admin password is set on a node and I forgot to pass in the correct `remote_current_user/password` should have been an error, no? It shouldn't have been able to make *any* change to that remote node. And yet we got back an `{\"ok\":true}`. That's got to be wrong."}}
{"actor":{"display_login":"wohali"}}