|
Computer Center News
|
Issue
3 |
September 1999
|
Data
Storage
Many
upgrades are taking place in the areas of data storage and batch farming. In the month of July, the tape
silo robotics were upgraded and new tape drives were installed. An additional 25 farm nodes were
ordered and have been installed, and a further 2.5 Terabytes of RAID disk
purchased for the work and staging area file servers.
The tape silo was upgraded from a StorageTek
4410 to a model 9310 (Powderhorn).
The upgrade included new robotics, controller units, and a license
upgrade to permit the use of all 6000 tape slots. The older robotics were capable of making 195 tape mounts
per hour, the upgrade brings this to 350 mounts per hour. The newer robotics are required in
order to make use of the latest tape drives.
Tape Silo New
Robotics
The new drives are
StorageTek model 9840. Five of
these drives were installed in the silo alongside the existing 8 RedWood
drives. Their installation
required the replacement of part of one of the silo walls. The 9840 is a
mid-loading, linear tape drive, while the RedWood is a helical scan device. Tape load times for the 9840 are a
fraction of that of the RedWood.
In addition, the 9840 drives are physically smaller than the RedWoods
such that a single drive wall can hold 20 devices in the same space as 4
RedWood drives. Another advantage
of the 9840 drive is lower cost. A
9840 drive represents only 25% of the cost of a RedWood unit. However, 9840 tapes have a capacity of
20 Gigabytes, or 40% of the capacity of the Redwood tapes. The I/O rate is comparable at 10
Megabytes per second.
In order to make
use of these new tape drives, a second Mass Storage Server is being assembled
and the tape access software modified.
The new drives should be available for general use toward the end of the
year. The proposed initial use of
these new tapes is for frequently accessed DST-like data.
The additional RAID disk is shortly to be installed, with 500 GB being added to the staging areas, bringing the total staging space to 1 TB, and adding 2 TB to the work areas giving a total of some 4.5 TB of work and cache space.
Batch Farm
An additional 25
dual, 500MHz, Pentium III, Linux systems have been added to the farm. The Linux systems in the farm now
represent about 2562 SPECint95.
The new machines are configured with 256MB of memory (the older systems
had 128MB).
We expect to
purchase a similar increment to the farm (25 more dual systems) early in 2000.
The farm currently consists of 75 dual processor Linux systems, 5 dual processor Solaris machines and 4 dual processor AIX systems. The Linux systems represent 97% of the total CPU power available. We intend to withdraw the AIX systems from the farm in the near future as maintaining them is no longer cost-effective.
Usage statistics
for the farm and tape system are available online at http://www.jlab.org/CC/sys_network/farms/stats. The graphs are updated every 5
minutes and show current and historical queue occupation, cpu usage etc… Accounting records for individual and
group usage of the farm are updated weekly and are available at the same URL.
Figure 1 Jobs running (solid) and queued (line) during
the past week
Figure 2 CPU utilization of Linux nodes over the last month
Figures 1 and 2
above show some examples of the statistics available.
The interactive
Linux systems (ifarml) were upgraded with the replacement of the old single
processor ifarml1 by a 4-processor 500 MHz Pentium III Xeon system. This new system is equivalent in power
to both of the Sun 4-processor (ifarms1,2) systems combined and has 1 GB of memory.
Networking
Over
the past several months the Computer Center Network Team has completed numerous
enhancements to the local area network. The largest and most difficult job was
the re-wiring of CEBAF Center with category five (CAT5) twisted pair cable.
This project was started over the Christmas shutdown of 1997 and wiring has
continued over practically all of the major holidays since then. The wiring
itself was completed in January of 1999. All users were moved to switched
connections by May 1999.
A
milestone was the installation of three new Foundry gigabit routers. The
original Cisco 7500 series router was reaching its limits, and a new generation
of router was needed to deploy a redundant gigabit backbone across the site.
The installation of the new routers was completed over the weekend of June 5,
1999. Gigabit Ethernet connections are now running to the Counting House,
Trailer City, the Silo and Farm networks, and to all of our high-end Ethernet
switches. We will be expanding the gigabit backbone to other buildings over the
next year. The old Cisco router was installed at the Machine Control Center and
is now the core router for the Accelerator Controls networks.
Another project just completed is the
re-wiring of Trailer City, moving all occupants to switched network
connections. With the move of most of the Physics users into Trailer City an
upgrade of this network was required. With the addition of the gigabit uplinks,
users will now be able to analyze data on their desktops without causing
network disruptions for the entire Trailer City network.
The second floor of the Counting House
will be the next CAT5 wiring project, followed by the EEL and Testlab
buildings.
The
Appletalk protocol used by older Macintosh systems and Apple devices (printers)
will be removed by the end of the year.
Almost all the devices that currently use Appletalk can be upgraded to
run the Ethertalk protocol over Ethernet.
There are a very few devices that will need to be replaced. The owners of all affected systems have
been notified and assisted with an upgrade.
At the moment the Computer Center supported Unix systems are:
Presently
the AIX systems are not used very heavily, and they represent a very small
fraction of the computing available (2 old central systems and ~1% of the CPU
power available in the farm). We
intend to therefore withdraw the AIX systems from the farm immediately; we are
not renewing maintenance contracts on any of the AIX systems and will close
down central AIX services in due course.
In the interests of
stability we do not intend to move towards later operating system versions for
the present. We currently expect
to introduce RedHat Linux 6.x into the central Linux services early in 2000.
The Computer Center manages the laboratory's
ADP strategy in accordance with DOE requirements and good business
practice. As part of that strategy
we limit support to as few different types of systems as possible consistent
with our mission and goals. This has
always been the case for the scientific systems where we currently support HP,
Sun, IBM, and Linux, but not for example, SGI, Digital Unix, etc. This strategy
evolves with time in response to both changing requirements and external
factors such as computing directions taken by industry and other laboratories
as well as price, performance and so on.
Thus, we have recently decommissioned VMS and Ultrix, but have begun to
support Linux and are considering decommissioning IBM-AIX.
The
same is true of desktop systems: we must make efficient use of the Lab's
resources by limiting the types of systems for which we provide full support.
The rest of the world has standardized on Windows on PC's as a business desktop
environment. Obviously, there are
certain applications and industries with specific needs where other systems
such as Macintosh have been essential, but Windows has by far the largest
market share. We are no different
from the rest of the world in that we have to provide a standard desktop
environment that allows straightforward collaboration, document sharing and so
on, that is also easy to maintain and administer. These requirements are met by standardizing on a single
system, but with the flexibility to have other desktops available where
necessary. We have standardized on
Windows NT in alignment with industry as well as with most other DOE and
physics labs in this country and in Europe. Obviously we have other specific needs. For instance, as a scientific desktop
Linux has become the system of choice for many, and for some applications such
as desktop publishing etc. Macintosh has been the preferred system although 
this is becoming less
and less true.
In
the past 18 months we have strengthened our desktop environment, based around
Windows NT. However, we are unique
in that our central file servers allow our users to have completely transparent
file sharing between Unix and PC's and all users have a single home directory
equally accessible from either world.
As an extension to that we have provided group areas shared by
workgroups to facilitate collaboration between colleagues. Since the introduction of that
environment (CUE - Common User Environment) we have invested several FTE-months
of effort to make the file sharing work on Macintosh systems. That facility has now been available for
several months, allowing files to be transparently shared between PC, Unix and
Macintosh. In addition significant
effort has been invested in ensuring access to printers from Macintoshes. We are presently working to permit
access to file server home directories from desktop Linux systems without compromising
security, which will allow us to extend the CUE environment to those systems.
From
the point of view of support and troubleshooting, the Computer Center hardware
and user support groups actively support all of these desktop systems. During the past year we have sent three
of our staff on training courses for Macintosh support so that we are able to
provide both hardware and system support for Windows PC's, Macintoshes and
Linux desktop systems.
Users
of desktop systems who do not wish to participate in CUE may certainly operate
stand-alone systems, but should realize that they will be denied access to most
network resources (as the users will not be authenticated) and that support
will necessarily be limited.
This is and will remain our standard PC-CUE
desktop environment. This is where
most of our desktop support effort will be focused and will be the environment
that we invest in for new applications and facilities. Today there are very few Windows
applications that will not run under Windows NT. Windows NT is even well supported on laptops now, with
software that permits almost-hot swap of certain PCMCIA devices. This support will continue to
improve. There is a lot of rumor
that NT does not do this or support that, but mostly that is no longer
true. In addition, NT is far more
secure as a network operating system than Windows 95 or 98, and that is of
critical concern to us.
We
will begin to evaluate Windows 2000 as it becomes available and stable. We will not approve purchases of
Windows 2000 systems or support them until we are satisfied that it is stable
enough and can be integrated into our environment. We expect that to be a year away at least.
Windows 98 and older have serious security
shortcomings (in fact almost no security features at all). Worse, in order to support those
systems in our central environment the security of the NT systems is
compromised and if users have the same passwords on Windows and Unix systems
then Unix password security is also compromised. This is not an acceptable situation in the present climate
for a DOE lab. Therefore we are
planning to withdraw support for Windows 95,98 and older versions by June 30,
2000 or earlier if possible. After
that time, we will not permit those systems to be part of the central CUE
environment - which means access to any network resources. We will work with groups to advise and
assist them in the transition to NT systems. There are still a very few specific applications that may
only run on Windows 95. We will
assist in devising appropriate solutions to those problems. That solution could be an upgrade to
Windows 2000 (which is advertised as an upgrade path from Windows 95 but that
remains to be seen). We urge
groups to start planning on these upgrades - perhaps as line items in their
FY2000 budgets. Newer systems will
require only a software upgrade, some older systems may need to be replaced as
NT does require more memory and does work better on Pentium or newer
processors. We also urge groups
with applications that they believe run only on Windows 95 to check with the
supplier to determine whether a version does exist for NT.
The situation with
Macintoshes is slightly different and will be discussed separately for the
short term (one year) and the longer term. At the moment we support existing Macintosh systems at the
same level as we support PC and Unix systems. This policy has not changed for several years. We stock a small amount of routine
spares (e.g. power supplies), and our technicians will troubleshoot and assist
with hardware problems. For a
period of about a year we had very little in-house expertise with Macintosh
systems. However, in the last 6-9
months that situation has improved dramatically as new staff have been hired
and trained. Our support for
Macintoshes is currently at the same level as that for PC's, and implemented in
the same way - via requests or trouble reports to the helpdesk.
In
the longer term the situation is less clear. We cannot guarantee the continued compatibility of
Macintoshes with our environment, as they tend to implement things
differently. We cannot be limited
in the development of the central environment for the majority of users in
order to retain compatibility with Macintoshes for a minority. In order to make the present generation
of Macintoshes compatible with the rest of our environment we have had to
expend considerable development effort for relatively few users. Additionally, Macintoshes tend to lag
behind in application support (for example Netscape and Java), which has a
direct bearing on the usability of many of the newly developed MIS web-based
applications and 3rd party software that we would like to provide as
part of CUE.
Our
policy
We
will continue to support Macintoshes at the present level for the lifetime of
the existing machines.
·
If
you have a Macintosh and want to keep using it in CUE, then it needs to be running
either MacOS 8.5 or higher (for PowerPC systems) or MacOS 7.6 for older
hardware. These versions will run
the latest versions of Netscape and allow you to run the standard web
applications. We will not support
earlier OS versions, except to assist in upgrades. We will organize a bulk purchase of upgrades to obtain
preferential pricing.
·
We
will not automatically approve the purchase of new Macintosh systems except for
specific identified and justified needs. If you are purchasing a new system then
we encourage you to contact the user support group (x7729) to discuss your
requirements and the support issues involved and whether those needs may be
better met with a Windows NT system.
With a Macintosh you will likely not get the full benefit of the central
CUE environment and continued compatibility with that environment cannot be
guaranteed.
·
We
will review this policy as new major revisions of MacOS are announced; for
example if Macintoshes become more compatible with "standard"
protocols then we might consider again approving open purchases.
Desktop Linux systems
have not yet been fully integrated into CUE, as there are problems with
authenticating access to the central file servers from Unix systems that are
not centrally managed. We are
presently working to devise a solution to this problem, with the goal of
eventually being able to provide a full CUE integration for stand-alone Linux
desktop workstations. We do
provide access to applications and general site utilities as well as system
configuration tools and utilities.
In terms of support, the hardware support for these systems is at the
same level as for any other PC system: the system should be purchased
preferably with 3 year on-site maintenance. We can assist in troubleshooting hardware problems. System problems will be handled in the
same way as any other system - via the helpdesk.
We
are negotiating with several vendors to provide custom pre-configured Linux
systems that may be purchased on the web in the same way as we have recently
done with Dell and Gateway for NT systems. More details will be published about this as they become
available.
The Computer Center
has been in the process of evaluating system management software for Windows
based PC’s for several months. The final result of this evaluation has been the
selection of the System Management Server (SMS) package from Microsoft. This
package will allow the Computer Center to provide better and increased support
for the Windows based PC’s here at Jefferson Lab, both remotely and from the
local desktop. The Computer Center plans on implementing SMS in a phased
implementation over the next several months.
The overall goal of SMS is to reduce
the time and system management costs that are associated with the maintenance
of Windows based PC‘s. SMS achieves this goal by helping to install and
maintain operating systems, install and configure applications, and discover
system configurations. The
Computer Center has been testing SMS in great detail and has concluded that it
is the correct tool for improving both the quality of service and reliability
of PC’s at Jefferson Lab.
SMS is a key component in Microsoft's
Zero Administration Initiative for Microsoft Windows operating systems. It
provides tools such as hardware and software inventory, software distribution
and installation, and remote diagnostics.
These tools will allow users to better manage their computing environments
and give the Computer Center an edge in system administration for PC’s.
Remote
management of Windows based PC’s by the Computer Center using SMS will only
occur for those users who have given permission through the SMS client
software. Allowing the Computer Center remote management capabilities will
reduce the amount of time required to troubleshoot and correct problems,
thereby reducing work stoppage and delays because of PC problems. It will be
the decision of each user whether they wish to have remote management enabled
and if you do not want this added capability you can choose not to enable it.
An additional
feature that is provided by SMS is the capability for the Computer Center to
remotely install new software.
Additionally the SMS client software will allow users to view and select
new software for installation. If
the software has already installed there is information reflecting the presence
of the installed software. SMS
will allow the scheduling of software installations to prevent interference
with daily work schedules and projects, automatically installing new software
and allowing software versions to stay current. Software updates can be
scheduled for any time and do not require any interaction other than the
initial scheduling on the part of the user. Also, SMS eliminates confusing software installation
questions and options. All users
have to do is schedule the install and everything else is automatic.
Software and
hardware inventorying is another benefit of the SMS package. If SMS client
software is installed on a JLAB domain PC, a software and hardware profile for
that PC can be generated. The
information from this inventory can be used by the Computer Center in the
diagnosis of problems to check for currency of software, driver compatibility,
and many other specifications.
The implementation
of SMS at Jefferson Lab will benefit both users and administrators of Windows
based PC’s. It will provide
improved management, currency of software, enhanced troubleshooting
capabilities, and it will decrease the amount of time needed by users to manage
their desktop Windows based PC.
As reported in a previous issue the Computer
Center and Procurement departments have negotiated a basic ordering agreement
with Gateway and Dell for new PC purchases. Dell and Gateway have both now
provided web pages for Jefferson Lab users to browse, configure and purchase
new systems. Instructions for purchasing systems from these vendors can be
found online at http://cc.jlab.org/desktop/docs/pc_purchase.html,
together with recommendations for the type of system you should purchase, and
how to get the system up and running in our environment.
The
latest basic standard configuration available is similar to the following:
·
Intel
Pentium III processor 600 MHz
·
64
Meg of Ram
·
Keyboard
·
MS
Intellimouse
·
17"
monitor
·
8
MB video card
·
13
GB Ultra ATA hard drive
·
1.44
MB floppy
·
Windows
NT 4.0 operating system
·
3Com
3C900B Combo NIC
·
40X
Max Variable CD-ROM drive
·
Sound
card
·
Speakers
·
MS
Office 2000 Professional bundled Software
·
3
year next business day on site service.
Certain
optional upgrades are available (e.g. for the monitor, memory etc.)
Also
now available from Dell is a standard hardware configuration pre-loaded with
RedHat Linux 6.0.
Unlike the Windows 95/98 operating system,
Windows NT does not allow the creation of boot disks for purposes of recovery
and repair should the operating system fail. There is however a method to
create a repair disk for each user that should be taken advantage of at the
earliest convenience. The procedure is as follows:
1. Install a 3.5 floppy
in the A drive, Warning: all data will be erased in the creation of system
specific Repair Disk.
2. Select Start.
3. Select Programs
4. Select MS Dos prompt
5. From prompt
Type: Rdisk /?
6. Select Create Repair
Disk
7. Acknowledge erasure
of all data on disk.
8. Await completion of
formatting, system polling, creation of user specific repair data.
9. Select Exit
NOTE:
The creation of an NT Repair Disk creates a user-specific disk that is
security sensitive, and as such should be treated accordingly. The user should safeguard the storage
of this disk!
This article is the first in a series that will present information about computer security at Jefferson Lab. It is addressed to all computer users at the Lab and does not assume that the reader is an expert in system administration or any specific application or type of system.
Why
is Computer Security Important to You?The advent of the
Web and ready access to the Internet has brought an incredible array of
resources to each of us. In
addition, the basic bi-directional nature of the net has exposed our own
machines and data to the world.
This has its benefits and disadvantages: we can present our work and ourselves to the world in a
pleasing and controlled way, while at the same time we must guard against
unwanted intrusions, breaches of our privacy, and damage to our work, whether
hostile or inadvertent.
Each of us has a
stake in maintaining good security in our working environment. A compromise of our computing
environment can lead to loss of time and data and a general disruption of
operations. Such an episode took
place in August of 1997 when we were "off-line" for nearly five days
in order to clear our systems of an intrusion and to physically distribute new
passwords to every computer user.
Even if you don't rely on a computer to accomplish your daily work,
there is still information important to you (e.g., pay records, evaluations,
health records, etc.) that should be available only to authorized
individuals. Protection of your
"electronic identity" is also important if someone breaks into your
account and makes use of your machine to send mail or launch attacks against
other sites, you may well become the object of unwanted attention.
The front-line
protection of our computers and networks is the responsibility of the Computer
Center. The authority for this
task comes from the Director, who is responsible to DOE for all site
security. The Computer Center
provides the basic technical and operational support to minimize unauthorized
intrusions into, or use of, our systems.
The level of effort devoted to this task is based on an assessment of
the risks associated with the compromise of our operations by intentional or
inadvertent actions of authorized or unauthorized users. In addition to administration and
monitoring of the central systems and network, the Computer Center provides
policy, procedures, and guidance to the Lab's community.
Our
computer systems and applications can normally be assumed to operate in a
secure manner, though some are better than others. Some applications are well designed with respect to
security, but not well implemented, while others are simply poorly
designed. However, even good
systems can be open to compromise due to poor procedures or lack of
understanding on part of administrators or users.
Thus, the
fundamental protection of our environment then comes down to having good
systems, keeping them up to date, and knowing how to use them. The Lab's strategic needs for
computation and data storage are being developed with security as a primary
criterion. Routine operational
procedures include the monitoring of "hacker" and security mailing
lists and the prompt correction of vulnerabilities in our central systems. Critical security information is sent
via in-house mailing lists to individuals and groups who manage their own
systems so that vulnerabilities can be reduced.
Knowing how to use
your system and maintaining an awareness of security issues is your
responsibility. Taking advantage
of the information offered by the Computer Center and other information centers
will make this task easier. This
article will point out some of the weaknesses of various systems or
applications and suggest practices that can minimize the risks.
Safe
SixThe following six items (well, there might be seven …) will highlight some issues that can make or break our security efforts.
Secure Login and
Mail Programs.
Some traditional network applications send passwords across the network
in clear (unencrypted) text, which is visible to "sniffer"
programs. Installing a sniffer (a
program that can monitor raw network traffic) is one of the main goals of a
system cracker. This allows the
cracker to collect a list of passwords used by people on the net, thus giving
him or her ready access to more machines.
On site, we are reducing the number of networks that are susceptible to
sniffing, though we still have some portions of our net that can be sniffed if
an intruder (or a disgruntled employee or visitor) installs a sniffer. We have no control over off-site
networks; the open networks on academic campuses are favorite targets for
sniffer installation.
Nearly all of the
intrusions in the past two years have started with a login by the cracker to a
valid account using a compromised password, probably one that was
"sniffed" at another site.
Three things will help us reduce this type of entry:
1)
Use a secure utility for all logins and file
transfers, both for local use and when working to and from an off-site
machine. For information on secure
login utilities, see these secure shell documents: http://cc.jlab.org/desktop/unix/docs/ssh.html
for UNIX, http://cc.jlab.org/desktop/winnt/docs/Teraterm.html
for PCs, and http://www/datafellows.com/download-purchase/
for PC's and Macintoshes (this is a commercial product).
2)
For mail reading, use a browser with a secure
IMAP feature, such as Netscape or Internet Explorer. See http://cc.jlab.org/services/email/.
3)
Use different passwords for machines in
different domains. If a cracker
has sniffed your password during a session to a central machine, he is likely
to try to use that password to get to any other machines that he finds
referenced in your files, e.g., to your desktop. Use different passwords for CUE, your desktop, and your
off-site accounts.
Strong Passwords. A frequent behavior of crackers who
have gained access to a system is to send a copy of the encrypted password list
to their own home system. They
then process this list with a password-cracking program that will break any
weak passwords. These provide
additional accounts on the target system that they can use for future
intrusions.
The primary
protection against a password-cracking program is to choose good
passwords. Passwords should be 7
or 8 characters long, contain upper case, lower case, and a number or
"special" character, such as '*', '&', etc. Since cracking programs actually use
on-line dictionaries as a source, do not use any real words. Such passwords can be hard to
remember. As a mnemonic, make your
passwords from the first letters of words in a memorable phrase like "my
wife delivered quintuplets on Friday afternoon" -- mwd5oFa.
As an aside, don't
give passwords to someone who calls you on the phone. JLab system administrators do not need your password (access
to all files on any system is open to that system's administrator). No one but you has any legitimate
reason to know your password. This
includes your colleagues. If you
need to share files, use your system's access control methods to provide shared
access.
Virus Checking. The Computer Center provides a licensed
virus checking and protection program (see http://cc.jlab.org/desktop/winnt/docs/NavNT.html
). Install it and use it.
Prompt updates. When a security or virus alert is sent
via News, the message of the day, or posted on the site's Security Alert page (http://cc.jlab.org/support/security/alerts),
you should promptly check your system and make the recommended updates. The Computer Center will normally
provide updated code within a day or so of the announced vulnerabilities (if
the vendor has been prompt in supplying it).
Lock
Up.
Any system that is left with an unlocked keyboard is open to
tampering. Most current desktops
have the capability of turning on a "screen lock" that requires a
password for subsequent access. Some, such as Windows 95, have little defense
against intrusion by someone who has physical access to the machine. This is one of the factors that are
driving the move to replace the early Windows systems with NT or, possibly,
Windows 2000.
Do Not Trust Email
for Privacy.
Electronic mail moves among many systems on its way to its
destination. The administrator of
any system through which it passes can view it. As a matter of policy at many sites, network traffic may be
subject to monitoring for security reasons (as it is here). Do not trust electronic mail with
anything that you would not say in public.
Back Up. The Computer Center provides daily
backups of your home directories on the central machines. However, the data on your desktop is your
responsibility. If you are a line
manager, you are responsible for ensuring that your crew has established and
follows good backup procedures. In
the world of computer users there are two kinds of people: those who have had a disk crash, and
those who will have a disk crash.
If you have topics
that you would like to have addressed in future security articles, please let
us know. Send email to security@jlab.org.
As
we approach “zero day”, the lab appears to be in good standing to face the Y2K
issue. Groups have taken inventory
of their equipment, and have been working to upgrade any systems and equipment
left that wasn’t Y2K-ready. Over the summer, the personal computers at the lab
have been checked so there won’t be big PC surprises when 2000 arrives.
The Computer Center plans to shut down all
non-essential machines by December 31, in case the lab does experience power failures
as a result of the Y2K problem. Only key services will remain operational. Watch our announcement status and
maintenance web page at http://cc.jlab.org/announce/status.html
for details.
PC date display: Several users have suggested clarifying
the date for Windows 95/98/NT. A simple change in the Control Panel / Regional Settings / Date style can
force the date display to be 4 digits, rather than the 2 shown by default. Changing this setting will eliminate
ambiguity when looking at a date displayed by the computer. Even if this change
is not made, errors do not result simply because the date is displayed as 2
digits when ’00 arrives. To see the year your computer thinks it is, check
Control Panel/ Date/Time.
We’d like to take this opportunity to remind
all staff and users of the resources available: Sandy Philpott is the site’s
Y2K Coordinator, Roy Whitney is responsible for the overall Y2K effort at JLab,
and Tom Hassler maintains a sitewide preparedness status. Each group also has personnel who have
participated to make sure their department is Y2K-ready. Also, a JLab Y2K web
page is located at: http://www.jlab.org/CC/cc_info/y2K_info
The Computer Center schedules monthly
maintenance periods in order to perform essential systems work. Normally these periods have to be
scheduled during the accelerator maintenance times, and are thus generally on a
Tuesday starting at 7:00 am. Longer extended outages we will usually try to
schedule after hours, at weekends, or during holidays. Maintenance day schedules are published
a month in advance at http://cc.jlab.org/announce/status.html
with details of work to be performed available generally a week in advance of
the maintenance day.
The Computer Center has recently purchased
new machines to upgrade the central web se
rvices.
Over the coming weeks, our current www.jlab.org machine will be replaced, and
the load distributed between it and several other new web servers. The new
machines are dual-processor 450MHz Pentium IIIs with 512MB of memory, and will
run RedHat’s Linux operating system with Apache’s web server. These should
provide significant performance improvements over the current single processor
Hewlett Packard 715 computer, which has been doing the job for the past 5
years.
Each of the experimental halls will get one
of the new machines to serve their hall’s web pages. Their own local Webmaster
will be able to make any required group-dependent changes that are not
implemented on the central web server.
We are also working with our site’s Webmaster
Karen Hokansson and the User Liaison office, to mirror the Lab’s web pages to a
machine that serves offsite Internet users. Separating internal and external access will provide
relevant pages as appropriate for the intended audience, making it easier to
keep internal information internal. Mirroring will also insure that any
wrongful changes to our web pages by a malicious hacker will be quickly
overwritten with good data. This is a very good idea, as some high profile
sites on the net know -- who had unwanted data visible way too long!
If you are a computer user at Jefferson Lab
you may at some point receive the following email message:
WARNING!!!
You have exceeded 95% of your quota on the central
fileservers. Should you exhaust your disk quota you will no longer be able to
receive Electronic Mail, and you may not be able to log in to fix the problem.
It is strongly suggested that you take steps to reduce your disk usage as soon
as possible. Contact the Computer Center Help Desk if you need assistance. The
Help Desk is reachable at x7155 (1:30 - 4:30 Mon-Fri) or on the web at:
http://www.jlab.org/CC/services/user_services/.
Thank you,
JLab Computer Center.
This is an
automatically generated email that is sent when you are approaching the limits
of disk quota for your JLAB computer account. This basically means that you are
filling up your allotted disk space on the central fileservers.
If you are able to log into your account you should
go in and try to clean up your home directory and subdirectories. Try to remove
as many large files that you no longer need, remove any temporary files that
may not be needed anymore, clean up your email folders removing any messages
that you do not need anymore, in general remove any files that you no longer
need to keep around. If you are unable to login, or you are unable to clean up
your home directory sufficiently contact the helpdesk as directed in the email
for assistance.
There are two different types of quota
systems in use at JLAB, personal quotas and group quotas. These quotas determine how much data
can be stored on the central file servers by an individual user or by a group.
Personal
quotas are assigned to every user.
This quota limits how much data can be owned by a particular user in the
/home filesystem. This is
typically all the files in your /home/<username> directory and all
of its subdirectories. This
includes your “J” drive on your PC that actually resides on the central
fileservers if you are part of the Common User Environment (CUE). This also includes all folders where
your email is stored when using IMAP mail. Files that may be in other user’s
home directories, but are owned by you still count towards your quota. Initial quotas on new accounts are set
at 50Mb. This can be increased to 100Mb upon request to helpdesk@jlab.org. For accounts that
require more than 100Mb, a Disk Resource Request form must be filled out which
justifies the need for more quota, and it must be signed by your
supervisor/sponsor and returned to the Computer Center helpdesk (TC RM 172).
Group
quotas are assigned to groups upon request to helpdesk@jlab.org.
Group areas are intended to be a place where several users can share files
easily. Access to group areas is
via membership in the appropriate group.
The group areas are found in “/group” on Unix and on the “M” drive on
your CUE PC. Initial group quotas
are 1Gb per group. Files in the
/group file system are counted towards the quota by group ownership, not
location. This means that files in
/group/aes only count towards the aes quota IF they are owned by
group aes. This has caused
some confusion in the past when users that are members of multiple groups
create files in one group area with group ownership of a different group.
All users can check the quota of users or
groups at the “Check CUE Quotas” page found from the Computer Center’s home
page (http://cc.jlab.org/, or directly at http://cc.jlab.org/cgi-bin/quotacheck.cgi.
Surge
Protection
An easy and inexpensive way to protect
computers and computer equipment from electrical fluctuations is the use of
surge protectors. In the past several months during severe weather a large
fraction of hardware failures can be directly attributed to lightning and/or
power surge related equipment damage.
Surge protection is a simple and inexpensive measure that minimizes
downtime and/or expensive repairs to electronic equipment.
Surge
protected power strips with several power outlets are available from the Stock
Room for a few dollars.
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 "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.
Pagers:
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.
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.
|
Obtaining Support |
|
|
General help (General questions, accounts, quotas,
etc) |
|
|
PC/Mac support |
|
|
Farms, mass storage, etc. |
|
|
Networks |
|
|
Informatics (e-mail, mail lists, netnews) |
|
|
MIS (etr, reqs, cis, etc.) |
|
|
Telecommunications (phones, pagers, cell phones) |
|
|
Or, go to: http://cc.jlab.org/support/
|
|
|
Helpdesk hours: daily 1.30pm – 4.30pm (tel. x7155) |
|
Or, go to: http://cc.jlab.org/support/
Helpdesk hours: daily 1.30pm – 4.30pm (tel. x7155)
This and previous
versions of the Computer Center Newsletter can be found at http://cc.jlab.org/announce/status.html
This document is maintained by {helpdesk@jlab.org}
Copyright Jefferson Lab 2007