Revision as of 02:09, 7 February 2012

__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.

Code of conduct

As a ProgClub administrator you have a lot of power. You have the capability to destroy ProgClub's files and configuration, to access all of ProgClub's databases, to pretend to be other users, and to access other users' private data. We expect you won't abuse your power. Specifically, under no circumstances should you:

Copy data from any of ProgClub's administrative databases into your own system

Read or copy any data from members' databases that are not yours

Pretend to be another member

Publicly disclose member details, such as name or email address, without their permission

All of your systems administration activity should be documented, and you shouldn't be doing anything evil. If you're not sure what qualifies as evil, if you have any doubt at all, please ask.

Although ProgClub doesn't make any guarantees, members should be able to feel as though their privacy is respected at ProgClub, and they should be able to feel confident that administrators aren't spying on them by reading their email or their other data.

Where are the keys?

Your administrator login on charity and your member account in LDAP will give you sudo privs on all of the ProgClub machines, both administrative and user machines. Some tools require special purpose logins, and for those you will find login details in the /home/jj5/login_* files which you can access from any of the machines.

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

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,

Configure mail and forwarding

# apt-get install bsd-mailx postfix

Package configuration
┌────────────────────────┤ Postfix Configuration ├────────────────────────┐
│ │
│ Please select the mail server configuration type that best meets your
│ needs.
│ ▒
│ No configuration: ▒
│ Should be chosen to leave the current configuration unchanged. ▒
│ Internet site: ▒
│ Mail is sent and received directly using SMTP. ▒
│ Internet with smarthost: ▒
│ Mail is received directly using SMTP or by running a utility such ▒
│ as fetchmail. Outgoing mail is sent using a smarthost. ▒
│ Satellite system: ▒
│ All mail is sent to another machine, called a 'smarthost', for ▒
│ delivery. ▒
│ Local only:
│ The only delivered mail is the mail for local users. There is no
│ network.
│
│
│ <Ok>
│ │
└─────────────────────────────────────────────────────────────────────────┘

Package configuration
┌─────────────────────────┤ Postfix Configuration ├─────────────────────────┐
│ The "mail name" is the domain name used to "qualify" _ALL_ mail │
│ addresses without a domain name. This includes mail to and from <root>: │
│ please do not make your machine send out mail from root@example.org │
│ unless root@example.org has told you to. │
│ │
│ This name will also be used by other programs. It should be the single, │
│ fully qualified domain name (FQDN). │
│ │
│ Thus, if a mail address on the local host is foo@example.org, the │
│ correct value for this option would be example.org. │
│ │
│ System mail name: │
│ │
│ example.progclub.net_____________________________________________________ │
│ │
│ <Ok> <Cancel> │
│ │
└───────────────────────────────────────────────────────────────────────────┘

Allocating user IDs

If you need to allocate a user id for a member, use their member number from the Members page. Member numbers start at 1000 and increment from there.

If you need to allocate a user id for a system user, such as a user that a process will run as, check for UIDs starting from 500 and use the next available one. If you create a user on one machine with a particular UID you should create the same user with the same UID on all the other machines too.

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 (create one for them if they haven't already created their own), 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: