Research Administration Tasks

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.
• The password you are prompted for at the end is for phaeton@hood.
• Add the newly-created user to our 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 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.

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

Hello $fullname

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

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

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

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

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

Sassafras K2 Keyserver Administration

Background

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

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

It's started from an init-script under

/etc/init.d/KeyServer

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

Administration

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

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