|
Size: 1124
Comment: Add notes based on ClintonEbadi's irc comments
|
Size: 2865
Comment: update instructions for creating new admin user for the modern era
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
<<TableOfContents>> |
|
| Line 5: | Line 7: |
| Currently, we do it this way: | `NAME` = Member's non-administrative username. All commands should be run from ServerGibran (or the current administrative server). |
| Line 7: | Line 9: |
| Gibran: | == Basic Setup == Steps required to create a minimally functional admin user. === Creating the user === |
| Line 9: | Line 16: |
| - cd /afs/.hcoop.net/common/etc/scripts - ./create-user NAME_admin - pts adduser NAME_admin system:administrators - bos adduser gibran NAME_admin - bos adduser lovelace NAME_admin |
/afs/hcoop.net/common/etc/scripts/create-user-new NAME_admin sudo kadmin.local cpw NAME_admin # set randomly generated initial pw |
| Line 16: | Line 20: |
| Then, update the `hcoop-[admin-]-common-config` package to include user in sudoers. | The user will now exist in Kerberos, AFS, and DomTool but have no administrative permissions. |
| Line 18: | Line 22: |
| Additionally, grant MitKerberos administrative permissions as needed. | === Administrative Email Lists === |
| Line 20: | Line 24: |
| == Puppet == | In `~hcoop/.domtool/hcoop.net` add the new admin users to the `admin_emails` list which will add them to the needed mail aliases to receive admin mail. |
| Line 22: | Line 26: |
| A puppet environment needs to be added. The new admin has to be added to the admin users variable in puppet, which *should* add sudoers and login.restrict entries as needed. IIRC all that is needed is: | Also add `emailAlias "NAME_admin" "NAME";` so administrative emails are forward to the admin's normal mail account. |
| Line 24: | Line 28: |
| * create /srv/puppet/environments/$user * link that from /etc/puppetlabs/code/environments/$user * copy in environment.conf + hiera.conf from the production env * clone manifests and modules/hcoop into the new user env |
TODO: update AdminArea with list of lists that admins are expected to not ignore. |
| Line 29: | Line 30: |
| == Domtool == | === SSH Access, Sudo On Administrator-Only Servers, and Kerberos Admin === |
| Line 31: | Line 32: |
| * check perms for an existing _admin user and add those to the new _admin user | In Puppet, modify `modules/hcoop/manifests/init.pp` and add the new admin user to the `$admins` list. This will allow them to connect to all servers and have sudo which will also grant access to locally administered services like Postgres and MySQL. This also grants them kerberos administrator privileges. ''FIXME'': do we make that optional? MitKerberos admin powers are very broad, and perhaps not all admins will need them. === Puppet Environment === Create a puppet environment for the new admin as described in [[ConfigurationManagement#Personal_Environments]] which allows them to actually make changes to system configuration. '''All system changes are made through Puppet.''' === Portal Admin === On the [[https://members.hcoop.net/portal/groups|Portal Groups Management Page]] add the admin's member account to the `root` group. This enables full access to portal administrative features and allows the admin to view support requests. == Services == Although not strictly needed, the admin will not be able to handle all support requests without these. === DomTool Administrator === To grant full admin permissions: `domtool-admin grant NAME_admin priv all` [[DomTool/ArchitectureOverview#Standard_ACL_classes]] has a list of all valid values for `priv` which can be used instead of `all` if more limited administrative permissions are desired. === AFS Administrator === AFS administrative permissions are controlled by membership in the `system:administrators` group, so if a user is intended to have AFS admin privileges: `pts adduser NAME_admin system:administrators`. === Wiki administrator === Add new admin's wiki account to the list on AdminGroup |
TODO: Write a create-admin-user script that does this all automatically (add it to the scripts git repo)
Contents
1. Adding new admins
NAME = Member's non-administrative username. All commands should be run from ServerGibran (or the current administrative server).
1.1. Basic Setup
Steps required to create a minimally functional admin user.
1.1.1. Creating the user
/afs/hcoop.net/common/etc/scripts/create-user-new NAME_admin sudo kadmin.local cpw NAME_admin # set randomly generated initial pw
The user will now exist in Kerberos, AFS, and DomTool but have no administrative permissions.
1.1.2. Administrative Email Lists
In ~hcoop/.domtool/hcoop.net add the new admin users to the admin_emails list which will add them to the needed mail aliases to receive admin mail.
Also add emailAlias "NAME_admin" "NAME"; so administrative emails are forward to the admin's normal mail account.
TODO: update AdminArea with list of lists that admins are expected to not ignore.
1.1.3. SSH Access, Sudo On Administrator-Only Servers, and Kerberos Admin
In Puppet, modify modules/hcoop/manifests/init.pp and add the new admin user to the $admins list. This will allow them to connect to all servers and have sudo which will also grant access to locally administered services like Postgres and MySQL.
This also grants them kerberos administrator privileges. FIXME: do we make that optional? MitKerberos admin powers are very broad, and perhaps not all admins will need them.
1.1.4. Puppet Environment
Create a puppet environment for the new admin as described in ConfigurationManagement#Personal_Environments which allows them to actually make changes to system configuration. All system changes are made through Puppet.
1.1.5. Portal Admin
On the Portal Groups Management Page add the admin's member account to the root group. This enables full access to portal administrative features and allows the admin to view support requests.
1.2. Services
Although not strictly needed, the admin will not be able to handle all support requests without these.
1.2.1. DomTool Administrator
To grant full admin permissions: domtool-admin grant NAME_admin priv all
DomTool/ArchitectureOverview#Standard_ACL_classes has a list of all valid values for priv which can be used instead of all if more limited administrative permissions are desired.
1.2.2. AFS Administrator
AFS administrative permissions are controlled by membership in the system:administrators group, so if a user is intended to have AFS admin privileges: pts adduser NAME_admin system:administrators.
1.2.3. Wiki administrator
Add new admin's wiki account to the list on AdminGroup