Admin reference

From ProgClub
Revision as of 03:39, 19 August 2011 by John (talk | contribs)
Jump to: navigation, search

__NOTITLE__ This page is a reference for ProgClub system administrators. For information about ProgClub domains, see Domains. For information about member services, see Services. See Machines for information about hosts on the ProgClub network. See Projects for current projects or check out our Forums to get in touch.

Administrative reference

If you're administering ProgClub assets, please document your actions on the wiki. See the relevant pages:

See Future machine names for the kind of stuff we're on about.

See, or update, Network administration for work that needs to be done.

Tools

See /home/jj5/login_ldap for the LDAP login. See /home/jj5/login_data for the database login. See /home/jj5/login_mail for the email login.

Documentation

The process for documenting network administration activity is:

Note: don't use screen while administering systems, because it frags PuTTY's scroll buffer, and you need that in order to copy-and-paste your session log.

  • Update the network administration page with a note about what you did:

It's not a bad idea to link to the relevant section(s) of the admin page(s) from the network administration 'done' note, but that's not strictly necessary.

  • Let everyone know what new features are available:

Administrative and user machines

As explained on the Machines page ProgClub separates its machines into two groups: administrative machines and user machines. There is only one administrative machine, charity. There are two user machines, hope and honesty. If you're doing sysadmin work on the user machines, make sure you duplicate your work and create an identical system configuration on each machine. Both user machines should have the same configuration. And, yes, this means that you have to duplicate your documentation too. If you're doing some experimental configuration I'd suggest doing it on honesty first, and then once you've got everything figured out and stable duplicating onto hope. You can use hope first though if it suits you. Try not to let too much time pass with the systems in different configurations, generally you should do your sysadmin work on both systems immediately one after the other.

Administrator logins

The way logins work for administrators (as opposed to normal users) is that you have two logins. One login is for the administrative server (currently there is only one of these, charity), and the other login is your Kerberos/LDAP login that gets you access to the user machines. You can use different passwords if you want, but the usernames (and UIDs) will be the same. All administrators are members of the 'sudo' group on charity and in LDAP. This means that you can use your sudo privileges on either administrative machines or user machines.

Etckeeper

Etckeeper is now installed on charity (and hope and honesty), which means the correct procedure after making edits to files in /etc is to issue:

$ sudo etckeeper commit "my reasoning here"

after you're done with your changes. There's an auto commit every day, and an autocommit whenever you apt-get install something. You can manually commit your changes as above. To see the commit log for a particular file:

$ sudo bzr log /etc/passwd

To revert an unwanted or bad change, work out which revision you want to revert to (see log above) and run:

$ sudo bzr revert --revision <commit number> <file>

For example, to restore the /etc/passwd file to the state it was in in revision 3,

$ sudo bzr revert --revision 3 /etc/passwd

To check for uncommited changes, run (From inside /etc):

$ sudo bzr status

For example:

$ sudo bzr status
modified:
  crontab

If you see no output, there are no uncommited changes.

Adding a new user

Updating members database

At the moment member information is recorded in Members. A member should have a Wiki account to start with, then an entry in the Members page (where they are allocated a member number), then the "User info" on their user page should be filled out (leave fields as "Not disclosed" unless you have their permission to publish their details). After the Members page has been updated you will have:

  • {username}: the Unix/Kerberos username of the new member
  • {member number}: the member's User ID
  • {group}: whether the user has 'sudo' membership or not
    • there are two groups at ProgClub: 'sudo' and 'user'
      • everyone is in 'user' (gidNumber == 500)
      • administrators are in 'sudo' (gidNumber == 27)

And that's enough information to create their account as detailed below.

Kerberos administration

To create a new user in Kerberos:

  • SSH to charity.progclub.org
  • Login
  • Run kadmin addprinc:
$ sudo kadmin -p {your username} -q "addprinc {username}"
    • Note: use sudo so that the log file can be written
    • {your username} is your ProgClub username
    • {username} is the ProgClub username of the user your are adding

If the user is an administrator, add them to /etc/krb5kdc/kadm5.acl. E.g., at the end of the file,

username@PROGCLUB.ORG *

replacing 'username' as appropriate. You need to restart the Kerberos administration server after this change:

$ sudo /etc/init.d/krb5-admin-server restart

Creating home directory or administrative login

  • SSH to charity.progclub.org
  • Login

If you are creating an administrative account, run:

# adduser --uid {member number} --gid 27 {username}

If you are creating a normal user account, run:

# adduser --uid {member number} --gid 500 --disabled-password {username}

(This creates the user's home directory)

LDAP administration

To create a user in LDAP:

  • Open the LDAP administration tool
  • Login: cn=admin,dc=progclub,dc=org (/home/jj5/ldap_login for password)
  • Navigate to: ou=users
  • Click 'Create new entry here'
  • Choose 'Default'
  • Container should be: ou=users,dc=progclub,dc=org
  • ObjectClass: inetOrgPerson
  • Select the RDN attribute: Username (uid)
  • Enter 'cn', this is the Common Name, i.e. the user's full name, or their username
  • Enter 'sn', this is the Surname, i.e. the user's last name, if it's disclosed, else username
  • Enter 'displayName', i.e. the user's full name, if it's disclosed, else username
  • Enter 'Email', i.e. the user's email address, if it's disclosed, else blank
  • Enter 'givenName', i.e. the user's first name, if it's disclosed, else blank
  • Enter 'Username', this is their Posix username, all lowercase
  • Click 'Create Object'
  • Review the entry and click 'Commit'
  • Scroll down to 'objectClass' and click 'add value'
  • Select 'posixAccount'
  • Enter the 'gidNumber': 27 for admin, 500 for user
  • Enter the 'homeDirectory': /home/{username}, e.g. /home/jj5
  • Enter the 'uidNumber': this is the member number allocated on the web-site in Members
  • Click 'Add ObjectClass and Attributes'
  • Review the entry and click 'Update Object'
  • Scroll down to 'objectClass' and click 'add value'
  • Select 'shadowAccount'
  • Click 'Add new ObjectClass'
  • Click 'Add new attribute'
  • Select 'loginShell'
  • Enter "/bin/bash"
  • Click 'Update Object'
  • Review changes and click 'Update Object'
  • Navigate to ou=groups
  • Select 'user'
  • Select the "Generic: Posix Group" template
  • Select the new user (all users should be selected)
  • Click 'Update Object'
  • Review changes and click 'Update Object'

If the user is an administrator:

  • Navigate to ou=groups
  • Select 'sudo'
  • Select the "Generic: Posix Group" template
  • Select the new user (all administrative users should be selected)
  • Click 'Update Object'
  • Review changes and click 'Update Object'