jmartin-sul
commented
5 years ago per the issue this was spawned from, these things will need to be confirmed to consider the issue closed:
- [ ] after the terraform and sinopia_acl changes have been merged, and the sinopia_acl docker image has been re-built and pushed: on the following monday, make sure the sunday morning run of the sinopia_acl migration completes without error, and adds any missing webID entries.
- [ ] get rid of cognito domain (the thing we were previously using to construct webIDs, see #80)
- [ ] terraform: get rid of the
COGNITO_DOMAINenv var for the sinopia_acl container and the underlying terraform variable (cognito_domain). - [ ] AWS: get rid of the cognito domain setting entirely since it should no longer be in use after the above (this may also be a terraform change, though i can't find where this is defined in TF at the moment, and rob showed me this by navigating to the setting in AWS console when we were working on this last week)
- [ ] terraform: get rid of the
spawned from LD4P/sinopia#224, which has lots more background and context.
currently, my very strong suspicion is that the user getting the cognito token and doing the update is not itself actually an admin user in the root ACL. e.g., when i queried the ACL on stage to see who has control privileges, the webID for
sinopia-devs_client-testerwas not in the list. that user is also absent from the list of admin users in the config file, despite being specified as the cognito admin user: https://github.com/LD4P/sinopia_acl/blob/7ac2681b14ad76b2c10ba67bcae2fd3a2793aeac/config/default.js#L8-L22however, when i went to try and add a new admin user to the root ACL on stage, executing
bin/migratefrom my laptop per the README, using my user (suntzu, whose webID does have control privs in the root ACL), things went smoothly for the group container creation, and then failed out on the admin user addition portion (i.e. the part we're trying to debug). the errors i get are along the lines of the following, for each defined admin user:i suspect that this may be unique to my laptop setup, or may be an issue with the way i'm invoking
bin/migrate. the command i ran was:though... looking at the terraform code, i am curious as to how the AWS creds are provisioned on the sinopia_acl container in AWS-land. based on the prior issues we were seeing in the ticket from which this was spawned, it seems possible that user lookup was never actually being exercised yet in AWS-land.
i also took the liberty of creating a new ACL admin specific user (manually registered the user via cognito signup on dev, stage, and prod). i have a draft PR up in our terraform repo to switch to that user, and will put up a corresponding sinopia_acl draft PR shortly. i created this user both to keep from possible simultaneous login by an account that we already share for integration tests run locally and in CI, as well as to keep user/password re-use to a minimum, esp since this is a somewhat more sensitive use case than integration testing. the sinopia_acl PR will also fix things so that the default sinopia_acl admin user for making changes is also in the default list of admin users to be put in the ACL when
bin/migrateis run.since we're pausing sinopia work for a few weeks to do some maintenance, i'm leaving these notes with the intent of picking the work back up when we start back on sinopia work in general. we don't anticipate adding admins very frequently, and can do so manually when needed (either by figuring out how to run
bin/migrateas has successfully been done in the past, or by manualcurlPOSTs to trellis with a valid cognito token for a current admin user).i'll assign myself for now, since i've been investigating this off and on for the last few weeks. but since @mjgiarlo and @ndushay wrote this code, and have more experience with this code base, i will likely try to pair with one or both of them when i get back to this.