Difference: ImagerTechnicalInformation (53 vs. 54)

<--

 Title 
 modified: mmm dd, yyyy 
	*

-->

Installation of SuSE Packages

modified: Mar 27, 2012

• Packages cannot be installed until they have been verified not to conflict with other installed packages (some packages may conflict, despite being be on the list of SuSE supported packages). This can take a few days depending on the tech staff member's schedule. If faster response is desired, recommended procedure is to install new packages under evaluation on a user-administered machine on subnet 54. If any of these package meet user requirements, they can then send email to help to have them installed globally. Once new packages are installed this way, they will become part of the default department OS image.

PowerPoint on TSE servers

modified: Feb 6, 2012

• The slide show function does not work.
• Going directly to slide show does not work. It results in a hung window. You have to hit ESC key get out of slide show mode.

• Workaround:
• Go to the Reading View (book icon at lower left hand corner) mode then select the slide show mode works.

Connecting to Printers on Windows

modified: May 30, 2011

• Staff-supported machines should already have all printers set up and ready to go.
• To print from user-administered machines, or from personal laptops connected to the VPN:

• • Server: winserver.cs.ubc.ca
  • Username: ubc-cs\your_username
  • Password: same as for CWL and VPN
  • Now add the printer via the Control Panel. No need to authenticate.
• For more details: http://www.cs.ubc.ca/support/printing-windows

Imager Software

modified: Oct 18, 2011

• To get a list of software and programs available to the department on staff supported machines, do the following:
  • Linux: Go to /cs/local/lib/pkg and see what's in the directory.

• A list of Imager's software is available on the wiki on the Imager Software List page.
• The imager tech software list (.xls file) is located in the imager/imager-tech/ folder. This file is only accessible to the imager-tech group. It should contain the same info as the list on the wiki, but it also has licensing information.

Imager Personal Disk Usage Policy

modified: Aug 9, 2010

• Imager Personal Disk Usage Policy effective Sept 2010.

Imager Filespace and Local Machine Space

modified: Nov 29, 2010

• Machine local space on Windows: c:/tmp
  • wiped when machine is reimaged, or hard-drive fills up
  • not wiped on reboot
  • not backed up, but could be used for code and data that can easily be reproduced
• Machine local space on Linux: /scratch
  • available after 11.4 upgrade (~May 29, 2011)
  • not wiped when machine is reimaged, but this is not guaranteed (so, backup before upgrades just in case)
  • not wiped on reboot
  • not backed up, but could be used for code and data that can easily be reproduced
• Machine local space on Linux: /var/tmp
  • wiped when machine is reimaged, or hard-drive fills up
  • not wiped on reboot
  • not backed up, and /scratch would be a better place to store reproducible code and data
• Machine local space on Linux: /tmp
  • wiped on reboot; poor space to place data
• Networked space: home directory
  • z: drive on windows, departmental account
  • stores your mail: ~/Mail and website: ~/public_html
  • backed up, RAID, recover through snapshot (see .snapshot in any directory)
  • small amound of space (quota)
• Networked space: /ubc/cs/research/imager/people/
  • backed up, RAID, recover through snapshot (see .snapshot in any directory)
  • setup when you join Imager via tech staff
  • shared space with everyone in Imager lab
  • project data should not be stored here because it may be inaccessible by your supervisor and others when you leave (although this depends on the permissions you set)
• Networked space: /ubc/cs/research/imager/projects
  • backed up, RAID, recover through snapshot (see .snapshot in any directory)
  • shared project data
  • shared within Imager, except PSM
• Networked space: /ubc/cs/research/psm
  • backed up, RAID, recover through snapshot (see .snapshot in any directory)
  • shared project data within PSM group

• The imager filespace is located at /ubc/cs/research/imager . /imager (2.2TB on NetApps2) contains both project/ and people/.

• • 2.2TB as of Oct 2008 (500GB purchased by Kelly and Robert)
  • 1.7TB as of Feb 2008
• The psm filespace is located at /ubc/cs/research/psm. On Nov 17, 2010, a new partition for psm was created.
  • 1.6TB as of Nov 2010 (?)
• There is also 1TB of old raid space which was imager's old disk space before moving to NetApps. This raid space (not on NetApps) is divided between two directories: /ubc/cs/research/imager-raid1 (600GB) and /ubc/cs/research/psm-raid1 (400GB).
• NetApps info:
  • Space capacity for NetApps = 7TB for a tray.
  • NetApps1 = smaller capacity, faster, expensive, $10/GB; NetApps2 = larger capacity, slower, cheaper, $5/GB
  • Imager gets 1.7TB of NetApps space for free and needs to pay for additional space. There is a policy on how much space out of the 1.7TB should be allocated to home dirs.

What changed with NetApps

modified: Sep 26, 2007

• The above link contains information on how to use the backup/restore features on the new file servers.

Purchasing Software and The Software License Czar

modified: Apr 27, 2009

• When purchasing software, faculty should email imager-tech so that the software license czar (currently Ernesto Torres) can follow up on the licensing info. (Note-- please see the Ordering Software page for further information)
• The software license czar's lab duties include: keep track of software licensing info, show nonsensitive info on wiki, keep sensitive info in area viewable by imager-tech only, send out renewal reminders to profs 1 month before expiry date.

Snapshot Failure Due To Large Data Changes

modified: Nov 10, 2008

• The following are answers from Mike Sanderson (tech staff) about the snapshot failure.
• When there is a snapshot failure due to large data change, what exactly is lost? If a snapshot fails, the entire snapshot will not be created. We take hourly, daily, and weekly snapshots. We retain 25 hourly, 8 daily, and 3 weekly snapshots. We currently have weekly snapshots from Nov 8, Nov 1, and Oct 25 run at 2:00 AM on netapp2. If the next weekly snapshot at 2:00 AM Nov 15 fails, we will retain the snapshots from Nov 8, Nov 1, and Oct 25. To clarify the problem we were having a little, it was not the snapshots in /ubc/cs/research that we were having problems with. The issue was on netapp3 - the filer dedicated to retaining weekly snapshot data. The intent was to retain 52 weeks of snapshots on netapp3, effectively replacing our tape backups with online disk-based backups. The combination of large changes in snapshot volume and disk space increases on netapp1 and netapp2 that were not mirrored on netapp3 resulted in 100% usage of the disk space on netapp3 - regular space and snapshot space. By deleting the oldest snapshots, we were able to do the transfers of the newest snapshots. Because the retention is so large, it takes much longer for the large snapshots to roll off the end and the space to be recovered.
• Note that (almost) all non -raid* filesystems in /ubc/cs/research/* share the same snapshot space as .../research/imager. The snapshot space is based on the total size of a "volume" - think of it as an entire disk - which we split up into research group space via quotas.
  • 1.3T 670G 565G 55% /ubc/cs/research/imager/.snapshot
  • 635G 213G 423G 34% /ubc/cs/home/.snapshot
• Would it be possible to get a directory that does not have snapshot utilities? The RAID space (disk space not on the filers) was intended for this purpose, though there are problems with this space. If NetApp filer space is needed because of performance needs or some other reason, this can be discussed. Tech staff will need some lead time with it however. We are approaching the available capacity of netapp2. Mike will be meeting with Bill this week to discuss a non-budgeted purchase of additional space.

Performance Issues with Raid Space

modified: Sep 3, 2008

• Imager has raid space (found in /ubc/cs/research/): imager-raid1, psm-raid1, spiff-raid, pai-raid.
• The raid space lives on a Xyretec disk and has performance problems. Sometimes, the raid is slow. Tibi performed some tests and Mike tried to figure out what caused the raid to be slow. However, the cause is still not known. Perhaps profiling during testing might help analyze performance. If the raid is problematically slow, please notify the help desk.
• Tibi's tests show that imager-raid1 and imager-raid2 have similar performance
• It is documented that sequential I/O over NFS when submitting several jobs in parallel to the SGE can bring the system to a halt. Therefore, optimizing the I/O activity when submitting jobs to the SGE on the clusters likely will improve the performance quite a bit. It is possible that some of the scripts submitted do a lot of sub-optimal I/O over the network thus slowing all of us down. Here is a document tht explains the basic SGE commands as well as some best practices to optimize the I/O over the network (page 31) including some sample code. http://www.biostat.jhsph.edu/bit/SGE_lecture.ppt.pdf

Computing Committee's Levels of Service Document

modified: Jun 11, 2008

• The Computing Committee's Levels of Service Document can be found on the computing web page:

• This document describes the type and amount of support provided by the technical staff to support research activities.

Sun Grid Engine/ICICS Cluster

modified: Aug 30, 2010

• The Sun Grid Engine is scheduling software used to run jobs on 3 clusters of machines. The 3 clusters are beta, icics, and arrow; the icics cluster is available to the dept. The documentation appears on the BETA wiki page under the link "SunGridEngine". To access the SGE users can either ssh into a beta machine or submit jobs through departmental servers okanagan or begbie.
  • BETA wiki page documentation
  • documentation for Beta lab members

Departmental Servers

modified: Feb 28, 2008

Video Editing Resources

modified: Feb 21, 2008

• caber is a general purpose Imager machine in x660 which has video editing software (Adobe Premiere Pro). Users should use the D drive to store their projects instead of the C drive since tech staff needs the C drive for maintenance.

Remote Access Policy For Shared Machines

modified: Nov 22, 2007

• caber is a general purpose Imager machine. Users can remotely log on to them or use them in x660.
• The first person who logs on (remotely or not) owns the machine. The next person gets a warning message and cannot log on until the first person logs off. Please be aware and do not to press the reset button on these computers in case someone is logged on remotely.

Imager Printer

modified: Nov 5, 2008

• Canceling Print Jobs: User X can cancel user Y's print job by running lprm on the cascade server. This command removes the first job in the print queue.

Dept Account/Email Expiration

modified: Sep 27, 2010

• No official departmental policy exists for account and email expiration. Departmental accounts tend to be deleted a few months after a person graduates. However, faculty may request to keep an account alive with guest status and a reduced quota. Every six months or so, faculty is asked whether or not the account should be kept alive. This is the current solution to keeping accounts and email addresses active for graduated students. A separation of account and email address (currently they are linked) is being worked on by the computing committee.

Imager Account Expiration

modified: Oct 4 2007

• There are 3 things associated with a person: the account, the home directory, and the imager filespace in /imager/people/. When a person's account expires, this procedure applies only to the person's imager filespace. Tech staff will have a semi-automatic way of deleting/archiving a user's imager filespace according to the user's type. When accounts are first created, they are assigned an expiration date. When the expiration date is reached, the supervisor receives a notification email requesting confirmation for account archival/deletion. After supervisor confirmation, the account will expire. The files will be chown'd to the supervisor in a "purgatory" archive for 12 months before they are permanently deleted. While students should make sure their important files are archived in the right place before they leave, this policy is meant to handle the reality that this does not always occur. The time period of 12 months was chosen since many paper deadlines are annual conferences, so it's likely that the need to hunt down files would happen within the year window. This policy covers both undergraduate interns and MSc students.
• Visitors/postdocs and PhD student accounts will never be automatically deleted. Yearly reminders of active visitor accounts will be sent to supervisors, since most collaborations continue for many years. When a supervisor decides that a visitor account is no longer required and should be deleted, they should to be archived with the same 12-month purgatory process as above. After PhD students graduate, accounts should stay active, although pressure to reduce disk usage can be applied (preferably by the supervisor). Rationale: PhD students spend a significant portion of their life here, and their email is listed as contact on (hopefully many) papers. In many cases they continue to collaborate with their former supervisor or fellow students.

Hardware Purchase Procedure

modified: Oct 18, 2007

• When purchasing new hardware, email Ming Lau, Glen Lee, and Ciaran Llachlan Leavitt with the specifications (mlau,glee,llachlan).
• When ordering a new machine, only provide Ming with the specs that you really care about, and tech staff will fill in the rest with compatible parts.

Machine Installation (or Reinstallation) Process

modified: Jan 26, 2009

• When a new machine name is chosen, Glen will add machine to appropriate groups (i.e. imager linux group).
• Hardware staff will leave a note on the machine to let user know that tech staff still needs to complete the setup (nVidia drivers, screen resolution).
• The process that tech staff should follow for new machine installation includes the following.
  • Check screen resolution to see if it works.
  • Check that nVidia drivers are installed for nVidia cards.
  • Test glxgears to make sure graphics card works.

Finding a Machine

modified: Feb 8, 2010

• Use the command 'qbox' with machine name to find port and location of machine.

Sudo Access Policy and Joint Admin Model

modified: Oct 4, 2007

• The Joint Admin Model exists for Imager machines so that representatives have admin privileges as well as the tech staff.
• Sudo access is given to the Imager representatives for Linux, Windows, and Macs. This is currently Tibi for Linux and Christopher for Windows and Macs.
• Sudo access should only be used in urgent situations after hours when help desk is not available. Help desk must be used whenever possible.
• When sudo access is used, email help desk notifying them of what was done on the machine.
• Tech staff will keep track of sudo accesses and will report un-emailed incidents.

Update Policy and Conference Freezes

modified: Feb 28, 2013

• Update policy applies to Imager Linux and Windows computers (including computers in subnet 54).

• The calendar on the Conference Freeze Dates page will list the freeze periods and the machines to be frozen during each period. If you would like your machine to be frozen for an upcoming conference please add your machine name, the machine's operating system, contact name, supervisor, the conference, and the conference deadline to the calendar. Imager Tech members will look at this page monthly to decide upon freeze periods. Once the freeze period has been determined, Imager Tech will notified Tech Staff. The page will also list conferences for which machines do not need to be frozen, and these conferences will be indicated as "no freeze". Tech staff will check the calendar for freeze periods and will not update the listed machines until the freeze period is over. No unnecessary updates (including security updates) will occur on listed machines during their freeze periods. At the end of the freeze period, the machines on the list will be patched and rebooted again. Then the machine returns to the normal patching/updating schedule as per CS System Maintenace Policy (see link below).
• In order to synchronize the machines and leave them in a known state before becoming frozen, a last update and reboot is performed just before the freeze period starts. Tech Staff will send a notification email with the machine names on the freeze list and the date and time that those machines will be updated then rebooted.
• Vulnerability patching: During the freeze period, if there is a vulnerability that requires an upgrade/update, there are 2 options:
  • Tech Staff will contact the users of the machines and coordinate the patching process. The severity of the patches will determine the period of time from first contact and the actual patching.
  • block non-CS access to host.