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 and Removing Computers to/from the Domain

• As root on hood:

hood ~ # diradm smbhostadd sr-#####

• refer to Workstation_Naming_Convention
• The LDAP entry is case-sensitive. Make sure it matches the machine's name.
• If you are adding a Windows 7 machine, it also requires a registry hack. See Win7_Samba3DomainMember.reg under \\hurricane\software\windows. It contains the following:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters]
"DNSNameResolutionRequired"=dword:00000000
"DomainCompatibilityMode"=dword:00000001

• To remove an LDAP entry, use smbhostdel:

hood ~ # diradm smbhostdel sr-#####

• To check what Samba thinks about all accounts (user-accounts and machine-accounts):

hood ~ # pdbedit -L

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 on our Windows server, lancer.iat.sfu.ca.
We currently (2012) 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 :-( ).


Old Information, Retained for Reference Purposes:

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 :-) ).

Administration

The main administration tool is the K2Admin program, which is capable of running under Windows, or Mac OS-X (only :-( No Linux). When installed, you will have a program called, KeyConfigure.

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.

Old Information, Retained for Reference Purposes:

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.
You need three entries to support a new key-served application:

1. Product
   This is the product whose license we are trying to control. A product is made up of one or more programs.
2. Program
   This is the file, or files, associated with a particular product.
3. Policy
   Policies specify the type of license we have for a given product, and allow us to dictate how that product can be used (eg: maximum of 5 concurrent users).

Sassafras Keyserver version 7 supports other features but the three that were mentioned are all we need to control how software is run.
The basic process is:

1. Make sure the program or programs that belong to your product exist, either in KeyServer's pre-made list of available programs, or in the audit report of programs. Note: there is no way to manually create a new program. The only way to create a new program entry is to install software on a machine that then gets audited, or to install it on your local machine and select it from the Browse dialog when you try to create a new program entry in KeyConfigure.
2. Create a new product by right-clicking on the Products window and choosing New Product.... In its program field, drag one or more programs from the Programs window into it.
3. Create a new policy by right-clicking on the Policies windows and choosing New Policy.... In its product field, drag the product from the Products window into it.
4. The policy settings will usually look like this:
   

Detachable means that the program can be run even if the user has lost connection to the key server. If the program is a key server-specific version and requires Sassafras KeyServer to provide a key, then the Detachable setting will be ignored.

Sometimes, we will get a keyserved version of a product that requires Sassafras Keyserver to be running and to serve up keys in order for that product to run. In that case, the vendor will also provide us with a license file that gets stored in the KeyServer Data Folder (C:\Program Files\Sassafras K2\Server\KeyServer Data Folder) on Lancer. When KeyServer is restarted, it will automatically generate the required entries to manage that product.

Old Information, Retained for Reference Purposes:

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

Sassafras KeyServer (version 7.x) Documentation

http://www.sassafras.com/hrl/7.0/index.html

Sassafras KeyServer Error

Problem:
When running the KeyVerify client, or when the keyserver tries to connect when launching a key served application, you get an error saying that KeyServer has denied permission to log onto the server. "KA-180" might appear at the bottom of the dialog box.

Solution:
This could mean that the Sassafras key server has used its maximum client capacity (in our case, it's 200).

To confirm this, launch KeyConfigure. You can get it from Sassafras, or from another page in this wiki: Research Administration Tasks

When you launch it, go to Window -> Computers. You'll see a list of computers that tried to connect to the KeyServer. In the left column, under Login, you'll see a count of the Full, Basic, and Prohibited computers. Chances are that Full and Basic add up to 200. Prohibited shows the computers that were unable to get a connection to the server (probably because it was full).

So, here's how to make room. In that same window's right-side pane, sort all the computers by Last Session. Then drag your selection to choose all computers whose last session was, say, more than 6 mos. ago. Then click on your DELETE key. This removes those computers from the key server's database.

Next, in the left column of the window, double-click on the Prohibited entry. This will bring up a window showing the Prohibited computers. You can either delete them all, or you can also double-click on the Full entry to open up another window showing computers that get full rights, and then drag the Prohibited selection into the Full window.

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