Research - User contributions [en]

RATS 2 Documentation

2011-03-30T04:01:14Z

Hha13: adding info about new features

This page serves as documentation for how to use [http://rats.iat.sfu.ca RATS 2]. As bugs are fixed and new features are added, this page will be updated.

== Basics ==
To use RATS 2, you need to log in with your Research account and password, and to have administrator privileges you must be part of the Research administration LDAP group. When you first log in to RATS 2, your RATS 2 profile is automatically created and paired with your Research account. Your RATS 2 profile will however be missing important data such as your SFU library card barcode. See below for how to match your profile with your library card.

== Viewing, Filtering and Searching for Items ==
Click on an item in the menu on the left, such as '''Objects''', '''Purchases''', '''Categories''', etc.. These links will bring you to a page where you can view a list of all the Objects, Purchases, etc., and where you can filter or search for more specific ones.

* To view an item's details, simply click on its name.
* To search for a particular item, enter your search term in the search bar (top right) and click Enter.
* To filter the items by a particular property, click on the property you want to filter by on the right. If you don't see the property you want to filter by, click '''Show All''' and a list of all existing properties will be displayed.

== Adding a User or Matching a Profile to a Library Card ==
Click on '''User''' in the menu on the left. Here you will see a list of everyone who has previously logged in to RATS 2, meaning that their RATS 2 profile has been created. If you see a library card number underneath their name, this means that their profile has already been matched to a library card. If you only see their name, follow these instructions for matching their profile to a library card:

* Click on their name. You will be brought to the Profile Details screen.
* You will see the message: "No library card matched to this user. Match now." Click on '''Match Now'''.
* Enter the person's library card bar-code and click Finish. Phone number is optional.

There is also a second option for matching an existing profile to their library card:
* In the navigation menu on the left, click on '''Add''' next to User. Alternatively, you could also browse to '''Users''' from the navigation menu on the left then click '''Add new or match existing profile to library card'''.
* Start typing the persons' name in the box labeled "Search for a profile...".
* Select the profile you wish to match from the list that pops up. If no profiles are found, you must add the new user (see below). Click Continue once selected.
* On the next screen, enter their library card bar-code and optionally their phone number. Click Finish.

Adding a completely new user requires an extra step and the actual presence of the user (their password is required):

* In the navigation menu on the left, click on '''Add''' next to User. Alternatively, you could also browse to '''Users''' from the navigation menu on the left then click '''Add new or match existing profile to library card'''.
* Ask the new user to enter their Research user name and password in the required fields, then click Add & Continue.
* On the next screen, enter their library card bar-code and optionally their phone number. Click Finish.

== Adding Items ==

=== Information You Need ===
Before starting:

* If you are adding a new category, you will need a Manufacturer to be already created. Check whether the manufacturer of the object exists in the database, if not add it.
* If you are adding a new purchase, you will need a Vendor to be already created. Check whether the manufacturer of the object exists in the database, if not add it.
* If you are adding a new purchase, you will also need to know the purchase date and total. Other optional information that is good to have are the purchase order, invoice number, requisition number, or any other relevant details.
* This goes without saying, but the object you want to add should also have a yellow Research barcode sticker attached to it :)

=== Step-by-step ===

Step 1 - Selecting or adding a category:

* Click on '''Add''' next to Objects in the menu on the left.
* Start typing the name of the category for the object in the box.
* If the category is found, click on it then click '''Continue'''.
* If the category is not found, click e "...or, add a new category +" to expand the form. Fill in the information then click '''Add & Continue'''. Note that the manufacturer must already exist when adding a new category.

Step 2 - Selecting or adding a purchase:

* Start typing the name of the purchase in the box.
* If the purchase is found, click on it then click '''Continue'''.
* If the purchase is not found, click on the "...or, add a new purchase +" to expand the form. Fill in the information then click '''Add & Continue'''. Note that the vendor must already exist when adding a new purchase.

Step 3 - Fill in the object form

* Type in the name of the object and use the barcode scanner to enter its yellow barcode. Fill in any other information and click '''Create Object'''.

== Checking Items In and Out ==
To access the Kiosk for checking items in our out, click on '''Home''' in the menu on the left. To check items in:

* Select the textbox with the text "Enter barcodes here" by clicking inside it.
* Use a barcode scanner to scan the items you want to check in, one at a time.
* After you have scanned them all, click '''Check In'''.
* If the Check In button is grey-ed out, it means that some items have never been checked out. Click the red X next to their name to remove them from the list, and the Check In button will become active. See below for how to check items out.

To check items out:

* Select the textbox with the text "Enter barcodes here" by clicking inside it.
* Use a barcode scanner to scan the items you want to check out, one at a time.
* Scan the library card of an existing user whose library card is matched to their profile in the same way. See above for how to match a library card or add a new user.
* After you have scanned all items and a single library card, click '''Check Out'''.
* If the Check Out button is grey-ed out, it means that some items are still on loan and cannot be checked in. Click the red X next to their name to remove them from the list, and the Check Out button will become active. See above for how to check items in.

== Editing or Deleting Items ==
The process for editing or deleting an item is quite simple. Find an item you want to edit/delete (such as an object, a category, etc.) and browse to its detail page. Then simply click the edit/delete link on the right-hand side of the page. Note that deleting an item does not remove it from the database, instead it just marks it as deleted. You can always un-delete an item (this is also easy - the delete button you used to mark it as delete it will change to 'un-delete' once deleted. Just click it!). You can also filter your searches when browsing items by including all items (default is only non-deleted items). Also note that it is impossible to check a deleted item out.

Booking Research Rooms

2011-03-25T20:48:55Z

Hha13:

Go to https://connect.sfu.ca/ and log in with your SFU credentials, as you normally would. Select the Calendar tab, right click on the day for the booking and click 'New Appointment'; you should see the Quick Add popup, like this:

 
[[Image:Add_appt_screen1.png|frame|center|Quick Add for making a calendar appointment]]

 
Click on the More Details (lower left). You should now see the expanded Appointment Details screen:

 
[[Image:Add_appt_screen2.png|frame|center|More Details for making a calendar appointment]]

 
Click on Find Locations (upper middle tab). Now, you should be looking at something like the screen shot below; for Name, provide a room (I have used the room-number 3950), and click Search. The system will suggest matches; if more than one result is found, highlight the one you want and click Select at the bottom middle:

 
[[Image:Add_appt_screen3.png|frame|center|Find Locations for making a calendar appointment. Partial room-name/number is enough to search with.]]

 
Click on the Appointment Details tab, you should see something similar to the screenshot below - notice that the Location has now been filled in, and a Resources entry
appears under the Attendees box.

 
[[Image:Add_appt_screen4.png|frame|center|Completed Location, for Appointment Details]]

 
If you want to check the availability of a room or Attendees, after you have made the Location and Attendee selections, click on Schedule tab:

 
[[Image:Add_appt_screen5.png|frame|center|Checking for available times, for all attendees and room-resources]]

 
Late-breaking news: you can now use AutoComplete for the room name/number, right from the Quick Add screen; enter any portion of the room name or number, and a drop-down selection will appear, allowing you to choose the exact item you want:

 
[[Image:Add_appt_screen6.png|frame|center|QuickAdd, showing autocompletion]]

Research Administration Tasks

2011-01-15T01:23:38Z

Hha13: /* For a single user */

== 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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
# '-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 [[Research Administration Tasks#Adding Groups|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
# '-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 [[HOWTO_Access_The_CVS_Server | 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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Research Administration Tasks

2011-01-15T01:23:09Z

Hha13: /* For a single user */

== 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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
# '-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 [[Research Administration Tasks#Adding Groups|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
# '-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 [[HOWTO_Access_The_CVS_Server | 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Research Administration Tasks

2011-01-15T01:22:31Z

Hha13: /* For a single user */

== 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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
# '-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 [[Research Administration Tasks#Adding Groups|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
# '-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:root /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 [[HOWTO_Access_The_CVS_Server | 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

RATS 2 Documentation

2010-11-17T01:54:26Z

Hha13: /* Adding Objects */

This page serves as documentation for how to use [http://rats.iat.sfu.ca RATS 2]. As bugs are fixed and new features are added, this page will be updated.

== Basics ==
To use RATS 2, you need to log in with your Research account and password, and to have administrator privileges you must be part of the Research administration LDAP group. When you first log in to RATS 2, your RATS 2 profile is automatically created and paired with your Research account. Your RATS 2 profile will however be missing important data such as your SFU library card barcode. See below for how to match your profile with your library card.

== Viewing, Filtering and Searching for Items ==
Click on an item in the menu on the left, such as '''Objects''', '''Purchases''', '''Categories''', etc.. These links will bring you to a page where you can view a list of all the Objects, Purchases, etc., and where you can filter or search for more specific ones.

* To view an item's details, simply click on its name.
* To search for a particular item, enter your search term in the search bar (top right) and click Enter.
* To filter the items by a particular property, click on the property you want to filter by on the right. If you don't see the property you want to filter by, click '''Show All''' and a list of all existing properties will be displayed.

== Adding a User or Matching a Profile to a Library Card ==
Click on '''User''' in the menu on the left. Here you will see a list of everyone who has previously logged in to RATS 2, meaning that their RATS 2 profile has been created. If you see a library card number underneath their name, this means that their profile has already been matched to a library card. If you only see their name, follow these instructions for matching their profile to a library card:

* Click on their name. You will be brought to the Profile Details screen.
* You will see the message: "No library card matched to this user. Match now." Click on '''Match Now'''.
* Enter the person's library card bar-code and click Finish. Phone number is optional.

There is also a second option for matching an existing profile to their library card:
* In the navigation menu on the left, click on '''Add''' next to User. Alternatively, you could also browse to '''Users''' from the navigation menu on the left then click '''Add new or match existing profile to library card'''.
* Start typing the persons' name in the box labeled "Search for a profile...".
* Select the profile you wish to match from the list that pops up. If no profiles are found, you must add the new user (see below). Click Continue once selected.
* On the next screen, enter their library card bar-code and optionally their phone number. Click Finish.

Adding a completely new user requires an extra step and the actual presence of the user (their password is required):

* In the navigation menu on the left, click on '''Add''' next to User. Alternatively, you could also browse to '''Users''' from the navigation menu on the left then click '''Add new or match existing profile to library card'''.
* Ask the new user to enter their Research user name and password in the required fields, then click Add & Continue.
* On the next screen, enter their library card bar-code and optionally their phone number. Click Finish.

== Adding Objects ==

=== Information You Need ===
Before starting:

* If you are adding a new category, you will need a Manufacturer to be already created. Check whether the manufacturer of the object exists in the database, if not add it.
* If you are adding a new purchase, you will need a Vendor to be already created. Check whether the manufacturer of the object exists in the database, if not add it.
* If you are adding a new purchase, you will also need to know the purchase date and total. Other optional information that is good to have are the purchase order, invoice number, requisition number, or any other relevant details.
* This goes without saying, but the object you want to add should also have a yellow Research barcode sticker attached to it :)

=== Step-by-step ===

Step 1 - Selecting or adding a category:

* Click on '''Add''' next to Objects in the menu on the left.
* Start typing the name of the category for the object in the box.
* If the category is found, click on it then click '''Continue'''.
* If the category is not found, click e "...or, add a new category +" to expand the form. Fill in the information then click '''Add & Continue'''. Note that the manufacturer must already exist when adding a new category.

Step 2 - Selecting or adding a purchase:

* Start typing the name of the purchase in the box.
* If the purchase is found, click on it then click '''Continue'''.
* If the purchase is not found, click on the "...or, add a new purchase +" to expand the form. Fill in the information then click '''Add & Continue'''. Note that the vendor must already exist when adding a new purchase.

Step 3 - Fill in the object form

* Type in the name of the object and use the barcode scanner to enter its yellow barcode. Fill in any other information and click '''Create Object'''.

== Checking Items In and Out ==
To access the Kiosk for checking items in our out, click on '''Home''' in the menu on the left. To check items in:

* Select the textbox with the text "Enter barcodes here" by clicking inside it.
* Use a barcode scanner to scan the items you want to check in, one at a time.
* After you have scanned them all, click '''Check In'''.
* If the Check In button is grey-ed out, it means that some items have never been checked out. Click the red X next to their name to remove them from the list, and the Check In button will become active. See below for how to check items out.

To check items out:

* Select the textbox with the text "Enter barcodes here" by clicking inside it.
* Use a barcode scanner to scan the items you want to check out, one at a time.
* Scan the library card of an existing user whose library card is matched to their profile in the same way. See above for how to match a library card or add a new user.
* After you have scanned all items and a single library card, click '''Check Out'''.
* If the Check Out button is grey-ed out, it means that some items are still on loan and cannot be checked in. Click the red X next to their name to remove them from the list, and the Check Out button will become active. See above for how to check items in.

RATS 2 Documentation

2010-11-17T00:57:41Z

Hha13: /* Checking Items In and Out */

RATS 2 Documentation

2010-11-16T23:51:18Z

Hha13: /* Adding a User or Matching a Profile to a Library Card */

RATS 2 Documentation

2010-11-16T23:48:44Z

Hha13: /* Viewing, Filtering and Searching for Items */

RATS 2 Documentation

2010-10-29T01:51:23Z

Hha13: /* Adding a User or Matching a Profile to a Library Card */

RATS 2 Documentation

2010-10-29T01:41:53Z

Hha13: /* Adding a User or Matching a Profile to a Library Card */

RATS 2 Documentation

2010-10-29T01:39:48Z

Hha13: /* Adding a User or Matching a Profile to a Library Card */

RATS 2 Documentation

2010-10-27T00:29:21Z

Hha13: Created page with 'This page serves as documentation for how to use [http://rats.iat.sfu.ca RATS 2]. As bugs are fixed and new features are added, this page will be updated. == Basics == To use R…'

Main Page

2010-10-26T21:39:13Z

Hha13:

Welcome. This is a wiki for the purpose of helping to keep the systems in Research running smoothly and to inform users of Research services.

{| border="1" cellpadding="6" cellspacing="0" style="border: black solid 1px; border-collapse: collapse; text-align: left; width: 100%; background: #f0f0ff; "
| colspan="3" style="text-align: center; font-weight: bold; font-size: 1.4em;" |
User Articles
|-
| width="33%" valign="top" | '''Projects'''
* [[AG Node Documentation]]
* [[Eye trackers @ EC3 Lab]]
* [[Large Scale Imagery: evolving the components]]
* [[Cluster User Documentation|Documentation for the Cluster]]
* [[SGI]]
* [[Acoustic Panels - DIY]]

| width="33%" valign="top" | '''Workstations'''
* [[Printers]]
* [[Research Workstations - default software loads | Standard Workstation Software List]]
* [[Windows Maintenance]]
* [[Linux Administration & Maintenance]]
* [[MAC Addresses and Hostnames]]

| width="33%" valign="top" | '''General Information'''
* [[Research Services]]
* [[Accessing Your Data]]
* [[People power - grad students and their expertise]]
* [[Research Mailing Lists]]
* [[HOWTO Access The SVN Server| Accessing the SVN Server]]
* [[HOWTO Access The CVS Server| Accessing the CVS Server]]
* [[Lockers]]
* [[Policies and Procedures]]

|}

{| border="1" cellpadding="6" cellspacing="0" style="border: black solid 1px; border-collapse: collapse; text-align: left; width: 100%; background: #f0f0ff; "
| colspan="3" style="text-align: center; font-weight: bold; font-size: 1.4em;" |
Administration Articles
|-
| width="33%" valign="top" | '''Administration & Resource Management'''
* [[Research Administration Tasks]]
* [[Server documentation | Server List]]
* [[Network Devices Servers & Workstations]]
* [[Workstation Naming Convention]]
* [[Backups with AMANDA]]
* [[INFO Network Routing Information | Network Routing Information]]
* [[RAID Documentation]]
* [[Software Management]]
* [[Websites Hosted]]
* [[RATS 2 Documentation]]

| width="33%" valign="top" | '''Customizing Linux Servers'''
* [[Research Servers - default software loads | Standard Server Software List]]
* [[REF Standard Server Configuration | Standard Server Configuration]]
* [[Setup a Project Wiki|Setup MediaWiki]]
* [[Maya]]
* [[Oracle on Gentoo]]
* [[WebDAV Setup]]
* [[Virtual Servers]]
* [[LTSP]]
* [[NFS Version 4]]
* [[XFS Filesystem HOWTO]]
* [[Webapp-Config]]

| width="33%" valign="top" | '''Client Side & Other Articles'''
* [[Linux Tips and Tools]]
* [[HOWTO Install SUSE with AutoYast|Install SUSE with AutoYast]]
* [[Who's Where - Availability of Research staff|Availability of Research Staff]]
* [[Maya]]
* [[Adding a Mac to the Research Domain]]
* [[Enterprise Deployment for Windows]]
* [[Short diradm Documentation]]

|}

{| border="1" cellpadding="6" cellspacing="0" style="border: black solid 1px; border-collapse: collapse; text-align: left; width: 100%; background: #f0f0ff; "
| colspan="3" style="text-align: center; font-weight: bold; font-size: 1.4em;" |
Reference
|-
| width="33%" valign="top" | '''Manuals'''
* [[File Servers]]
* [[Belkin F1DA116T KVM Switch]]
* [[D-Link DGS-3224TG Switches]]
* [[Printer Manuals|Printers]]
* [[Scanners]]
* [[Theaterette Information, Instruction, and Manuals]]

| width="33%" valign="top" | '''Notes'''
* [[Command Syntax]]
* [[Micellaneous Notes]]

| width="33%" valign="top" |
* [http://research.iat.sfu.ca/awstats.pl?config=infrastructure AWstats (wiki-traffic)]
* [[Media:Satellite_channels.pdf|Bell ExpressVu Channels]]

|}

[http://research.iat.sfu.ca/wiki/index.php?title=Special:Recentchanges&feed=rss http://research.iat.sfu.ca/wiki/images/b/b6/Rss.gif]

Research Administration Tasks

2010-05-26T07:57:04Z

Hha13: /* For multiple users */

== Adding Users ==
* 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 ==

=== 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
# chown -R $user /mnt/raid/projects/$project
# chmod -R 2701 /mnt/raid/projects/$project
# mkdir /mnt/raid/projects/$project/htdocs
# chmod 2775 /mnt/raid/projects/$project/htdocs

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
# '-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 [[Research Administration Tasks#Adding Groups|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

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
# '-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 [[HOWTO_Access_The_CVS_Server | 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Maya

2010-04-10T02:16:25Z

Hha13:

= Intructions for Maya 2011 =

Maya provided by Autodesk

== License-Server Installation ==

The license server (FLEXnet) was downloaded from the Autodesk Subscriptions website and installed (as an rpm). Use the following init.d script to make it run:

#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/app-admin/flexlm/files/flexlm-init,v 1.4 2006/09/26 04:10:49 eradicator Exp $

depend() {
need net
}

start() {
ebegin "Starting flexnet lmgrd"
su - ${LMUSER} -c "echo starting lmgrd >> '${LMLOG}'"
nohup su - ${LMUSER} -c "umask 022; /opt/flexnetserver/lmgrd -c '${LMLICENSE}' >> '${LMLOG}'"
su - ${LMUSER} -c "echo sleep 5 >> '${LMLOG}'"
sleep 5
su - ${LMUSER} -c "echo lmdiag >> '${LMLOG}'"
su - ${LMUSER} -c "/opt/flexnetserver/lmdiag -n -c '${LMLICENSE}' >> '${LMLOG}'"
su - ${LMUSER} -c "echo exiting >> '${LMLOG}'"
eend $?
}

stop() {
ebegin "Stopping flexnet lmgrd"
/opt/flexnetserver/lmdown -q -all -c "${LMLICENSE}"
eend $?
}

And here's the conf.d for it:

# Logfile path: (NOTE: This must be uid/gid owned by the value of $LMUSER!)
LMLOG="/var/log/flexnet.log"

# Run the lmgrd user as:
LMUSER="flexlm"

# List all license files delimeted by a colon
LMLICENSE="/opt/flexnetserver/MAYA2011enlicense.lic"

Make sure you open port 2080 in the firewall, and also allow pings since Maya 2011 requires this.

== Maya Client (Workstation) Installation ==

When installing the software, make sure to select Network License, and enter '''bismarck.iat.sfu.ca''' for the server. You also need to modify the generated license file.

The location of this license-file varies a bit, according to your OS:
* Mac: /var/flexlm/Maya.lic
* Windows: C:\flexlm\Maya.lic
* Linux, IRIX, etc: /var/flexlm/Maya.lic

Open the file in a text-editor and modify it to look as such
SERVER bismarck.iat.sfu.ca 0 2080
USE_SERVER

= Intructions for Maya 2008 =

Maya provided by Alias

Lmhostid is a unique number created for each computer by the lmhostid program provided by alias. This number is required for purchasing a license, and is also called: Hardware Info: System ID.

== Purchasing Maya ==
Make sure you purchase the '''floating license version''', this is the only version that can be floated through a flexlm server. Keep track of the Customer Location Code (CLC).

== License ==
Fill out the license form and select floating here:
http://www.alias.com/spar/

== Relocation ==
Relocation is required if you move the flexlm server to another machine, or you have a license file created with 1 hardwareID that you want to use on another server. Alias will provide you with a new license file if you fill in the relocation form:
http://www.alias.com/relocation

== License-Server Installation ==

Download pdr_LicenseServer10.80_linux.tar.gz which contains lmgrd and sgiawd, necessary executables for starting flexlm with an alias license.dat file.

Download it from:

musashi:/export/mirror/purchased-software/lin

OR

alias.com/glb/eng/community/downloads.jsp

put the license.dat file in the /etc/flexlm directory. Edit the file and replace 'server' with the actual server name.

Note: Add this line to the license file to lock down the sgiawd service to a certain port:
VENDOR sgiawd port=****

== Maya Client (Workstation) Installation ==
There are two steps to a workstation-installation:
*create the license-file on the client workstation, which will direct the workstation Maya client to "talk" to our flexlm server for authourization to run
*install the Maya software (currently version 7 - Jan. 2008)

At this time of writing (Jan. 2008) we have 3 "Permanent" copies of Maya Unlimited, with Cloth, Fluids and Fur effects.

=== Maya Client: License File ===
The location of this license-file varies a bit, according to your OS:
* Mac: /var/flexlm/aw_client.dat
* Windows: C:\FLEXlm\aw_servername.dat
* Linux, IRIX, etc: /var/flexlm/aw_servername.dat

Open a text-editor and create the license-file that points to our flexlm server.
For Windows, the file is:
C:\FlexLm\aw_bismarck.dat

The file must contain:
SERVER bismarck.iat.sfu.ca 0 7111
USE_SERVER

=== Maya Client: Software Installation ===
Grab the CD's, begin installing and follow your nose :-) 
After installing, with the license-file in place, it should "just work" :-)

For server debug output:
# tail -f /var/log/flexlm.log

Research Administration Tasks

2010-01-28T00:04:47Z

Hha13: /* For a group */

== Adding Users ==
* 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 ==

=== 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
# chown -R $user /mnt/raid/projects/$project
# chmod -R 2701 /mnt/raid/projects/$project
# mkdir /mnt/raid/projects/$project/htdocs
# chmod 2775 /mnt/raid/projects/$project/htdocs

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
# '-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 [[Research Administration Tasks#Adding Groups|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

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
# '-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 [[HOWTO_Access_The_CVS_Server | 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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://$user@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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Research Administration Tasks

2010-01-28T00:04:39Z

Hha13: /* For a single user */

== Adding Users ==
* 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 ==

=== 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
# chown -R $user /mnt/raid/projects/$project
# chmod -R 2701 /mnt/raid/projects/$project
# mkdir /mnt/raid/projects/$project/htdocs
# chmod 2775 /mnt/raid/projects/$project/htdocs

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
# '-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 [[Research Administration Tasks#Adding Groups|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

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
# '-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/
# 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 [[HOWTO_Access_The_CVS_Server | 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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://$user@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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Research Administration Tasks

2009-10-30T01:44:17Z

Hha13: /* For a gruop */

== Adding Users ==
* 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 ==

=== 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
# chown -R $user /mnt/raid/projects/$project
# chmod -R 2701 /mnt/raid/projects/$project
# mkdir /mnt/raid/projects/$project/htdocs
# chmod 2775 /mnt/raid/projects/$project/htdocs

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
# '-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/
# 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 [[Research Administration Tasks#Adding Groups|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

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
# '-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/
# 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 [[HOWTO_Access_The_CVS_Server | 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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://$user@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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Research Administration Tasks

2009-10-30T01:44:02Z

Hha13: /* Adding Projects */

== Adding Users ==
* 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 ==

=== 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
# chown -R $user /mnt/raid/projects/$project
# chmod -R 2701 /mnt/raid/projects/$project
# mkdir /mnt/raid/projects/$project/htdocs
# chmod 2775 /mnt/raid/projects/$project/htdocs

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
# '-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/
# cat vhost_template.sample > $project.conf

'''TO DO - DATABASE HOWTO'''

Make sure you get Vic to add an alias!

=== For a gruop ===

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 [[Research Administration Tasks#Adding Groups|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

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
# '-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/
# 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 [[HOWTO_Access_The_CVS_Server | 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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://$user@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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Research Administration Tasks

2009-10-30T01:41:36Z

Hha13:

== Adding Users ==
* 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 ==

=== 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
# chown -R $user /mnt/raid/projects/$project
# chmod -R 2701 /mnt/raid/projects/$project
# mkdir /mnt/raid/projects/$project/htdocs
# chmod 2775 /mnt/raid/projects/$project/htdocs

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
# '-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/
# cat vhost_template.sample > $project.conf

'''TO DO - DATABASE HOWTO'''

Make sure you get Vic to an alias!

=== For a gruop ===

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 [[Research Administration Tasks#Adding Groups|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

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
# '-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/
# cat vhost_template.sample > $project.conf

'''TO DO - DATABASE HOWTO'''

Make sure you get Vic to 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 [[HOWTO_Access_The_CVS_Server | 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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://$user@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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Research Administration Tasks

2009-10-30T01:10:22Z

Hha13: /* For a single user */

== Adding Users ==
* 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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 ==
* As root on '''hood''':
# diradm amadd -O $mapbase $key $src
# diradm amadd -O home.projects meditation 209.87.56.240:/export/projects/0/m/meditation
* '-O' means the default mount options for automount.
* As root on '''yamato''':
** Make the $src directory. mkdir -p $src
** Set ownership. chgrp -R $group $src
** Set permissions. chmod 2771 $src
** If web content is being served: mkdir -p $src/htdocs ; chmod 2775 $src/htdocs

== 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 [[HOWTO_Access_The_CVS_Server | 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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://$user@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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Servers:Hercules

2009-10-20T22:49:19Z

Hha13:

== Adding a new vserver ==
* As root on '''hercules''':
* First create the template the server will use for portage
# cd /etc/managed-portage/
# rsync -avP hosts/TEMPLATE_webdb/ hosts/sr-hercules$$
* Commit the new vserver's template to git
# git add /hosts/sr-hercules$$
# git commit -m 'New VM, Hercules$$'
# git push
* Create the new vserver
# cd ~/vps-siat/scripts/
# ./make-vps sr-hercules$$ br0:10.0.1.XX/16 br0:209.87.56.XX/24
* Note that $$ must be the number of the new vserver, which start at 00.
* Further note that XX is the IP to be assigned to the new server. '''Be very careful not to assign an already taken IP.'''

== Removing an existing vserver ==
* As root on '''hercules''':
* First ensure that the Vserver is stopped
# vserver sr-hercules$$ stop
* Kill the server
# cd ~/vps-siat/scripts/
# ./kill-vps sr-hercules$$
* Note that $$ must be the number of the vserver.

== Working with managed-portage profiles ==
* '''It is very important that you DO NOT touch /etc/portage/ on any vserver.''' Everything must be done through /etc/managed-portage/ on the master server.
* Below are a few common tasks for managed-portage
=== Setting up vserver-specific USE flags ===
* As root on '''hercules''':
# cd /etc/managed-portage/hosts/sr-hercules$$/make.profile/
* Here you can create/edit any regular files you would under /etc/portage/, such as package.use for example:
# vim package.use
* Specify what USE flags you'd like a package to use
* Commit the changes to git
# git commit -m '$MESSAGE' package.use
# git push
# cd /vservers/sr-hercules$$/etc/managed-portage/
# git pull
* Note that $$ must be the number of the new vserver, which start at 00.
* Also note that you must replace package.use with whatever file you edited/created.
=== Changing or setting the profile of a vserver ===
* As root on '''hercules''':
# cd /etc/managed-portage/class/$PROFILE
* Add the name of the vserver to the applies_to file (if your vserver is sr-hercules99, add 'sr-hercules99' to a new line in the file)
* Commit the changes to git
# git commit -m "$MESSAGE' applies_to
# git push
* Enter the vserver
# vserver sr-hercules$$ enter
* Pull the changes from git and emerge
# cd /etc/managed-portage/
# git pull
# emerge -knN @system ; emerge -knN @world ; emerge -knN @installed

Servers:Hercules

2009-10-20T22:35:40Z

Hha13: New page: == Adding a new vserver == * As root on '''hercules''': * First create the template the server will use for portage # cd /etc/managed-portage/ # rsync -avP hosts/TEMPLATE_webdb/ hosts/s...

Research Administration Tasks

2009-01-15T21:00:02Z

Hha13: /* Deleting Users */

== Adding Users ==
* 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.
* The password you are prompted for at the end is for '''phaeton'''.
* Add the newly-created user to our [http://bismarck.iat.sfu.ca/mailman/admin/research/ Research Mailing List].

== 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 [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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!

== 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 ==
* As root on '''hood''':
# diradm amadd -O $mapbase $key $src
# diradm amadd -O home.projects meditation 209.87.56.240:/export/projects/0/m/meditation
* '-O' means the default mount options for automount.
* As root on '''yamato''':
** Make the $src directory. mkdir -p $src
** Set ownership. chgrp -R $group $src
** Set permissions. chmod 2771 $src
** If web content is being served: mkdir -p $src/htdocs ; chmod 2775 $src/htdocs

== 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 2770 /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 [[HOWTO_Access_The_CVS_Server | 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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 $group /mnt/raid/svn/$repository

* The repository URL is '''svn+ssh://$user@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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Research Administration Tasks

2009-01-13T22:42:19Z

Hha13: /* Adding CVS Repositories */

== Adding Users ==
* 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.
* The password you are prompted for at the end is for '''phaeton'''.
* Add the newly-created user to our [http://bismarck.iat.sfu.ca/mailman/admin/research/ Research Mailing List].

== Deleting Users ==
Make sure there are no sym-links pointing to important stuff!!
# find -P /home/users/$username -noleaf -type l

* As root on '''yamato''':
# DEBUG=1 diradm userdel -r $username
* As root on '''hood''':
# DEBUG=1 diradm userdel $username
* Keeping the user on our [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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!

== 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 ==
* As root on '''hood''':
# diradm amadd -O $mapbase $key $src
# diradm amadd -O home.projects meditation 209.87.56.240:/export/projects/0/m/meditation
* '-O' means the default mount options for automount.
* As root on '''yamato''':
** Make the $src directory. mkdir -p $src
** Set ownership. chgrp -R $group $src
** Set permissions. chmod 2771 $src
** If web content is being served: mkdir -p $src/htdocs ; chmod 2775 $src/htdocs

== 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 2770 /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 [[HOWTO_Access_The_CVS_Server | 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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 $group /mnt/raid/svn/$repository

* The repository URL is '''svn+ssh://$user@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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

HOWTO Access The CVS Server

2009-01-09T22:46:15Z

Hha13:

For those who don't like to read, here is the information you'll need (replace $user with your username and $repository with your repository name):

'''Use CVS_RSH="ssh" with the URL being :ext:$user@cvs.iat.sfu.ca:/var/cvsroot/$repository'''

== Command Line on Linux ==
Checkout
# export CVSROOT=:ext:username@cvs.iat.sfu.ca:/var/cvsroot/projectname
# export CVS_RSH=ssh
# cvs checkout modulename
Update
# cvs update modulename

== Eclipse on Windows ==

To checkout a repository with Eclipse, use the Import Project tool from CVS. Enter the information below with Your projectname, and Your username/password

[[Image:eclipse-cvs-checkout.gif]]

Then, select Use an existing module to see a list of which modules you can checkout (they will be listed below).

[[Image:eclipse-cvs-checkout-module.gif]]

Linux Tips and Tools

2009-01-08T23:36:50Z

Hha13: /* Automatic (Pronounceable) Password Generation */

==Automatic (Pronounceable) Password Generation==
Use of automated tools will help ensure high-quality passwords, enhancing security. '''apg''' is one such tool, which (by default) attempts to generate pronounceable passwords.
Once '''apg''' is installed, invoking it like this will produce best results:
hostname ~ # '''/usr/bin/apg -M NCL -t -m 9 -x 9 -n 10 -E O | egrep -v [ol]'''
Explanation of options:
*'''-M''' is a mode-switch, with following options which tell '''apg''' what characterset to use
**'''-N''' numbers must be included with each password
**'''-C''' upper-case (capital) letters must be included
**'''-L''' lower-case letters must be included
*'''-m 9''' minimum password length
*'''-x 9''' maximum password length
*'''-n 10''' generate 10 passwords After the '''egrep''' filtering below, you will get substantially fewer than 10 results.
*'''-E O''' exclude letters (upper-case only possible) O from password. This prevents confusion with "oh" and "zero".
*'''| egrep -v [ol]''' does the same as above, except it filters out/discards passwords with lower-case ol. This prevents confusion with "oh" and "zero"; "ell" and "one".
 

== Screen ==
Screen is a very powerful terminal application that makes server and remote maintenance much easier.

Screen sessions can be created, detached, and then later resumed from another machine. This allows you to ssh to a machine, start a compile or emerge, detach and logout, and then come back later to the session and see it finished.

Screen session are created from the terminal with
# screen

A session is detached by a Ctrl-a d.

There are three more commands you should know:
# screen -r
# screen -ls
# screen -r ####
The first to reattach a session, and the second to list the screen sessions. The third is useful if there is more than one screen sessions you can reattach. Just list the sessions and then reattach with the specific numbers given for the session you want.

 

== Genlop ==
{{Gentoo}}
Genlop is a log reporting program for gentoo's portage utility. Want to know how much longer the package being emerged will take? or average emerge time? This program has it all
# emerge genlop

Here's how to use it. First is emerge history, second is information on the current package being emerged + expected time remaining, third is for averge build time of that package.
# genlop -l
# genlop -c
# genlop -i gcc

== Colourize Grep ==
Add this to your '''.bashrc''' file.

<pre>
if echo hello|grep --color=auto l >/dev/null 2>&1; then
export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
fi
</pre>

Setup a Project Wiki

2009-01-07T23:54:46Z

Hha13: /* Upgrade MediaWiki */

Setup a Project Wiki

2009-01-07T23:53:41Z

Hha13: /* = */

Setup a Project Wiki

2009-01-07T23:53:30Z

Hha13: /* = */

Websites Hosted

2009-01-07T22:45:04Z

Hha13: /* List of hosted domains */

== List of hosted domains ==

=== sr-skimmer00 ===
* http://meatbook.iat.sfu.ca
* http://pain.iat.sfu.ca
* http://www.transformingpain.org

=== sr-skimmer01 ===
* http://lore.iat.sfu.ca
* http://lornet.iat.sfu.ca
* http://ecl.iat.sfu.ca
* http://stories.iat.sfu.ca

=== sr-skimmer02 ===
* http://www.antle.iat.sfu.ca

=== sr-skimmer03 ===
* http://dolphin.iat.sfu.ca

=== sr-skimmer04 ===
* http://www.mmart.iat.sfu.ca

=== sr-vindicator00 ===
* http://mapture.iat.sfu.ca

=== sr-vindicator01 ===
* http://catgames.ca

Websites Hosted

2009-01-07T22:12:42Z

Hha13: /* List of hosted domains */

== List of hosted domains ==

=== sr-skimmer01 ===
* http://lore.iat.sfu.ca
* http://lornet.iat.sfu.ca
* http://ecl.iat.sfu.ca
* http://stories.iat.sfu.ca

=== sr-skimmer02 ===
* http://www.antle.iat.sfu.ca

=== sr-skimmer03 ===
* http://dolphin.iat.sfu.ca

=== sr-skimmer04 ===
* http://www.mmart.iat.sfu.ca

=== sr-vindicator00 ===
* http://mapture.iat.sfu.ca

=== sr-vindicator01 ===
* http://catgames.ca

Websites Hosted

2009-01-07T22:10:48Z

Hha13: New page: == List of hosted domains == === sr-skimmer01 === * http://lore.iat.sfu.ca * http://lornet.iat.sfu.ca * http://ecl.iat.sfu.ca * http://stories.iat.sfu.ca === sr-skimmer02 === * http://ww...

Main Page

2009-01-07T21:59:39Z

Hha13:

Welcome. This is a wiki for the purpose of helping to keep the systems in Research running smoothly and to inform users of Research services.

{| border="1" cellpadding="6" cellspacing="0" style="border: black solid 1px; border-collapse: collapse; text-align: left; width: 100%; background: #f0f0ff; "
| colspan="3" style="text-align: center; font-weight: bold; font-size: 1.4em;" |
User Articles
|-
| width="33%" valign="top" | '''Projects'''
* [[AG Node Documentation]]
* [[Eye trackers @ EC3 Lab]]
* [[Large Scale Imagery: evolving the components]]
* [[Cluster User Documentation|Documentation for the Cluster]]
* [[SGI]]
* [[Acoustic Panels - DIY]]

| width="33%" valign="top" | '''Workstations'''
* [[Printers]]
* [[Research Workstations - default software loads | Standard Workstation Software List]]
* [[Windows Maintenance]]
* [[Linux Administration & Maintenance]]
* [[MAC Addresses and Hostnames]]
* [[Problems due to moving]]

| width="33%" valign="top" | '''General Information'''
* [[Research Services]]
* [[Accessing Your Data]]
* [[People power - grad students and their expertise]]
* [[Research Mailing Lists]]
* [[HOWTO Access The SVN Server| Accessing the SVN Server]]
* [[HOWTO Access The CVS Server| Accessing the CVS Server]]
* [[Lockers]]
* [[Policies and Procedures]]

|}

{| border="1" cellpadding="6" cellspacing="0" style="border: black solid 1px; border-collapse: collapse; text-align: left; width: 100%; background: #f0f0ff; "
| colspan="3" style="text-align: center; font-weight: bold; font-size: 1.4em;" |
Administration Articles
|-
| width="33%" valign="top" | '''Administration & Resource Management'''
* [[Research Administration Tasks]]
* [[Server documentation | Server List]]
* [[Network Devices Servers & Workstations]]
* [[Workstation Naming Convention]]
* [[Backups with AMANDA]]
* [[INFO Network Routing Information | Network Routing Information]]
* [[RAID Documentation]]
* [[Software Management]]
* [[Websites Hosted]]

| width="33%" valign="top" | '''Customizing Linux Servers'''
* [[Research Servers - default software loads | Standard Server Software List]]
* [[REF Standard Server Configuration | Standard Server Configuration]]
* [[Setup a Project Wiki|Setup MediaWiki]]
* [[Maya]]
* [[Oracle on Gentoo]]
* [[WebDAV Setup]]
* [[Virtual Servers]]
* [[LTSP]]
* [[NFS Version 4]]
* [[XFS Filesystem HOWTO]]
* [[Webapp-Config]]

| width="33%" valign="top" | '''Client Side & Other Articles'''
* [[Linux Tips and Tools]]
* [[HOWTO Install SUSE with AutoYast|Install SUSE with AutoYast]]
* [[Who's Where - Availability of Research staff|Availability of Research Staff]]
* [[Maya]]
* [[Adding a Mac to the Research Domain]]
* [[Windows XP Maintenance]]
* [[Short diradm Documentation]]

|}

{| border="1" cellpadding="6" cellspacing="0" style="border: black solid 1px; border-collapse: collapse; text-align: left; width: 100%; background: #f0f0ff; "
| colspan="3" style="text-align: center; font-weight: bold; font-size: 1.4em;" |
Reference
|-
| width="33%" valign="top" | '''Manuals'''
* [[File Servers]]
* [[Belkin F1DA116T KVM Switch]]
* [[D-Link DGS-3224TG Switches]]
* [[Printer Manuals|Printers]]
* [[Theaterette Information, Instruction, and Manuals]]

| width="33%" valign="top" | '''Notes'''
* [[Command Syntax]]
* [[Micellaneous Notes]]

| width="33%" valign="top" |
* [http://research.iat.sfu.ca/awstats.pl?config=infrastructure AWstats (wiki-traffic)]
* [[Media:Satellite_channels.pdf|Bell ExpressVu Channels]]

|}

[http://research.iat.sfu.ca/wiki/index.php?title=Special:Recentchanges&feed=rss http://research.iat.sfu.ca/images/rss.gif]

Setup a Project Wiki

2009-01-06T22:26:48Z

Hha13: /* Add a Separate Instance of MediaWiki */

Setup a Project Wiki

2009-01-06T22:26:31Z

Hha13: /* Add a Separate Instance of MediaWiki */

Short diradm Documentation

2008-12-07T00:03:39Z

Hha13: New page: Make sure the diradm.conf file has the following settings on spitfire: SAMBAPATHPREPEND='\\\SPITFIRE\Users' AUTOMOUNT_HASHING='${key}' # no home directory hashing AUTOMOUNT_USERDIRBAS...

Make sure the diradm.conf file has the following settings on spitfire:

SAMBAPATHPREPEND='\\\SPITFIRE\Users'
AUTOMOUNT_HASHING='${key}' # no home directory hashing
AUTOMOUNT_USERDIRBASE="209.87.56.230:/home/users"
AUTOMOUNT_GROUPDIRBASE="209.87.56.230:/home/projects"

Main Page

2008-12-06T23:54:46Z

Hha13:

Welcome. This is a wiki for the purpose of helping to keep the systems in Research running smoothly and to inform users of Research services.

{| border="1" cellpadding="6" cellspacing="0" style="border: black solid 1px; border-collapse: collapse; text-align: left; width: 100%; background: #f0f0ff; "
| colspan="3" style="text-align: center; font-weight: bold; font-size: 1.4em;" |
User Articles
|-
| width="33%" valign="top" | '''Projects'''
* [[AG Node Documentation]]
* [[Eye trackers @ EC3 Lab]]
* [[Large Scale Imagery: evolving the components]]
* [[Cluster User Documentation|Documentation for the Cluster]]
* [[SGI]]
* [[Acoustic Panels - DIY]]

| width="33%" valign="top" | '''Workstations'''
* [[Printers]]
* [[Research Workstations - default software loads | Standard Workstation Software List]]
* [[Windows Maintenance]]
* [[Linux Administration & Maintenance]]
* [[MAC Addresses and Hostnames]]
* [[Problems due to moving]]

| width="33%" valign="top" | '''General Information'''
* [[Research Services]]
* [[Accessing Your Data]]
* [[People power - grad students and their expertise]]
* [[Research Mailing Lists]]
* [[HOWTO Access The SVN Server| Accessing the SVN Server]]
* [[HOWTO Access The CVS Server| Accessing the CVS Server]]
* [[Lockers]]
* [[Policies and Procedures]]

|}

{| border="1" cellpadding="6" cellspacing="0" style="border: black solid 1px; border-collapse: collapse; text-align: left; width: 100%; background: #f0f0ff; "
| colspan="3" style="text-align: center; font-weight: bold; font-size: 1.4em;" |
Administration Articles
|-
| width="33%" valign="top" | '''Administration & Resource Management'''
* [[Research Administration Tasks]]
* [[Server documentation | Server List]]
* [[Network Devices Servers & Workstations]]
* [[Workstation Naming Convention]]
* [[Backups with AMANDA]]
* [[INFO Network Routing Information | Network Routing Information]]
* [[RAID Documentation]]
* [[Software Management]]

| width="33%" valign="top" | '''Customizing Linux Servers'''
* [[Research Servers - default software loads | Standard Server Software List]]
* [[REF Standard Server Configuration | Standard Server Configuration]]
* [[Setup a Project Wiki|Setup MediaWiki]]
* [[Maya]]
* [[Oracle on Gentoo]]
* [[WebDAV Setup]]
* [[Virtual Servers]]
* [[LTSP]]
* [[NFS Version 4]]
* [[XFS Filesystem HOWTO]]
* [[Webapp-Config]]

| width="33%" valign="top" | '''Client Side & Other Articles'''
* [[Linux Tips and Tools]]
* [[HOWTO Install SUSE with AutoYast|Install SUSE with AutoYast]]
* [[Who's Where - Availability of Research staff|Availability of Research Staff]]
* [[Maya]]
* [[Adding a Mac to the Research Domain]]
* [[Windows XP Maintenance]]
* [[Short diradm Documentation]]

|}

{| border="1" cellpadding="6" cellspacing="0" style="border: black solid 1px; border-collapse: collapse; text-align: left; width: 100%; background: #f0f0ff; "
| colspan="3" style="text-align: center; font-weight: bold; font-size: 1.4em;" |
Reference
|-
| width="33%" valign="top" | '''Manuals'''
* [[File Servers]]
* [[Belkin F1DA116T KVM Switch]]
* [[D-Link DGS-3224TG Switches]]
* [[Printer Manuals|Printers]]
* [[Theaterette Information, Instruction, and Manuals]]

| width="33%" valign="top" | '''Notes'''
* [[Command Syntax]]
* [[Micellaneous Notes]]

| width="33%" valign="top" |
* [http://research.iat.sfu.ca/awstats.pl?config=infrastructure AWstats (wiki-traffic)]
* [[Media:Satellite_channels.pdf|Bell ExpressVu Channels]]

|}

[http://research.iat.sfu.ca/wiki/index.php?title=Special:Recentchanges&feed=rss http://research.iat.sfu.ca/images/rss.gif]

Research Administration Tasks

2008-12-06T23:26:48Z

Hha13: /* Removing Key-served Applications */

== Adding Users ==
* 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.
* The password you are prompted for at the end is for '''phaeton'''.
* Add the newly-created user to our [http://bismarck.iat.sfu.ca/mailman/admin/research/ Research Mailing List].

== Deleting Users ==
Make sure there are no sym-links pointing to important stuff!!
# find -P /home/users/$username -noleaf -type l

* As root on '''yamato''':
# DEBUG=1 diradm userdel -r $username
* As root on '''hood''':
# DEBUG=1 diradm userdel $username
* Keeping the user on our [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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!

== 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 ==
* As root on '''hood''':
# diradm amadd -O $mapbase $key $src
# diradm amadd -O home.projects meditation 209.87.56.240:/export/projects/0/m/meditation
* '-O' means the default mount options for automount.
* As root on '''yamato''':
** Make the $src directory. mkdir -p $src
** Set ownership. chgrp -R $group $src
** Set permissions. chmod 2771 $src
** If web content is being served: mkdir -p $src/htdocs ; chmod 2775 $src/htdocs

== Adding CVS Repositories ==
Replace ''$foobar'' with the name of the repository.
* As root on '''hood''':
# diradm amadd -O auto.cvs $foobar 209.87.56.240:/export/cvs/$foobar
* As root on '''yamato''':
# cvs -d /export/cvs/$foobar init
# chmod -R 2770 /export/cvs/$foobar
: If this repository is for a group, (assuming there's a previously created group called ''$foobar_group''):
# chgrp -R $foobar_group /export/cvs/$foobar
: If this repository is for a single user:
# chown -R $user /export/cvs/$foobar
* Group name and cvs repository name don't have to match.
* To access CVS repo, use ''CVS_RSH="ssh"'' with URL being '':ext:$user@cvs.iat.sfu.ca:/var/cvsroot/$foobar''
* '''Users must be in group cvs in addition to $foobar to access the repository!'''

== 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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 $group /mnt/raid/svn/$repository

* The repository URL is '''svn+ssh://$user@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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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).

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Research Administration Tasks

2008-12-06T23:22:42Z

Hha13: /* Adding Key-served Applications */

== Adding Users ==
* 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.
* The password you are prompted for at the end is for '''phaeton'''.
* Add the newly-created user to our [http://bismarck.iat.sfu.ca/mailman/admin/research/ Research Mailing List].

== Deleting Users ==
Make sure there are no sym-links pointing to important stuff!!
# find -P /home/users/$username -noleaf -type l

* As root on '''yamato''':
# DEBUG=1 diradm userdel -r $username
* As root on '''hood''':
# DEBUG=1 diradm userdel $username
* Keeping the user on our [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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!

== 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 ==
* As root on '''hood''':
# diradm amadd -O $mapbase $key $src
# diradm amadd -O home.projects meditation 209.87.56.240:/export/projects/0/m/meditation
* '-O' means the default mount options for automount.
* As root on '''yamato''':
** Make the $src directory. mkdir -p $src
** Set ownership. chgrp -R $group $src
** Set permissions. chmod 2771 $src
** If web content is being served: mkdir -p $src/htdocs ; chmod 2775 $src/htdocs

== Adding CVS Repositories ==
Replace ''$foobar'' with the name of the repository.
* As root on '''hood''':
# diradm amadd -O auto.cvs $foobar 209.87.56.240:/export/cvs/$foobar
* As root on '''yamato''':
# cvs -d /export/cvs/$foobar init
# chmod -R 2770 /export/cvs/$foobar
: If this repository is for a group, (assuming there's a previously created group called ''$foobar_group''):
# chgrp -R $foobar_group /export/cvs/$foobar
: If this repository is for a single user:
# chown -R $user /export/cvs/$foobar
* Group name and cvs repository name don't have to match.
* To access CVS repo, use ''CVS_RSH="ssh"'' with URL being '':ext:$user@cvs.iat.sfu.ca:/var/cvsroot/$foobar''
* '''Users must be in group cvs in addition to $foobar to access the repository!'''

== 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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 $group /mnt/raid/svn/$repository

* The repository URL is '''svn+ssh://$user@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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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 ====

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Research Administration Tasks

2008-12-06T23:07:25Z

Hha13: /* Adding Key-served Applications */

== Adding Users ==
* 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.
* The password you are prompted for at the end is for '''phaeton'''.
* Add the newly-created user to our [http://bismarck.iat.sfu.ca/mailman/admin/research/ Research Mailing List].

== Deleting Users ==
Make sure there are no sym-links pointing to important stuff!!
# find -P /home/users/$username -noleaf -type l

* As root on '''yamato''':
# DEBUG=1 diradm userdel -r $username
* As root on '''hood''':
# DEBUG=1 diradm userdel $username
* Keeping the user on our [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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!

== 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 ==
* As root on '''hood''':
# diradm amadd -O $mapbase $key $src
# diradm amadd -O home.projects meditation 209.87.56.240:/export/projects/0/m/meditation
* '-O' means the default mount options for automount.
* As root on '''yamato''':
** Make the $src directory. mkdir -p $src
** Set ownership. chgrp -R $group $src
** Set permissions. chmod 2771 $src
** If web content is being served: mkdir -p $src/htdocs ; chmod 2775 $src/htdocs

== Adding CVS Repositories ==
Replace ''$foobar'' with the name of the repository.
* As root on '''hood''':
# diradm amadd -O auto.cvs $foobar 209.87.56.240:/export/cvs/$foobar
* As root on '''yamato''':
# cvs -d /export/cvs/$foobar init
# chmod -R 2770 /export/cvs/$foobar
: If this repository is for a group, (assuming there's a previously created group called ''$foobar_group''):
# chgrp -R $foobar_group /export/cvs/$foobar
: If this repository is for a single user:
# chown -R $user /export/cvs/$foobar
* Group name and cvs repository name don't have to match.
* To access CVS repo, use ''CVS_RSH="ssh"'' with URL being '':ext:$user@cvs.iat.sfu.ca:/var/cvsroot/$foobar''
* '''Users must be in group cvs in addition to $foobar to access the repository!'''

== 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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 $group /mnt/raid/svn/$repository

* The repository URL is '''svn+ssh://$user@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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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 ====

===== Mac OS X =====

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 ====

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Research Administration Tasks

2008-12-06T21:19:57Z

Hha13: /* Viewing Key-served Applications */

== Adding Users ==
* 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.
* The password you are prompted for at the end is for '''phaeton'''.
* Add the newly-created user to our [http://bismarck.iat.sfu.ca/mailman/admin/research/ Research Mailing List].

== Deleting Users ==
Make sure there are no sym-links pointing to important stuff!!
# find -P /home/users/$username -noleaf -type l

* As root on '''yamato''':
# DEBUG=1 diradm userdel -r $username
* As root on '''hood''':
# DEBUG=1 diradm userdel $username
* Keeping the user on our [http://bismarck.iat.sfu.ca/mailman/admin/research/ 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!

== 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 ==
* As root on '''hood''':
# diradm amadd -O $mapbase $key $src
# diradm amadd -O home.projects meditation 209.87.56.240:/export/projects/0/m/meditation
* '-O' means the default mount options for automount.
* As root on '''yamato''':
** Make the $src directory. mkdir -p $src
** Set ownership. chgrp -R $group $src
** Set permissions. chmod 2771 $src
** If web content is being served: mkdir -p $src/htdocs ; chmod 2775 $src/htdocs

== Adding CVS Repositories ==
Replace ''$foobar'' with the name of the repository.
* As root on '''hood''':
# diradm amadd -O auto.cvs $foobar 209.87.56.240:/export/cvs/$foobar
* As root on '''yamato''':
# cvs -d /export/cvs/$foobar init
# chmod -R 2770 /export/cvs/$foobar
: If this repository is for a group, (assuming there's a previously created group called ''$foobar_group''):
# chgrp -R $foobar_group /export/cvs/$foobar
: If this repository is for a single user:
# chown -R $user /export/cvs/$foobar
* Group name and cvs repository name don't have to match.
* To access CVS repo, use ''CVS_RSH="ssh"'' with URL being '':ext:$user@cvs.iat.sfu.ca:/var/cvsroot/$foobar''
* '''Users must be in group cvs in addition to $foobar to access the repository!'''

== 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 2770 /mnt/raid/svn/$repository
# chown -R $user /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 $group /mnt/raid/svn/$repository

* The repository URL is '''svn+ssh://$user@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.
<pre>
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.
</pre>

== Sassafras K2 Keyserver Administration ==
=== Background ===
We use the [http://www.sassafras.com 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 [[Media:K2Admin.dmg|Local Mac Copy]] 
And, the [[Media:K2Admin.exe|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 ====
==== Removing Key-served Applications ====

== Flexlm License Server Administration ==

== 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 [[Research Administration Tasks#Deleting Users | 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

Research Administration Tasks

2008-11-28T22:06:02Z

Hha13: /* Adding Users */

Research Administration Tasks

2008-11-28T22:04:23Z

Hha13: /* For a single user */

Research Administration Tasks

2008-11-28T22:04:09Z

Hha13: /* For multiple users */

Research Administration Tasks

2008-11-28T22:03:57Z

Hha13: /* Dumping the contents of SVN Repositories to a file, and vice-versa */

Research Administration Tasks

2008-11-28T22:03:42Z

Hha13: /* Working with LDAP */

Research Administration Tasks

2008-11-28T22:03:09Z

Hha13:

Research Administration Tasks

2008-11-28T21:35:12Z

Hha13: /* Adding Users */