|
|
Issue 15 |
December 2003 |
Andy Kowalski (kowalski@jlab.org,
x6240)
The core network for the site is being
upgraded during the December shutdown.
This upgrade requires network outages on December 27, 28, 29, and
30. The upgrade is being done during the
shutdown to limit its impact on the daily operation of the lab. Services such as email, internet access, web
server access, Domain Name Service (DNS), Network Information Service (NIS),
calendar, and other
The working plan is to completely shut down
the network on the 27th to perform hardware upgrades, replacements, and
installations. The outages on the 28th,
29th, and 30th will be intermittent as configurations are changed to make use
of the new features and capabilities the hardware provides. These intermittent outages will be random and
could last for hours at a time. Although
the outages on the 28th, 29th, and 30th will be intermittent, there should be
no expectation of service or network availability.
Accelerator networks located within the fence
will remain operational during this upgrade but will not be externally accessible;
either from the internet or RAS (dial-in) connections.
The new features and capabilities provided by
the network upgrade will enable us to keep up with the increasing demands being
placed on the network. These demands are
in the areas of security, functionality, flexibility, and manageability. One new feature that will be of importance to
many groups at JLab is the deployment of VLAN (Virtual Local Area Network)
support. A VLAN is a logical grouping of
systems that appear to be on the same physical LAN segment. In reality, the systems are located on
different physical segments. This will
allow, for example, one of our current subnets (Business Services) to be
deployed as a VLAN such that select systems across the site (
One area of new growth requiring the use of VLANs has been in the monitoring of heating and air conditioning units by facilities management. This upgrade will allow us to build a private network across the site where only the facilities management systems are included. In the past, dedicated fiber and cables were used to build a private physical network. With VLANs, this can be done logically using existing fiber, cables, and in some cases, network equipment. The sharing of physical components to build VLANs will provide us greater flexibility while saving us time and money.
Marty Wise (wise@jlab.org,
x7214)
A few months ago, the 
the
site network.
For most users, their systems will support
installation of Windows XP without any problem. Most systems, hardware
components, etc. that are in common use at the lab are supported by Windows XP.
A few exceptions exist for hardware whose manufacturer has gone out of
business. In some of these cases, drivers for XP (or anything else) are not
available. In a few cases select hardware may need to be replaced to maintain
compatibility. Fortunately, Microsoft provides information on its web site
about this issue, and even a tool that you can download and run to determine if
your system is supported. More information is available on the
The
Many users continue to store documents, data,
etc. on their local system disks. Since your local disk will be completely
overwritten by the rebuild process, before you rebuild, you’ll need to insure
that you have all of your data stored in a safe location. Rebuilding your system
provides a great opportunity to reorganize where you store your working data to
take advantage of our central file servers. See the “Building or Rebuilding
Windows Systems at JLab” article in this newsletter about this topic for more
information on how to prepare your system for a rebuild.
While upgrading from NT4.0 to a newer version
of Windows will certainly take planning and a bit of care, the many benefits of
these newer systems is well worth the trouble. And, if that’s not a good enough
reason, the fact that NT will effectively be unsuitable for use on the network
within a few months should provide ample reason to pursue the upgrade.
David Bianco (bianco@jlab.org,
x5268) 
As you may have heard, RedHat has announced
that they are dropping support for their free Linux product, RedHat Linux,
preferring, instead, to concentrate on corporate customers (with a targeted
RedHat Enterprise Linux product). RedHat
has announced the end-of-life of all RedHat distributions up to and including
version 9. RedHat will cease support for version 9 on
One option would be to change to an entirely
new Linux distribution. This would mean,
however, tearing down and rebuilding our entire Linux infrastructure from
scratch. As we gave a strong preference to solutions based on current RedHat
technology, the two leading contenders were RedHat Enterprise Linux and the
community-supported Fedora project.
We first considered the community supported
Fedora Linux project. Sponsored (but not supported) by RedHat, this project can
most simply be described as a continuation of the RedHat Linux
Since Fedora Linux was not deemed a viable
solution, we evaluated RedHat Enterprise Linux next. Based on RedHat 8.0 (with improvements from
version 9), this is a stable platform upon which to build a computing
infrastructure that would enjoy vendor support for a minimum of 5 years. It supports most of the newer hardware and
software available, and can be integrated with RedHat's system management
solution, similar to SUS and SMS which we already use for the Windows side of
the house. Technically speaking, this is
a very attractive option, but it is also the most expensive. However, since most of the other High Energy
Physics Labs are facing the same issue, the Department of Energy has been in
negotiations with RedHat for more favorable licensing costs. This cost would need to be spread among the
various divisions at the lab each year.
Ultimately, the DOE negotiations with RedHat
resulted in a price for RedHat Enterprise Linux Workstation at an attractive,
and workable, cost. We have recently
purchased enough desktop licenses to support our current number of Linux desktops
(about 500), and will be developing a level 1/2 desktop build based on it. This build will be available by mid-December
and we encourage anyone running a version of RedHat less than 9 to upgrade to RHEL
3 as soon as possible. People running
RedHat 9 should also upgrade to the
The
Paul Letta (letta@jlab.org,
x5106)
On the October maintenance day, several of
the general purpose Unix login systems were upgraded to new hardware. Both
jlabs1 and jlabs2 were Sun E450 servers with four 250MHz cpus and 2GB of RAM. They
are now Sun E280R servers with dual Ultra III Sparc CPUs that run at 1.2GHz and
have 4GB of RAM.
Andy Kowalski (Kowalski@jlab.org,
x6224)
SILOA total of fifteen 9940B tape drives are now
installed in the SILO. The last five 9940B tape drives went into production
during October. All writes to the tape SILO are being made to 9940B tape
drives. The six 9840 and fifteen 9940A tape drives are being used as read only
devices. The 9940B tape drives have a
capacity of 200GB per tape and a transfer rate of 30MB/sec. This represents a
233% gain in capacity and a 200% gain in transfer rate when compared to the 9940A
tape drives. The table below lists the type and quantity of drives we currently
have in production and how they are being used.
|
Type |
Quantity
|
Capacity
|
I/O
Rate |
Use |
|
9840 |
6 |
20 GBytes |
10 Mbytes/sec |
Read Only |
|
9940A |
15 |
60 GBytes |
10 Mbytes/sec |
Read Only |
|
9940B |
15 |
200 GBytes |
30 Mbytes/sec |
Read and Write |
The following table shows the usage of the
tape SILO over the past 8 months minus any data migration activity.
|
Month,
Year |
Terabytes
|
Files
Requested |
Failures |
Percent
Success |
|
March, 2003 |
91.40 |
161,374 |
8,653 |
94.64 |
|
April, 2003 |
93.02 |
185,071 |
21,261 |
88.51 |
|
May, 2003 |
59.01 |
104,915 |
7,390 |
92.95 |
|
June, 2003 |
98.38 |
334,312 |
24,352 |
92.72 |
|
July, 2003 |
131.79 |
199,705 |
21,551 |
89.21 |
|
August, 2003 |
73.91 |
161,881 |
13,246 |
91.82 |
|
September, 2003 |
59.40 |
97,689 |
9,485 |
90.29 |
|
October, 2003 |
65.549 |
102,471 |
3,475 |
96.61 |
The majority of failures result from either
the clients (jput and jget) not being active to receive the data files and
cache servers failing during data file transfer. In the case of clients not being active, they
usually have been killed by the user (Ctrl-c).
In the case of failed cache servers, these are failures for files being
transferred from the data mover to the cache server at the time of the cache
server failure.
The last of the tower-cased systems have been
decommissioned from the farm. They were
dual Intel Pentium III 500MHz systems.
They have been replaced by 24 dual Intel P4 Xeon 2.6GHz systems. These new systems have 1GB of RAM and 120GB
of disk space for user jobs. The
Hyper-Threading feature of the P4 Xeon processor make the systems appear as
quad processor systems. These systems
run 6 simulations jobs instead of the traditional 3. As currently configured,
this increase results in the farm now having up to 738 running job slots. Limits and restrictions do, however, prevent a
single user from using all the available job slots.
Ifarml1 was replaced with a quad Intel P4
Xeon 1.4GHz system similar to ifarml3.
The ifarm now consists of 3 quad processor Linux systems and 2 dual
processor Sun 280Rs. With
Hyper-Threading, the Linux systems appear to be 8 processor systems to the
operating system.
Michael Haddox-Schatz (mschatz@jlab.org,
x5803)
The
David Bianco (Bianco@jlab.org,
x5268)
As you may have noticed, the Lab's default
web browser and email client are getting a bit long in the tooth. In the past,
we've settled on using Netscape as our standard for both browsing and email,
but we are now revisiting this choice. While Windows and Linux users are able
to take advantage of the newer versions of Netscape Communicator, our Solaris
and HP-UX users are left out in the cold. In the interests of making the same
features available to all our users and reducing support costs, the 
changing
the standard supported browser/email client recommendations from Netscape to
Mozilla 1.5.
“What the heck is 'Mozilla'?” you may be
asking yourself. You might not think you're familiar with it, but you probably
know more about it than you think. Mozilla is an Open Source project that
provides a full suite of Internet utilities, including a web browser, email
client, HTML editor and IRC chat client. If this sounds familiar, it should: Netscape
has been based on Mozilla technology since version 6! Netscape Communicator and
Mozilla offer many of the same features in an interface that is very similar to
what you probably already use.
That's not to say that there are no
differences. First, unlike Netscape, the latest versions of Mozilla are
available on all our computing platforms, including HP-UX and Solaris. Mozilla
also offers many new features that Netscape does not. For example, the browser
features integrated blocking that can end those annoying pop-up window ads forever.
On the email side, Mozilla has a built-in spam filter that learns the
difference between legitimate messages and junk mail. After a short initial
training period, you can configure it to automatically route junk email to a
special folder where it can be held for manual review or automatically deleted
after a few days. For those of us who get a lot of spam, this feature alone
could make it worth checking out Mozilla.
Mozilla is now available for all JLab CUE
machines. Under Unix, simply type “mozilla” launch and use to the software to
launch it. Under Windows, you can install Mozilla by pointing at
“Start->Programs->JLab CUE->User Installable Programs->Mozilla
1.5”. On either platform, it will detect the presence of your Netscape
configuration profile (only if you have used Netscape 6.0 or higher) and offer
to import your web and email settings automatically. Configuration details and
information for the Mozilla email client can be found in the
Marty Wise (wise@jlab.org,
x7214)
Everyone who is currently running Windows NT
4.0 will soon need to upgrade their systems to a newer version of Windows. In
general, there is very little reason to choose Windows 2000 over Windows XP, so
most people will be upgrading to Windows XP.
By now, I’m sure all of us have a collection
of horror stories of the problems we have encountered in the past while
tackling this process. I can’t even count how many times I have forgotten to
back up my address book prior to rebuilding, only to discover after the fact
that my system no longer knows who “sweetie” is. And if remembering to take
care of all of my data wasn’t enough to worry about, I also had to make sure
that the system itself was installed, configured, patched, etc. correctly. The
Additionally the
In the past, the process of installing
Windows, getting it patched, installing MS Office, common applications, etc.
has been very time consuming. It has also provided numerous opportunities to
introduce configuration errors either through misunderstanding or simple
mistakes. Speaking from experience – a simple typo in the wrong form field
during setup can turn an otherwise perfectly good system into an incoherent
mass of electronic parts. The new system is designed to allow users to rebuild
an existing system with a minimum of trouble.
Once rebuilt, the system will conform to the Windows Workstation
Configuration defined by the
For the most part, systems built at the lab
conform to a fairly simple basic configuration. Most users need Windows to be
correctly configured and they need access to a fairly small set of common
tools. A standard basic configuration for desktop systems has been developed. A
description of this configuration is available online at http://cc.jlab.org/docs/services/windows/WorkstationConfig.pdf.
The
Overall, the new build process is intended to
provide a stable, reliable windows desktop platform that is well integrated
into our environment. For users, this means a system that does what you want,
when you want, without a lot of hassles.
Microsoft has announced that security patches
for Windows NT4.0 will no longer be available after
|
Platform |
OS Revision |
Notes |
|
Sun |
Solaris 2.6 |
Support Ended |
|
|
Solaris 7 |
Not supported |
|
|
Solaris 8 |
Supported, default for new systems |
|
|
Solaris 9 |
Not supported |
|
HP |
HP-UX 10.20 |
Support Ended (except special cases) |
|
|
HP-UX 11.11 |
Supported, default for new systems |
|
Linux |
RedHat 6.2 |
Support Ended |
|
|
RedHat 7.2 |
Currently Supported, Default for new
systems |
|
|
RedHat 7.3 |
Not Supported |
|
|
RHEL 3 |
Support Beginning Mid-December 2003 |
|
Windows |
3.x, 95, 98 |
Not supported. Microsoft Security Fixes
ending |
|
|
ME |
Not supported. Microsoft Security Fixes
ending |
|
|
NT 4.0 |
Currently Supported, support ending |
|
|
2000 Pro |
Currently Supported |
|
|
XP Home |
Not Supported on site |
|
|
XP Pro |
Currently Supported, recommended for new
purchases |
The
Networks
Michael Memory (memory@jlab.org,
x6240)
As the
Heather Larrieu (hlarrieu@jlab.org,
x5067)
The past three months have seen the lab affected by several
significant worm and virus outbreaks.
MS-BLASTER, which propagates via the network, infected at least 63 machines
on site in its first week of propagation. Welchia followed with similar
infection rates. SoBIG, which propagates to vulnerable machines via email, has
been detected by the VirusWall 33,473 times. The annoyance to users on 
site for SoBIG was a deluge of notices indicating that the virus
had been removed from the incoming mail message. People who were infected by
Blaster/Welchia saw machine failures, performance issues, and in several cases
loss of network connectivity while
Why was the lab so significantly affected by these pieces of
malware? The answer is primarily end-user managed machines, including laptops
and home machines used to dial into the lab.
As a result of these problems, some changes were applied to the
network which helps to prevent home machines that are dialed into the RAS
server from infecting machines on site. This protection means that protocols
which communicate on the Microsoft network service ports will no longer work on
a RAS connection. Users dialing in can still use the web, email, and other
TCP/IP based services. The ability to browse the "Network
Neighborhood" or to print to on-site printers is no longer available. Similar
limitations were placed on the open conference network. In addition to these
network controls, we have been strongly suggesting the machines on site join the
centrally managed JLab domain to ensure that the machines are kept up to date
on critical patches and anti-virus capabilities.
These viruses wreak havoc all over the Internet. Home machines
have become one of the softest targets for hackers, and are very attractive to
worm/virus writers because they are in general not very well maintained. Here
are some things you can do to protect yourself and others from these and other
malware.
· ensure that its "realtime" protection mode is enabled
when possible
(NOTE: This can
incur a small performance penalty which gamers may notice)
· ensure that a complete system scan is done on a regular basis
· Microsoft has the automatic update system for XP and W2K
machines or visit http://windowsupdate.microsoft.com
· Macs have a similar automatic update for MacOSX
· RedHat Linux has the RedHat network and rpm based patching also
with some automation
BONUS TIP: If your machine is running poorly, you might just
have Spyware/Adware on your machine. See the Spyware/Adware article in the July
version of the Computer Center Newsletter.
David Bianco (Bianco@jlab.org,
x5268)
As previously announced, the
The
number of Windows machines increased from 500 last year to about 650 this year,
though the percentage of Windows machines on the entire network remained at
about 22%. The number of Solaris machines increased by 50%, from 50 to 73, but
overall Solaris accounts for a mere 1.8% of all devices on the network, down
from 3.3% last October. HP-UX use seems to have declined over the last year,
with 109 machines (3.9%) showing up on this year's scan, down from 154 (6.9%)
last year. Linux showed the largest increase, from 550 devices last year (25%
of the network) to 1000 this year (35.5%). The remainder of the network, about
40%, is composed miscellaneous devices, including printers, X terminals,
switches, routers and wireless access points. In addition, there were 398
devices (14.1%) which could not be classified automatically into one of the
preset categories
Todd Coates (tcoates@jlab.org,
x5337)
During the last three months,
Descriptions of the latest ME CAD related
software upgrades and installations are provided below:
I-DEAS
10 NX Series - JLab’s I-DEAS installation was upgraded
from I-DEAS 9m2 to I-DEAS 10m1 at the end of August. I-DEAS is the primary ME
CAD design software in use at JLab. The I-DEAS software, which is used for both
2-D and 3-D design work, is provided via central network servers on the JLab
CUE network.
Electronic
Job Ticket - The Accelerator Division’s Document
Control Group (DCG) recently announced the completion of their efforts to scan
all of their stored drawings into PDF format. All of the JLab drawings that are
under DCG control are now stored in PDF format. All future drawings that are
submitted to the DCG for processing will be scanned to PDF as part of their
normal processing. These drawing PDF files are available for viewing and print
submission from a web interface, through the DCG’s new Electronic Job Ticket
software. Interested parties should reference the DCG home page http://www.jlab.org/accel/doc_controls/ahomedcg.html
for more information on using the Electronic Job Ticket software to access JLab
drawings.
Acrobat
Reader 5.0 - The Acrobat Reader software for HP-UX has
been upgraded to version 5. Acrobat Reader is used to view drawings that have been
stored as PDF. Version 5 allows for more control in manipulating the displayed
drawing images. This upgrade is particularly important in light of the recent
DGC announcement that they have recently finished scanning all of their stored
drawings into PDF format.
Mozilla
1.5 – New web browser software, Mozilla 1.5 has
been installed and is available on HP-UX 11i. The
Java 1.4 – Java 1.4 for HP-UX was installed to support the new features that are available in the new Mozilla web browser software and in the latest version of the I-DEAS software. The I-DEAS application uses Java applets in its online help.
Lois Lucas (lucas@jlab.org,
x7361)
Telephones:While it is true that you can dial the
Newport News Emergency Services by dialing either "9 911" or "911"; you must
understand that there will be a 10 to 15 second delay if you choose to dial
"911" without the access code,"9" first. This is because
the phone system is looking for the usual seven or eleven digit number that
would normally be dialed after dialing the "9" to obtain an external
line.
The reason we have programmed this option is
to assure that if a caller is in a panic situation and forgets to dial the
"9" before the "911" the call will still go through.
Remember: dial
"9 911" for faster connect time.
If you are sending a page do not put
"911" in your message unless it is truly an emergency. Emergencies would consist of any situation
that is or has the potential of becoming life/property threatening. If the
situation is a life-threatening emergency, you should dial "9-911"
and/or the Guard House at extension "4444". The guard will then
contact the appropriate personnel for the emergency.
To page someone to give you an immediate
response: dial the pager number, wait for the tone to type in the number you
would like them to respond to, press * (will show a blank space on the pager
display) and then "9999" and "#". Putting in
"9999" will tell the called party that while his or her immediate
response is needed, it is not a life-threatening situation. Putting in the extra space on the display
between the extension number and the "9999" simply makes it easier to
read the page. Continually inputting "911" in your urgent pages, will
cause people to start ignoring the 911 part in the message when it is a real
emergency.
Paging Tip: When you want to digitally page
someone to call you at an extension or phone number that they may not
recognize; input the number you would like them to call, followed by,
"*" and then your extension number and then "#". This will
indicate what number you want them to call and that it is you who is paging
them.
The Computer Center (Trailer City, x7456)
provides computing support for the scientific program, as well as general
computing services and support to the laboratory, including desktop computing,
administration computing (Business Services, Human Resources), and network
infrastructure. The group also provides Telecommunications support (phones,
pagers, etc.), coordination of CAD computing activities, and is responsible for
all cyber security functions. Other computing activities within the laboratory
include the Accelerator Controls, Data Acquisition, High Performance, and MIS computing groups.
Requests for support can be submitted via email (helpdesk@jlab.org), or from the Computer
Center Problem Reporting (CCPR) system available onsite via the web for
support. Additionally a
For
critical emergency assistance during after hours (i.e. major systems or
networks down, problems affecting the production experimental program), please
contact one of the JLab Security Guards (Main Guard, Gatehouse, 757-269-5822)
who will contact the Computer Center on-call staff.
Other sources of
information in CUE are the news messages available on login, and the
For
users who have purchased Dell, or Micron 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.
The Computer Center
Computing Weekly News mail archive can be found at:
http://www.JLab.org/ccc/mail_archives/ALERTS/cc-weekly/CURRENT/.
The
Computer Center Scientific Computing Briefs mail archive can be found at:
http://www.JLab.org/ccc/mail_archives/ALERTS/jl-scicomp/CURRENT/.
If
you have ever been caught off guard by the unavailability of any central
computing resource you probably are not subscribed to the outage-alert@jlab.org mailing list.
This mailing list is used to make notifications of computing outages that are:
Further
the outage-alert mailing list is used to provide notification of the end of
unplanned outages and provide details concerning the resolution of the outages.
Basically if you wish to keep informed about computing resource outages you
should subscribe to the outage-alert@jlab.org
mailing list as it is the front line notification mechanism for the
Send
a single line email message to majordomo@jlab.org
(the subject line does not matter) which has the following content:
subscribe
outage-alert
If
you have successfully subscribed to the mailing list you will receive an email
notification indicating such, and you will begin to receive outage alerts the
next time that one is sent out. Further information regarding mailing list
subscriptions can be found at http://cc.jlab.org/docs/services/email/How_to_Subscribe.html.
The
archive of previous
This document is maintained by {helpdesk@jlab.org}
Copyright Jefferson Lab 2007