|
|
Issue 12 |
November 2002 |
Power Outage and Home Fileserver UpgradeDuring
the Thanksgiving holidays the
After power upgrades completed on
For most users this move should be transparent as the
We do recommend that
JLab Windows PC users reboot their
systems upon returning to work after
the holiday upgrades have completed.
Additionally it will be necessary for users who have local Unix desktop systems configured for CUE to either reboot
their systems after the completion of the upgrade, or shut their system down
prior to leaving for the holiday. These systems would include:
Unix systems that utilize mount services from CUE that are
maintained by local system administrators, will need to have modifications made
to the /etc/fstab or /etc/auto* files to prepare for
this upgrade and any future fileserver/file system moves. For these systems we
are providing a list of descriptive fileserver/ file system aliases that should
be incorporated into these files to properly access centrally provided
fileservers/filesystems resources:
An example of the new aliases in use from our central
#
@(#) auto.u - CUE indirect automounter map for jlab
#
#
#
top-level autmounts for
site-wide (CUE) mounts (e.g. /u/site)
#
#
home -rw,actimeo=0
jlabhome:/home
apps -rw
jlabapps:/appsroot/$OSNAME$OSREL
site -rw
jlabsite:/site
mail -rw,actimeo=0
jlabmail:/mail
group -rw
jlabgrp:/vol/vol1
#
#=====
Misc. stuff
scratch -rw
jlabscr:/scratch
For
further information or details please contact Kelvin.Edwards@jlab.org.
Out
with the old!It’s
been about three years since the
|
Platform |
OS Revision |
Notes |
|
Windows |
Windows 3.x, 9x, ME |
Not supported, will no longer network on site in 2003 |
|
|
Windows NT4.0 |
Currently Supported, support ending 2003 |
|
|
Windows 2000 Pro |
Currently Supported |
|
|
Windows XP Home |
Not Supported on site |
|
|
Windows XP Pro |
Currently Supported, recommended for new purchases |
|
Sun |
Solaris 2.6 |
Supported, support ending 2003 |
|
|
Solaris 7 |
Not supported |
|
|
Solaris 8 |
Supported, default for new systems |
|
|
Solaris 9 |
Not Supported |
|
HP |
HP-UX 10.20 |
Supported, support ending 2003 (except special cases) |
|
|
HP-UX 11.11 |
Supported, default for new systems |
|
Linux |
RedHat 6.2 |
Currently Supported, support ending 2003 |
|
|
RedHat 7.2 |
Currently Supported, Default for new systems |
|
|
RedHat 7.3 |
Not Supported |
|
|
RedHat 8.x |
Not Supported yet |
Our
CUE servers will no longer support NETBIOS connections from Windows ME,
Windows9x (and earlier) clients. It should be noted, however, that TCP/IP
connections (browsing the internet, e-mail client connections) will still work.
Importantly, dial-up users will still be able to use these earlier OS versions
to dial in to the lab, however they will
not
be able to make direct connections to Windows-style resources using the windows
network browser. Neither will UNC (e.g. -- \\MYMACHINE\myshare) names work via
dialup connections for these users. These users will need to explore the use of
sftp to do file sharing from on-site to their
off-site systems.
These
changes will be included in the rollout of Windows 2000 server
In
with the new! Recently
the
On
the server side, the
We’ve
done a lot of work recently evaluating and understanding some of the problems
that we have seen with Windows over the past several years, and will
incorporate the result of this study into the new server deployment. Our
network and systems teams have worked together to gather detailed network
diagnostics, and have constructed a test network on which to evaluate our
results, and to test our design. Problems that you may have seen in the past
with the start button slowing things down, or the problems when a domain
controller could not be reached should improve. Significant emphasis has been
placed on stability and availability in the new design.
The
new system is still in the design phase and as such a detailed deployment plan
and schedule is not yet available. This information should be available before
Thanksgiving and information will provided through news, announcements, and an
installment in our next CC Newsletter.
I
may be asking for trouble here, but if anyone has any specific complaints,
suggestions, etc. please mail them to wise@jlab.org
. I assure you, I’ve heard a lot of them already (verbally or in e-mail – you
know who you are! ;^), but I’d rather get too much input than too little. So
let me know – particularly if it’s something that could offer consistent,
recurring improvement in your ability to work, or has offered significant,
recurrent impediment to you. Also, would there be any interest in an
informational seminar sometime in the January/February time frame?
The
The
The old printing system relied heavily upon vendor
supplied solutions. The Windows
platforms printed using their bundled Microsoft based print solution while many
of the different Unix flavors depended upon their vendor’s implementations of
previously established, well documented Unix based printing protocols. In fact, under the old system, the two sets
of solutions were entirely
separate. Windows users made use of
Windows based print servers (jlabn2, jwins1) while Unix
users printed via a Unix based print server (printsrv).
As a result the old printing system suffered many
problems. For one, the use of separate print servers meant maintaining the
operating costs associated with supporting the additional equipment. This made supporting both platforms more
complicated due to the high level of inconsistency between printing in Unix and Windows. Added to a list of incompatibilities
between the vendor implementations of Unix printing
software packages, the result was an overall degradation in printing
performance complicated further by a lack of effective printing administration
tools.
The new printing solution seeks to create a more
stable printing environment that capable of extending the greatest number of
printing features to the greatest number of computing platforms without
sacrificing ease of use.
The new printing system combines upgraded hardware
with a software compatibility layer to create a single consistent CUE
compatible printing interface for Unix while
maintaining backward compatibility with existing Windows clients. A single print server has been configured to
support both Unix and Windows printing protocols. As a result, the processes of using and
managing printers have been greatly simplified.
Windows clients may print to the new system using
the standard Add Printer Wizard, or the preferred method of locating the
printer in the network neighborhood and double clicking to install it. For Unix clients, a
new application, PDQ/XPDQ has been added to the CUE environment and is
available from all CUE machines.
In
order to print a file from Windows, you need to find the machine \\jlabprt
on the windows network neighborhood.
This can be done by opening ‘My Network Neighborhood’ or ‘My Network
Places’ on the Windows desktop and then entering \\jlabprt into the browser
window. From there, a listing of
printers will appear. (See figure 1)
Double clicking on the printer of your choice should
download the printer’s driver to your system and establish its connection. From this point on, the printer will be
available to your applications.
Installing printers functions exactly the same as it does for
installing printers from any windows print server. Currently, the total number
of printers available on JWINS1 is now available on jlabprt.
Some printers may be present but without device drivers. If you do not see a printer that you are
interested in listed, see the printer but it doesn't download the associated
driver to your computer, OR would like to have a printer added, you can request
the printer and/or driver be added by sending a print related CCPR.
Currently, no printers can be added site-wide for Unix users. Rather,
access to the entire inventory of Jefferson Labs printers is provided via the
new PDQ/XPDQ interface. The advantage of this interface is that it supports the
postscript printer definition files needed to access the extended features of
the supported printers.
Printers that are currently supported include:
Hewlett Packard:
LaserJet 4000, 4500, 4550, 4600, 4, 4+, 4mv, 4si,
5, 5si, 5000, 8000,
8100, 8150, 8500, 8550
Xerox/Tektronix:
2PXi, 550, 560, 740, 850, 860, 8200
Oce:
9400, 9600
Canon:
ImageRunner 2200, 2800, 3300
Although new printers are added by hand, PPD
support has made this process much quicker.
If you would like to see a printer added that is not supported above,
you can send the
The current system maintains compatibility with the
old system. As a Unix
printer server, all rlpr and (eventually lp) commands function essentially the same as they did in
the old system (TOS). The advantages
offered by the new applications (pdq/xpdq)
include:
XPDQ is a
non-daemon-centric graphical print system built upon a unix command pdq
which features a built-in, and sensible, driver configuration syntax. Both
include the ability to declare printing options. The GUI and command line tool
allows users to specify these options with either a mouse with which the users
get a nice dialog box in which to specify resolution, duplexing,
paper type, etc (See figure 3) OR command line configuration options tailored
for the selected printer.
To print using this command, simply
select the destination printer from the print window, then select ‘open file’
from the File Menu.
To change the printing options, simply
select ‘Driver options” (See figure 3) for the current printer and click on the
features you are interested in.
The job status will appear in the lower
window along with any errors that may occur during processing. If you desire more detailed status
information, right-clicking on your print job will display additional
diagnostics.
When passing over a feature in the
driver options window, the equivalent command line switch will be
displayed. This switch is used in
conjunction with the pdq command described below to set
extended printer features.
pdq is the command line
based utility with a functionality almost identical in practice to that of the
prior rlpr command previously employed for the same
purpose. Differences between the two include greater support for printer
features, client side postscript processing, and the ability to graphically
control and get the status of submitted print jobs via xpdq.
pdq
prints the listed files, or STDIN if none is listed. The printer is
selected with the -d or -P flag. If none is given, the job is sent to the
default printer. Driver options and arguments are specified with the -o and -a
flags respectively. Interface options and arguments are specified with the -O
and -A flags respectively. To show printer-specific options
and arguments, pass the -h or --help flag, and at the same time select a
particular printer with the -d or -P flag.
pdq can
be used as a direct replacement for lp and rlpr commands.
PDQ OPTIONS
-a VAR=value - Set driver argument VAR to value.
-A VAR=value - Set interface argument VAR to value.
-d printer - Send job to printer. (The -P option may also be used to select printer.)
-h, --help - Show summary usage. If no printer is selected, a list of available printers will be displayed. If a printer is selected, available options and arguments will be displayed.
-o option - Select driver option option.
-O option - Select interface option option.
Over the past months the
To use any of the video conferencing equipment the conference rooms in
which they are located must be reserved via normal channels by the individual
or group that will be using the equipment.
It is additionally the responsibility of these same users to provide the
ISDN phone number or IP address information of a video conference prior to
connection. For further details or information please contact Randy.Hartman@jlab.org (x6399).
In November, the
We hope that the
addition of this system will provide you with one more system for general
purpose computing.
Mail
Handling Procedures – Improving Email PerformanceCurrent mail-handling
procedures require that all staff retain all mail messages sent to them. The
extra messages that must be managed by the mail system have put a heavy load on
the central servers. We have added servers to our configuration to handle the
load. In addition, the following procedures will allow your mail reading to be
more efficient, while still conforming to the mail retention policies.
The following
configuration settings are presented in detail on the mail configuration pages
at http://cc.jlab.org/services/email/.
It is important that the settings be consistent for all the mail readers you
use to check JLab mail (e.g. from home, from school, from different
clients/machines on site.)
Normally, when a
message is "deleted" from a folder (such as "INBOX"), it is
simply moved to the "Trash" folder. The Trash folder can be manually
or automatically emptied -- in order to retain all messages, this is NOT
APPROPRIATE, so it was suggested that you not empty the Trash folder, but leave
it in place to keep copies of all email that did not get moved to other more
permanent folders.
Unfortunately, a
Trash folder containing many messages puts a large load on the mail server as
you move through your INBOX deleting messages. In order to have the advantage
of retaining deleted messages and having a responsive mail client, you
must routinely transfer the contents of the Trash folder to a permanent holding
area. This is done by creating a mail folder to hold all "deleted"
messages, for instance, one possible name is "Hold_until_further_notice".
At the end of each day, you file all the messages in Trash into your holding
folder and then compact folders and exit your mail client. This gives you an
empty Trash folder and should make your mail handling much faster.
Instructions to
create and use a holding folder in Netscape clients:
· In the mail server/folder selection panel of the Messenger client
· Right click the jlab.org account and select "New folder"
· Give the new folder a memorable name, e.g. "Hold_until_further_notice"
· Open the Trash folder, and select all (Ctrl-A or use the menu)
· Right click over the selected messages, and select "File" or "Move to" and select the desired destination folder. All messages in the Trash folder will be moved to the holding folder.
Once you have a small
Trash folder backed up by a holding folder, you should be able to delete
messages from your INBOX with greater facility. Like a large Trash folder, a
large INBOX causes more load than is necessary on the mail clients and servers.
By filing messages in appropriate subject folders and by moving unwanted
messages to Trash/Hold, your interaction with the mail system will be faster.
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.
Tape
MigrationOver 4200 of the 4500
Redwoods tapes have been copied to 9940A tapes. With the exception of a few
problematic tapes, all of the CLAS tapes, non-duplicate Hall A and Hall C
tapes, and the home tapes have been migrated to 9940A tapes. The migration of
data from Redwood tapes to 9940A tapes has been a huge undertaking and has been
a top priority for the
Effort in now being directed
toward retrieving data off of a few problematic tapes and the Hall A and Hall C
duplicate tapes. Once completed, we will
have moved over 200TB of data during 2002 while also handling the day-to-day
workload for the experiments.
Five new 9940B tape
drives will soon be installed in the SILO. These are the next generation of
tape drives in the 9940 series that have just been released on the market and
have a native tape capacity of 200GB. That is three times greater than the 60GB
tape capacity of the 9940A tape drives. The 9940B tapes drives use the same
tape media as the 9940A and can read tapes previously written to by 9940A tape
drives. This backwards compatibility will allow us to migrate toward the next
generation of tape drives without having to migrate
our data to a new tape format.
The addition of the
9940B tape drives will require some configuration testing to the data movers
and code changes to JASMine. The 9940B tape drives are only available with
fibre channel interfaces. Since JASMine makes use of Linux PCs for data movers,
testing will have to be done with different fibre channel controllers and
drivers. JASMine will also require some code changes to deal with the backwards
compatibility of the 9940B tape drive with 9940A tapes.
It is anticipated
that the 9940B tape drives will be put into production in the spring of 2003.
It is also anticipated that a second purchase of five 9940B tape drives will
have been made by the spring of 2003. This will bring the total number of 9940B
tape drives to ten and help ensure that their introduction into the production
environment does not create a tape drive bottleneck.
The oldest twenty
farm nodes (dual Intel Pentium II 400MHz systems) were decommissioned in July
and have been replaced with twenty new dual Intel P4 Xeon 1.8GHz systems. Each
of these new systems has been configured with 1GB of RAM and 120GB of disk
space for jobs.
These new farm nodes
use the Hyper-Threading feature of the P4 Xeon processor. This makes the operating
system think there are 2 processors for each physical processor. Since these
systems are dual processor, the operating system sees four processors.
Hyper-Threading does not increase the performance of a single non-threaded job,
it does, however, increase the overall throughput of the system and allow us to
execute more jobs per farm node.
Four new work file
servers replaced the aging Symbios file servers (fs3, 4, 5, 6). The Symbios
file servers had 100mbit Ethernet connectivity and a total of 4TB of disk
space. The new file servers are Linux based with gigabit Ethernet connectivity
and a total of 8TB of disk space. They also use the XFS file system from SGI.
XFS is a journaling file system that provides rapid recovery from system
crashes which simply means that a file system check is not necessary after a
system crash.
The Hall A and Hall C work disks previously located on the Symbios file servers. The performance issues of the five-year-old servers had become a problem for the Hall A and Hall C experiments. These new servers provide better performance, greater capacity, and eliminate the “Permission Denied” error messages users were seeing when they tried to use their work disk when the server was under heavy load.
Need a Linux workstation but don't have $1200 to spend? Maybe
you need only occasional access to a Unix desktop, or
perhaps you need to set up a computer in a common area but don't want to spend a
lot of time managing it? Or maybe you just have some old X terminals to
replace? The
A diskless Linux workstation is very similar to a full Linux
computer; it just has no local hard drive. All files, including the operating
system, are stored on our central file servers where the
These diskless workstations are no slouch in the software
department, either. Each is fully integrated into the JLab CUE environment, so
users have access to their central home directories, /apps, /work and /scratch.
In short, for most normal uses these diskless machines are indistinguishable
from full-blown Linux workstations. Some early users have described it as being
"like having ifarml1 on your desktop."
Ordering a diskless Linux workstation is very simple. Please see
the JLab PC Purchasing page at http://cc/docs/services/pc_purchasing/pc_purchase.html. From this page, go to the "Build to
Order" section and read the instructions on how to place an online order.
You can then proceed to the Build To Order site and
place your order for a "BTO Mfg P4 Slimline/Diskless Thin-Client"
system. With low-end prices starting at just $500 (including monitor), these
systems are well suited to a variety of uses.
Questions about the diskless Linux workstations can be directed
to David Bianco <bianco@jlab.org> at
x5268.
X-windows users on
site have long depended on our two font servers – CCH2 and CCH1 to provide
access to fonts needed by many of the X-based applications available in CUE.
Additionally NCD X-terminals and a number of printers get boot-time
configuration information from the “bootp” servers running on these systems.
CCH1/2 are currently among the oldest HP systems still
in use on site. Their time has come. We have two shiny new HP systems sitting
in the racks upstairs and we are preparing to put them in to service. Font
services will be moved to these new systems. Bootp clients will be moved to our
existing DHCP server system.
Currently, in your
X-windows configuration somewhere, you have a variable set that tells your X
server (typically your terminal or PC) where to locate any fonts that it may
need. Most terminals come with a pre-installed set of fonts, but X-windows allows you to configure additional fonts as desired, either
from your local filesystem, or from font servers on
the network. Your system currently should be set to look at the font sources
“tcp/cch2:7100 and tcp/cch1:7100” (probably in that order). Notice that the actual machine names (cch2
and cch1) are used and entered into everyone’s systems. Nowadays, it’s popular
(and smart) for us to use an “alias” for these font services. That way, if the
The new server
systems are going to be called – well, I’m not going to tell you, but the
aliases for them will be “font1” and “font2”. These two systems are available
now in “test” mode. We will continue to operate the legacy servers as our
“production” servers so the new systems can be tested. You can help us test
them by directing your X-terminal to use them during this test phase. You
should replace the entries reflecting cch2/cch1 in your font path with
“tcp/font1:7100” and “tcp/font2:7100” in order to use the new systems. Please
let us know if you encounter any difficulties.
Assuming no problems
are encountered in this testing phase, we will deem the new servers to be our
“production” servers. At that point, the central x-terminal configuration will
be updated to reflect the change, all of our documentation will be updated to
reflect these new aliases as the correct configuration on site, and all new
systems will be configured accordingly. This will occur on the November
maintenance day (watch the CC Maintenance Schedule for details). Note that for
NCD X-terminal users, your terminal may be updated automatically. If you
have not made modifications to your terminal’s configuration, and rely on the
centrally managed configuration, everything should take care of itself. It’s
only if you have made and saved changes in your NCD terminal’s NVRAM that you
will have to make this update manually.
We will continue to
operate the old font servers for a period of time to allow users to migrate
their client systems. By the first of the year, all users should have updated
the X-configurations accordingly. At that time, cch2 and cch1 will be shut
down.
When many X-terminals,
printers and other devices boot, many rely on a server on the network to
provide them with their network address, configuration data, etc. Most of our
NCD X-terminals and a few printers use “bootp” to do this. CCH2 and CCH1 have
also provided boot services to these devices. To prepare for the shutdown of
these systems, bootp services will be migrated to our DHCP server (the modern
version of bootp) during the November maintenance day. Now, the migration is
fairly straightforward, but there is a lot of detailed data involved, so it’s
likely an error or two may creep in. After the change goes in, if your terminal
or printer fails to boot, contact the helpdesk and we’ll get the problem
straightened out quickly.
These changes should
provide users with significantly improved boot and font performance, as well as
allow the
Did you know you are
the first line of defense for protection of your critical data from loss due to
local hard drive failure? Windows OS
users can create their own system Emergency Repair Disks (ERD) and the
NOTE: have a
formatted floppy disk handy before taking the following steps.
WinNT 4.0
Select:
Win2K
Select:
3. Accessories
4. System Tools
Mark date/time of
creation on the ERD and keep it in a safe place once complete – It may be the
only tool that saves your critical data
The Computer Center
Homepage located at http://cc.jlab.org/
is the place to find all the helpful FAQ’s available to help you be more
productive. Check them out!
Reporting
Computer Security IncidentsThis article is
intended to clarify what constitutes a "security incident" and what
procedures should be followed when you encounter possible security issues.
If you don't read further
than this, here are some basic guidelines for reporting security problems:
The most basic definition of a computer security breach is
"unauthorized access to computing resources." "Attacks" can be classified as
"undirected" and "directed." An undirected attack is one that does not
target a specific institution, but opportunistically invades whatever machines
it comes across. An example is an email virus. A directed attack is one that
has a specific target or goal, and often requires some kind of interaction
between the attacker and his or her target, though automated tools may be used
to probe a target network or computer.
Undirected attacks are more common, and, with proper computer
administration practices, are easier to avoid and eradicate. We rely on tools
such as our mail filter software and on keeping our knowledge and software up
to date to avoid newly hatched exploits.
Directed attacks may have a less predictable pattern and are
thus harder to avoid automatically. We
rely on watching the patterns of network scans that are directed against the site's
network and on monitoring our internal machines for changes in configuration
and programs. We also rely on astute
users who report unusual changes or access to their machines.
The next two items are problems that have been avoided, though,
in the case of spam, maybe only partially. These are things that do not have to
be reported to the
Our email-filtering tool is currently removing about 75 viruses
and 800 spam messages a day. We use the standard spam filters that are
automatically updated a couple of times a week by the vendor.
More restrictive filtering could be set up, but two problems
arise:
We ask that you simply place whatever unwanted messages actually
get through in your trash folder. If the spam is intensive enough, it will get
added by the vendor to the filters that we use.
Please note that if you do receive excessive amounts of
egregious spam and it continues more that several days, let us know, and we will
see if a specific block would be useful. Send the request to helpdesk@jlab.org.
CLEANED
OR QUARANTINED VIRUSESWhen our email virus filters have detected a virus, it will be
either cleaned or stripped from the message and "quarantined." This
is a fairly routine occurrence and does not need to be reported. You may wish
to notify the sender of the message that his or her machine is sending infected
mail -- this is not done by the virus filtering software. Note: if the elided
virus is the KLEZ virus, the nominal sender of the message is spoofed --
notifying the spoofed sender of the problem is not likely to be useful.
The incidence of virus infections should be very small, since we
provide a license for all machines with Microsoft software to run the Norton
AntiVirus package and we require that it be installed and operational. We have
had one instance of a new email virus being delivered to an internal machine
within the 4-hour window between discovery of the virus in the wild and
installation of the filter in our mail systems, but this should remain rare.
Questions about non-critical computer security issues should be
sent to helpdesk@jlab.org. As mentioned above, this allows several
things to happen:
If you feel you have a critical security problem requiring
immediate assistance, call the Helpdesk. If the Helpdesk cannot be reached,
call Bob Lukens (x6376), Heather Larrieu (x5067), or
Note that this list is for security issues, not for basic
operational or configuration problems.
If you are able to determine that your system has been
compromised (e.g., someone else is logging in as root or admin, you have extensive
changes in system files, etc.), then immediately disconnect your system from
the network. Do not shut it down or
reboot.
The
Trailers 34D, 34E,
35, 52A, 52B, and 52C have been upgraded to a switched 100Mbit Ethernet
infrastructure. These trailers previously had a shared 10Mbit Ethernet
infrastructure.
The two network
switches in
Within the
The Scientific
Computing network which serves the farm/’ifarm systems,
data movers, cache servers, work fileservers, and data silo has also been
upgraded. Changes were made to enhance performance by installing a new network
switch capable of supporting 120 Gigabit Ethernet devices. The new switch is
capable of supporting 10gbit/sec Ethernet connections when they become
necessary.
Future network
upgrades for FEL, EEL, Hall A, Hall C and the
Residence Facility are in the planning stage and will be implemented provided
the funding is available. Each will get upgrades to support switched networks
with greater bandwidth. Proposed changes also include upgrading the building
links from 100Mbit/sec Ethernet to 1000Mbit/sec Ethernet. The Residence
Facility may also be upgraded to provide enhanced security capabilities and
network performance.
Finally, the wireless
network will experience significant configuration changes and be expanded for
larger areas of coverage. Most of these configuration changes are required to
address security issues associated with wireless networks. Details of the
wireless network security improvements are still in the works as explained
briefly below.
Wireless networking
is rapidly becoming a day to day part of our work life here at JLab. Accessing
computing resources via the wireless network provides flexibility to our users.
In addition to serving our users in various locations around the site it also
supports our temporary guest and conference attendees. Operating with an “open” wireless network
does not provide the security needed, so the computer center has mapped out a
plan to improve wireless network security and still provide flexibility for
users who are only with us temporarily. The time to execute this plan draws
near and educating our users for an easy transition is a priority.
The following is a
brief description of the computer center’s plan. Wireless access points are the
means by which all wireless clients communicate with computer center
resources. Currently we have sixteen access
points spread across site in the following areas:
If budget
requirements allow we will be purchasing additional Wireless Access Points.
These new access points purpose will be to support the Lab’s users are
temporary in nature, such as conference attendees and visitors. They will be
isolated from the Lab’s backbone network, but visitors will still be able to
get to their offsite email and internet services.
During the month of
September,
The primary hardware platform
used at JLab for ME CAD work is the HP Unix
workstation. Mechanical engineering and design groups in both the Accelerator
and Physics divisions are using various HP Unix
C-class workstations in the production of their 2-D and 3-D design data. In September
the operating system on each of these workstations was upgraded from HP-UX 10.2
to HP-UX 11.11. This OS upgrade was necessary, due in part to HP’s recent
announcement that it was discontinuing its HP-UX 10.2 operating system. The OS
upgrade was also necessary to keep up with the increased hardware requirements
for the latest versions of the CAD applications being used at JLab.
The primary design
software that is used by ME CAD users at JLab is I-DEAS. JLab’s I-DEAS
installation provides I-DEAS software licenses to users from a central license
server as described in the summary that is provided below. In September the
JLab I-DEAS installation was upgraded from I-DEAS 8m2 to I-DEAS 9m2.
The figure below
illustrates the current configuration of the JLab I-DEAS installation. The
installation includes both Microsoft Windows and HP Unix
client machines, in a heterogeneous team data sharing environment. The Windows
clients have the I-DEAS application software and online help files installed on
a local disk drive. The Unix clients download the
application executables from the file server, to local memory. All clients
communicate with the I-DEAS license manager process that is running on a
central server, which also provides the resource locking service for the shared
team database. The I-DEAS shared data includes of all
parts, assemblies, and drawings that have been checked into the I-DEAS
libraries. This data is shared heterogeneously to clients on both the Windows
and Unix platforms.
Questions regarding
the information provided in this article can be directed to Todd Coates, x5537,
Todd.Coates@jlab.org.
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
For
users who have purchased Dell, Micron, 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
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/.
Scheduled
November 2002 – Farm
Overview
December 2002 – Print
Services
January 2002 –
CUE/Windows Desktop PC Overview
February 2003 – Email
Overview
March 2003 – Spam
email & virus protection overview
April 2003 – Cyber
Security
May 2003 – Linux
Services
June 2003 – Mass
Storage Overview
July 2003 –
August 2003 – Network
Overview and plans
September 2003 –
October 2003 – JLab
Grid Computing
The
archive of previous
This document is maintained by {helpdesk@jlab.org}
Copyright Jefferson Lab 2007