## 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


### 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

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.