Research - User contributions [en]

Who's Where - Availability of Research staff

2025-06-13T17:15:08Z

Gordp: /* Gordon */

For co-ordination and information purposes:

==Larry==
Normal hours: Monday - Friday, 7am - 3pm

'''2011 Schedule:'''
*March 21-25: vacation
*July 4-8, 11-13: vacation

How to Send Sensitive Information

2024-12-04T21:28:02Z

Gordp:

If you need to send some sensitive information (eg: passwords), you can use SFU's Celox.MEssage server. It allows you to send an encrypted message that is automatically destroyed after it is viewed once. It is free to use and doesn't require any kind of login.

You can access it here: [https://secret.rcg.sfu.ca/ https://secret.rcg.sfu.ca/]

2018-04-25T22:47:11Z

Gordp: /* TV DX: Long-distance TV */

=History=
SIAT's EC3 Lab (Electronic Commerce, Communications and Communities) has an interest in digital media, which grew to include HD digital over-the-air television after Canada's August 31, 2011 transition from analog TV.

=Beginning=
* Built and tried a few different antennae:

[[Image:IMG 20160307 065814.jpg|4-bay broadband antenna, no reflector]]

[[Image:IMG 20160307 065744.jpg|2-bay fractal antenna, with mesh reflector]]

 
* Collected the electronics onto a board:

[[Image:SIAT OTA tuner board.jpg|SIAT OTA tuner-board]]
 

=Enhancement=
==MythTV for DVR (digital video recording)==

=TV DX: Long-distance TV=
==The Idea==

==The Plan==

==The Prototype==
===Antennae===
[[Image:IMG 20180421 162830.jpg|antenna signal processing board]]
 
===Electronics===

File:IMG 20180421 162830.jpg

2018-04-25T22:46:33Z

Gordp: antenna signal processing board

antenna signal processing board

2018-01-24T18:59:03Z

Gordp:

'''Need root access? Want to avoid port collisions? Got a file permissions problem?'''
 
We work with the ITI Group (Information Technology Infrastructure) at the Burnaby Campus, to provide a virtual server that gives you the benefits of a stand-alone server (no conflict with software versions, no firewall or port contention, full control and sudo (root) privileges).

To help you with your new server, the first thing we need to know is your choice of server-name. The server-name can take the form of:
''something''.'''iat'''.sfu.ca
or
''something''.'''siat'''.sfu.ca

* '''Access''' to your server can be configured by the ITI folks at the time of creation or through the creation of an SFU Mailing List. It is most-common to specify the SFU users needing access when the server is created, and have ITI configure these as local-users on the server. Your SFU username and password control access. A Mailing List is something to consider, where there may be a larger number of contributors, or where contributors may change fairly frequently - one person will have to be specified as the Mailing List maintainer. Only SFU people can be included when using a Mailing List for access-control; additional non-SFU local users can be created later.
 
* '''Connect''' to the virtual server via SSH from any '''wired''' campus network connection. In the first instance, you will want to connect to the server with SSH (Secure Shell) - on Windows, you can download and use PuTTY; on a Mac you can use their Terminal application (included with OS-X). Once connected over SSH, you will have a command-line environment, from which to configure and enable whatever services you wish. Later, you should be able to connect to this new server-machine using a graphical file-transfer-utility, like WinSCP on Windows or Fugu on a Mac. You would provide the server-name, and your SFU credentials (username/password). These utilies work through port 22, again using the SSH (Secure Shell) encrypted protocol. You can create HTML content locally on your own computer, and use WinSCP / Fugu to easily transfer the content over to this new server. 
Mailing-List Dialogue: 
[[File:maillist_creation.png|image showing dialogue of SFU mailing-list creation]]

 
* The SFU '''DNS''' (hostname-to-IP-address mapping) record is entered by ITI when your server is created. The server will have an public IP address that can also be used with your own Registrar's DNS for non-SFU server-names. In other words, your domain name (eg: www.mydomainname.com) can resolve directly to your virtual server.
 
* ITI will set up the server with a basic OS and software, commonly consisting of a LAMP stack (Linux, Apache, MySQL, PHP). It is up to the owner of the server to install the rest (eg: Wordpress, Drupal, Wiki), then configure and enable everything. It is quite a bit of work to maintain the hygiene and proper operation of a server, so please consider this when making a request.
 
* Resource-contraints can be quickly and easily handled by ITI - with a click of a control-panel, they can increase the CPU, add more RAM, or boost drive-space for you.
 
* If you're interested, please contact [mailto:gordonp@sfu.ca Gordon Pritchard] (gordonp@sfu.ca).

File:Maillist creation.png

2018-01-24T18:55:36Z

Gordp: image showing dialogue of SFU mailing-list creation

image showing dialogue of SFU mailing-list creation

HOWTO Setup Tripwire

2018-01-04T22:51:46Z

Gordp: /* File System Error Messages */

=== Setting Up a Tripwire Installation ===

hostname ~ # '''emerge tripwire mktwpol'''
hostname ~ # '''cd /etc/tripwire'''
hostname ~ # '''emacs -nw /etc/tripwire/twpol-GENERIC.txt''' ''(change '''HOSTNAME=''' to the proper hostname; no domain/no FQDN)
hostname ~ # '''emacs -nw /etc/tripwire/twcfg.txt''' ''(change /bin/nano to /usr/bin/vi for use during updating, for example)''
Create the keys, and sign the policy and configuration files:

hostname ~ # '''cd /etc/tripwire ; /bin/bash twsetup.sh''' ''(supply site- and local-key multiple times to setup, site-key another couple of times to sign tw.pol and tw.cfg)''
Now initialize everything (creates the database file /var/lib/tripwire/$hostname.twd)
hostname ~ # '''tripwire --init'''
Create the list of files we want to fingerprint and monitor:
hostname ~ # '''/usr/local/bin/mktwpol.sh > /etc/tripwire/twpol.txt'''
(If you don't have this on your system, grab it [[MEDIA:mktwpol.sh|'''HERE''']], name it '''/usr/local/bin/mktwpol.sh''', and make it executable with '''chmod u+x /usr/local/bin/mktwpol.sh'''

=== Generate a Report ===

hostname ~ # '''tripwire --check'''

The first time you do this, there may be a few files not found. Go through these, one by one, and either find the proper location of the file, or comment them out in the twpol.txt. Sometimes files are re-located from what's in the original twpol.txt - like, a binary moved from /bin/ to /usr/bin/ or maybe from /sbin/ to /usr/sbin/.
 

=== File System Error Messages ===

To get rid of "File system error." messages where the file or folder does not exist, first check to see if the file has been re-located (somewhat common when updating packages), or comment out the culprits from /etc/tripwire/twpol.txt if it's truly disappeared.
 
hostname ~ # '''emacs -nw /etc/tripwire/twpol.txt'''

'''A BETTER WAY''':
hostname ~ # '''/usr/sbin/mktwpol.sh /etc/tripwire/mktwpol-default.rules > /etc/tripwire/twpol.txt'''

Check the resulting /etc/tripwire/twpol.txt file for sanity... for example, if the ruleset was incorrect or unspecified during invocation of mktwpol.sh, you may see a very-short twpol.txt file that only references the tripwire files :-(

Then, update the policy file, delete and re-init the db:

hostname ~ # '''twadmin --create-polfile -S /etc/tripwire/site.key /etc/tripwire/twpol.txt'''
hostname ~ # '''rm /var/lib/tripwire/$hostname.twd*'''
hostname ~ # '''tripwire --init'''

Now, run a check, followed by an update. This shifts files around (mainly creates /var/lib/tripwire/$hostname.twd.bak) which will be flagged as "changed" on the next run, so re-run the check/update:

hostname ~ # '''tripwire --check'''
hostname ~ # '''tripwire --update --twrfile /var/lib/tripwire/report/'''''<hostname_date_time>'''''.twr'''
hostname ~ # '''tripwire --check'''
hostname ~ # '''tripwire --update --twrfile /var/lib/tripwire/report/'''''<hostname_date_time>'''''.twr'''

=== After System Changes ===

After you emerge packages or change config files:

hostname ~ # '''tripwire --update --twrfile /var/lib/tripwire/report/'''''<a_previous_integrity_report>'''''.twr'''

=== Tidying Up ===

After a while, the '''/var/lib/tripwire/report/''' directory becomes quite large. At some point, these historical reports are of no value, so they can be deleted. One guideline might be to blow away anything more than 6 months old.

=== Troubleshooting ===

An error of: '''Fatal Exception st9exception''' indicates that the tripwire database has become corrupted. Re-initialize (tripwire --init) and follow the steps under File System Error Messages.

Research Administration Tasks

2017-12-13T19:29:06Z

Gordp: /* Working with LDAP */

== Finding Users ==
 
If you want to know if a user exists in the Research database, run the following command on any of the Linux servers (eg: sr-hood): 
* getent passwd |grep '''search-string'''
 
Where '''search-string''' is part of, or the entire, user name that you're searching for. 
''Note: Not all entries have the user's full name (ie: first and last), so you may have to search for just part of the user's name.''

== 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 [https://ponyexpress.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 [https://ponyexpress.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

In addition, many users are added to a group in order to maintain and evolve related web-content. In this case, we add a symlink in the user-home-directory, which points to the project/htdocs folder. On any LDAP-enabled machine where logins are permitted (ie not hood), first make the symlink, then change the ownership (from root):
# cd /home/users/$user
# ln -s /home/projects/$project
# chown -h $user:$project /home/users/$user/$project

== 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 and Removing Computers to/from the Domain ==
* As root on '''hood''':
hood ~ # '''diradm smbhostadd sr-#####'''
* refer to [[Workstation_Naming_Convention]]
* The LDAP entry is case-sensitive. Make sure it matches the machine's name.
* If you are adding a Windows 7 machine, it also requires a registry hack. See '''Win7_Samba3DomainMember.reg''' under \\hurricane\software\windows. It contains the following:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters] "DNSNameResolutionRequired"=dword:00000000 "DomainCompatibilityMode"=dword:00000001
* To remove an LDAP entry, use '''smbhostdel''':
hood ~ # '''diradm smbhostdel sr-#####'''
* If you don't add the computer's name to ldap and its MAC to Men and Mice, the machine will not be able to connect to the Research domain. This problem can also be verified by going into the command line and typing '''ipconfig /all'''. If the domain name doesn't show as '''iat.sfu.ca''', then it is very likely that one or both of those two steps were skipped.
* We add machine to the Domain to facilitate Windows' operations; Unix/Linux/Mac don't care about machine entries. You may want to verify machine-names (either present, or absent) - to check what Samba thinks about all accounts (user-accounts and machine-accounts):
hood ~ # '''pdbedit -L''' ''(note: machine-accounts end in '''$''')''

== 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>
From: help@siat.sfu.ca
To: $FULLNAME <$EMAIL>
Subject: Research account created - $NEWUSER

Hello $FULLNAME,

Your SIAT Research account has been created:
Username: $NEWUSER
Password: $NEWPASS

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

Please visit https://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@siat.sfu.ca
Please include a good description of the entire problem and a suitable subject
line.

More information about SIAT Research can be found on our Research Wiki:
https://research.iat.sfu.ca/wiki/

Our wiki also has information about how to connect to SIAT printers:
https://research.iat.sfu.ca/wiki/index.php?title=Printers

and the software that is available to researchers:
https://research.iat.sfu.ca/wiki/index.php?title=Research_Workstations_-_default_software_loads

Here are some cool ideas about the benefits of this SIAT Research account:

- you can log onto a SIAT Research workstation with your new account,
and automatially have your U:\ drive connected, on any workstation
you log onto! This U:\ home-directory is held on a SIAT Research
fileserver, and gets backed-up nightly.

- you can access your data, on our SIAT Research file-servers, from
just about anywhere:
https://research.iat.sfu.ca/wiki/index.php?title=Accessing_Your_Data

- we have a cloud service, which can let you access your data across
many different devices and locations; here is Owncloud:
https://research.iat.sfu.ca/wiki/index.php?title=Cloud-based_File_Storage
https://owncloud.iat.sfu.ca

- there are SVN and CVS servers available, for check-in/check-out and
version control

- we can create shared "project" folders, which allows for collaboration
and sharing among several people

If *YOU* have any ideas for services or features which may be useful,
please don't hesitate to let us know what you're thinking! We can all
benefit from your ideas!

Welcome! Have fun!
</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 on our Windows server, lancer.iat.sfu.ca.
 
We currently (2012) have 200 key-client licenses, which covers our current user-quantity, with some room for future growth. 
This keyserver serves licenses to Windows and Mac clients (only :-( ). 
 
'''Old Information, Retained for Reference Purposes:'''
The Sassafras keyserver runs under Linux, on bismarck.iat.sfu.ca, with install-root under '''/usr/local/k2'''. 
In a process-listing, it shows up as:
/usr/local/k2/ks -d -e /usr/local/k2/startup.txt 
It's started from an init-script under
/etc/init.d/KeyServer
which, in turn, is launched upon startup by the Gentoo rc-update scripts. No manual intervention is necessary (normally :-) ). 

=== Administration ===

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

Here is the [[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.
 
'''Old Information, Retained for Reference Purposes:'''
In the Licenses window, you will see the name of the application, as well as how many licenses are in use at that particular moment in time, how many people are waiting for a license to free up, and how many licenses we own (labeled as 'Limit').

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

==== Adding Key-served Applications ====

Before starting, you must be on a Mac or Windows PC that already has the software you'd like to add installed and working.
 
You need three entries to support a new key-served application:
# '''Product''' This is the product whose license we are trying to control. A product is made up of one or more programs.
# '''Program''' This is the file, or files, associated with a particular product.
# '''Policy''' Policies specify the type of license we have for a given product, and allow us to dictate how that product can be used (eg: maximum of 5 concurrent users).
 
Sassafras Keyserver version 7 supports other features but the three that were mentioned are all we need to control how software is run.
 
The basic process is: 
# Make sure the program or programs that belong to your product exist, either in KeyServer's pre-made list of available programs, or in the audit report of programs. Note: there is no way to manually create a new program. The only way to create a new program entry is to install software on a machine that then gets audited, or to install it on your local machine and select it from the Browse dialog when you try to create a new program entry in KeyConfigure.
# Create a new product by right-clicking on the '''Products''' window and choosing '''New Product...'''. In its program field, drag one or more programs from the '''Programs''' window into it.
# Create a new policy by right-clicking on the '''Policies''' windows and choosing '''New Policy...'''. In its product field, drag the product from the '''Products''' window into it.
# The policy settings will usually look like this: 
[[File:Sassafras-policy-config.jpg]]
 
''Detachable means that the program can be run even if the user has lost connection to the key server. If the program is a key server-specific version and requires Sassafras KeyServer to provide a key, then the Detachable setting will be ignored.''
 
 
Sometimes, we will get a keyserved version of a product that requires Sassafras Keyserver to be running and to serve up keys in order for that product to run. In that case, the vendor will also provide us with a license file that gets stored in the KeyServer Data Folder (C:\Program Files\Sassafras K2\Server\KeyServer Data Folder) on Lancer. When KeyServer is restarted, it will automatically generate the required entries to manage that product.
 
'''Old Information, Retained for Reference Purposes:'''
Open KeyConfigure and go to File > Create License (or press Cmd+i on a Mac or Ctrl+i on Windows).
A new window will appear. Enter a License Name, usually the same as the Software name. Then click Browse, and find the App that you'd like to keyserve (on a Mac it's usually under Applications, on Windows in Program Files). Double click it.

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

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

==== Removing Key-served Applications ====

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

==== Sassafras KeyServer (version 7.x) Documentation ====
http://www.sassafras.com/hrl/7.0/index.html

==== Sassafras KeyServer Error ====

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

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

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

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

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

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

== Flexlm License Server Administration ==

== Working with LDAP ==

The options used in commands below 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

=== Searching LDAP ===
Oddly enough, the tool we'll use is called '''ldapsearch''' :-)

==== Find Machine Accounts ====
To find machine$ (Computer) entries, almost always Windows Domain machine-accounts:
* As root on '''hood''':
hostname / # '''ldapsearch -x -D"cn=<ReadOnlyUser>,dc=iat,dc=sfu,dc=ca" -b "ou=Computers,dc=iat,dc=sfu,dc=ca" -s one "(objectclass=*)" -w <SecretReaderPassword> -x'''

==== Find Users ====
To find all Users, modify the Base -
* As root on '''hood''':
hostname / # '''ldapsearch -x -D"cn=<ReadOnlyUser>,dc=iat,dc=sfu,dc=ca" -b "ou=Users,dc=iat,dc=sfu,dc=ca" -s one "(objectclass=*)" -w <SecretReaderPassword> -x'''

=== 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''':
hostname / # '''ldapmodify -x -f $file.ldif -D cn=Manager,dc=iat,dc=sfu,dc=ca -W'''
* You will be prompted for our LDAP 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''':
hostname / # '''ldapdelete -x -f $file.ldif -D cn=Manager,dc=iat,dc=sfu,dc=ca -W'''
* You will be prompted for our LDAP password

HOWTO Setup Nullmailer

2017-06-23T17:35:52Z

Gordp: /* Install Nullmailer */

HOWTO Setup Nullmailer

2017-06-23T17:02:48Z

Gordp: /* Install Nullmailer */

From the authour's web-site:
Nullmailer is a mail transport agent designed to only relay all its
messages through a fixed set of "upstream" hosts. It is also designed
to be secure.
 
We use nullmailer on a number of servers, where minimalist functionality is all that is required. All mail (typically only cron-job outputs, like '''logwatch''' and '''tripwire''' are then sent to our research-admin mailing-list, on ponyexpress.iat.sfu.ca. From ponyexpress, the admin-list will fire off copies to all subscribed research-administrators.

== Install Nullmailer ==
hostname ~ # '''emerge nullmailer -va'''

This may pull in '''sys-process/supervise-scripts''' (or, you can emerge it manually), which will then require:
hostname ~ # '''rc-update add svscan default'''
hostname ~ # '''ln -fs /var/spool/nullmailer/service /service/nullmailer'''
Note: you may have to create the '''/service''' directory first, by hand... 
 
and
hostname ~ # '''/etc/init.d/svscan start'''

== Configuration ==
Edit the following files to configure the machine to send mail to our mailing server (Bismarck).

'''/etc/nullmailer/adminaddr'''
admin@ponyexpress.iat.sfu.ca

'''/etc/nullmailer/defaultdomain'''
iat.sfu.ca

'''/etc/nullmailer/me'''
$hostname.iat.sfu.ca

'''/etc/nullmailer/remotes'''
ponyexpress.iat.sfu.ca smtp

'''/etc/mailname'''
$hostname.iat.sfu.ca

== Status ==
hostname ~ # '''mailq'''

== Testing ==
(note: you may have to '''emerge mailx''' to get the '''mail''' command)
 
Send a message to root, then wait a brief moment for it to be picked up and sent onwards.
hostname ~ # '''mail -s "this is a nullmailer test" root'''
Type your message, complete it with a '''ctrl-D + Enter'''
If everything is going properly, the adminaddr should receive a shiny new message in a short period of time!

Network Devices Servers & Workstations

2017-05-09T21:35:06Z

Gordp: /* Servers */

== Network Devices ==
{| border="1" cellpadding="1" cellspacing="0" style="font-size: 95%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 95%;"
|-style="background: #ececec;"
! style="width:10em" | IP Address
! style="width:25em" | APC 7900 Power Switches
!Servers Powered: Socket Number
|-
!style="background: #ececec;"| 209.87.56.100
|[[PSwitches:sr-apc00|sr-apc00.iat.sfu.ca]]
|[[ESwitches:sr-dlink00|1. dlink00]] [[Servers:KVM #00|2. KVM #00]] [[Servers:Lightning|3. lightning]] [[Servers:Hood|4. hood]] [[Servers:Nelson|5. nelson]] [[Servers:Navajo|6. navajo]] [[Servers:Unused|7. Unused]] [[Servers:KVM Monitor|8. KVM Monitor]]
|-
!style="background: #ececec;"| 209.87.56.101
|[[PSwitches:sr-apc01|sr-apc01.iat.sfu.ca]]
|[[Servers:Lightning|1. lightning]] [[Servers:Lightning|2. lightning]] [[Servers:Unused|3. Unused]] [[Servers:Nerva|4. nerva]] [[Servers:Musashi|5. musashi]] [[Servers:Unknown|6. Unknown]] [[Servers:MEDIA ARRAY|7. MEDIA ARRAY]] [[Servers:RAID #03|8. RAID #03]]
|-
!style="background: #ececec;"| 209.87.56.102
|[[PSwitches:sr-apc02|sr-apc02.iat.sfu.ca]]
|[[ESwitches:sr-dlink01|1. dlink01]] [[Servers:Bismarck|2. bismarck]] [[Servers:Vindicator|3. vindicator]] [[Servers:Tirpitz|4. tirpitz]] [[Servers:Kingfisher|5. kingfisher]] [[Servers:Dragonfly|6. dragonfly]] [[Servers:Dolphin|7. dolphin]] [[Servers:Clipper|8. clipper]]
|-
!style="background: #ececec;"| 209.87.56.103
|[[PSwitches:sr-apc03|sr-apc03.iat.sfu.ca]]
|[[Servers:Unused|1. Unused]] [[Servers:Skimmer|2. skimmer]] [[Servers:Thunderbolt|3. thunderbolt]] [[Servers:Lancer|4. lancer]] [[Servers:Yamato|5. yamato]] [[Servers:RAID #02|6. RAID #02]] [[Servers:RAID #01|7. RAID #01]] [[Servers:RAID #00|8. RAID #00]]
|-
!style="background: #ececec;"| 209.87.56.104
|[[PSwitches:sr-apc04|sr-apc04.iat.sfu.ca]]
|[[ESwitches:sr-dlink02|1. dlink02]] [[Servers:Wildcat|2. wildcat]] [[Servers:Corsair|3. corsair]] [[Servers:Pool|4. pool]] [[Servers:Aki|5. aki]] [[Servers:TAPE DRIVE #0|6. TAPE DRIVE #00]] [[Servers:TAPE DRIVE #01|7. TAPE DRIVE #1]] [[Servers:KVM #01|8. KVM #01]]
|-
!style="background: #ececec;"| 209.87.56.105
|[[PSwitches:sr-apc05|sr-apc05.iat.sfu.ca]]
|[[Servers:Seagull|1. seagull]] [[Servers:Beaufort|2. beaufort]] [[Servers:Unused|3. Unused]] [[Servers:Unknown|4. Unknown]] [[Servers:Titus|5. titus]] [[Servers:Cossack|6. cossack]] [[Servers:Valiant|7. valiant]] [[Servers:LTSP|8. LTSP]]
|-
!style="background: #ececec;"| 209.87.56.106
|[[PSwitches:sr-apc06|sr-apc06.iat.sfu.ca]]
|[[ESwitches:sr-dlink03|1. dlink03]] [[Servers:hvilab|2. hvilab]] [[Servers:Slinky|3. slinky]] [[Servers:campuscanada|4. campuscanada]] [[Servers:Intendant|5. intendant]] [[Servers:BROKEN|6. BROKEN]] [[Servers:Echo|7. echo]] [[Servers:Hmr|8. hmr]]
|-
|}

== Servers ==
{| border="1" cellpadding="1" cellspacing="0" style="font-size: 85%; border: gray solid 1px; border-collapse: collapse; text-align: center; width: 70%;"
|-style="background: #ececec;"
! style="width:10em" | IP Address
!Device
!More Info
|-
|-
!style="background: #ececec;"| 209.87.60.1
| sr-boomerang.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.2
| not used
|
|-
!style="background: #ececec;"| 209.87.60.3
| not used
|
|-
!style="background: #ececec;"| 209.87.60.4
| not used
|
|-
!style="background: #ececec;"| 209.87.60.5
| sr-echo.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.6
| not used
|
|-
!style="background: #ececec;"| 209.87.60.7
| not used
|
|-
!style="background: #ececec;"| 209.87.60.8
| hdhr4_1.iat.sfu.ca
| SiliconDust HDHR4-US networked over-the-air dual-ATSC-tuner
|-
!style="background: #ececec;"| 209.87.60.9
| hdhr4_2.iat.sfu.ca
| SiliconDust HDHR4-US networked over-the-air dual-ATSC-tuner
|-
!style="background: #ececec;"| 209.87.60.10
| sr-sling1.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.11
| sr-sling2.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.12
| mythpvr.iat.sfu.ca
| MythTV secondary backend
|-
!style="background: #ececec;"| 209.87.60.13
| not used
|
|-
!style="background: #ececec;"| 209.87.60.14
| not used
|
|-
!style="background: #ececec;"| 209.87.60.15
| sr-lancer.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.16
| not used
|
|-
!style="background: #ececec;"| 209.87.60.17
| sr-tirpitz.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.18
| not used
|
|-
!style="background: #ececec;"| 209.87.60.19
| not used
|
|-
!style="background: #ececec;"| 209.87.60.20
| spitfire_old.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.21
| not used
|
|-
!style="background: #ececec;"| 209.87.60.22
| sr-clipper.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.23
| eprints.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.24
| owncloud.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.25
| not used
|
|-
!style="background: #ececec;"| 209.87.60.44
| sr-slinky.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.50
| not used
|
|-
!style="background: #ececec;"| 209.87.60.51
| not used
|
|-
!style="background: #ececec;"| 209.87.60.52
| not used
|
|-
!style="background: #ececec;"| 209.87.60.54
| not used
|
|-
!style="background: #ececec;"| 209.87.60.56
| sr-hercules.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.57
| sr-hercules00.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.58
| sr-hercules01.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.59
| sr-hercules02.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.60
| sr-hercules03.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.61
| sr-hercules04.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.62
| sr-hercules05.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.85
| idrac.iat.sfu.ca
| assigned (Dave Barnes)
|-
!style="background: #ececec;"| 209.87.60.86
|
| assigned (Dave Barnes)
|-
!style="background: #ececec;"| 209.87.60.86
|
| assigned (Dave Barnes)
|-
!style="background: #ececec;"| 209.87.60.88
| moco.iat.sfu.ca
| assigned (Dave Barnes)
|-
!style="background: #ececec;"| 209.87.60.89
|
| assigned (Dave Barnes)
|-
!style="background: #ececec;"| 209.87.60.90
|
| assigned (Dave Barnes)
|-
!style="background: #ececec;"| 209.87.60.91
|
| assigned (Dave Barnes)
|-
!style="background: #ececec;"| 209.87.60.92
|
| assigned (Dave Barnes)
|-
!style="background: #ececec;"| 209.87.60.93
|
| assigned (Dave Barnes)
|-
!style="background: #ececec;"| 209.87.60.94
|
| assigned (Dave Barnes)
|-
!style="background: #ececec;"| 209.87.60.95
|
| assigned (Dave Barnes)
|-
!style="background: #ececec;"| 209.87.60.100
| sr-apc00.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.102
| sr-apc02.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.103
| sr-apc03.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.104
| sr-apc04.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.105
| sr-apc05.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.109
|
| Temporary place-holder for new-VM spawning
|-
!style="background: #ececec;"| 209.87.60.110
| hydra.iat.sfu.ca
| Virtual Machine host (kvm/QEMU) for lots of Research-infrastructure guests
|-
!style="background: #ececec;"| 209.87.60.111
| ponyexpress.iat.sfu.ca
| mail and mail-list server
|-
!style="background: #ececec;"| 209.87.60.112
| sentinel.iat.sfu.ca
| Nagios network-status monitor
|-
!style="background: #ececec;"| 209.87.60.113
| teleport.iat.sfu.ca
| SSH "gateway" machine, for off-campus access
|-
!style="background: #ececec;"| 209.87.60.114
| research.iat.sfu.ca
| Main SIAT Research web-server, including html site and wiki
|-
!style="background: #ececec;"| 209.87.60.115
| plex.iat.sfu.ca
| SIAT media repository and server
|-
!style="background: #ececec;"| 209.87.60.116
| rats.iat.sfu.ca
| SIAT barcodes (RATS=Research Asset Tracking Server)
|-
!style="background: #ececec;"| 209.87.60.117
| music.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.129
|
| iKVM remote/web administration for HYDRA
|-
!style="background: #ececec;"| 209.87.60.230
| sr-spitfire.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.231
| sr-hurricane.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.232
| unused
|
|-
!style="background: #ececec;"| 209.87.60.233
|
| unused
|-
!style="background: #ececec;"| 209.87.60.234
|
| unused
|-
!style="background: #ececec;"| 209.87.60.238
| sr-hood.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.239
| sr-musashi.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.240
| sr-hvilab-host.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.241
| sr-hvilab00.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.252
|
| unused
|-
!style="background: #ececec;"| 209.87.60.253
| sr-dellsw.iat.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.254
| sry-gate60.net.sfu.ca
|
|-
!style="background: #ececec;"| 209.87.60.255
| Broadcast
| Never use this address!!!
|}