|
Computer Center News
|
Issue 7 |
March 2001 |
On the Computer Center maintenance day in
May, we will turn off direct access to JLABS1 and JLABH1 from off-site locations.
External login services will be provided by a "hardened" login
server. The machine, known as "jlab.org", is available now.
This machine will be a "jumping-off
point" for everyone logging in from off-site locations. It will provide no
services beyond acting as a relay. Once you have logged into this machine, the
only thing you can do is to log into an internal machine, like JLABS1 or
JLABH1. If you have an account on other internal machines, they will also be
accessible from this intermediate login.
On the first Monday of March, there were
probes of our network and erroneously routed network packets from 3368 external
network addresses. This is typical for a weekday. On weekends, the number of packets probing our site can go up an
order of magnitude.
The intent of the hackers doing these probes
is to determine our network topology and to determine what kinds of machines
and services are accessible and, possibly, vulnerable to compromise.
Our firewall and associated monitoring
routines provide an active defense to this automated probing. In addition, we
minimize our exposure by restricting the visibility of our servers and
services, e.g., login, file transfer, mail, and web. Those servers that are exposed must be maintained at a high level
of integrity. We do this by "hardening" the system configuration and
by prompt updates of software whenever a potential vulnerability becomes known.
Reducing our exposure to off-site intrusions
is a continuing battle. Over the last several years, we have reduced the number
of exposed servers that provide interactive logins to two machines, JLABS1 and
JLABH1. A specially configured login
server machine will now provide the interactive login service.
The login server has definite performance
advantages. This implementation of a dedicated login server will allow for
scalability of the login server system to multiple login servers when the need
arises. We can now dedicate JLABS1 and JLABH1 to those users who use them for
their computational needs. We will no longer use them as the default
"pass-through" for logins to other machines.
Note that if you use SSH for your interactive
logins, you can do the entire process in one line, as shown below. From a UN*X style machine, this allows you
to establish a command alias that would do a direct login to your internal
machine through the login server.
Examples of use:
To
open an X connection from an off-site UNIX/Linux machine:
ssh -f jlab.org ssh jlabs1
xterm -name jlabs1
ssh -f jlab.org ssh
halldlinux2 xterm -name halldlinux2
ssh -f jlab.org ssh
myjlabbox emacs -name myjlabbox
To open a command
line in your current terminal window:
ssh –t jlab.org ssh mybox
For telnet logins
(discouraged due to the exposure of your password over the net):
telnet jlab.org --> login directly to login server
ssh jlabs1 --> continue the login to the
internal machine
If you frequently move your laptop or
workstation between different networks on site, the Computer Center has made
this easier through the use of the Dynamic Host Control Protocol, or DHCP. Registering to use DHCP has now become
easier through the use of NetReg, an application that allows automatic DHCP registration
system.
To utilize DHCP registration via
NetReg:
1. Configure your machine to obtain its
IP address from a DHCP server.
2. Reboot the machine.
3. After the system has rebooted with a
temporary IP address open a web browser
4. In the web browser go to http://www.jlab.org
5. Login using your JLAB username and
password.
6. Read the Network Acceptable Use Policy
statement that is displayed
7. Click on the Accept button at the
bottom of the page.
8. Reboot your machine for a final time
to get your correct assigned IP address.
Upon completion of these steps your
system will be registered to use DHCP. For further information contact Kelvin
Edwards (Kelvin.Edwards@jlab.org,
x7770)
The current NCD
hardware maintenance contract will not be renewed in October, and the current
NCD Xterminals will be unsupported at the end of this year due to their age and
the high cost of their maintenance. As Xterminals are replaced, the Computer
Center will gather and stock these unused Xterminals and their associated
peripherals, and use them as substitutes for broken systems as long as the
extra equipment is available. Additionally NCD will no longer repair monitors,
which account for 90% of the NCD repairs that are requested.
In order to provide
equivalent (or better) functionality to the NCD Xterminals, the Computer Center
is evaluating alternatives:
All of these
alternatives will be used together with the Windows Terminal Server (see
article in this Newsletter) to provide access to Windows applications.
We expect that
these alternatives will be much more affordable than the current cost of
Xterminals and their associated maintenance contracts. The cost will be much
less than $1000 per instance, including monitor, versus the greater than $4000
of associated costs per Xterminal.
For more
information on these alternatives contact Kelvin Edwards at kelvin@jlab.org.
The standard JLAB
Web Server configuration has been available for about a year, and has been
deployed in several instances to provide a web server dedicated to particular
group needs. In many cases these are a single web server, running and serving
mostly static pages, so a system that supports multiple “virtual servers”
employing SSL, using authentication, and deploying applications integrated with
databases, and implemented in a variety of scripting and conventional
languages. The list of web servers currently deployed is available at: http://cc.jlab.org/services/webservers/WebList.php.
Upgrades
3/20/2001The CUE web
servers, including the main site server (www.jlab.org)
and several others operated by various groups on site all underwent a major
update on the March 20th maintenance day. The centrally managed MySQL servers were updated as well. Some
changes help to address various security and general bug fixes, while others
offer increased functionality and capabilities. The improvements included a
major upgrade to the PHP scripting engine, the Apache web server software
itself, mod_layout and MySQL.
Specifically, the following versions are the
defaults –
Software |
Version |
Apache |
1.3.17 |
mod_session |
0.1.6b |
mod_perl |
1.25 |
mod_ssl |
2.8.0-1.3.17 |
HTML-EmbPerl |
1.3.1 |
mod_layout |
2.10 |
php |
4.0.4pl1 |
MySQL |
3.23.33 |
A central CUE
configuration for MySQL has been developed and successfully deployed for a
small number of groups at the lab. This database offers relative ease of use,
and can be accessed using a variety of APIs (PHP, Perl, Java/JDBC, etc.), to
allow development of web-integrated database applications. If your group is
interested in developing web applications that take advantage of these
facilities, have your web administrator or coordinator contact the Marty Wise (Marty.Wise@jlab.org, x7214) information
on getting this set up.
The long battle to
implement a reasonable Java Servlet system on the CUE web servers is complete
in at least preliminary form. The rapid development of the tools and components
of the Java Servlet system itself have resulted in some delays, but things are
stable enough to allow people to begin work with these systems if desired. Be
careful, however! Many people are familiar with the older Apache/Jserv system.
This has been replaced by the Jakarta/Tomcat release of the Java Servlet
Specification. CUE provides the newer tools from the Jakarta package, since
this is the thread that will continue to be developed and supported by
Sun/Apache. If you are interested in these tools for your group’s server, you
will need to have your web administrator request the configuration of these
tools via an email with the subject of “Web” to helpdesk@jlab.org, or a submission to CCPR.
A couple of mailing
lists have been created to allow easy communication between everyone interested
in CUE Web Server administration and authoring. These lists are available from
the site’s majordomo server (see http://cc/services/email/#jlabmaillist
) . There is an announce list cue_webauthor-announce@jlab.org that is reserved for announcing changes and
developments relating to the CUE Web servers. There is also a general
discussion list, cue_webauthor@jlab.org that can be used to post questions,
comments, etc.
A
number of users have inquired about the availability of mod_web_dav for use in
doing distributed web authoring. This is a fairly complex component, so it will
likely be a while, but it is envisioned that this will eventually become
available. A re-work of some of the server configurations is currently being
developed. This will relocate some of the web server configuration files, but
should not alter content paths, etc.
There will always be a continuous stream of small improvements in
configuration, log file maintenance, etc.
Jefferson Lab’s
mass storage system software will be updated this spring and summer to
accommodate the addition of high speed StorageTek 9940 tape drives and allow
for future expansion. The silo currently has ten 9840 tape drives and eight
Redwood tape drives. The Redwood tape drives are nearing the end of their life
and will be phased out over the next five years.
There are currently
three layers of software that together move data from the halls to the SILO and
then out again to the farm for processing. They are StorageTek’s ACSLS, The
Open Storage Manager (OSM), and the JLAB developed TapeServer.
The
lowest-level layer, StorageTek’s ACSLS software, controls the silo’s robotic
arms, moving tape cartridges within the silo. It mounts tapes in tape drives
and then stows them in storage cells when not in use. This layer of software
remains unchanged.
The Open Storage
Manager (OSM) maintains a database of tapes and file locations on those tapes.
OSM manages the silo as a whole, using ACSLS to perform mounts and move tapes
on a first-come-first-serve basis. OSM has limitations that force us to replace
it: it has no ability to be run on multiple server machines at the same time.
That is, it expects all tape drives to be attached to one machine, a severe
limitation. It is also single threaded, meaning that requests are handled in a
sequential manner, slowing the entire silo when there are many tape mount
requests. Finally, OSM is a commercial product from Computer Associates that
has been discontinued and is unsupported.
The highest level
of software is the locally developed TapeServer software that provides silo
services to the users and the farm. It services the jget, jput,
and jcache commands, manages the pools of cache disks, queues and
schedules requests, and provides reports on silo usage. It also makes our
current two installations of OSM appear as a single instance to the user.
This three-layered
software solution has worked well for several years, but does not scale to meet
upcoming experimental needs. It is cumbersome and impractical to add a third or
fourth instance of OSM. The JASMine project integrates the functionality currently
provided by OSM and the TapeServer into a single server that can be distributed
over multiple servers, share a common database, and be easily scaled and
modified as needed.
We are currently
beta-testing JASMine with a cluster of Linux machines and several different
tape drives. We plan to do throughput testing and minor revisions during March
and April so that we can deploy a working system for testing by the users in
May. Once the system has been shown to be robust and reliable, we will shut off
OSM completely.
The Mass Storage
System (MSS) will be undergoing hardware upgrades during the summer shutdown.
The newer 9840 tape drives were installed
last summer. The 9840 tape drives have faster loading an unloading times
than the Redwoods, but their storage capacity is 40% of that of the
Redwood. In addition, the 9840 tape
drives are far more reliable than the Redwoods. After installing the 9840 tape
drives, halls A and C began using them to store data for new experiments. CLAS
began using them to store their production data. Currently, only CLAS’s raw
data and the MSS home directories are being stored on Redwoods.
StorageTek has now
released the 9940 tape drive to replace the older troublesome Redwood. The 9940
tape drive is built on 9840 technology, but is designed for capacity rather
than fast loads and unloads. The 9940 tape drive has 20% more capacity than
that of the Redwood and is expected to be more reliable.
Five new 9940 tape drives have been
purchased to replace the function of the Redwood tape drives. In order to make
use of these tape drives, one of the SILO walls must be replaced with a drive
wall. This will require at least one day of downtime. After the wall is
replaced, the new 9940 tape drives will be installed and tested. Testing is
expected to take about a week. Barring any problems discovered during testing,
the 9940 tape drives will be put into production and replace Redwoods for
storing CLAS’s raw data.
Since the Redwood,
9840, and 9940 tape formats are not compatible, the Redwood tape drives will
remain for read-only access for existing Redwood tapes. Over time, users and
experiments will be asked to migrate any data they want to keep from Redwood to
9940. Tools will be created to help make data migration easier, but it will be
up to the users to decide what data is migrated and the experiments or halls to
pay for the required tapes.
OSM, the software
that manages the data stored on tape within the SILO, will also be replaced by
JASMine during the summer shutdown. JASMine supports distributed tape drives
across multiple systems on the network. Such systems are called Data Movers.
Multiple Data Movers
will be installed during the summer shutdown. Distributing the tape drives
eliminates many of the bottlenecks that arise with a single system MSS. Each Data Mover will have a gigabit network
interface and local disk space for staging data to and from tape. Since each
Data Mover functions independently of the others, the failure of one will have
no impact on the others.
The gigabit switch
used by the MSS and Farm will be also upgraded during the summer shutdown. The
new switch, a Foundry BigIron 8000, supports up to 64 gigabit connections and
has a switching capacity of 256 Gbps. This new switch will provide us with the
gigabit ports needed to support a distributed MSS.
The Computer Center has been in the
process of testing and evaluating the Windows Terminal Server product. There
are clients available for Unix/Linux and Windows systems. This new terminal
server has been tested by numerous Unix and Windows users over several months,
and has proved to be a useful product. This testing and evaluation phase has
been completed and the system is now available for general use. At the moment
the server software that supports Unix/Linux clients (Citrix MetaFrame), has 15
concurrent user licenses. The server (for both Windows and Unix clients) is
CCTS.
Currently
the CCTS service provides access to the following popular Windows software:
We
will expand the catalog of software available in this environment as time goes
on; suggestions include Microsoft Project, AutoCAD, Visio, etc.
To use the Windows Terminal Server
CCTS (MetaFrame), all Unix clients will need to use the ICA client software.
The Computer Center has installed the ICA clients software in the central /apps
directory for Sun, HP, and Linux.
To start a session, execute the following command on any CUE Unix system: metaframe.
Detailed
instructions on the use of the new Windows Terminal Server can be found from http://cc.jlab.org/docs/services/unix/ICAClients.html.
For
Windows users, the Terminal Server provides access to Windows applications that
may be used only occasionally and are not installed on the user’s machine. Installation of the client is available from
the “CUE” menu under the Windows “Start” button. Refer to http://cc.jlab.org/docs/services/windows/TSClient.html
for more details.
The
Computer Center and Procurement have been working to add new vendors to the
on-line PC purchasing program. Micron is the newest addition to the on-line PC
purchasing system. Micron systems are now available from the current purchasing
pages located at: http://cc.jlab.org/services/pc_purchasing/.
In
the event that there is the need for a special function PC we recommend using
Build to Order as the vendor. Build To Order has been able to supply JLAB with
PCs running Linux or that have special parts requirements. There are no plans
to add Build To Order to the PC Purchasing web pages at the current time. If
you do have the need to have a special build PC you will have to order it by
getting a quote from Build To Order and then writing a req.
Pony
Computers has been removed as one of the available vendors for on-line PC
purchasing, after undergoing a major corporate-wide restructuring. This
restructuring resulted in the degradation of service that the lab had been
receiving from the company. There were several problems that occurred which
resulted in the removal of Pony from the available vendors. However, Pony will
still honor all existing warranty agreements on previously purchased systems.
Warranty and contact information can be found in the Dell, Gateway, Micron, and
Pony Onsite Support section at the end of this newsletter.
For
further information please contact Randy Hartman (Randy.Hartman@jlab.org, or x6399).
SafeTP
(Secure FTP Replacement)The Computer Center will soon be
deploying the SafeTP suite of applications to replace insecure FTP clients and
servers. The SafeTP suite includes client and server software for Windows and
Unix platforms. The easiest way for a cracker to compromise a computer system
is to place a sniffer on a network and watch network traffic to retrieve a
username and password. This is possible because several programs transmit
passwords as clear text. The two most common applications that transmit clear
text passwords are Telnet and FTP. In keeping with DOE security goals, the
Computer Center has been working to minimize the transmission of clear text
passwords to the site. Telnet has been replaced on site with SSH and its
variants, and general purpose FTP will be replaced with the SafeTP suite of
applications. For data transfers use BBFTP as directed on the Off-Site File
Transfer page located at: http://cc.jlab.org/docs/scicomp/how-to/off-site-data-transfers.html.
For a FTP client, a part of the SafeTP
suite transparently interposes itself between outgoing FTP traffic from any
standard FTP client to provide secure authentication when it detects a
connection to a secure FTP server.
On the server side, SafeTP listens to
the standard FTP port, accepts incoming FTP traffic and authenticates it. After
the user is authenticated, the SafeTP daemon passes the traffic along to the
FTP daemon for normal processing. It also has the capability to provide a
secure data channel, encrypting the data stream in addition to the login
sequence.
The
server application, sftpd, intercepts FTP traffic on the designated Unix
host, authenticates it, and then passes it along to the regular FTP daemon. The
server can be configured to accept only secure connections, or it can be
configured to accept secure and insecure connections. The secure connections can have varying levels of security. All
levels of security protect the password exchange.
The
client application is a drop in replacement for the FTP binary called sftpc.
This program works like command line FTP.
On
the Windows platform, the client interposes itself as a transparent proxy in
the networking stack. It intercepts and
secures outgoing FTP traffic from any standard FTP client (e.g. FTP.exe,
WS_FTP). SafeTP Windows client is available for Windows 95/98/ME/NT/2000.
The
goal is to have a secure connection only server for all internal traffic, and a
server that accepts secure and insecure connections for external traffic.
The client software for the Unix
platforms will be available in /apps. The client for Windows platforms will be
available from the CUE menu and is also available in the PC apps
directory.
For further
information please see http://cc.jlab.org/docs/security/secure-communications/safetp/index.html.
On January 10,
2001, the W32.FunLove.4099 virus hit JLAB Windows PC’s with a vengeance. This
virus infected desktop machines, servers, and fileservers. It spread fast
through mapped network drives by workstations with no anti-virus software or
outdated virus definitions, which caused many hours of down time for several
critical servers and workstations. Many users weren’t using their anti-virus
software or the software was not configured correctly. 
It
is extremely difficult to maintain a virus-free environment on a site as large
as Jefferson Lab without using centrally controlled virus protection. To solve
this problem the Computer Center has tested and implemented the centrally
controlled virus protection software “Norton Anti-Virus Corporate Edition”, and
is providing it for JLAB Windows PC’s.
Norton AntiVirus
Corporate Edition 7.5 for desktops and file servers offers centralized policy
management with scalable, cross-platform virus protection on an enterprise-wide
basis. Centralized management from a single console allows the Computer Center
to lock down policies that keep systems up to date and properly configured,
fully protecting users at all times.
Testing of this
software involved deploying it on small groups of users, which resulted in
favorable and successful results. Once the software has been installed on a
client machine, the client can neither disable nor uninstall the software. From
a single server console, the Computer Center can establish policies and enforce
them (i.e. weekly scan of hard drive, file system real-time protection, type of
files to monitor, backup options, …etc), verify protection, manage virus
definition updates, and control live virus. When there is a new virus users
will not have to worry about updating their virus definitions; the server will
deliver updated virus definitions automatically.
It is not necessary
to uninstall existing Norton AntiVirus 2000 or 5.0 before Norton AntiVirus
Corporate Edition is installed. The software will be automatically deployed and
installed on all Windows machines in the JLAB domain. User’s will have several days within which to accept the install
at their convenience. At the end of
that grace period the software will install automatically.
Note, the
installation of this software is not optional.
All PC’s connected to the JLAB network are required to run anti-virus
software, those that are part of the domain will get this software, stand-alone
and lab-owned home PC’s must run a stand-alone client. Refer to http://cc.jlab.org/docs/services/windows/NAV_install.html
for details on all aspects of installation.
The
FunLove virus uses files infected with W32.FunLove.4099 to insert the Flcss.exe
file into the \Windows\System (Windows 95/98/Me) or \Winnt\System32 (Windows
NT) folder. Whenever the Flcss.exe file can be created, the virus attempts to
execute it as a service on computers running Windows NT. If for any reason the
service cannot be executed, the virus creates a thread inside the infected
program. This thread infects local and network drives by searching for Portable
Executable (PE) files with .exe, .scr, or .ocx extensions. The thread then
executes inside the infected process and the main thread of the program takes
control. W32.FunLove.4099 is the second virus that runs as a service on Windows
NT.
When
the virus runs as a service, it can spread to the local drives, even if no one
is logged on. Because of this, the virus can infect files that are normally not
accessible after the logon. For example, the virus can infect Explorer.exe on a
Windows NT system. This virus also attacks the Windows NT file security system.
For the virus to attempt the attack, it needs administrative rights in Windows
NT Server or Windows NT Workstation during the initial infiltration. Once the
Administrator or someone with the equivalent rights logs on, W32.FunLove.4099
has the opportunity to modify the Ntoskrnl.exe file, the Windows NT kernel
located in the \Winnt\System32 folder. These modifications compromise the
security of the machine; giving any user administration permissions on the
machine
The
infection here on site led to over 24 cumulative hours of downtime for a few
groups, and at least 9 full machine rebuilds along with numerous hours of
repairing and cleaning by Computer Center staff. Unfortunately, most of the
down time could been prevented if the infected machines had been running
anti-virus software correctly. The virus definitions to detect this FunLove
virus have been available since November of 1999, and all anti-virus software
packages provide a method to update the virus list if the user configures it
correctly.
It is the responsibility of desktop users to keep all desktop machines at the current security patch level for the operating system and any applications run. All work should be stored on disks that are actively backed up. Also, for your protection, never open a suspicious email attachment.
In the area of
mechanical design, much emphasis is placed on the printed hardcopy of a
drawing. Most design developers and manufacturers depend heavily on the drawing
hardcopy as the primary means of communicating the design intent. This
dependency is likely to remain in place for the foreseeable future. The design
groups at JLAB also depend heavily on the integrity and security of their
design data that is stored in the form of electronic drawings and associated
files. While the electronic design data
provides for the creation of the drawing hardcopy, it also represents valuable
design work that can be reused.
Indeed one of the
greatest advantages of using CAD software in the process of design development
is that existing design data in electronic form can be easily referenced and
reused when creating new designs or revising existing designs. However, for the
design data to be referenced and reused effectively it must be well organized,
easy to locate and secure from deletion or data corruption.
Several Mechanical
Engineering design projects at JLAB use CoCreate’s ME10 2D CAD software to
produce the drawings of their designs. Once a drawing is complete, the
electronic drawing file is plotted to hard copy (on velum media) and signed off
by the appropriate engineering management personnel. The drawing hard copy is
then taken to room 225 in the Applied Research Center and submitted to JLAB’s
Document Control Group (DCG) for reproduction, distribution processing, and
hard copy storage.
The procedures that
are followed in issuing, distributing and storing a drawing hard copy are well
established and used consistently for all ME design projects at JLAB. However,
the processes for handling the corresponding ME10 electronic drawing file are
less clear and vary from one design project to another. The file storage
locations and file access permissions sometimes even vary from one designer to
another. This variation in the organization of and access to the electronic
design data presents a problem.
In November 2000,
personnel from the Computer Center, DCG, and various engineering and design
groups at JLAB worked together to develop a solution to this problem. The
result of this collaborative effort is the ME10 Drawing File Archive System.
Under this new drawing file archive system a designer submits the electronic
ME10 drawing file to DCG along with the signed drawing hard copy that is to be
issued. To submit the electronic drawing file, the designer simply moves the
drawing file into an established “holding” directory that exists on a common
JLAB file server. DCG personnel then process the electronic drawing file along
with the drawing hard copy.
The Quality
Assurance procedures that are followed by the DCG include validation of certain
elements of the electronic ME10 drawing file. The elements of the drawing file
are also checked for correlation with the corresponding elements of the drawing
hardcopy. When DCG is satisfied that all of the items on their QA check lists
are met they move the electronic drawing file from the “holding” directory to
the “archive” directory structure for permanent storage.
The
drawing archive directory is arranged in a hierarchical structure that is easy
to learn and navigate. From the drawing file archive directory, the drawing is
read-accessible by any ME10 user who wants to view the drawing from within the
ME10 application. The drawing file access permissions are established to
prevent any modification or deletion of the file. Since the drawing file
archive directory resides on the central fileserver, all of the files receive
hourly and nightly backups. This provides for file recovery and restoration in
the event of a catastrophic event, such as power outage or a hardware
failure.
Not all of the ME
design project groups at JLAB have started using the new archive system for
ME10 drawings. Those that have, have demonstrated the benefits that the system
offers. The ME10 Drawing File Archive System provides a single, logically
organized and secure long-term storage location for all electronic design data
that is generated in the ME10 CAD application. The system also provides for an
additional level of Quality Assurance performed by the independent group at
DCG.
Additional
information including detailed procedures on the use of the ME10 Drawing File
Archive can be found on the DCG web site, at http://www.jlab.org/accel/doc_controls/cservsupport_MEGdwgarchive.htm.
Telephone
Authorization CodesMany of you ask why
the lab uses authorization codes when dialing off site.
Originally these codes
were developed to protect what we refer to as “Open Area” telephones. Sometimes
there are employee’s who have phones located in open areas such as in the Test
Lab and in the EEL. These people requested that their phone be protected from
unofficial Domestic or International phone calls being made. At the same time,
the owner of these phones needed to be able to make Domestic and International
calls.
Two things were
done to protect their phone. Firstly these phone extensions were put on
restriction; this prohibited anyone from making Domestic or International calls
from them. Secondly another class of service was created that allowed
particular employees to bypass the phone restrictions and to use an
authorization code to make necessary calls.
A
by-product of this feature also allows employees to make calls from any phone
at the lab even if the phone used was restricted from outside calls. At the
same time, the charges incurred on this phone would be charged to the
authorization number the employee used to make the call, not the originating
phone.
Submit
a problem report or request for assistance:
Note that the quickest
method is to submit an electronic request, as the report is immediately
assigned to a staff member and seen by many other staff.
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.
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, Micron, Pony, 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 Micron, call
1-800-249-1179: extension 59684 for
Tech Support, extension 59028 for Customer Service, and extension 31205 for
Sales Service. To contact Gateway, call 1-800-846-2303 with your system’s
serial number. For Pony support please
call 1-888-809-1588 extension 114.
The
archive of previous Computer Center newsletters, as well as the current
newsletter, can be found online at http://cc.jlab.org/announce/newsletter/.
This document is maintained by {helpdesk@jlab.org}
Copyright Jefferson Lab 2007