ST Knowledge Base

The computing environment used in a typical office. We include laptops here as the idea is the same; where one does one's typical "office" work. It also includes equipment for the home office. In practice, it's workstations, displays, and sometimes printers and UPSes.

Faculty members are expected to purchase their own equipment. Support subscriptions can be purchased from CSCF, who will then help with any technology selection, purchase, installation and maintenance related to their research interests. The result is often heavily customized.

For admin staff, a workstation (almost always a Mac) is provided. A UPS, and possibly a printer, is supplied as well. There isn't too much variation, although in some cases administrative access is allowed.

For others, a "thin client" (a.k.a. Nettop) is provided, for connection to the CS "general" computing environment.

The standard workstation environment supplied to graduate students, that are supported by the research support group, starts off as a standard (powerful, dual-boot) workstation, or a laptop, or an iMac, which they can then customize any way they like. We spend a non-trivial amount of time providing and updating these systems.

We have one room (DC3335) for the course master's programs. It currently provides Mac workstations. We include this as a separate service because of its visibility, and its being a distinctively different approach to providing a "desktop" computing environment.

There is a wide variety of specialized computing environments, typically used by research groups that subscribe to CSCF support. The activities involved with supporting them include all aspects of computing support, for technically unconstrained systems. They aren't further subcategorized to avoid this list becoming too large. For researchers, each Subscription Code can imply a completely different set of needs. There is no simple description for this.

We provide a general purpose computing environment, often called the "cs-general" environment, usable by all SCS people with the exception of undergraduate students. It is deliberately distinct from the SCS teaching environment, to address concerns such as load, software licensing, and security.

The environment provides database systems for various administrative and infrastructure data. That includes student registration data used in planning courses.

Central to the environment is an increasingly redundant file server, used by SCS servers and workstations.

There is an email service that implements the @cs.uwaterloo.ca address. While we're engaged in the long term project of moving personal email from here to the IST provided service, it could be a very long time before it can be eliminated (if ever). E.g.

• a history from the dawn of email of @cs.uwaterloo.ca email addresses, present not only on campus, but across the world.
• a few faculty who insist that their email and the rest of their data belong together.
• software systems that send email for logging purposes, which is then processed by log analysis software.

We're also expected to maintain a variety of mailing lists, which for lists with computed contents is mostly easily done with the current system.

There are printer rooms scattered about the DC that are driven by print servers, providing spooling, access control, and accounting.

The Linux (currently Ubuntu) servers provide casual computing resources. This isn't intended for resource intensive computing, that being done on research machines. It's an absolute requirement for those using "thin clients".

A "Windows Terminal Server" is provided for casual access to a Windows environment. Aside from providing a general use environment, it has proven necessary when use of external systems require a Microsoft Windows environment to function properly.

There is a WWW service which provides access to/for:

• around 30 different WWW sites, many for research groups
• personal WWW pages
• those SCS (typically administrative) WWW pages that have yet to move to Drupal elsewhere
• various WWW interfaces to systems and data
• a development environment

The student computing environment is varied. The variety changes with pedagogical needs.

The environment provides various general and specialized teaching labs, together with non-trivial computing resources; mostly Linux based (currently Ubuntu). The latter is an absolute requirement for those using "thin clients". In addition to computing done by students for assignments, it also provides the horsepower to run the assignment processing systems. Access to a Windows environment is provided via a "Windows Terminal Server".

We have 3 types of service in the following, all sorted together.

That part of the environment that provides technology in aid of providing, submitting and marking assignments. Markus, Marmoset, and MOSS are some current examples.

The accounts, named after courses, used by instructional staff to provide materials and services in aid of course presentation. E.g.

• course-specific software, maintained by course staff.
• course specific WWW pages.
• a course-specific mail address, although the direction is to move that to IST services.
• historical continuity.

At most, they should be used to augment, rather than replace, the use of Waterloo LEARN.

There are database system(s) provided for various courses. DB2, MySQL, and PostgreSQL are available.

Students are expected to print use the campus printing service. An interface is providing to allow these printers to appear in the print menu of the various systems.

There is an (increasingly redundant) file service used by (almost) all of the servers and workstations in the environment, as well as by remote access (off and on campus).

Multiple general access and special purpose teaching labs are supported. The general access labs can be used by all students taking CS courses, and by all Math Faculty students.

There is a Graphics Lab (in MC3007) used in teaching the graphics course. It's mostly good workstations with instructor specified graphics cards. Physical Access is restricted.

There are multiple rooms of MacOS workstations. These are fundamental to the delivery of lower year courses. As such, there is a double lab with audio and dual projection systems for use by instructors.

A few courses (e.g. CS349 and CS446) use mobile devices, such as tablets (e.g. iPads), smart phones, and smart watches. This is can be thought of as a virtual lab. CSCF does the buying, which takes longer that expected, as stores tend to rate limit purchases. The Library handles the loaning of the devices to students.

There is a networks lab (MC3007a), containing workstations and networking equipment. It is suitably isolated from the campus network, allowing only `ssh` access for instructors. Physical Access is restricted.

The (MC3018) lab for the real-time course. It traditionally contains remote controlled trains, and the hardware needed to drive them, although it's not always been limited to that. It also contains lightweight workstations ("Nettops"), and power for laptops. Physical Access is restricted.

SCS is responsible for support of the environment needed for the teaching side of the Software Engineering program. There is a Software Engineering lab (in DC2577), with a small number of Linux workstations. Physical Access is restricted.

There are multiple rooms of "thin clients" providing access to the student Unix and Windows servers. They have evolved into very lightweight workstations (a.k.a. Nettops), that satisfy all of the criteria for thin clients; especially suited to the lab environment. They are used mostly for upper year courses.

There is a remnant of the @student.cs mail service. The primary remaining use of it is "course account" mail.

There are podiums in many undergraduate lecture rooms across campus. They run Windows with Nexus. We provide a Nexus accessible fileserver (smb-nexus.student.cs) so that CS instructors can access their cs-teaching filespace.

Seashell is a WWW based interface to the Unix CPU servers. It's used for lower year courses, avoiding the need to login directly.

CSCF provides workstations for the MC4065 CS student tutorial centre.

The environment has multiple server class Linux (Ubuntu) systems, used directly for assignments, and indirectly via assignment processing systems.

There is a set of (currently 28) machines that can be used to form a cluster, or run whatever specialty OS instructors need. Configuration changes from term to term. Specific courses may have a subset of the machines allocated to them.

There is a Windows Terminal Server (windows.student.cs) that provides casual access to a Windows environment. It isn't a course resource requirement.

The student WWW service provides access to/for:

• course specific WWW pages
• personal student WWW pages
• a development environment for instructors and students
• course specific software (currently MediaWiki)
• assignment handling systems (currently Markus, Marmoset, MOSS)
• tools specific to the environment (e.g. for password resetting)

We provide technical support for teaching that doesn't involve any specific student computing environment. Much of this is for CS "Undergraduate Operations". It often involves student data and data regarding instructors, and the related databases and WWW interfaces.

We have worked on software that provides reports based upon student course evaluation data. Some of this has moved into the Science "Evaluate" system.

We develop and maintain an "Exam Seating" system, used both by CS and others:

• Arts - AFM (almost all exams)
• Science - Chemistry
• Engineering - ECE, CHE
• Math - MATH, STAT
• Extended Learning - all PAC examinations

We have a small pool of laptops for loan to instructors, on a per-term basis, intended to augment the systems in the podiums in campus lecture rooms.

CSCF provides the database aspect of "OAT" (Online Academic Tools) and the needed servers for the rest of the system. Application development for it is done by CS, although not by CSCF.

There have been times when we've had to support technology for the creation of online courses. Adobe Connect is an example, as is classroom setup for online course creation.

There are various expectations that aren't specific to the major identifiable computing environments. They aren't so visible that a top-level category would be appropriate.

Backups are generally considered to be an implementation detail, as part of a reliable computing environment. However we have clients who provide their own computing resources, and expect us to provide backups as a distinct service. In practice that's CS research groups.

CSCF does backups of many workstations, for both faculty and staff.

CSCF also does backups of parts of the Math teaching environment.

Some of the documentation CSCF provides involves technology in its production, typically involving a database of some kind.

We support the database system used by the CS Graduate Office to record graduate student data. Support is currently limited to the server, as opposed to the use of Filemaker.

At times we have to support services provided by others. The most common example is supporting the use of IST services. We

• support the client side of IST services that CS is required to use, as IST expects some degree of that,
• diagnose, report, and when practical compensate for local problems with IST services,
• and augment IST services where appropriate.

The typical example is assisting someone dealing with IST's email service.

We are directed to stop providing an email service to the extent possible. As a result all admin staff, all students, and most faculty and grads use an external service (often IST's). In practice, the additional work this requires is in maintaining local mailing lists using the IST provided mailing list service (@lists.uwaterloo.ca), and moving mailboxes (shared and personal) to either Connect or mailservices.uwaterloo.ca, dealing with different filtering mechanisms that can't always do what's needed. As of 2015, we have yet to resolve the problem of an existing course account system that relies upon direct mailbox access.

Much of CS (access controlled) administrative documentation is present on the campus Sharepoint system. CSCF provides basic advice, and updates permissions as needed.

CSCF provides a system in aid of faculty recruiting for the CS SACA committee. This started as a result of participating in the Management Sciences OFAS project some time ago.

The CS graduate admissions system exists to augment the central GAP (Graduate Admissions Project) system. It is sometimes referred to as OGSAS or GrAd.

We provide assistance in support of producing grant proposals. It includes sourcing, estimating, planning, ...

There have been self-serve Kiosks that provided information about CS to the public. We expect that this may include digital signs. The number varies, depending upon staff time to keep them functional. As of 2014-06 there is a small slide show on a monitor.

Machine rooms are generally an implementation detail for the computing environments we provide. However for researchers, they are an expectation. Some research equipment resides in CSCF machine rooms, some resides in researcher machine rooms. In either case, CSCF is involved in the support.

CSCF provided WWW support to MFCF. This category exists only for historical reasons, as the agreement ended some time ago.

We rely upon IST to provide networking. However, when clients perceive a problem as networking, or need help with machine room networking design, we may be involved. It applies to both wired and wireless. This isn't often needed, mostly for problems with wireless. For typical office network connections or problems, the service is "Desktop Computing", networking being one of several components of that service.

We are expected to provide initial handling of login problems involving the campus Nexus Active Directory, for CS clients. We also must support a Nexus compatible student fileserver (smb-nexus.student.cs).

CSCF has participated in the OFIS project. This category exists only for historical reasons, as there is no direct involvement now.

CSCF supports some of the printers in the shared printing rooms. More of the printers are being provided by Retail Services. Printers in private staff and faculty offices are in the "Desktop Computing" category above. This can include auxiliary functions of printers, typically scanning. The work for this is generally client side and server side configuration to use the printers.

CSCF supports the (apparently ongoing) renovation of SCS space, typically machine rooms, research labs, and presentation rooms. This often involves providing detailed diagrams of the space involved. This isn't considered as the Service when the space is specific to CSCF. This is also an implementation detail (Component).

CSCF provides computing resources and/or support in presentation/meeting rooms (i.e. in addition to the teaching labs). This usually involves dealing with workstations and/or projection systems, and assistance with network and projector connections for laptops. This doesn't include classrooms in the student computing labs, which is considered part of the teaching lab services.

Various forms of support is provided for "special events", such as the IOI, CCC, ESQ, Computer Science High School Liaison events, ...

Anything involving accounts creation/deletion software. This is usually the "accounts" package, but doesn't have to be. It can also involve creation/deletion/manipulation of accounts, and default accounts setup. Whether there should be a separate category for the latter is unclear.

Technology involving the creation, submission, and marking of assignments.

Marmoset is a specific non-trivial technology being used for assignment submission and marking.

Markus is a specific non-trivial technology being used for marking assignments.

Technology involved in authentication. It can range from simple password files to Kerberos.

The authorization part of a service. Can be a technology, or changes to authorization data.

General backup technologies.

The Legato Networker that we use for most backups.

Research support is in part funded by faculty subscribers. This is about the non-trivial time required to prepare and process the necessary bills.

As in "Computer Aided Design" or "Computer Aided Drafting". It's often done with AutoCAD, however not always. It's used for planning new facilities and documenting existing facilities.

A visual understanding of what's connected to what can be useful.

CAD is very handy when planning room creation/changes.

The physical aspects of classrooms, not otherwise categorized, e.g. chairs, desks, carpet, heating/cooling/lighting.

Any database technology.

The hardware used for desktop computing. See "Software" for the related software.

Mostly about displays, although it can include keyboards, mice, basic KVM's, and speakers.

Laptops, as opposed to workstations.

Anything about "thin client" technology.

About workstations in general. That includes the standard "grad pc". The specification of a specific OS, or just Software can help distinguish between hardware and software problems.

About directory services, which currently means Microsoft Active Directory.

There is a domain ("cs-teaching") for teaching systems, and a domain ("cs-general") for the general computing environment, various staff and grad student workstations, and for some research systems.

The campus Microsoft Active Directory used for most teaching systems (workstations) on campus, which CS being perhaps the only exception. We provide a Nexus authenticated fileserver for Nexus workstations across campus when used by CS students.

Disk drives, e.g. configuration, updates, and failures.

The provisioning of sufficient power to a device. It's usually but not always done in machine rooms.

We find ourselves asking for power outlets to be installed.

Power supplies are a common failure point in computing systems; both workstations and servers; we often do the replacements.

Uninterruptable Power Supplies.

Any external service provided needed to meet (client) expectations. Whether the client (if there is one) knows that an external provided is being used is irrelevant. Some examples are:

Using services provided by IST.

Using services provided by Plant Operations

File servers, typically it's about our Netapps, although it can be almost anything when research systems are involved.

About the significant effort required to hire, primarily co-op and temporary labour.

About identifying people. This includes the assignment of consistent ids to people, including UIDs and GIDs.

The use of WatIAM administrative access, and the use of its data to identify people.

About information related to Services and their provision.

Obtaining publications useful for work.

Training (of CSCF staff) needed to provide a service. It has a real cost in both time and money, and in practice has been known to result in work items.

Consulting as a component of a service. Think of it as interactive documentation.

Documentation as a component of a service. Think of it as static consulting.

Inventory system maintenance and development.

About the license for something, or the technology used to track/impose licensing. This includes maintenance/support contracts.

About any approach to load balancing. DBS round-robin is often used as the "poor man"s version, however it has been seen to balance the teaching environment well enough. Its biggest flaw is when a system in the round-robin is down.

Includes wiring closets (TR's), although we're largely uninvolved in those now.

Anything involved with providing access to a device console. Includes LOM, and any other form of remote access to achieve the effect of being in a machine room.

About mail, when not covered by the following:

The mail UI to read and send mail.

Software to filter and deliver mail. It includes forwarding.

About providing, maintaining, and using mailing lists. This includes both local lists, and those maintained on the campus email service.

The system software that implements the various mail related protocols (primarily IMAP and SMTP).

About the server itself, usually load/failure reports.

Some CS courses now involve a variety of mobile phones, tablets, etc. Purchase, inventory, basic configuration and repair, and arrangement with the Library for loaning to students are (so far) the typical involvement.

Monitoring technology itself, rather than the act of monitoring, which is currently /advancement/inherent/monitoring.

We spend enough time shuffling equipment around that it gets a category.

What it takes for a typical network connection. Usually that's labelling and installing patch cables, switch configuration and DNS entry creation/update.

The electrical and physical aspects of networking.

This refers to separate firewalls, not the so-called firewall on workstations.

For some specialized server arrangements, specific routes matter. There can be an overlap with "Topology" below.

About the network services needed to make a network connection work in practice, e.g. BOOTP, DHCP, DNS.

We currently run our own DHCP service, however that will eventually cease (ST #88122).

We currently run our own DNS service, however that will eventually cease (ST #88123).

This is about network switches, which is work handled mostly by IST. We occasionally have to diagnose switch problems (e.g. ST #98503). Research environments can have "hidden" networks, with their own network infrastructure, and hence switches that we have to handle.

This is largely historical, as the TR's are IST's responsibility now.

Typically diagnostic tools, e.g. a Fluke.

The includes both paths between switches, and choice of subnet/vlan. A common example is moving things to private subnets, or to specific subnets for firewalling. This work is often the result of IP address space conventions.

This usually involves reporting problems to IST.

Technologies involved in the presentation of online courses, that aren't otherwise categorized.

Adobe Connect, when used for online instruction.

Technology for clustering machines.

Technology for a "cloud"; virtualization in aid of remote provision of computing resources.

Work caused by the use of some Unix variant. That includes Linux's. Whether it should include Mac OS X is debatable.

This isn't the norm for us, although we've had to use it for SMB servers, as Ubuntu failed to handle the load.

This is historical.

This includes Ubuntu, our currently (2015) preferred Unix based OS.

This is historical, referrring to Solaris 8 and earlier.

There is one reasearch workstation that uses this. MFCF also uses it, and we provide ST to them, which has resulted in significant work, as Solaris 10 doesn't have the broad range of software, easily installed, that Ubuntu does.

This is the implementation detail for "Cloud" above. There are multiple virtualization technologies of interest. We use (as of 2015) VMWare, Linux containers, and Parallels.

This refers to an version of Windows, both server and workstation.

We provide both a cs-teaching and cs-general Windows Terminal Server environment.

Typically used in classrooms, meeting rooms, and labs.

There are projectors in teaching labs, research labs, and presentation rooms. Even in some offices. We engage in specing and buying projectors and parts. Installation is usually handle by Plant Ops. Non-trivial repair is outsourced.

The podiums found in campus classrooms. Typical problems are with logins.

This can include all of the functions of modern printers, including scanning.

About printing, when it's not as simple as being client or server specific.

This is about client side problems with printing. Device driver and configuration problems are common. As such, it overlaps with the Desktop category.

This is about print servers. I.e. that part of the printing environment that's neither the client nor the printers themselves.

About the work required to buy anything. E.g. quotes/RFP's and P-card processing can require significant time.

Equipment racks are found mostly in machine rooms and labs. We've seen them in both teaching and research labs.

This involves the renovation of SCS space, e.g. machine rooms, teaching labs, research labs. This is also a Service, as it often involves more than CSCF space.

Any aspect of security not covered by other categories. Combining this with another technology is reasonable.

Obtaining, understanding, and renewing security certificates.

Investigation and resolution of system compromises.

SSL host keys, typically used by `ssh`. Often related to distributing/updating public host keys.

Ranges from securing monitors to door locking and alarms.

The two-factor authentication service involves both servers, and the tokens used by people.

About servers, as opposed to workstations. It's usually about buying, replacing, and maintaining hardware. It can also be about server downtime when there's no other obvious category to use.

About the SMB protocol, and its provision.

About software, typically that people want installed in a computing environment.

What people think of as optional software used directly by them. This doesn't include standard windowing systems. Some examples are:

This can refers to any Microsoft Office replacement, e.g. LibreOffice.

About parts of the "system", including tools used for system maintenance. This includes standard windowing systems. If it inherently requires system privileges to work at all, then it's usually system software. Privileges to allow safely sharing among multiple users doesn't usually qualify. Some examples are:

About `ssh`, other than distributing/updating public host keys. That's "Security -- Keys".

A windowing system.

Technology used to deploy software, not the act of deployment itself.

Configuration management systems impose (computed) configuration on a set of systems.

Software deployment via complete disk images of an operating system. E.g. cs-appserv.cscf is an imaging deployment tool.

Work that's the result of our packaging software, not specifically via xhier. Software deployment by individual software packages.

About xhier itself, as well as work caused by the use of xhier rather than some other system.

About the customized `man` command that can find man pages within xhier'd packages.

This is about the organization and maintenance of multiple storage and staging areas that we use.

We spend enough time surplusing equipment that it gets a category.

Data about the teaching of students. Much of it is student registration data; we put IST supplied data into a form useful to those involved in the teaching programs. In addition, we record various data about students, e.g. grade revision forms, and teaching, e.g. teaching assignments. This applies to both undergraduate and graduate students.

About technology used to track our work. Currently that's "ST", and the RSG subscription system.

ST (a.k.a. Service Tracker), is the primary tool used to organize and report on the work of CSCF.

The CSCF research support group subscription system organizes and tracks subscriptions to the group's services.

To do with basic WWW services, not applications that happen to use a WWW interface.

While we prefer a single WWW browser, currently Firefox, as it's available on all platforms, the reality is that we have to deal with multiple versions. It's usually not a problem, however some browsers don't follow standards well, so being aware of such vagaries can be useful.

Manipulating and sometimes updating content for others. We don't expect to be doing this often, however there are times when it's more practical than available alternatives. This is often the result of requests to change the URL for something, which is best done en masse. It can also include changing a site URL. In either case, it's often the case the server configuration will change as well (to map the old URL to the new URL).

Tools for creating and editing content.

A broad area, as it includes both tools for the creation and maintenance of content (other than content editors), as well as the creation of CGI to produce content. Content management systems and related tools are included. Standard style sheets are regarded as tools (by content maintainers) as well.

Much of the CS WWW site is implemented via Drupal. As of W2015, that was using the Math Drupal server. That is expected to migrate to the campus server.

Provision of basic advice, and permission updates as needed, for the CS Sharepoint site.

A TWiki is used for various faculty pages, as well as for much of CSCF internal documentation. As of W2015, a MediaWiki is used for CS100.

Changes to the WWW server, or its configuration, if not covered by other categories. In particular, URL changes often require changes to content as well as to server configuration.