Research Administration Tasks

Adding Users

We try to align the research usernames with an existing SFU Computing ID. This reduces confusion, and if the user chooses to also align their passwords, this gives the illusion of a single, seamless set of credentials across SFU / SIAT Research.

However, about 50% of our research users are non-SFU people. It is for this reason we run our own LDAP authentication server, and maintain our own users (as an aside, we also encrypt/store passwords in four different formats, which include suitable format for our SGI supercomputers, Linux workstations, Mac OS-X and two variations of Windows - this variety of password encryption is another reason we run local authentication).

For a non-SFU user, we create their username by period-separating their first and last names:

Non-SFU userid creation:

firstname.lastname (for example:  john.doe)

• As root on spitfire:

# cd
# DEBUG=1 /usr/local/sbin/diradm.superadduser '$username' '$email' '$fullname'

• Note that a file named '$username' is created in your current directory with the template filled out for mailing (the same file is displayed onscreen), and this is why it is very important to 'cd' to root's home directory before running the script so as to not cause any problems with home-directory creation.
• Further note that $username is the new user's username (which will not be tied in with their regular SFU username), $email is their preferred email address and $fullname is their first and last name.
• An email will be sent to their email address
• Add the newly-created user to our Research Mailing List.
• Add the new user to '/etc/amanda/spitfire/disklist'. This is to enable backups of the user's home directory

Deleting Users

Make sure there are no sym-links pointing to important stuff!!

# find -P /home/users/$username -noleaf  -type l

• As root on spitfire:

# DEBUG=1 diradm userdel -r $username

• As root on hood:

# DEBUG=1 diradm userdel $username

• Keeping the user on our Research Mailing List is probably a good idea.
• If you delete a user, you MUST disallow diradm from ever using that UIDNumber again. To do so, go to each machine with diradm and edit the diradm.conf file so that UIDNUMBERMIN to equal the same number as the highest UIDNumber currently being used. (At least one higher than the user you deleted) This is important!
• Comment out the user from /etc/amanda/spitfire/disklist, only if they will never need the data.

Changing a Users Password

This method does not require the old password.

• As root on hood:

# ldappass $username

Adding Users to a Group

Adding or removing from a group. Uses the same syntax as gpasswd(8).

• As root on hood:

# diradm gpasswd (-a|-d) $username $group
# diradm gpasswd -a mdeepwel pond

Adding Groups

Adding groups takes the same syntax as groupadd(8).

• As root on hood:

# diradm groupadd $groupname

To change the GID of any group:

• As root on hood:

# diradm groupmod -g GID $groupname

Adding Projects

This creates a project for the user, and adds a web folder, hosted via hercules00. If the user just wants places for their files, skip the htdocs and htlogs stuff, and skip all the hercules config.

For a single user

Note that $project designates the name of the new project and $user designates the user for whom the project is being created.

Create the new project directory:

• As root on hurricane:

# mkdir /mnt/raid/projects/$project
# mkdir /mnt/raid/projects/$project/htdocs
# chown -R $user /mnt/raid/projects/$project
# chmod -R 2701 /mnt/raid/projects/$project
# chmod 2775 /mnt/raid/projects/$project/htdocs
# mkdir /mnt/raid/projects/$project/htlogs
# chmod 755 /mnt/raid/projects/$project/htlogs

Add an LDAP entry for the newly created project:

• As root on hood:

# diradm amadd -O home.projects $project 209.87.56.231:/mnt/raid/projects/$project

1. '-O' means the default mount options for automount.

Create a sym-link in the user's home directory

• As root on whatever you want:

# cd /home/users/$user
# ln -s /home/projects/$project

Next, to set the up the hosting and the database:

• As root on hercules00 set up a new vhost.conf using an existing template:

# cd /etc/apache2/vhosts.d/projects/
# cat vhost_template.sample > $project.conf

TO DO - DATABASE HOWTO

Make sure you get Vic to add an alias!

For a group

Note that $project designates the name of the new project and $group designates the group for whom the project is being created.

First create a new group.

Create the new project directory:

• As root on hurricane:

# mkdir /mnt/raid/projects/$project
# chgrp -R $group /mnt/raid/projects/$project
# chmod -R 2771 /mnt/raid/projects/$project
# mkdir /mnt/raid/projects/$project/htdocs
# chmod 2775 /mnt/raid/projects/$project/htdocs
# mkdir /mnt/raid/projects/$project/htlogs
# chmod 755 /mnt/raid/projects/$project/htlogs

Add an LDAP entry for the newly created project:

• As root on hood:

# diradm amadd -O home.projects $project 209.87.56.231:/mnt/raid/projects/$project

1. '-O' means the default mount options for automount.

Create a sym-link in the all the user's home directories (the users belonging to $group). To find out who is in what group, use the command getent group | grep $group on any ldap-enabled machine.

• As root on your LDAP-enabled machine of choice:

# cd /home/users/$user
# ln -s /home/projects/$project

Next, to set the up the hosting and the database:

• As root on hercules00 set up a new vhost.conf using an existing template:

# cd /etc/apache2/vhosts.d/projects/
# cat vhost_template.sample > $project.conf

TO DO - DATABASE HOWTO

Make sure you get Vic to add an alias!

Adding CVS Repositories

Note: $user represents a user's username, $group represents a new group that will need access to the repository, and $repository is the new name for the CVS repository.

For a single user

Add the user to the cvs group:

• As root on hood:

# diradm gpasswd -a $user cvs

Create the repository and set the correct permissions:

• As root on hurricane:

# cvs -d /mnt/raid/cvs/$repository
# chmod -R 2700 /mnt/raid/cvs/$repository
# chown -R $user /mnt/raid/cvs/$repository

For multiple users

Create a new group, and add all the users that require access to the newly created group as well as the cvs group:

• As root on hood:

# diradm groupadd $group
# diradm gpasswd -a $user $group
# diradm gpasswd -a $user cvs

Create the repository and set the correct permissions:

• As root on hurricane:

# cvs -d /mnt/raid/cvs/$repository
# chmod -R 2770 /mnt/raid/cvs/$repository
# chgrp -R $group /mnt/raid/cvs/$repository

• To access the CVS repository, use CVS_RSH="ssh" with URL being :ext:$user@cvs.iat.sfu.ca:/var/cvsroot/$foobar
• See the more detailed CVS User guide

Adding SVN Repositories

Note: $user represents a user's username, $group represents a new group that will need access to the repository, and $repository is the new name for the SVN repository.

For a single user

Add the user to the svn group:

• As root on hood:

# diradm gpasswd -a $user svn

Create the repository and set the correct permissions:

• As root on hurricane:

# svnadmin create /mnt/raid/svn/$repository --fs-type fsfs
# chmod -R 2700 /mnt/raid/svn/$repository
# chown -R $user:root /mnt/raid/svn/$repository

For multiple users

Create a new group, and add all the users that require access to the newly created group as well as the svn group:

• As root on hood:

# diradm groupadd $group
# diradm gpasswd -a $user $group
# diradm gpasswd -a $user svn

Create the repository and set the correct permissions:

• As root on hurricane:

# svnadmin create /mnt/raid/svn/$repository --fs-type fsfs
# chmod -R 2770 /mnt/raid/svn/$repository
# chown -R root:$group /mnt/raid/svn/$repository

• The repository URL is svn+ssh://$username@svn.iat.sfu.ca/$repository

Dumping the contents of SVN Repositories to a file, and vice-versa

Note: $repository represents the repository's name.

To dump the contents to a file:

• As root on hurricane:

# svnadmin dump /mnt/raid/svn/$repository > file.dump

To load the contents from a file into a previously created repository:

• As root on hurricane:

# svnadmin load /mnt/raid/svn/$repository < file.dump

Adding Computers to the Domain

• As root on hood:

# diradm smbhostadd sr-#####

• refer to Workstation_Naming_Convention

General User Management

• diradm offers almost all regular POSIX commands, sometimes with a few extra frills. The only commands NOT completely implemented are gpasswd and passwd.
• Welcoming new users; email template
  • This is in the diradm.superadduser script, as it fills out the template.

To: $fullname <$email>
Subject: Research account created - $newuser

Hello $fullname

Your research account has been created.
Username: $newuser
Password: $newpass

Please visit http://research.iat.sfu.ca/network/changepassword.php to change
your password when you receive this email.

For support with the research network, please email:
help@research.iat.sfu.ca
Please include a good description of the entire problem and a suitable subject
line.

For more information about SIAT Research, visit our Research Wiki found at:
http://research.iat.sfu.ca/wiki/

Please note that this username/password pair is only valid for the SFU Surrey
Research Network, and is NOT tied into the main SFU authentication systems.

Sassafras K2 Keyserver Administration

Background

We use the Sassafras K2 Keyserver product for most license-compliance, primarily to extend the usefulness of a small number of licensed applications within the School of Interactive Arts & Technology (SIAT) Researcher community. Most users are sporadic, and don't require full-time access to our specialized applications; rather, they need to accomplish a defined task which may be one component of their research or publication.
The Sassafras keyserver runs under Linux, on bismarck.iat.sfu.ca, with install-root under /usr/local/k2.
In a process-listing, it shows up as:

/usr/local/k2/ks -d -e /usr/local/k2/startup.txt

It's started from an init-script under

/etc/init.d/KeyServer

which, in turn, is launched upon startup by the Gentoo rc-update scripts. No manual intervention is necessary (normally :-) ).
We currently (2007) have 200 key-client licenses, which covers our current user-quantity, with some room for future growth.
This keyserver serves licenses to Windows and Mac clients (only :-( ).

Administration

The main administration tool is the K2Admin program, which is capable of running under Windows, or Mac OS-X (only :-( No Linux).

Here is the Local Mac Copy
And, the Local Windows Copy

Viewing Key-served Applications

Open up K2's KeyConfigure, the license administration software. When you do, you'll need to enter the following information:

• Server: research-keyserver.iat.sfu.ca
• Username: Administrator
• Password: secret

Once open, you can see which Computers on the network are using what Software, what Software is running on what machine, and what Licenses are registered with the system.

In the Licenses window, you will see the name of the application, as well as how many licenses are in use at that particular moment in time, how many people are waiting for a license to free up, and how many licenses we own (labeled as 'Limit').

Double clicking on the name of a key-served software application, will bring up more details about its use. You can change the name of the application or change the way it is being key-served. More importantly, you can see who is using the application and on what machine (Click on 'Current User List' or 'Computer List'), and you can also see what application and which version is registered with the particular license. To see this, expand the 'Programs' section.

Adding Key-served Applications

Before starting, you must be on a Mac or Windows PC that already has the software you'd like to add installed and working.

Open KeyConfigure and go to File > Create License (or press Cmd+i on a Mac or Ctrl+i on Windows). A new window will appear. Enter a License Name, usually the same as the Software name. Then click Browse, and find the App that you'd like to keyserve (on a Mac it's usually under Applications, on Windows in Program Files). Double click it.

Make sure you check off 'Allow launch when KeyServer not available' (this is the default) just in case something breaks on the server, so people can still use their software until it's fixed.

Click OK. A new window with more details will come up. Expand the 'Limits' section by clicking on the small triangle, and choose 'Concurrent Use Limit (Floating License)', and under 'User Limit' enter the amount of licenses we own. Close the window, and make sure you 'Save'.

Removing Key-served Applications

This is very easy. Once you open up KeyConfigure, select the Application you'd like to remove, and go to Edit > Delete (or click Cmd+delete on a Mac, or Delete on Windows).

Working with LDAP

Modifying an LDAP entry

First create a .ldif file with its content in this format:

dn: uid=bob,ou=Users,dc=iat,dc=sfu,dc=ca
changetype: modify
replace: sambaHomePath
sambaHomePath: \\NEW\Samba\home\path

Then run this command:

• As root on hood:

# ldapmodify -x -f $file.ldif -D cn=Manager,dc=iat,dc=sfu,dc=ca -W

• You will be prompted for our LDAP password

The options in this command do the following:

• -x: use simple authentication instead of SASL
• -f: use the file $file.ldif to read the changes to be made
• -D: bind-dn (user to bind with)
• -W: prompt for password

Deleting an LDAP entry

Note that it is still better to delete users using the diradm method above, this is just for general use.

First create a .ldif file with its content in this format:

cn=bob,ou=home.users,ou=AutoFS,dc=iat,dc=sfu,dc=ca

Then run this command:

• As root on hood:

# ldapdelete -x -f $file.ldif -D cn=Manager,dc=iat,dc=sfu,dc=ca -W

• You will be prompted for our LDAP password

The options in this command do the following:

• -x: use simple authentication instead of SASL
• -f: use the file $file.ldif to read the changes to be made
• -D: bind-dn (user to bind with)
• -W: prompt for password