Administrator Credentials

How to make an admin hat

Kerberos

This is similar to the procedure in Using Multiple Instances. Create a prinicpal on the kdc via kadmin:

addprinc ${USER}/admin
pts createuser ${USER}.admin

Note that as per Kerberos KDC admin hats automatically have full access to the Kerberos database through kadmin. You should probably update /afs/acm.jhu.edu/group/admins.pub/k5login file to include the new admin; see The Special Case of admins.pub. Don’t forget to vos release group.admins.pub afterwards.

LDAP

For LDAP to consider this user an administrator, a new entry must be created:

dn: cn=admin,uid=${USER},ou=People,dc=acm,dc=jhu,dc=edu
cn: admin
uid: ${USER}
objectClass: jhuacmKerberosInstance

For details, consult LDAP.

AFS

For AFS to consider this user an adminstrator, this user must be put in the system:administrators group and by convention we keep the non-admin hats of administrator users in a separate group:

pts add ${USER}.admin system:administrators
pts add ${USER} system:non-admin-hats

Note

No non-.admin credentials should ever be present in system:administrators.

To make the user an AFS superuser, which grants ability to manage the AFS servers, the file:///afs/acm.jhu.edu/group/admins.pub/UserList file must be updated. Update the .annotated file beside it, then derive the UserList by running ./scripts/afs-UserList.pl < ./UserList.annotated. Then release the volume (which will suffice to update the machines which are AFS file servers) and inform the ubik servers by hand:

for i in root@typhon.acm.jhu.edu root@echidna.acm.jhu.edu root@chicago.acm.jhu.edu; do
  echo $i
  ssh -t $i sudo cp /afs/acm.jhu.edu/group/admins.pub/UserList /etc/openafs/server/UserList
done

Note

We have to do the latter stage separately because the release will break callbacks, and the Ubik servers will attempt to read the UserList after the callback is broken, and will time out. This is sad. Ideally, the VLDB should be a client of the PRDB for these operations (unless a flag is given?) and the PRDB should interrogate itself rather than UserList (again, unless a flag is given?)…

SSH

Probably the new admin should also give an SSH key to the pool in file:///afs/acm.jhu.edu/group/admins.pub/authorized_keys . See The Special Case of admins.pub.