|
Computer Center News
|
Issue 5 |
July 2000 |
The
Computer Center installed a new Network Appliance F760 fileserver in CUE over
the July maintenance weekend. It replaces the previous FS1 fileserver, a
Network Appliance F540, which reached the end of vendor support. FS1 provides
the central SITE (platform-independent files, including the site’s central web
pages), APPS (platform-specific applications for NT, HP-UX, Solaris, and
Linux), and MAIL (electronic mail system inbox) filesystems to all of CUE.
Like our other
central fileservers, this new NetApp supports multiple protocols, providing
UNIX access via NFS and Windows access via CIFS, on the same filesystem. It
also provides support for user and group quotas, and the snapshot backups that
keep deleted files available online for 3 days.
This recent
purchase adds an additional 500GB to the central CUE disk areas. This allows
for upcoming growth in the home and group filesystems, which are now both
approximately 85% full, and room to grow in the site, apps, and mail filesystems which were almost 100%
full on the previous filer.
The fileserver
hosts 4 shelves of 7x36GB fibre-channel disks in a system that is connected to
3 of our primary networks – the central computing, general purpose LAN (Local
Area Network), the Trailer City LAN, and the Experimental Physics Computing
LAN.
Additionally, the
Computer Center is ordering a 500GB fileserver for central scratch space. Its
usage will be similar to the local scratch areas on each host now, but will be
available to all CUE UNIX and Windows systems. This area will NOT be backed up,
but will allow users large temporary space for short periods of time.
The
Computer Center has recently purchased a new Hewlett Packard J6000 system to
replace the aging JLABH1-4 machines. This new HP triples the performance of our
current JLABH* environment, providing > 80 SPECint of compute power. The new
system is a dual processor machine with 1GB of RAM. It will be installed during
the August timeframe.
The IFARMH* Hewlett
Packard machines are being decommissioned during the August Computer Center
maintenance period. These machines are
part of the original CHDR (Counting House Data Reduction) cluster, and no
longer play a role in the scientific computing environment.
The two C-class
workstations will continue to provide CUE services – one remaining as the
public tape server for our stackers, renamed as TAPE2. The other will be used
to upgrade CCH1, which provides font, license, and X terminal boot services.
The two older 9000/735 workstations will no longer be used.
Increasing numbers
of users have been using the central UNIX JLAB* machines to run large jobs, causing
the systems to slow down and become almost unusable for regular interactive
sessions. The central UNIX systems are provided as shared resources, and are
essential for the day-to-day computing needs of many people. Any user with a valid CUE account may login to these machines, but they
are not intended for large or long-running scientific applications. They are
intended to provide general email, login, X-windows, programming, and Internet
browser services for users who do not have their own UNIX computer. For users
with larger computing requirements, the interactive and batch farm machines
should be used.
To maintain the availability and performance of the central UNIX
systems, the Computer Center runs a process monitoring application named procmond.
Its primary function is to monitor, restrict, and when necessary kill
delinquent or excessive jobs on these systems.
It has been running on the Computer Center managed UNIX systems for
several years, but has been modified recently to reflect the increase of large
jobs being run on these systems. In the past procmond
would “nice” (reduce the priority of) jobs after a limit of CPU utilization
time was reached, but since this did not return system resources, system
performance and availability was not always improved.
As a result, new
rules for the procmond application were implemented during the June
maintenance period. The new rules for procmond
were designed to limit the system resources that can be consumed by any one
user. In particular, no job is allowed to continue to run for more than 60
minutes on these machines (or 15 minutes on JLABS1). There is additionally a one-job-per-user limit.
When procmond
determines that a job is exceeding the new rules and limits, the offending job is
killed, and the user who owns the job is notified by email:
To: username@jlab.org
From: root@jlab.org
Subject: jlabs1: process 5747 KILLED
HOST: jlabs1
DATE_TIME: 6/26/100 03:13:59
USER: username
PID: 5747
START_TIME: Jun 23
RUN_TIME: 16:00
COMMAND: /apps/netscape/PRO/netscape
http://www.jlab.org
ACTION TAKEN: Your process
was KILLED.
Your process
(/apps/netscape/PRO/netscape http://www.jlab.org) was killed because it has
exceeded the maximum time allowed per process.
The information contained in this message includes:
If you need to run
long jobs, the correct place is on either the batch farm, or for interactive
jobs the IFARM machines (IFARMS1/2,
IFARML1/2/3). Access to the batch farm
and IFARM systems is managed through the use of UNIX groups. This group
structure is also used to provide group-based accounting, and to allocate
resources between the various groups in different stages of data processing. A
UNIX group is created for each experiment at JLab. At the current time all of
the experiment groups have full access to the Farm systems.
All users involved
in the off-line processing of experimental data should verify that they are included
in the appropriate UNIX group(s) for the experiments in which they participate.
The UNIX “groups” command will show user group memberships. To join a different
group, please contact the computing coordinator for your Hall.
Further details on
the FARM and IFARM systems can be found from the Scientific Computing pages provided by
the Computer Center at http://cc.jlab.org/scicomp/.
The current Linux farm for physics
data processing is being expanded and upgraded. Much of this work is underway
and will continue for the next several months with user visible changes
starting to appear after the July 4th shutdown period. Major changes include
the addition of new farm nodes, increased network connectivity, and software
changes to the batch system. The
outcome of this work will provide more CPU power and better management of farm
resources.
50 new farm nodes are being brought
into production. These machines are rack-mounted dual 750MHz Pentium III
machines with 25GB of local scratch space per machine. This group of machines
represents an increase of over 3500 SPECint, more than doubling the farm's CPU
power and bringing the total number of Linux farm machines to 125.
The new farm nodes
will run RedHat Linux 6.2. To ease the transition from the current RedHat 5.2
machines there will be a period of running two farm queues to distinguish
between OS revisions. At first the production queue will remain RedHat 5.2 and
jobs will run on the older machines. The new machines will be installed in a
queue named redhat62. Over a period of
a few weeks we will upgrade the older farm machines, gradually increasing the
size of the RedHat 6.2 queue. Eventually it will become the default production
queue and we will drop support for RedHat 5.2 on the farm entirely.
Once the majority
of the farm nodes are running RedHat 6.2 all the IFARML machines will also be upgraded. One IFARM machine, IFARML3, currently runs
RedHat 6.2. Because of library differences it is important to compile and link
code on a machine running the same operating system release of machine where
the code will run. That is, compile on RedHat 6.2 when submitting to the
redhat62 queue and compiled for RedHat 5.2 when submitting to the current
production queue. Using static linking
where possible will also help to minimize runtime library problems between machines.
The farm’s networking
infrastructure is being renovated to provide ample bandwidth to the new farm
and cache machines. A Foundry BigIron
switch with a 256Gbit/sec backplane replaces the current Cisco 5500 switch. Multiple Gigabit ethernet connections fan
out from the central farm switch to several smaller Cisco 2900 switches
providing full duplex 100Mbit ethernet to the farm machines. Gigabit
connections to the mass storage machines (MSS1 and MSS2) and to the Linux cache
machines help keep the network from becoming a bottleneck.
Disk
StorageThe /cache storage
areas contain a changing subset of the files that are stored in the silo. Files
are added to the cache using the "jcache" command and files are
removed on a least-recently-used basis to make space for new files. The cache
areas are being expanded by the addition of several Linux-based file servers
that provide 500-800GB each of online disk storage for various cache needs,
including general use, DST cache, and farm-related caching. The cache machines
are dual processor Linux machines with gigabit ethernet and Mylex RAID
controllers. These machines will fortify the Linux and Metastor cache servers
that are already heavily used.
The mass storage
system and the farm are tightly coupled. If the mass storage system cannot
supply the farm with input files for jobs, then CPU cycles are wasted. Changes
to the farm's batch system will make sure that jobs are not started on farm
nodes until the files that the job needs are available on disk. To accomplish
this, a major rewrite of the batch queuing system is underway. A second pool of
Farm cache servers will pre-stage input files from the silo to tape and then
copy them from cache disk to local scratch disk on the farm node when the job
runs. Similarly, once the job completes, the output files will be copied to
another post-job staging area to be held on disk until they can be copied to
tape. This pre- and post-staging of farm data helps to keep the farm CPUs busy
at all times, buffering them from the queuing effects of the tape system.
Computer Center support for Windows
95/98 operating system and application issues ended June 30. In addition, user
authentication to the JLab domain from Windows 95/98 will be turned off on December
30, 2000 due to security issues. This will make central CUE print services and
file systems (HOME, SITE, APPS, GROUP - mapped on CUE PCs as network drives J:
K: L: and M:) inaccessible to Windows 95/98 systems. To continue receiving
Computer Center support, Windows 95/98 systems must be upgraded to either
Windows NT or 2000 Professional.
The
Computer Center recommends upgrading older PCs to Windows NT 4.0, due to
increased requirements for memory and disk space for Windows 2000 as well as
the current lack of many hardware drivers for the existing equipment on site.
Users should upgrade all but the very newest machines to Windows NT 4.0.
Support for Windows 2000 Professional will not be provided on older computers.
Windows 2000 Professional will be supported on newer desktop machines and
laptops that are ordered with Windows 2000, or have the Windows 2000 upgrade
certificate that came with the system as it was purchased.
The Computer Center
will purchase Windows NT and Windows 2000 licenses for the site; users who need
to upgrade to NT should complete and return to the Computer Center, the Windows
2000/Windows NT License Purchase Form, that can be downloaded from http://cc.jlab.org/support/forms/win2klicensepdf.pdf,
to transfer the license and cost. The NT licenses are $69 and do not include
documentation or media.
The
Computer Center is implementing new features in CUE that better integrate the
site’s UNIX and Windows systems. One of these features is the StarOffice
software, providing UNIX users access to Microsoft Office Word, Excel, and
PowerPoint files. The second is password synchronization between the Windows
and UNIX platforms. Users will now be able to have a single password for
(almost) all CUE systems and services.
(At present, the Netscape Calendar password cannot be integrated, but we
hope to be able to in the near future.)
The Computer Center
has installed a new office productivity suite on the Sun and Linux workstations
in CUE -- StarOffice 5.1. This office productivity suite is similar to the
Microsoft Office suite of applications and is able to read and write documents
formatted in Microsoft Office format (as well as others). If you run any version of Unix on your
workstation, you can now read .doc, .xls, and other Microsoft Office formatted
files received via your email by starting StarOffice on a Sun or Linux machine
and using it to open those files. No
longer will you need to logon to a PC in order to open and read these files.
Unfortunately, the software is not yet available on HP-UX.
In order to run
StarOffice, you must first run the initial StarOffice install program. This program creates an area on disk to hold
your personal customizations and work area. The complete installation
instructions can be found at http://cc.jlab.org/desktop/docs/staroffice_howto.html.
Once StarOffice is
installed per the instructions above, you may use StarOffice at any time by
logging in to a central Sun or any Linux box with the CUE /apps mounted and
typing soffice. This will launch the
application and display it on your local system.
Currently,
users have 2 separate passwords for central CUE services:
Effective
with the August 1 maintenance period, all CUE users will be able to set one
password for both UNIX and NT systems.
To
set the single CUE password for both environments, use the new jpasswd password command on any of the
central UNIX systems, or
use the web interface that is currently in development (available soon!). The web
interface is recommended for Windows and Macintosh users.
With
jpasswd, users will only have to
enter their new password once; it will be changed on both UNIX and the JLAB NT
domain automatically. Dial-In passwords
are also changed as part of this synchronization; UNIX users no longer have to
change their dial-in password from an onsite NT system. These benefits will
greatly ease user access to CUE systems and reduce confusion over which
password to use.
The
built-in system password change functions will no longer be available. The passwd and yppasswd commands on UNIX will be disabled, as will the
Ctrl-Alt-Del Change Password option on Windows NT/2000. All password changes must use the jpasswd command or the password change
web page.
The
password synchronization system was installed over the July 1 maintenance
weekend, and its test phase is complete with no known problems.
The
Computer Center announced support for Linux on the desktop in the spring. This support is divided into two levels;
users may choose to upgrade to either level, depending on the type of Computer
Center support they desire.
Level 1 support
provides a user access to all CUE file system areas (home, group, site, apps)
and installs the necessary tools to automate maintaining the system in a secure
manner, including applying any security patches as required. The Computer Center will maintain the root
password for the system and will monitor the system for security breaches just
as we do for all other CUE Unix systems.
The CUE file systems will be mounted on the system with full CUE
access. This level provides the user a
CUE Unix system with access to their CUE home directories, group areas, and a
local scratch. Since all of their data
will be stored in their home or group areas, the files will be backed up and
available for restoration if required.
(As on the central CUE systems, /scratch will not be backed up). Due to the configuration problems of this
level, users will need to save any required data from their system before doing
a clean install to this level.
Level 2 support is
similar to what users have now, except that the system is built/upgraded to a
CUE standard configuration. The CUE site and apps directories will be mounted,
and tools will be installed to automatically install any security patches as
they are identified and released. This
level allows the user to keep their root password, while the Computer Center
can assist in maintaining the security of the system. Users will be responsible for providing backups and fixing any
problems that occur on the system. They may choose to upgrade an existing
system (which will preserve their data) or do a clean install to this level.
To read more about
how to move an existing system to one of the levels above, see the Linux
Desktop Support Web page at http://cc.jlab.org/desktop/linux.
The Computer Center’s User Services group
provides user support for all of the JLab computing resources supported by the
Computer Center including: central UNIX systems, experimental physics
computing, and desktop computers running both Windows and UNIX. Macintosh
systems are also supported on a best effort basis; however as previously
stated, our desktop support is directed towards Windows systems. The
information provided here defines the Computer Center’s user support model, so
that users have an understanding of our goals and working methods, and
understand what support the Computer Center can provide.
The
User Services group assists users of all of the Computer Center supported
systems at Jlab. UNIX support includes SUN Solaris, Hewlett Packard HP-UX, and
RedHat Linux. Windows PC support
includes Windows NT and most recently Windows 2000 Professional.
Hardware
support is provided for JLab hardware (ones with a JLab property sticker,
and/or included on the lab’s maintenance agreements), and for systems directly
used in support of JLab’s scientific mission. Hardware that is provided on-site
by collaborating institutions should be maintained by those institutions. The
preferred method of maintenance would be through an on-site maintenance
contract for service while the machine is located at Jlab.
Software
support is available only for those machines that have been configured for use
in the Computer Center’s CUE (Common User Environment).
Assistance
is provided by the User Services team through various means: the Computer Center Helpdesk, the electronic
reporting and request system CCPR, through documentation such as web pages,
instructions, newsletters, and through training courses.
The
Helpdesk is open Monday – Friday 1:30 – 4:30, and is located in Trailer City
room 172. To reach the helpdesk by phone, dial x7155. If the Helpdesk staff
member is not able to solve the problem immediately a CCPR entry will be made
so that appropriate personnel can follow-up.
To
send electronic requests anytime, send email to helpdesk@jlab.org or fill out the web
information via the CCPR link at http://cc.jlab.org/support.
Always be sure to include a pertinent subject and a full description of the
request or problem, including as much specific information as is
available. This method is normally the
quickest way to reach the most number of people; multiple staff members see
each request.
The
Computer Center strives to provide timely turnaround on all user requests for
assistance. Since a person needing assistance perceives “timeliness”
differently than one providing it, here we provide our definition of timeliness
as a baseline for user expectations.
We
prioritize based on the severity of the problem, including such factors as –
how many people are affected, the impact on the lab, the impact on CUE systems,
networking, databases; the impact on the running experimental physics program
or interaction with Accelerator Controls (the latter two being the only
categories where we can provide after-hours response).
Nature of problem |
Goal for response time |
|
Major central outages – network, systems,
services |
Immediately, including after-hours |
|
Smaller outages – partial network, systems,
services |
Immediately – 2 hours, including
after-hours if it affects the accelerator or experimental program |
|
Group outage |
2 hours – same day |
|
Group problem |
Next day – 2 days |
|
Individual user outage |
Next day – 2 days |
|
Individual user problem |
Less than 1 week |
We
provide handouts on common configurations for supported software, so it may be that
the answer already lies in the existing Computer Center documentation.
Note
that these goals are the LONGEST we hope that it takes to get issues
resolved; in many cases if the problem or outage is already familiar to us it
can be resolved sooner.
We strive to
acknowledge CCPR items within 24 hours, and often are able to do so much
quicker.
Several tasks are
processed once a day, and only under special circumstances occur at other
non-scheduled times. These tasks include
The
Computer Center provides user support for Microsoft Windows computer users. Our
model is very straightforward: the
desktop user installs the operating system and JLab CUE configuration; the
Computer Center is then able to assist. (It is not possible given our current
resources to offer personal assistance with computer and operating system
installation and hardware and software upgrades to all desktop users.)
As part of the CUE
configuration, Microsoft’s SMS (Systems Management Server) client is installed.
SMS provides Computer Center staff three key features: 1) hardware and software inventory, 2) the
ability to install software remotely based on several installation models, and
probably most important for user support, 3) remote management capability. With SMS, Helpdesk, or System
Administration personnel can view a PC’s console remotely after the user grants
permission, often eliminating the need for an office visit. SMS is now
automatically installed on all CUE clients in the JLab domain.
Currently Windows
NT is the supported platform for most systems. We are also supporting Windows
2000 Professional on the desktop for newer computers. Windows 95/98 support
ended June 30, 2000.
For users who
require only a standard CUE configured system, without local administrator
privilege or additional hardware and software, the Computer Center can install
and configure a PC for you. Please submit an electronic request to request this
support.
Desktop
Support for Linux SystemsSee above
information for Linux on the Desktop, or see http://cc.jlab.org/desktop/linux.
Plan ahead. It is
much easier for us to schedule support when we know about requirements in
advance. We can work a support issue
much faster if we have it scheduled than if we’re asked to reprioritize what’s
already in the queue for a problem or issue that we could’ve planned for in
advance. Provide as much relevant information as possible. Include software
information, version numbers, error messages, hostnames, etc. Give us feedback
– your comments and suggestions, any error or omissions you may find in our
documentation, suggestions for courses, and anything else that will help us
provide improved user support!
The Computer Center
is in the final stages of adding Pony Computer to its available vendor list for
on-line PC purchasing. This will allow authorized JLAB personnel to purchase
personal computers loaded with either Linux or NT. Pony has provided many Linux
configured PC’s to the Computer Center and other JLAB groups previously, but
with the new system Pony computers will be available for general purchase,
configured with either Windows NT or Linux as optional operating systems.
The ordering
process for Pony systems will be somewhat different than the current vendor
ordering processes. When ordering from Pony the users REQ and PO will be
created automatically through a new ordering system currently being developed
and designed by the Computer Center’s MIS group. When the on-line purchasing
for Pony systems is available and finalized, notification will be provided through
the site-wide news system, as well as web notification at http://cc.jlab.org/announce/whats_new.html.
This notification will include information containing the appropriate links and
instructions for purchasing Pony systems on-line.
In the near future
the Computer Center and the Procurement Departments hope to have Micron Systems
added to the new PC purchasing system. This will allow users a choice between Dell,
Pony, and Micron for purchasing PC systems. Currently improvements are being
made to the Dell on-line web ordering to make the REQ and PO system automatic.
Additional
questions, comments, or concerns can be directed to Randy Hartman, hartman@jlab.org or x6399.
Support
Changes for NCD X-Windows TerminalsEffective October
1, 2000, the site’s maintenance agreement with Network Computing Devices will change
to meet NCD’s current support policy. NCD will no longer support the original
15r and 19c X-terminals, which are now at least 5 years old. Currently our maintenance contract covers
some 230 systems; after October 1 the contract will be reduced to cover only
the HMX and Explora series (110 systems) units.
The following year,
NCD’s policy will cover only the base units, and will not include monitors,
keyboards, or mice. Since most of the
repairs under our maintenance contract are for monitor-related problems, we
plan to end the support contract entirely effective September 30, 2001.
To summarize:
§
From Oct. 1, 2000 - only HMX and Explora
units will be under maintenance contract - including base, monitor, keyboard
and mice
§
From Oct 1, 2001 - no NCD X-terminals will be under maintenance.
X-terminals
are now relatively expensive compared with current PC prices; the lab has
bought none in the past 3 years. The
Computer Center will try to maintain a stock of replacement parts as far as
possible, and is actively researching alternative systems.
Owners of older NCD systems should plan to replace them soon. Current options include switching to a PC running Linux or Windows NT/2000. We are also investigating inexpensive “thin client” solutions.
For
many, it is hard to imagine how a cracker (or more popularly, a hacker) could break into a site's
computer systems. The following
describes one possible scenario, starting with the assumption that the cracker
has had no previous access to our site.
The
cracker obtains a password that is valid for a current user's account. This could be done by monitoring (sniffing) network traffic on some off-site
network at a university, research lab, or even from a compromised computer used
by an Internet service provider (ISP). This monitoring would be effective against
all clear-text communications, including login sessions (telnet, ftp, pop,
imap) and mail transfers from machine to machine.
The
cracker will conduct scans of our network to locate computers that provide the
kind of service he needs, in this case, a simple login session. Using the compromised password and the
address of a host that has responded to a login request, he simply logs
in. Normally, the smart cracker will
then attempt to get as much information as possible without bringing attention
to his activities.
He
will attempt to get a list of user accounts with the associated encrypted passwords. This list can then be moved off site, where
it is subjected to a brute-force, dictionary
attack. This kind of attack on the
encrypted passwords will quickly reveal any that are based on the user's name,
account, or any word found in a normal dictionary, even if there are random
upper/lower case shifts and substitutions of look-alike numbers for
letters. Having a few more accounts
with free entry allows him to come back, posing as another user.
A
primary goal of a cracker is to own a
system. This bit of jargon means that
he was able to gain administrative access to the machine (break root). Once he has
administrative access, he has access to all the files and applications on the
machine and can load his own set of trojan
system utilities (a root kit). These utilities allow him to hide his
presence and allow him to return easily to the system. He can also set up a password sniffer to monitor our network for
clear-text passwords.
The
ability of the cracker to break root
and gain administrative access depends on what tools he has available and on
how well the system is maintained. If
the system is up to date on the latest software patches, the cracker's job
becomes much harder, to the point where it is not worth his effort. If this is the case for the machine on which
he has logged in, he will look around and try to find other machines on our
network that are more vulnerable. On
Unix-like systems, he can use such files as /etc/hosts
and .rhosts to get the names of other
systems. In the case of .rhosts, he may even find mutually
trusted systems that allow direct login without further password checking. Moving around among several machines, the
cracker will often find one that is vulnerable to his cracking tools.
Each
of the intrusions that our systems have suffered in the last two years has been
incurred by way of a login using a compromised password. The primary front-line defensive measure
that every user can take is to protect his or her password. Two key components of this protection are 1)
using good passwords and 2) not exposing the passwords to monitoring.
The
first can be accomplished by following DOE guidelines for choosing
passwords. These guidelines are posted
on our Web site (http://cc/policies/PasswordRules.html).
Somewhat
abbreviated, these guidelines indicate that your password should contain:
Of
course, this makes a password that is hard to remember. Try creating one with an acronym, such as
"She ate five smoked salmon with fries on Wednesday" - - SA5ssw/foW.
The
second issue, exposure of your password to network monitoring, can only be
handled through applications that provide encryption. We already allow only mail clients that encrypt the password that
is used to read your mail. We also have
secure login facilities that make use of secure shell (ssh/scp). The basic rules
are: "Do not use telnet, use ssh" and "Do not use ftp, use scp."
See http://cc/desktop/unix/docs/ssh.html
for information on ssh.
We
have built and continue to improve our capability to detect unauthorized use of
the Lab's systems. These efforts
include alarms that warn of unauthorized access to restricted systems, traffic
filters that attempt to warn of unusual activity, and host-based routines that
monitor changes in system software and configuration. The host-based monitoring routines are installed on all centrally
managed machines and, by policy, are required
on all machines whose software is capable of supporting network logins. This facility is presently limited to
UNIX-like systems now.
The
installation of the host monitoring capability on user-administered machines is
the responsibility of each machine's administrator. We provide instructions and a script for installation of these
tools on current RedHat Linux distributions to make the process as convenient
as possible. A recent break-in went
unnoticed for two days because the machine on which the cracker was able to
gain root access was not set up for central monitoring.
Rigorous
enforcement of the policy regarding the installation of the monitoring
capability has been limited in the past by personnel resources. In the past, delinquent administrators have
received several warning messages asking that the facilities be put in
place. Recent experience underscores
the fact that prevention and early detection are more cost effective than
recovery from an intrusion. Due to the
potential harm to our operations that a compromised machine can cause,
procedures for handling delinquent systems will be less forgiving. Your network privileges are contingent on
compliance with the Lab's policies.
Instructions
for installing the host monitor facilities on Linux and other UNIX systems are
available at http://cc/support/security/docs/account-setup.html.
A new feature has
been added to our Voice Mail system, called the Dial-By-Name Directory.
This
function allows you to request, via voice mail, the mailbox number of an
individual on site. It is just a matter of spelling out the name (last name
first), of the person you are trying to leave a message for.
For more details,
please contact Lois Lucas (7361) or Dawn McGinnis (7206)
Alphanumeric pages can be sent through email:
For more paging information see http://cc.jlab.org/telecom/docs/paging.html.
Jefferson Lab Electronic Commerce
(WEBStock) is an on-line catalog that allows you to order from many different vendors
utilizing the same interface for all. The catalog currently includes vendors
that sell electronics, small tools, computer software and hardware and office
supplies. You can use the system to create an order using one or many vendors.
These orders are turned into purchase requisitions, and go through the same
signature authority as if a purchase requisition was written in the REQS
system. As soon as everything has been signed off, the order is automatically
placed with the vendor via an email. The initial problems running this
application on UNIX systems have been resolved.
The Jefferson Lab on-line PC Purchase
program went into production in July. With this application you can configure a
system from components that have been approved by the Computer Center. Once you
hit the buy-it button, a purchase requisition is generated for you and
sent to the proper queues for signature.
Currently we have one vendor, Pony Computing, participating in this
program. More vendors will be added in the future.
Submit
a problem report or request for assistance:
After business
hours, for emergencies only involving major outages or interruptions to the
physics experimental program, contact the guards, who will contact our on-call
staff member.
Note that the
quickest method is usually to submit an electronic request to the helpdesk, as
the report is immediately assigned to a staff member and seen by multiple other
staff.
Other sources of
information in CUE are the news messages available on login, and the Computer
Center’s web status and announcement pages. For news, simply type “news” to get
the latest unread messages, “news a b” for a brief listing of all messages, or
“news 100” to read message #100. The web page information can be found at http://cc.jlab.org/announce/status.html.
For
users who have purchased Dell or Gateway PCs under Jlab’s ordering agreement,
your machine includes 3-year onsite hardware support. You can directly contact
Dell at 1-888-560-8324; you will need your 5-digit service code (a label on the
back or bottom of your machine). To contact Gateway, call 1-800-846-2303 with
your system’s serial number.
This document is maintained by {helpdesk@jlab.org}
Copyright Jefferson Lab 2007