Computer Center News
|
Issue 8 |
July 2001 |
On Saturday, July 7th, at 6am, the group
areas were unavailable for use as we migrated the group data to its new
location. This caused a ripple effect in the CUE, and most of the CUE areas and
services were unavailable during this time as well. The group areas were moved
and CUE was back up by 6pm the same day.
Previously the CUE /group directories
resided on a network fileserver that was over 3 years old. As such, the vendor began phasing out full
support for it. Additionally, we were
unable to increase the disk space available for the group areas on this
fileserver. As there has been an ever-increasing demand for disk space under
the group area it was necessary to replace the older fileserver with a newer
system with increased storage capacities.

With these considerations in mind, the
Computer Center purchased disk space on a newer fileserver, and has moved all
of the group areas to the new location.
Make sure that you are accessing the group
areas via the CUE alias JLABGRP (not FS2) as the FS2 area is no longer
available after the upgrade. As you make these changes, please make sure that
you are accessing the other CUE fileservers by their aliases as well (JLABSITE,
JLABAPPS, and JLABHOME).
If you are mounting the group areas via FS2
from your fstab, you need to make sure that you have made the necessary changes
to reflect the new location. The new
group areas are available as fs1:/vol/vol1/<groupname>. If you are
in CUE, and are using the CUE automounter maps, you may need to reboot your
system to have the changes take effect.
After the move was complete it was necessary
to reboot all of the Computer Center maintained CUE Unix. Local users of
desktop CUE Unix satellites are responsible for rebooting their personal
desktop systems. During reconfigurations like this one please make sure that
you have logged off of your system prior to the scheduled maintenance. However, DO NOT shut your machine down
unless you are sure that no one else is depending on you for services such as
NIS. If you are unsure of this, don't
shutdown your machine. If you have
problems with your Unix machine after these sorts of upgrades, reboot your
system before calling the helpdesk in order to verify that you are getting the
correct automounter maps.
Now that the group areas have moved to their
new location, they are once again on a fully supported fileserver. Additionally
the available space on the group area has been increased from 200GB to 600GB.
The Computer Center has made available for
testing a new web interface for reading and sending email from your JLab
account. This
new application is being provided to ease the retrieval of your JLab email from
offsite, and is not meant as a replacement for your current email application
while you are on-site. This interface
eases the retrieval and sending of email from offsite because it can be used
from any computer that has Internet connectivity and a web browser, and does
not require the setup of local profiles on offsite computer systems.
The address for the new web email interface
is https://webmail.jlab.org, or just
simply https://webmail from machines connected
to the JLab network. When logging in to
webmail, you will need to supply the following 3 pieces of information:
1) Your CUE username
2) Your CUE password
3)
Your IMAP mail folder prefix. This is probably "mail" or
"Mail", whichever directory you have chosen to place your IMAP
folders. It is also the same directory
you have specified in your IMAP mail preferences in Netscape according to the
Netscape IMAP mail setup instructions.
After
logon a listing of the last 20 messages currently in your INBOX will be
displayed. Click on the left and right arrows to move forward and backward
within your INBOX. To view the contents of other mailboxes click on the drop
down pick list in the header at the top of the page. There are several buttons
on this page that will allow you to select individual messages to manipulate
(such as delete or move to another mail folder). The JLab LDAP server (email
address lookup service) is already built in. To use the LDAP server click on
the contacts link, search for the name you need, select the name that you
desire, and then click on new message to compose an email to this person.
The webmail
application contains an online help system, which provides detailed information
about the application and its functionality. To start the help system while
running the webmail application simply click on the big blue question mark
located in the upper left corner to activate it. Also note that since the URL address starts with https, the
entire session is encrypted. This avoids sending both your email and your
password in clear text over the network, and adheres to the security policies
that are implemented at the laboratory for electronic mail.
On an upcoming Computer Center
maintenance day the site's calendar server will be upgraded. The current server
runs on a Windows NT based machine, after the upgrade the new version will run
on a Unix machine. This move will have
impacts on users in several ways:
1) Password
synchronization with the rest of CUE. After the upgrade, you will use
jpasswd to change all your CUE passwords (Unix, NT, and Calendar). Upon initial deployment your calendar
password will be set to your current CUE password PROVIDED you have used
jpasswd at least once. If you have not
used jpasswd at least once to change your CUE passwords prior to the upgrade,
you will need to use it after that date to set your calendar password (thus
changing all your CUE passwords at once).
2) New user
interfaces. The current user interface, nscal, is a Netscape
application. This client will still
work with the new server. However, we
encourage all users to gradually move to one of the new clients below.
Netscape's nscal will not be supported after the upgrade.
3) Greater
Stability. The new server will not need to be shut down to do nightly
backups like the current server does.
The
current version of RedHat supported by the Computer Center is RedHat 6.2;
however, RedHat has recently announced their new version RedHat 7.1. This
version provides some significant new features, including the long-awaited
2.4.2 kernel. The Computer Center is
currently evaluating this version for support in level 1 and level 2 CUE Linux
Desktop installs. Support for this
version will most likely be available later this summer or fall. There are currently
no plans, however, to upgrade the farm and interactive Linux farm machines to
the new version until later this year..
If your Linux machine is already
running RedHat 7.1 and it mounts the shared Linux /apps directory, there may be
some applications shared from this area that do not work correctly with RedHat
7.1. If you encounter problems with any of these applications please send a
message to helpdesk@jlab.org to notify
us of the problems.
JASMine
UpdateOn May 7, 2001 the
Computer Center officially turned on Jefferson Lab’s Asynchronous Storage
Manager (JASMine) and shutdown Open Storage Manager (OSM). JASMine is a distributed, scaleable,
efficient, and modular mass storage system manager locally written by the
Computer Center. OSM was a commercial
product from Computer Associates (CA).
The deployment of
JASMine has been a great success. We
have already seen increased throughput and we have not yet turned on all the
tape drives, data movers, and cache servers.
The raw data dumps from CLAS have been done at an average data rate of
8.5 MBytes/sec. That is no less than
80% of the advertised bandwidth of the new T9940A tape drives. The overall throughput of the system has
already exceeded 50Mbytes/sec over a 15-minute period and 30 Mbytes/sec over an
hour. These measurements are for
real-time end-to-end performance during a given period of time. This includes the tape copy and network copy
time, tape load/unload time, and any time the file may remain staged on disk
due to momentary resource contention.
These numbers are also expected to increase as experiments start up
again after the May shutdown and users saturate the batch farm with jobs.
Since 1996
Jefferson Lab had been using OSM to manage the data, tapes, and tape silo along
with a layer of locally written software (TapeServer) to provide an interface
to the user. As the lab's scientific
program has expanded, the TapeServer grew to include disk cache manager
components. The failings of OSM, lack
of scalability and poor error handling, began to drive the need for a
replacement. Since OSM was only being
used to move data between tape and stage disks, it was a relatively
straightforward exercise to replace that functionality within the
TapeServer. During the summer of 2000,
the Computer Center began to work on JASMine.
The goals of
JASMine were to provide:
JASMine was
designed using object-oriented software engineering principles and was written
in Java. The use of Java is a surprise
to many people. However, data movement
with software written in Java is just as fast as that written in C. Java also provides for a fast, easy
development process. The Java Virtual
Machine (JVM), an abstract computing machine with its own instruction set that
uses various memory areas, handles garbage collection, while Java Database
Connectivity (JDBC) makes using and changing databases easy, and Java does not
require porting to support different operating systems.
A single logical
instance of JASMine is called a store.
Within a store there can be many storage groups. A storage group is a collection of other
storage groups or volume sets. A volume
set is a collection of tape volumes.
When a file is written to tape, the tape chosen comes from the volume
set of the destination directory or the volume set of a parent directory. This allows for the grouping of similar data
files onto a common set of tapes. It
also provides an easy way to identify tape volumes that can be removed from the
tape silo when the data files they contain are no longer required.
JASMine is made up
of many modules. These modules can be
replicated to avoid single points of failure.
A Request Manager handles all client requests. These requests include status queries as well as requests for files. A Library Manager manages the tape
silo. All tape mounts are made via a
Library Manager. This keeps the Data
Movers from having to know about different types of tape silos. A Data Mover then manages the movement of
data to and from tape.
Data
Movers themselves are made up of several modules. A Dispatcher queries the request queue for work to do. Since each Data Mover has its own
Dispatcher, the entire system will not stop if a Data Mover crashes. A Volume Manager keeps track of tape usage
and availability. It also assures that
the Data Mover will not sit idle waiting for a tape in use by another Data
Mover. A Drive Manager keeps track of
tape drive usage and availability. It
is also responsible for verifying that the correct tape is loaded before new
data is written to it. A Cache Manager
keeps track of the files being staged to and from tape. It is also responsible for sending and
receiving data to and from the clients.
The Cache Manager is the same as that used to mange the cache disks.
The Cache Manager
code was also upgraded with JASMine to support some new features. Cache Managers can now do third party data
transfers. This was done to help reduce
tape drive usage for file retrieval when the file already exists on a cache
disk. JASMine will have a Cache Manager
send an already cached file to a jget client instead of retrieving it from tape
a second time.
The Cache Manager
code in JASMine still makes use of disk groups or pools. This allows experiments to be given a set
amount of disk space for disk cache.
One can also think of it as a simple quota system. Different disk groups can also be assigned
different management policies. The
management policy used most often is the least recently used policy. Users must use the ‘-g’ option with the
‘jcache’ command in order to make use of the different disk groups.
JASMine also makes
use of a MySQL database. It is fast and
reliable. All the information about a
file is stored in the database. Cache
Servers also use a MySQL database to keep track of cached files and their
locations.
More information on
JASMine can be found at http://cc.jlab.org/scicomp/JASMine/.

During the second
week in May, the Computer Center began a series of hardware upgrades and
installs that will continue through the month of August. Such items include the installation of a
second tape silo and the addition of ten tape drives to replace the ever
failing Redwood tape drives.
With regards to the
tape silo, five new T9940A tape drives were installed in May. These supercede the older Redwood tape
drives for storing CLAS raw data. The
older Redwoods are now only being used to retrieve previously written
data. No new data will be written out
to Redwood tapes. The T9940A tape
drives have a native capacity of 60 Gbytes per tape and a transfer rate of 10
Mbytes/sec. The Redwood tape drives
have a native capacity of 50 Gbytes per tape and a transfer rate of 10 Mbytes/sec. So there is a gain in storage capacity. There is also a greatly anticipated gain in
reliability over the Redwoods.
In addition to the
five T9940A tape drives installed in May, five additional tape drives have been
purchased and will be installed around the first week of August. This will bring the total number of T9940A
tape drives to ten, which is two more than we currently have of Redwoods.
The installation of
a second tape silo will begin on July 24.
This silo will double the number of tapes that can be kept online and
available for access from 6,000 to 12,000.
These numbers are maximum values as the number of tape drives connected
to the tape silo limits the actual available amount of storage space. The installation of the second silo is
expected to take at least five working days.
Once completed, the
two tape silos will be able to pass tapes between each other in order to make
use of any available tape drive.
Assuming all 60 Gbyte T9940A tapes, they will have a combined capacity
of 703 Tbytes.
In addition to the
tape silo, additional disk space became available during the month of
June. An additional 9 Tbytes of cache
disk space was added to the existing 6.5 Tbytes. This now provides a total of 15.5 Tbytes spread over 20
servers.
The work files systems have also been
upgraded. Four file servers, each with
1 Tbyte of disk space, were made available during the month of June. These servers, like the cache servers, are
Linux systems, however these work fileservers use Mylex eXtremeRAID 2000 RAID
controllers. As with the existing work
file servers, they utilize RAID-5 to protect the data from a single disk
failure. However, since, as
before, these systems are not backed
up, they should not be used to store data that cannot be recreated.
A new quad CPU 700MHz system was also installed during the month of June. It replaced the two older IFARML2 and IFARML3 dual CPU systems and has 2 Gbytes of memory.
Lastly,
a farm upgrade will also take place around the first week of August. Sixty dual CPU 1GHz systems will be
installed. These newer system will also
have 512 Mbytes of memory rather than the 128 or 256 Mbytes in the present
systems. At the same time the oldest 10
300 MHz systems will be retired. The
farm will then have 350 Linux CPU and will deliver over 10,000 SPECint95.
The NCD warranty
service contract on all JLab Xterminals expires October 2001.
The
warranty repair service previously contracted through NCD repair facilities
will no longer be available for all remaining JLab Xterminals (including HMX
series and newer). Should a failure of
this brand equipment occur, the owner is responsible for its replacement beyond
the warranty expiration date. Any questions should be directed to Sam Stevens
at ext. 7148 or sstevens@jlab.org.
The Computer Center will stock working
replacement X-terminals as far as space permits. As mentioned in previous Computer
Center Newsletters the following alternatives are available as alternatives to
the Xterminals:
Recent increases in malicious hacker activity and a continuing
pattern of vulnerabilities found in popular web-page servers are forcing us to
reevaluate our list of machines that remain open to the Internet. Specific
vulnerabilities were
brought to light by the corruption of
JLab internal web page by outside hackers.
A closer look at the servers and content is under way. In particular, we will be removing outside
access to machines that are publishing pages that do not fulfill a program-related
operational need. Several centrally administered web-page servers are available
for routine web-page publication and these should be used when possible.
The web-page servers that remain will
be required to operate under a more structured procedure than in the past. This procedure will include having an
active, qualified administrator who understands how properly to install and
configure a secure server and how to install upgrades to the software. This administrator must subscribe to the
internal 'web-admin’ mailing list and must evaluate and acknowledge alerts that
are distributed via this list. Outside
access will be removed for machines that do not have up-to-date patches.
In the last year, DOE has provided
one-time, supplemental funding to the labs in response to proposals submitted
by each site. These additional funds
will provide us with an enhanced security posture, as we are able to bring the
new hardware and software on line.
The funded projects, totaling about
$310,000, include email filtering, enhanced network monitoring, a prototype
login-authorization system based on secure ID cards, and a
virtual-private-network (VPN) test bed.
The project that will have the most
immediate impact on our daily activities is the email filtering software. We have tested and licensed TrendMicro's
Viruswall email software and will be installing it on newly acquired
hardware. This package provides
filtering of all mail (in-coming and out-going) that passes through our central
mail server and will eliminate any messages that contain viruses that match
known patterns. There is also a capability for some level of spam filtering.
The TrendMicro software got good reviews from our colleagues at ORNL, SLAC, and
LBNL.
Improved network monitoring equipment
and software allows us to monitor performance and traffic patterns on our
internal net, even with the higher giga-bit speeds. The secure-ID prototype will give us the experience needed to
fully evaluate two-factor authentication techniques – these involve
"something you have" (the card) and "something you know" (a
pin), both of which are needed to get access to a critical system or
application. The VPN equipment and
software will be a base for allowing better point-to-point isolation of
critical traffic (such as business-sensitive information or personnel data)
over a public network.
These funds have provided an important
head start on several capabilities that we could not have funded out of our
normal budget.
Many people are now starting to use
DSL or cable modems to connect their home computer to the Internet. While there
are many benefits from using such services, they do increase the risk of a
computer compromise on the home computers.
Crackers and spammers are attracted to home machines on these networks
because of the high-speed and persistent connection to the Internet. Also, most home machines are connected to
such networks without giving any thought to security. In general, a default install of any operating system connected
to such a network is wide-open to compromise. Users are unaware of what
services their machines are offering, and applications are at patch levels with
known vulnerabilities. Some operating
systems have no way to control remote access, so the files on these systems are
open to anyone who wants a look.
Here are some things you can do to
help protect yourself.
- Stop all unnecessary services
- Keep your OS and applications patched
- Install a software/hardware based personal firewall
- Install and maintain anti-virus software
- Don't use the same passwords for different networks
- Use ssh and a secure ftp client for remote connections
There are many resources available on
the web for further information.
From Sans: Security Essentials for the
Home Network
http://www.sans.org/infosecFAQ/homeoffice/home_net.htm
A
Necessary Evil!Anti-virus
software -- what a pain! I have used various anti-virus software packages over
the years, and it has always seemed to be a case where the cure was worse than the
sickness! It seemed that no matter what software I was using or how I
configured it, the anti-virus software was constantly getting in the way of
doing my work. The scans were constantly happening when I was in the middle of
doing something. The system would grind to a snail’ pace, and I would have to
choose between canceling the scan, or taking a coffee break (I don’t smoke any
more). Well, I try to be “good” and opt for the break most times, but alas, I
would occasionally abort the scans when I was in a hurry.
Then,
there was the issue of keeping all of the virus definitions up to date. It was
fairly convenient to get a web-based update from time to time, but I never
seemed to do this as frequently as I probably should. And when some new virus
appeared on the scene, it was virtually impossible to get to the server to
download the new definitions for days. In many cases, this was too late.
Auto-update was pretty cool when it came out. It solves the problems I had with
keeping the virus definitions for my system up to date (as long as everything
was configured correctly). And once it was configured to update from a server
on site, it was even better. But, this still relied on me (the user) to
properly install and configure the software in order to insure that my system
was adequately protected. Really, the entire site was relying on me to
configure it correctly to protect THEM from ME. Don’t get me wrong, I like that
kind of thing and I was doing a pretty good job – but what about the other 800
systems and users on site?
“NAVCE”
or, Norton Anti-Virus, Corporate Edition finally seems to be anti-virus
protection that I can live with. It is protection that I almost don’t even
notice! For example, while the package was being installed on my system, I
continued my work with no appreciable degradation due to the installation
activities! When the installation was complete, it didn’t even require a reboot
(and you know that everything requires Windows XX to reboot). NAVCE was
now installed and protecting my system – almost without my even knowing it. I
now have real time virus scanning that checks files as I open them with my
application software. This sometimes causes a small delay, but it’s hardly
noticeable. On a faster machine than mine (~3 yrs old), you probably wouldn’t
notice it at all. Full filesystem scans are performed weekly, but I only know
that from looking at the scan log, the system otherwise does its work without
pestering me.
Meanwhile,
Myung Bang, the lab’s Windows Administrator, has a display on his system that
shows all of the systems on site. Information is available to indicate when
virus scans have been performed on each system, what viruses have been found,
and what actions have been taken to correct the problem. It also indicates what
virus definitions are installed on each system. This allows the Computer Center
staff to insure that all systems are protected using the latest virus
definitions. Our recent experiences
with virus outbreaks on-site have taught that it is very important to keep
definitions and configurations current on all systems – “most” systems
is simply not good enough in this case. Additionally, if a virus does manage to
propagate on site, the management display allows Myung to track and follow the
spread of the virus to more quickly eradicate it at its source – it’s kind of
like the Computer Center for Disease Control (CCDC).
There
are over 800 windows-based systems at Jefferson Lab that required installation
of NAVCE. Some of these systems already had anti-virus software of various
types installed. Some systems didn’t have enough disk space to install the new
package, some systems had other, conflicting software installed, and some
systems were offline much of the time. To do the installation, the Computer
Center used Microsoft’s System Management Server (SMS). This tool, along with
some locally written code allowed the Computer Center to determine which
machines had problems, and to schedule the delivery of the software to a large
number of machines in a way that caused it to be installed even on systems that
were offline (by installing as soon as they came online). A few systems were
determined to have problems and were followed up for manual configuration or
reinstallation. In the future, as
systems are added to the site, they will automatically be scheduled to receive
the anti-virus software. Overall, about 95% of the systems have been installed
as of this writing. The remaining
systems are being pursued and are expected to be complete by the time that this
is published.
For
a few systems, problems were encountered despite our efforts to identify them
ahead of time. For these, in most cases a simple re-install was all that was
required. For an extremely small number, more elaborate recovery was required
(manual registry edits, etc.). One common problem was related to the real-time
virus scans. In a few instances, following installation of NAVCE, MS Office
applications fail to open files. If you ran into this problem, it was corrected
by uninstalling and reinstalling NAVCE.
In
order to insure that the work and the time of the lab are protected from loss
due to computer virus infections, the Computer Center has installed NAVCE on
Windows systems on site. This tool provides the right combination of features
and capabilities for administrators without unduly degrading your ability to
use your system. Overall, I like knowing that it’s one less thing that I have
to worry about.
For
further information please contact Marty Wise (Marty.Wise@jlab.org, x7041)
Applications
like Napster, Aimster, and Gnutella allow nearly unrestricted sharing of information
and files among a group of hosts. These applications, by their nature, trust
peer machines without substantial authentication and thus pose security risks.
Hacked versions of these applications could create havoc within our work
environment. A virus has already been created
to exploit the peer-to-peer
environment.
Another
issue with the use of these applications is the legal one – the Lab cannot be a
party to the transfer or storage of illegally held copyrighted material.
The final point is that
the network and most of the equipment on site is intended to fulfill DOE's
programmatic goals. Noticeable use of
resources that is not program-related is a violation of our acceptable use
policy. Refer to the User Agreement and
acceptable use policies available at http://cc.jlab.org/policies.
If your work needs
the type of peer-to-peer data sharing that is provided by these applications,
please contact the Computer Center for guidance.
Web-Based
Travel Planning SystemOn June 1st, 2001 the new Web-Based
Travel System was officially released for use at JLab. This application is the
culmination of a year’s worth of meetings, decisions, planning, coding and
testing. Thanks go out to the many people who have contributed to this process.
The new web based travel system
eliminates the paper travel requisitions previously used for travel planning
and tracking. The new system now
provides the capability to complete and submit all travel requests online. There are two major benefits provided by the
new system for the JLab community:
The new system was evaluated and
tested over a four-month period. Since the first electronic trip was entered
back in December 2000, we have processed over 800 trips, totaling over 1.2
millions dollars in travel expenses.
The process of creating a basic trip online can be accomplished a few
minutes.
We are currently working on phase two of this project to include the additional forms related to travel. When phase two is completed, the entire travel process should be via the web. Additional information is available by contacting Carol Kinsey-O'Neil - 269-7519 or Geoffrey Barth - 269-7439
The
Test Lab (Building #58) is currently having it's network media and network backbone
upgraded. Shields Communication has been awarded the contract of upgrading the
current network media (coax) to Category 6 (Unshielded Twisted Pair). Increased
security, better network performance and flexibility with modern Ethernet, Fast
Ethernet and Gigabit devices are the main reasons for upgrading the media. The
Computer Center has chosen CISCO Catalyst 4003's as the core switches for the
upgrade. These provide better
performance, upgrade and management capabilities than are available under the
current setup.
The
current plan is to complete installation of network media and network equipment
by the end of July. The Computer Center will then begin to move users
individually to the new network.
Please contact
Steve Wells (X7639) or Mike Memory (X6240) with any questions or specifics that
need to be answered.
The Computer Center
is preparing to move to the next phase of additional site wireless networking
capabilities. Currently there are several locations where a user can gain
access to Jefferson Lab’s network via wireless Ethernet devices. These
locations include areas within Cebaf Center, Trailer City and VARC (Training
Room #47), but not the entire buildings.
We also have a limited capability to put wireless networking in other
locations temporarily for special
requirements.
After evaluating the current setup and recognizing the need to increase
availability, the Computer Center is in the process of implementing a new plan.
The new strategy will give wireless access in additional areas and will provide
a secure way of monitoring wireless network activity. It will also make it
easier for visiting users from other labs as well as Jefferson Lab users to
gain access to our network resources.
The design adheres to the wireless standards (802.11) and gives users a
more flexible vehicle for accessing our networks. No completion date has been
established at this time. Investigation of our current network devices and
their required ability to support VLAN's (Virtual Local Area Networks) is
underway. Information will be coming
out in the near future via the Computer Center Web pages. Any question or specifics should be directed
to Steve Wells (x7639), Andy Kowalski (x6224) or Mike Memory (x6240).
It should be noted
that the Accelerator Division, which supports the control system and
Accelerator networks (ACE), has different standards for accessing the dedicated
Control System networks via wireless. The ACE team is not currently supporting
the DHCP protocol that the Computer Center uses as its means of dynamically
assigning IP addresses for wireless connectivity. The ACE team uses static IP
addresses and requires that wireless network cards connecting to their networks
run 128bit (26 key) encryption.
A
new area code went into effect as of June 1, 2001. The new 434 area code for
Central and Southside Virginia is available, while there will be a seven and
one half month 'grace period' for dialing the previous extensions. During this
period, calls to numbers changing to the new 434 Area Code will be completed
when dialed with either 434 or 804. The 434 area code was carved out of
existing 804 service areas, and will serve customers in the southern and
western portions of the current 804 territory.
Remember that if
you were dialing a '1' before the 804 area code before, you will now dial '1'
for 434 connections.
Please do not
hesitate to contact Lois Lucas, x7361 regarding any questions or problems
dialing.
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