need a plan for creating a new site admin account

[chaos@bbn.com]

There should be a plan or checklist for creating accounts on a rack for a new site admin.

[ricci@cs.utah.edu]

There is a suggested solution for this, waiting for additional feedback. Bits of relevant mail follow:

Leigh:

Rather then design and implement yet another mechanism, it seems we can go
with a simpler approach; before any rack can be installed, someone has to
contact us and tell us the network configuration so we can bake the control
and boss/ops VMs. That person or entity can supply us with an ssh pub key
(or keys) and we will bake them in. We can use a generic "localadmin"
account name, to which we add the keys when baking.

After that, the localadmin can add new keys as needed. If not already
mentioned, the more a local admin messes around, the greater the chance
that something will break (especially inside the boss VM).

I am not sure how Nick is planning to deal with this, but I suspect the
above approach is easy for him too! :-)

Chaos:

Hmm... so, my off-the-cuff reaction is that this may not be the best
approach.

It loses user-level customization and logging features which you already
have (trivial example: what if different site admins want different
shells in Emulab?), and i don't think it actually makes maintenance
all that much easier.  You still need to keep the key file in sync on
all hosts which have it.  If someone leaves a site and the site wants
to delete their admin account, you now have to go through each key file
and remember which key belongs to which user (and not miss an extra key
which was added for them or what-have-you), as opposed to just deleting
the account.

Leigh:

The local admin account is wholly under the control of the local admin.
Once we create the control node, they can do whatever they like. They want
more users, go ahead and create them.

Another possibility is that we ask for a file with a set of keys, one per
user, and bake that set of users into the images. That gets you multiple
admin accounts, but is still very easy to do.

[chaos@bbn.com]

Sorry i let this drop for so long. I am confused about the proposed solution. Are you suggesting more like:

1. There will be one admin account, named localadmin, which is shared between all site admins of the rack. The expectation is that all site admins will use that account for whatever they need to do.
2. There will be an admin account, named localadmin, which site admins can use to bootstrap their own accounts. The expectation is that site admins will create their own accounts themselves, and use them for whatever they need to do.

My feedback depends slightly on what is being proposed, but, in general:

• It's better for people to have individual accounts for auditing purposes, not to mention for individual user convenience.
• Any time there's a shared credential, there needs to be a plan for changing that credential when someone who has access to it leaves.

Let me know whether either A or B is similar to what you had in mind, and we'll go from there.

[chaos@bbn.com]

We had a hallway conversation at GEC about this ticket:

• We prefer for site admins to have individual accounts, rather than use a shared account.
• Rob asked if we need to be able to add accounts after the rack has been deployed, or if this is a one-time thing. We definitely need to be able to delete accounts after the rack has been deployed (e.g. if someone leaves the project), and the creation process is probably similar, and likely also necessary.
• A proposed solution:
  • For each new rack, Utah should create one account for some initial admin at the site (e.g. whoever takes delivery of the rack).
  • That account should have the credentials needed to add new accounts using the same method.
  • Utah should document the steps needed to create and delete site admin accounts.
  • Armed with that initial account and the documentation, each site will administer its own site admins thereafter (with the exception of "please rescue us because we had one site admin who left, sorry" type situations, which will hopefully be rare)

I believe both Rob and i are okay with the proposed solution. Rob, does this sound like what we talked about to you?

[chaos@bbn.com]

As far as i know, this ticket is still active: the solution proposed in 3 is still desirable and still outstanding.

[chaos@bbn.com]

I'd like to ping on this ticket: if we get the BBN rack in the near future, that would be a great time to test out the site admin account creation procedure. And i think we definitely want this procedure to exist in time for it to be used on any non-Utah/non-BBN racks which are delivered.

[chaos@bbn.com]

Leigh started a page for this at ​https://users.emulab.net/trac/protogeni/wiki/RackAdminAccounts, containing steps for creating control node and emulab admin accounts.

Someone (probably Nick) should produce some text about how to create accounts on the foam and flowvisor VMs, and that will be it for this.

[chaos@bbn.com]

Nick added information to ​https://users.emulab.net/trac/protogeni/wiki/RackAdminAccounts about creating FV and FOAM accounts, which is all this ticket needed to be closed.