Details
Category: FAQ
Hits: 77008
Printing Service
Written by Scott Ostrander   
Thursday, 02 February 2006 08:54

The School of Computing uses a Common Unix Printing System (CUPS) server to manage printing, using the Internet Printing Protocol (IPP). CUPS provides both lpr and lp style client commands under Unix.  Printers are only accessible from within the department's network.  If you wish to use the SoC printers from outside the school's firewall, you will need to use the VPN system to establish a link into the school network first.

The main public printer is csps for single sided printing, and csduplex for double sided. The printer is located in MEB 3153.

Various research groups, labs and grad student areas have printers available for their use. You can get a list of printers and other information using the printer web page or the lpstat command:

lpstat -t


Ignore the bogus date fields. The lpstat man page explains more options. Various printer options, defaults and such can be set using the lpoptions command. For example, to make grduplex your default printer, you would run the command:

lpoptions -d grduplex


With a default destination printer set, you can just do "lpr filename" instead of "lpr -Pgrduplex filename"

Documentation for the CUPS system is available via the web.

Windows

On systems running Windows, the printers are available through cups using the form

http://printspool.cs.utah.edu/printers/name_of_printer_here

You may need someone with admin privleges to add the printer and share it before regular users can make use of it.

Macintosh

On Macintosh systems, open the Print & Fax preference pane.  In the dialog set the protocol to "IPP" and in the Address (Printer on older Macs) field enter:

printspool.cs.utah.edu

In the Queue (Spool on older Macs) field enter:

printers/name_of_printer_here

In the Name field, you can name this printer entry to anything you'd like.

Configuring a Self Administrated UNIX System Using CUPS

There are two quick methods to allow a UNIX system within the SoC network to access the CUPS server.  If you wish to make the change globally for all users of the system, edit the/etc/cups/client.conf file and add the line:

ServerName printspool.cs.utah.edu

If you only wish to make the change for your user account on a UNIX system, simply set the $CUPS_SERVER environment variable to "printspool.cs.utah.edu".

Cups documentation.

Printer Status
       [ Only available from machines within School of Computing ] 

If you have troubles with printing, first make sure it isn't something obvious like the printer out of paper, jammed, offline or the network cable unplugged. If there is a non-obvious problem, send a message describing the trouble in detail to .

Details
Category: FAQ
Hits: 789536
ntp.conf
 Network Time Protocol Example Configuration
Written by Scott Ostrander   
Thursday, 02 February 2006 08:47 
## University of Utah, School of Computing
##
## ntp.conf-  xntpd configuration file
##
## Written by: Chad Lake  12/8/97
##
## Updates: 
##

## This means that this host will get it's time
## information from these servers:
server timemaster.cs.utah.edu

## this is the driftfile
driftfile = /etc/ntp.drift

Details
Category: FAQ
Hits: 74174
Door Lock/Room Access FAQ
Written by Todd Green   
Thursday, 13 December 2007 05:03

The School of Computing Facility manages its own door lock system for doors internal to the SoC.

  

To see the list of doors and request access, please use the online form.

 

All other doors are managed by other entities and you'll have to contact them for access.  This includes the doors to the buildings themselves (see the front desk in MEB 3190) and the labs in EMCB (please contact the CADE via ).

Details
Category: FAQ
Hits: 73412
Miscellaneous
Written by Scott Ostrander   
Thursday, 02 February 2006 08:27

Miscellaneous Frequently Asked Questions

  • I sent email to support@cs for help with the Visual Supercomputing Center, but no one helped me.

The VSC is not managed by the CS department facility staff. Please email  , and they'll be more than happy to take care of your needs.

 

  • I tried to FTP with my facility username to ftp.cs.utah.edu, but it doesn't work. What gives?!?

ftp.cs.utah.edu is for anonymous FTP only. To use authenticated FTP, please use authftp.cs.utah.edu. The system is set up this way for security reasons. Note that this is only available from internal networks. Please see the SCP/SFTP FAQ for details on how to transfer files through the firewall.

 

 

  • After I log in to a Unix box, I can't run programs like pine, emacs or anything else I need. What is going on?

You probably don't have the directories containing common programs. In addition to standard system directories, like /bin, and /usr/bin, you probably want /uusoc/opt/bin in your $PATH variable.

If you are using csh or tcsh, you can set the path as follows:

set path = ( $path )

Bourne or ksh users can set the path via:

PATH=$path: ; export PATH

If you want to make the changes permanent, modify your .cshrc for csh or tcsh or your .profile for Bourne or ksh.

 

  • I have a question regarding a class I'm taking, whom should I mail?

You should email your professor or your TA(s). You should not email support. We are not necessarily familiar with the software and/or lessons being used in the class.

 

  • Why do I get a permission denied error when trying to delete a file via Unix when all the permissions are set correctly?

The reason that this happens is due to our netapp boxes supporting both the Windows and Unix worlds. If a you have a file 'FOO' open under Windows and you try to delete 'FOO' under Unix you will get a permission denied message. This is because the Netapp box sees that another program under Windows is using the file 'FOO' and will stop you from deleting it. If you really want to delete the file shut down any Windows apps that are using the file 'FOO' and then delete 'FOO'.

 

  • How do I get support for the scanner/copier in MEB 3401 ?

    The Imagistics DL850 was purchased by the front office with an outside support contract and we have no special access to it.  For any issues please contact the front office for assistance.

 

  • My question isn't covered here, is there anywhere else I can go?

Yes, we have more detailed FAQs covering each service we offer (some are still being written and/or updated.) Please go to the main support page and look under the FAQ heading. If your question isn't answered there, feel free to email us.

Details
Category: FAQ
Hits: 74755
Passwords
Written by Scott Ostrander   
Friday, 21 January 2011 13:52

Frequently Asked Questions About Passwords

  • How do I change my password(s)?
To update your NIS/LDAP password, log onto shell.cs.utah.edu, and run:
yppasswd
This will change your password across all the *nix machines in the department.  Note that some systems run caching daemons and it may take upwards of 10 minutes for the old password to expire from the cache.
To change your Active Directory password log onto shell.cs.utah.edu and run:
smbpasswd -r gomorrah.cs.utah.edu
We regularly run our password database against various password crackers.  If your password is vulnerable, your account will be locked without warning. 
  • What if I've forgotten or need to reset my password?
There is a web front end with options for NIS/*nix (shell.cs, Linux systems, email, web, etc.) and Active Directory (Windows, VPN) that let you sync your local passwords to your uNID's password.
  • How do I pick a secure password?
A good strategy it to pick a phrase that you can remember and then use the first letter of each word in the phrase.  Modify it with uppercase, numbers, and symbols. e.g.
all good dogs go to heaven
Could become: 
Agdg2h!*
Make sure your password (for NIS) is 8 chars in length.  Anything longer gets truncated. Do not pick a proper noun or a word from any language! Even permutations of words will most likely be caught by the password cracker.
You may also test your password at the PasswordMeter orYetAnotherPasswordMeter. These are just two of many.  Google for others.
  • How do I to test my own password to see if it is crackable?
John the Ripper is Open Source software.  You can run it against this word list: /uusoc/facility/contrib/tag/john/8chr.lst.  You may get your passwd via the getent command on shell.cs.utah.edu.

Do not email support to ask for your current password.  It is encrypted and we cannot decipher it for you.  Never respond to an email that asks for your password.  It is a phishing scam.  We'll never ask for your password.

Details
Category: FAQ
Hits: 72817
Host Self-Administration Guide
Written by Todd Green   
Monday, 05 November 2007 00:42

This page addresses common questions about self-administering machines at the University of Utah School of Computing. Suggestions for additions and modifications to this page are welcome through e-mail to: .

Host Self-Administration Guide

  • Who is this information for?

It is for SoC faculty, staff, and students who administer, or are considering administering, a machine that is connected to the SoC network. This machine may be one that is owned by the SoC or it may be a personal laptop (personally owned desktop machines are not permitted to connect to the SoC network).

 

It is likely that the only undergraduate students affected by this information are those who are actively involved with a research group.

 

Not affected by this information are users of machines administered by the SoC support staff and users of machines that are connected to the Flux, SCI, CoE, campus, or any other network.

  • What is a self-administered ("self-admin") machine?

This is a machine connected to the SoC network whose system administrator is anyone other than the SoC support staff. The administrator of such a machine is personally responsible for its behavior. Informally, if you have root on a machine, or administrator access to a machine running Windows, then it is self-admin and you are the administrator. The OS and OS version that the machine runs is not relevant.

  • What is the advantage of connecting a machine to the SoC network?

For most SoC faculty, staff, and students who work for a research group, this is the preferred way to connect to the Internet while you are in MEB/WEB. Also, you get access to SoC services that are not available from outside our firewall.

Note that an alternate way to put a machine inside the SoC firewall is to use the SoC's VPN. Or to put that a different way, there is little effective difference between a laptop in MEB that is connected to the SoC network and a laptop in MEB (or anywhere else in the world) that is connected to the Internet in any fashion, and that is connected to the SoC VPN.

  • Can I get root on a machine that is administered by the facility?

No. If you must have root access then self-administration is your only option. 

Please keep in mind that being root is a very blunt tool and it may not be the best solution to whatever problems you are having. Self-administration requires substantial expertise and time.

Furthermore, many problems that initially seem to require root access do not actually require root access. We are happy to discuss various options with you.

  • How do I request to self-administer a machine?

Just fill out this online request form.

  • How do I find out my MAC address?

On a Windows host you can bring up a cmd window and run 'getmac /v'. On a *nix based host you can run 'ifconfig -a' (on some platforms you need to be root to do this). Many machines have multiple interfaces (wireless, wired, VPN, VMWare, etc.) so please be sure to report the MAC address for the interface you intend to use.

  • What are the DNS servers?

If your ip address ends in an even number use 155.98.64.70, then 155.98.64.71. Otherwise list .71 first. 155.101.115.10 may be used as a tertiary server. 

 

  • I have inherited a machine from a student or a staff member or a professor. Is it self-admin? If so, what are the implications?

When you start using a machine, it is critical that you figure out if it is self-admin or not. If you are not absolutely sure of the machine's status, contact the support staff at . If you cannot login using your SoC userid and password, then the machine is either self-admin or broken.

 


If it turns out you have inherited a self-admin machine, you have three main options:

  1. Let the support staff reinstall the OS at which point the machine is no longer self-admin (see the question about this below).
  2. Keep the machine as self-admin, but reinstall its OS yourself.
  3. Keep the machine as self-admin, running its current OS build.

Although option 3 is initially the easiest, it can lead to major problems in the long run if the machine contains customizations that you are not aware of or do not fully understand. Regardless, this machine is now 100% your responsibility and any problems with it are your problems.

  • Where can I obtain media for installing the operating system or other software on my self-admin machine? 
For Microsoft based machines, people affiliated with the SoC have access to a vast array of software including several versions of the OS through our MSDNAA service. Please see our MSDNAA FAQ for more information.  If there is additional software that you would like to install, that is your prerogative and responsibility. We suggest that you check with the Office of Software Licensing or the University Bookstore before making a purchase, as you can sometimes save money by purchasing through the University.
For Linux, software is freely available on the Internet for whatever distribution you might be interested in.  Please note that we do keep a local mirror of several of the more popular Linux distributions, which will greatly speed up your installation.  Please see our Site Mirroring page for more details. 
  • What are my responsibilities as a system administrator?

For every machine that you administer, you must:

    • Install the OS
    • Keep the system up to date by installing patches in a timely fashion
    • Keep software that you compile yourself up to date
    • Turn off network services that you do not require
    • Configure the machine to use any SoC network services that you want (see links below)
    • Install any application software you wish to run
    • Perform any backups that you feel are necessary
    • Deal with the aftermath (e.g. by reinstalling the OS) if your machine becomes compromised
    • Let us know if the machine moves, changes MAC or IP address, changes host name, or leaves the SoC
    • Let us know if the administrator for the machine changes
    • Abide by the University's Policies And Procedures Manual, in particular not using University resources for commercial gain, not releasing sensitive or copyrighted information, etc.
  • What will happen if my machine is hacked?

The immediate consequence is that your network port will be turned off and filtering rules specific to your machine may be entered into the SoC firewall. These measures are necessary to protect the rest of the users of the SoC network. To get these reversed, talk to the SoC support staff and convince them that you have fixed the problem and that you can prevent it from happening again.

If your machines represent a persistent security hazard to the SoC network (i.e. they keep getting hacked) or if some significant abuse of the SoC computing policy occurs, then machines that you administer will permanently lose access to the SoC network.

  • If my network port gets turned off and I have a hub or switch connected to that port, will all machines connected to the port be cut off from the network?

Yes -- this is unavoidable. For this reason we recommend that multiple users (e.g. in student labs) avoid sharing a single network tap if any of the connected machines are self-admin.

 

  • What services are available to a self-admin machine?

 

Basically any SoC service that can be authenticated on a per-user basis is available to self-admin machines. The major service that cannot be authenticated per-user is NFS. Available services include

  • Network connectivity
  • Printing
  • E-mail via SMTP and IMAP
  • Shell access to interactive servers
  • CIFS (i.e. to mount filesystems via smbmount)

 

  • What services are absolutely not available to self-admin machines?

 

  • NFS
  • Backups performed by the SoC support staff
  • Rebooting, restarting, tweaking, tuning, debugging, or any other
  • Hands-on management by the facility

 

  • Why won't the SoC support staff help me out by taking over [complicated or boring or time-critital] system administration tasks on my self-admin box?

 

The facility is designed so that most users do not need to be system administrators. If you choose to live outside of this structure by becoming your own system administrator, then you are largely on your own. A middle ground -- sharing administration tasks between users and the support staff -- has been found to work poorly in practice.

 

  • Can my self-admin machine be a server?

 

Probably -- send an email request to  with the port(s)/protocol(s) you need unblocked. Not all services are allowed on our network (e.g. we will not give remote access to MySQL nor SMTP).

 

  • How can I learn more about system administration?

 

A copy of the Linux Administration Handbook may be checked out from the front office.

The web is also a great resource for both *nix and Windows administration. These are two of the many sites available for Windows administration:

  • What are my options if I decide that I no longer want to administer a self-admin machine?

 

The SoC support staff is happy to take over a machine again, provided that it belongs to the SoC in the first place. We will install a new OS image (Windows or Linux) on the machine. After this, the machine will no longer be a self-admin machine. In general, data cannot be preserved across this transition, it must be backed up somewhere else until the reinstallation is complete.

Details
Category: FAQ
Hits: 72279
WEB Overview
Written by Scott Ostrander   
Friday, 03 February 2006 05:58

A Guide to the WEB 124 and 130 Instructional Labs

Who to Contact if You Need Help

The "Opers"

Though the WEB 124 and 130 labs are part of the School of Computing, the CADE handles all day to day operations of the labs. During regular hours, you can find help in WEB 130 from the consultants or "opers" manning the lab. Simply approach them on the lab floor or in the office area and request aid. The lab consultants have all the tools needed to keep the machines running properly.

Note: Though the lab consultants may have the technical skill to help you with your course work, this is not their job and they are under no obligation at all to aid you with your course work. If you are having trouble with programming problems during the course of your lab work, contact your TA.

E-Mail assistance through 

If you are working on a machine outside of the lab, or you are working in the lab outside the normal staffed hours, or simply cannot find a consultant in the lab, send your problem via e-mail to . Be sure to include your E-Mail address if mailing from a Web browser.

Your problem will be dealt with as quickly as possible. Should you need to refer to the problem again, please refer using the ticket number you've received.

WEB Instructional Lab Policy

Mission:

The WEB 124 and 130 Instructional Labs are designed to provide a computing framework for students, staff and faculty engaged in study at the School of Computing.

Hours:

The WEB instructional labs are open 24/7 unless otherwise noted.

Resources:

The WEB 124 and 130 labs are equipped with network enabled PC's running Microsoft Windows XP Professional (SP2). The WEB 130 lab also has a user available HP 9150 laser printer, named "ugps".

The installed software on the machines varies from semester to semester and is set by the faculty at the School of Computing. If you feel there is a program that is necessary for your work, please filter the request through your TA.

 

Acceptable Use Policy:

 

    • Class work has priority over all other activities. Playing of computer games is never allowed.
    • Your account is for your use only. Do not log other people onto computers using your account.
    • The EMCB instructional labs are quiet areas for study purposes and any use of the PC's producing audio (such as WinAmp) requires a compatible set of headphones.
    • No food or drink is allowed in any School of Computing lab.
    • Use of these machines for mail forging/spamming or harassment of another as well as any illegal purpose (such as unauthorized access of another system/data) is forbidden.
    • Do not lock a lab machine for longer than 10 minutes. The consultants may log you off at any time after 10 minutes. This can cause loss of data!
    • All user files are to be stored on the users "U:" drive. (Files stored on the Windows Desktop or in "My Documents" are located within your U: drive already, under .CS_WIndows.) Your UNIX home directory is the same filespace as the Windows U: drive. Do not store files on the local hard drive. Any and all files on the local drive of any machine may be DELETED without notice.
    • Users are not to install or remove ANY software on these PC's.
    • Print jobs should be limited to 20 pages; no more than 2 copies per print job.
    • EMCB lab facilities and software, as well as this policy may be changed to accommodate future need by departmental staff at any time.

Violations of this policy will result in loss of facility computing privileges!

 


Using the WEB Labs for SoC class accounts


One consequence of the reduction in SoC computing services is that all class accounts will be handled by the CADE. For most instructors, this has two effects: (1) on-line turning in of class assignments; and (2) establishing accounts for students.

On-line turning in of class assignments

The process in the CADE is similar to the submit facility used within the SoC. 
  • All SoC instructors using the CADE for class support will need an account on the CADE systems. If you do not already have an account or you have an account but have forgotten your password, send email to .
  • While the CADE has a centralized file server, it has no server machines comparable to the SoC trust/antitrust/... To log in to a CADE machine, you need to log in to some individual desktop machine. Hostnames follow the pattern labM-N.eng.utah.edu, where M is the lab number (1-4) and N is the machine number (1-48 for lab1, 1-44 for lab2, 1-25 for lab3, and 1-15 for lab4). While the CADE recomments conntecting to a load-balancing server in order to access the machine which is currently most lightly loaded, this causes problems due to issues with public key encryption. You can avoid the problem by logging in to a specific machine, but then you have no idea in advance of the load or number of other users. Thelab1 and lab4 machines run Linux while the lab2 and lab3 machines run SunOS. Thelab1 and lab4 machines are relatively new dual core boxes and likely to give the best performance.
  • Each class supported by the CADE has an associated user. The user name is csxxxx, where not surprisingly xxxx is the class number. Class related files are kept in the home directory of the class account: ~csxxxx. You will need to establish an account for your class if one does not already exist. You will also need to make sure that your own CADE account has the class group associated with it and that you are the group owner. Once you own the group, you can use the groupmodify command to add your TAs to the group. Send email to requesting establishment of the class user account and class group.
  • Students turn in assignments using the handin program, which is very similar to the SoC submit program. The class directory needs to contain a directory with the name handin, owned by the class account, in the class group, read/write/search for owner and group, and no access otherwise. The handin directory contains subdirectories for each assignment, plus two files: logfile and users.deny. Both of these files need to be in the class group, read/write for owner and group, and no access otherwise. Because of the need for the class account to own these files, you may need to request that the be set up by sending email to . More information on the CADE handin system can be found by typing the following while logged in to a CADE machine:
man handin
man rcvhandin
  • scp -r ... can be used to copy handin subdirectories from the CADE to the CS system, which is usually easiest for grading.

Example of how to establish a CADE handin account

To enable handin, cd to the class handin dir, e.g.,:

% cd ~csxxxx/handin

You can increase the chances that all files created in this directory will be in the correct group by insuring that the setgid bit is on for group:

% chmod g+s ~csxxxx/handin

Make sure an empty file named users.deny exists:

% touch users.deny
% chmod ug=rw,o= users.deny

This file tells the handin program who not to allow to handin files. Since it will be empty, there will be no restrictions on who can submit material. 

Now create a directory for each assignment and again copy the users.deny file into the new directory:

% mkdir Assignment1
% chmod ug=rwx,o= Assignment1
% cp users.deny Assignment1
% chmod ug+rw Assignment1/users.deny

You can also create a .comment file in the assignment directory. The contents of this file will be shown when the student types:

% handin csxxxx

with no additional arguments.

Make sure you test that all is working by trying to handin something yourself!!!

Establishing CADE accounts for students

At the start of every semester, the CADE will obtain a list of students registered in each class having a CADE class account. Accounts will be created for anyone on that list who does not already have an account. A hard copy listing of real-name/user-name/password can get picked up from one of the CADE operators a few days before the start of each semester. This list is designed to be cut up and handed out to the individual students. Any student that is officially registered but does not have an existing CADE account and is not on the CADE-provided list will need to see one of the CADE operators in EMCB. For upper division undergraduate CS classes, most/all registered students will alreay have CADE accounts.

Turning in files using handin in the CADE

To electronically submit files while logged in to a CADE machine, use:

% handin csxxxx assignment_name file_1 file_2 ...

where csxxxx is the name of the class account, and assignment_name is the name of the appropriate subdirectory in the handin directory.

The CADE also provides a web-based facility for turning in files electronically: <https://cgi.eng.utah.edu/webhandin/index.cgi>
  1. WWW Services Guide

Subcategories

Email Services

Miscellaneous