|
Computer Center News
|
Issue 6 |
November 2000 |
Plans
to remove traditional TELNET and FTP servicesA basic goal of DOE's security program is to
remove the occurrence of clear-text passwords in network traffic. Unfortunately,
a number of our traditional tools (POP mail, IMAP mail, telnet, and ftp) send
an unencrypted password across the net as standard procedure.
Earlier this year we replaced the POP and IMAP
mail services with Secure IMAP, and we are now making plans to turn off access
by traditional telnet and ftp. There are no fundamental technical problems with
removing these services -- they can simply be replaced with "secure
shell" utilities (ssh and scp) or other similar enhanced packages, like
bbftp. There have been some restrictions based on patent rights, but these have
been cleared with the recent expiration of patents on the RSA encryption
algorithms.
Hurdles to making this happen include educating
computer users about how to replace the traditional tools with the secure
versions and making the use of these tools habitual. We are investigating an
assortment of packages that will provide users (in particular, those who are
used to graphical applications) with easy and inexpensive alternatives to
telnet and ftp.
Some current candidates for replacement of
telnet/ftp that address both our security and usability needs are listed below.
Please try these applications -- though be warned that, at the moment, we don't
have local supporting documentation. The more feedback we get on users
preferences, the better our choices will be. As we are able, we will post more
detail along with additional documentation at http://cc/support/security/secure-communications.
Microsoft Windows
ttssh - This
package is the one currently supported by CUE.
The ssh application is okay and forwarding of X11 sessions works well.
Secure file transfer is provided through the use of a secure
"tunnel," but its setup is awkward.
It is available for machines in the JLab domain from the "Start"
menu (Jlab-Cue / Client Installed Software / TTSSH Setup).
ssh from SSH, Inc.
- This proprietary package is currently free to
individual academic users (see http://www.sans.org/newlook/resources/SSH2.htm).
It has a GUI-based ftp replacement. We
will be setting up the needed proprietary server, if our tests show this to be
a stable application. For the current
status, please see http://cc/support/security/secure-communications.
ssf - ssf
was developed for use in France and is a direct replacement for ssh. All users who need a secure interactive
package to use in France should see http://ww2.lal.in2p3.fr/~perrot/ssf/tools/.
SafeTP - This package was developed at Berkeley to provide secure ftp (see http://www.cs.berkeley.edu/~smcpeak/SafeTP/). It uses a "shim" in the Windows network code and a proxy on UNIX which sets up a secure tunnel for authentication. This technique allows the use of current ftp applications without change. Testing of safeTP is under way. The current status of safeTP will be published at http://cc/support/security/secure-communications.
openssh
- This is the Lab's preferred ssh client and server for UNIX-based
machines. It is an open-source
implementation of the original ssh distribution (see http://www.openssh.org). It now ships with Redhat 7 and is available for
Redhat 6 (RPMs on JLab mirror mirror.jlab.org:/mirror/redhat).
safeTP
- The same comments apply here as in the section above for safeTP.
NiftyTelnet SSH
- This package provides a good telnet replacement for Macs. It is needed by anyone who needs to log into
DB1 from a Mac to complete his time sheet.
See the article below in the Desktop Support section titled “Secure Shell Application for Macintosh”.
Instructions on installation are available at http://cc.jlab.org/desktop/mac/docs/nifty_ssh.html.
The home page for this package is at http://www.lysator.liu.se/~jonasw/freeware/niftyssh/.
A more difficult
problem comes from the restrictions on use of certain forms of encryption in
different countries. The legislation typically deals with two issues: 1)
manufacture /import /export of the technologies and 2) the use of the
technologies on domestic networks. In some cases, restrictions on the use of
encryption in network traffic have eased. For instance, France now allows a
moderately high level of encryption (128-bit) on public networks. This enables
the use of an adapted version of secure shell (for details, see http://ccweb.in2p3.fr/secur/ssf/index.html).
We are interested
in any information that users might have that would limit the use at their home
institutions of secure shell (ssh) or other public-key encryption technologies.
Access to Jefferson Lab by non-secure methods will be severely restricted in
the coming months, and we need to know which users may be unable to comply.
Good information on current world-wide legislation on cryptography is work done
by Bert-Jaap Koops of the Netherlands (see
http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm).
Please send mail to
security@jlab.org or contact Bob Lukens
(757-269-6376) if you have any information or comments on our removal of telnet
and ftp services.
The
Computer Center has recently upgraded several centrally provided resources
including several new central printers, an upgrade of the central HP Unix
systems, and a new centrally provided scratch area
There is a new
Tektronix color laser printer located in the public atrium area above the
cafeteria. Its name is "cctek1". Currently, this is a demonstration
printer, and has only one paper tray available currently configured to be used
for transparencies. The Computer Center will keep this printer supplied with
the correct transparency film. Since it is on trial, we are actively seeking
feedback on it. So please use it and send comments to helpdesk@jlab.org. The original color
printer at this location, "pscolor3" along with the monochrome laser
printer "cchp1" will remain at this location.
Additionally a new
HP color laser printer is located in the 1st floor A wing of Cebaf Center. Its
name is "phyhp14". Our plan is to have this new printer replace the
Tektronix printer "pscolor4" after it has been tested and shown to be
acceptable.
On the Unix server
side the four old central Hewlett-Packard systems: jlabh1, jlabh2, jlabh3, and
jlabh4 have been replaced with a single new HP J6000, dual 544MHz processor
machine. The new machine is named jlabh1 and has more than double the processor
power of all four old machines combined.
There is a new
scratch area installed on all central Unix servers. It is mounted as /scratch
on all machines. This means that you have the same scratch area, no matter to
which machine you are logged on. Previously, each server provided a local
scratch area. The new area is over 500GB in size. Additionally, this scratch area is available on CUE Windows systems
– mapped as the “N” drive and can be used to share files between systems. As with the old local scratch areas, this
space is intended as temporary storage – it will be regularly cleaned, with
files not accessed for 14 days being automatically removed. Files stored in that area are not backed up.
During the week of October 30, the Jefferson
Lab Computer Center hosted the Fall 2000 HEPiX/HEPNT meeting. Computer
professionals from many high energy and nuclear physics labs attended the
combined meeting of Windows and Unix system administrators, to exchange
information about directions the labs are headed, common issues that each site
must address, and creative solutions to enhance the computing environments.
The focus of HEPiX in recent meetings has
become largely centered on Linux systems, as this is the solution that almost
every site has implemented to provide batch compute farming for scientific
computing, as well as desktop systems where users choose Unix over Windows.
The focus of the HEPNT meeting has moved from
Windows NT over the past several years, to implementing Windows 2000. Migration
to 2000 has several tricky, if not difficult, issues to be tackled, and each
site is at different stages in this process.
The
meeting was held in the ARC auditorium, and many Lab staff attended
presentations on specific topics of interest. More information about the
meeting is located at http://www.jlab.org/hepix-hepnt
including online versions of the presentations and video recordings of the
sessions available in the archive located at http://www.jlab.org/hepix-hepnt/agenda.html .
The Computer
Center’s continued expansion over the last several years of computational and
storage capacity in support of the experimental program required more
electrical power and in early May, the venerable but old 75 KVA Uninterruptible
Power System (UPS) system reached the limit of its capacity. No additional
equipment could be installed until the UPS was upgraded. The UPS upgrade had been anticipated but the
schedule for doing so had to be altered to coincide with the accelerator summer
shut down period. A 225 KVA replacement system was ordered in late May with
delivery set for mid-August. But the problems with replacing a system that was
literally built into Cebaf Center during the building’s construction began to
manifest themselves. Some doors were not large enough to move components
through and the elevator did not have the weight capacity. However, the real
problem was the floor loading capacity of Cebaf Center. Outside of the Computer
Center’s specially reinforced floor area, the building’s floors just couldn’t
take the extreme weight of moving the equipment across them. After numerous
consultations with Plant Engineering, the only viable solution was to remove
the equipment the same way it was installed, that is to say, vertically. Once
again, this presented a host of additional problems for Plant Engineering to
overcome. A roof access hatch had to be designed, fabricated, and installed
along with a structural analysis of the impact of cutting a large hole in the
roof. Electricians needed to relocate countless electrical service conduits,
both large and small, to clear the vertical path to the new access hatch.
Refrigerant lines and air ducts were also in the way and had to be relocated.
Finally the suspended ceiling tiles and support grid were removed giving
unobstructed access to the roof opening. Procurement worked side by side with
the Computer Center and Plant Engineering to ensure contracts for metal
fabrication, roofers, cranes and riggers, electricians and HVAC technicians
were issued and all contractors met a very tight delivery schedule. All work
had to be performed without undue disruption to normal operations.
When the first
suitable weather day permitted, the 
roof
opening was cut and the new access hatch frame was installed and welded to the
structure. Additional support members were welded in place to compensate for
the large opening and finally the roofing contractors reattached the rubber
roof membrane and made the hatch opening weather tight. The same week, all
computer and networks systems were shut down early Saturday morning (Aug 12)
and UPS power to the Computer Center was disconnected. The electricians worked
throughout the day to completely mechanically and electrically isolate the old
UPS system and associated breaker and power panels. Late in the day they
installed temporary electrical connections bypassing the old UPS to supply
unconditioned and unprotected power to the Computer Center. For the next two
weeks, computer operations were at risk and subject to interruption.
Work was delayed due
to bad weather until the following Thursday, when at 5:30 AM the decision was
made to bring the crane on site and open up the roof access hatch. The first
load was on the way out by 9 AM and removal operations were completed by noon.
The new UPS system components were transported from their staging area in the
Physics warehouse to the loading dock area behind Cebaf Center and rigged for
lifting. All the components were installed through the roof hatch and
positioned by late afternoon.
For the next week,
electricians worked every day to complete the connections to and between all
the UPS components. New main breaker panels were installed and an additional
power distribution cabinet in the computer room was installed. All the wiring
and connections were checked and rechecked to ensure everything was ready for
the cutover to the new UPS system. A complete power outage to the Computer
Center and the second floor of Cebaf Center was then scheduled for the upcoming
Saturday (Aug 26).
Promptly at 7 AM
power was shut down and the final work to cut over to the UPS system began.
Temporary power connections to the computer room were removed and permanent
connections to the UPS system were established. Electrical service to equipment
racks was rerouted to feed from the new power distribution cabinet. This was a
large job that was completed by the four electricians in a remarkably short
time as a result of the detailed planning beforehand by Plant Engineering and
Computer Center staff. Startup engineers from the UPS manufacturer were present
and began installation checkout and power up procedures. By 5 PM that day power
was restored to the computer room and Computer Center staff restored all
systems and networks to normal operation. The old UPS had served reliably for
eleven years and we expect the new system to meet all our power requirements
for at least that long in the future.
The Computer Center performs
semi-annual user account audits in April and October. This audit is an
important function that is performed to meet compliance with DOE requirements,
as well as to manage the computing resources provided by the Computer Center.
The user audit is the primary mechanism to verify the validity of user accounts
on JLab’s computer systems.
It is the
responsibility of any individual who sponsors or supervises JLab user accounts
to complete their user account audit form for the accounts that they sponsor.
The sponsor/supervisor indicates through this audit whether user accounts they
are sponsoring should remain active or be disabled. The basic process for the
user audit is as follows:
1. Notification
sent to Supervisor/Sponsors through email
2. Supervisor/sponsor
goes online through their MIS “mypage” and completes their audit form
3. Computer
Center disables the user accounts based upon the returned information
The October user
audit began on October 12 and is scheduled for completion on November 6. The user
audit performed in April 2000 resulted in the disabling of approximately 200
unused accounts.
There
are several mechanisms available to enable the transfer of large multi-Terabyte
data sets between Jefferson Lab and remote institutions. In the past, most such
transfers have used tape – involving copying data in the silo to and from DLT
as the export media. Now, however, with the upgrade of the Jefferson Lab wide
area network connection to OC-3 speeds (155 Mb/s), the use of the network to
transfer those data sets is becoming the preferred mode, especially for those
institutions that are on ESnet or on one of the fast NSF networks (such as
Abilene). Although there are sometimes teething problems initially, we will
work with the ESnet engineers and those of the peered networks to understand
and resolve the problems. In the long run the effort put into this will pay off
since already network transfer bandwidths are regularly achievable that equal
or better the bandwidth of copying data to DLT tape. Thus we encourage
collaborators to make use of the network for their data import/export and to
work with us to resolve any problems.
Information
on using the services described in this article can be found at: http://cc.jlab.org/scicomp/userdocs.
This
service is available and accessed with the jexport commands. The
user must supply the DLT tapes. Our tape robot is compatible with either
DLT7000 or DLT4000 tapes. Note that even with DLT7000 tapes, the writing speed
is somewhat less than 5 MB/s; copying a single Terabyte of data will take at
least 60 hours even ignoring tape mount and seek times, and require 20 tapes.
There
are several options:
For files known to the mass storage system (or importing files
destined to be written into the silo), the extended jcache
service will provide transparent access that is secure and attempts to
fully utilize available network bandwidth. This option is not yet
available, but a version should be announced early next year.
Since this is not
secure, it is provided by a machine sitting outside the firewall, that mounts
the /work and /cache filesystems read-only. As passwords are passed
clear-text over the network, we require users to register to use this service;
they will be provided an account on that machine with a password that should be
different from their CUE password. Register on the web at
http://cc.jlab.org/scicomp to use this system. We prefer that if at all
possible people use the bbftp service. Note, that the ftp service
can only access /work and /cache, home directories and group areas are not visible.
bbftp (http://ccweb.in2p3.fr/bbftp/)
provides an alternative to ftp for wide-area file transfers, that:
This service is to
be preferred over traditional ftp, since it is both more secure and tries to
optimize network bandwidth usage. The facility can be used to transfer files
already present on disk (/work or /cache). Since it is more secure than traditional ftp the
filesystems are mounted read-write and the service can accept incoming file
transfers. Users' home directories and group areas are also available for this
service.
The standard bbftp
command takes an input command file containing a list of instructions (cd, put, get etc). Options are
available to enable compression, specify the number of parallel transfer
streams etc. This command is suitable for command line use - the user name and
password are supplied when the command is invoked.
However, for use in
a script bbftp would normally need the username and password to
be stored in a file. This is obviously not a good solution. For this reason the
bbftpcd and bbftpc commands should be used. The user should start
the bbftpcd daemon to contact the remote host - supplying username and
password. This daemon will just run in the background on the user's machine and
keep the username and password in memory. Then the bbftpc (client)
command should be used in a script to initiate the actual file transfers - it
talks to the local daemon (bbftpcd), which in turn authenticates the
user to the remote server, and does the file transfer.
Full details of the
use of the bbftp command are explained in the man pages - for bbftp, bbftpc
and bbftpcd.
This
software is an extension to the Jefferson Lab Tapeserver software and will facilitate
transfer of files known to the mass storage system. A simple Java client can be
installed on the remote machine, and will allow:
more
efficient Farm and Silo useThe silo holds
nearly 6,000 tapes, meeting the storage requirements for all of Jefferson Lab's
experiments. As a way to address users' needs for fast, online access to
frequently used data, the most often used files from the silo are kept on disk
in the /cache area. Recent additions of disk space and changes to the cache and
batch farm software are helping to make the use of the farm and silo more
efficient.
The cache area is a
large pool of disks on Linux machines (cache servers) that serve read-only
filesystems under /cache. Cache manager software runs on each server, removing
old files as new ones are added and coordinating operations to avoid
duplication of work. Requests that a file from the silo be added to the /cache
area are made using the "jcache" command. Because the cache servers
contain only data that is also on tape, no backups are made and the disks are
striped into large RAID-0 partitions. The use of RAID-0, Linux, and commodity
hardware has allowed the creation of a 6TB cache pool for less than 3 cents per
megabyte, less than half the price of larger RAID systems like the Metastor or
Network Appliance machines.
There are now a total
of nine cache servers. Each is a dual processor, rack-mounted Linux machine
with Mylex RAID controllers and Gigabit Ethernet. The first four machines have
50GB disks and the newer machines have 73GB disks. The systems are designed to
balance between the CPU, network, and disk space requirements to avoid
bottlenecks. All told, there are nearly 6TB of usable cache space online.
Some 1.6TB of the
new cache space is reserved for the farm. When a user submits a job to the farm
the input files are now automatically cached to the farm area before the job is
started on a farm node. This helps to make sure that most of the time spent on
the farm node is dedicated to CPU use, not to long waits during file copies.
This pre-staging of data files to the farm helps to boost overall farm
utilization both by queuing up the files beforehand and also by avoiding
duplication of work. If a number of farm jobs need to process the same input
file it will only be copied from tape once, which also improves the use
patterns of the silo.
The
/cache NFS filesystem provided to the user appears the same as it has since its
introduction. The mechanism behind the scenes has changed significantly. More
cache servers will be added and the number of data movers will also increase.
Data movers and cache servers are tightly coupled making questions of
performance, interdependence, and scale important. For example, a data mover
copies a file from tape and then must select a destination cache server.
Considerations for where to put the file include: the requested group, the free
space, and the availability of the cache server. Exceptional conditions like
failed servers must be handled gracefully. We have taken several steps to
ensure this.
The MSS data mover
machines (mss1, mss2) do not use NFS to copy files to the cache server. Instead
they use a simple file copy protocol developed for file movement within the
mass storage system. This protocol uses TCP connections to transfer the file.
File metadata and requests are transmitted using serialized java objects, but
the file transfer itself uses a fast TCP connection without the object
serialization overhead. Even though this protocol is implemented completely in
java, performance has been excellent. It exceeds NFS in performance and under
heavy loads delivers a more fair round-robin performance to the clients than
the Linux NFS server does.
The other advantage
to this protocol is that we can detect a crashed machine and work around it. As
more cache servers are added, the possibility of a hang or a crash invariably
increases. To keep one failed machine from impacting the entire system, we have
built in some tolerance for failed cache servers. Other cache servers and
storage server machines are able to pick up the load. CUE machines that NFS
mount the cache will still see NFS server hangs, but the interactive access to
NFS-mounted filesystems is a convenience that is currently required.
The cache system has proven to be an effective system for managing large pools of data. The cache system will expand over the next year with the addition of several more Terabytes of space. Your input about any aspect of the cache system is useful. Please send ideas and comments to Bryan.Hess@jlab.org.
BackgroundIn 1995 Jefferson
Lab researched several tape libraries and Hierarchical Storage Managers (HSM)
for managing and storing the data generated by the experiments. StorageTek was
chosen for the tape library and tape drives because of initial cost, licensing
and maintenance costs over time, tape drive speeds, and tape storage
capacities.
Open Storage Manager (OSM), from Computer Associates (CA), was chosen for the HSM. The HSM software keeps track of tapes and the files on tapes. It also manages all the reading and writing from and to tape. OSM had support for StorageTek tape libraries and Redwood tape drives. With the additional utilities developed at DESY, it provided the best method for storing data to tape. OSM was also the least expensive solution.
Over time, OSM’s
shortcomings have become more apparent. OSM is not a distributed system, which
does not scale and is not able to deal with the increased data rates. In
addition, CA dropped support for OSM at the end of 1999. A java based front-end
called the TapeServer and its user interfaces (jput, jget, etc.) were developed
3 years ago to work around many of OSM’s shortcomings. In order to accommodate additional tape
drives and higher data throughputs, OSM must be replaced by a distributed
storage system.
There are not that many HSMs to choose from. After reviewing the commercial solutions, it was realized that no commercial solution exists that is affordable, distributed, and capable of dealing with the data rates expected in the future. In addition, a lot of the needed functionality (disk-cache managers, data staging, and scheduling) is already in place as the front end to OSM. Therefore, the Computer Center has begun development on Jefferson Lab’s Asynchronous Storage Manager (JASMine), by adding components to control the robotics and tape drives to the existing TapeServer components. Fault tolerance is an essential part of the design as most failures currently are due to OSM’s inability to trap and deal with errors.
JASMine is
comprised of a MySQL database, distributed data movers, distributed disk cache
managers, and a number of administrative daemons. JASMine is designed to have
configurable request scheduling and few single points of failure. The database
contains all file information, system state information, user requests, and
statistical information. Robustness in the administrative daemons is achieved
by replication of services. The data movers are designed so that individual
machine failures will merely degrade overall performance and not halting the
entire system.
The MySQL database
provides JASMine with some flexibility that other storage systems do not have.
It uses the standard and well-known SQL database language. This allows JASMine
to make use of any SQL database with little or no code changes. Since most
experiments are already using MySQL or an SQL-based database with data reconstruction,
users might be granted read-only access to the database for developing
experiment specific reports. This of course will depend on the performance
impact on the system by user queries of the database.
JASMine
has distributed data movers, which are machines with locally attached tape
drives and stage disks. OSM servers are themselves the data movers. Thus an OSM
installation will only allow one server system. JASMine can have as many data
movers as tape drives. No single data mover will have its performance hindered
by the other data movers or the requests being processed on the other data
movers. Instead, adding additional data movers to the system will increase the
overall performance of the system. This will allow us to scale the system to
handle the expected data rates of future experiments. Data movers can also be
dedicated to an experiment or dedicated to only reading from or writing to
tapes.
The current cache
disks already utilize the disk cache managers of JASMine. Data is moved from
data mover to disk cache manager via JASMine’s own file copy protocol. This
part of JASMine will also be expanded in the future to do bulk data transfers
over the Internet to remote sites.
For further
information please contact Andy Kowalski (Andy.Kowalski@jlab.org).
The Computer Center
is now supporting Windows 2000 Professional as well as Windows NT 4.0 on the
desktop. All Computer Center provided documentation for Windows 2000 Professional
hardware and software can now be found at http://cc.jlab.org/desktop/win2000.
Currently we do not support any Windows 2000 Server products because
there has not been testing performed to evaluate its compatibility and
supportability in our CUE environment. If you are interested in installing
Windows 2000 on your Desktop, a Windows 2000 license can be purchased from the
Computer Center using the form to be found at http://cc.jlab.org/support/forms/win2klicensepdf.pdf.
If you frequently move your laptop
system between different networks around the lab, the Computer Center can now
ease this transition via the use of the Dynamic Host Control Protocol, or DHCP.
Setting your computer system to receive its IP address via DHCP will permit
your system to be easily moved between various networks on site. As you move
between networks the DHCP server will issue your machine a valid IP address for
the network that you are connected to. This is in contrast to the current
practice of modifying the IP configuration for each network to which a computer
is attached. Currently there are limited IP address ranges available for DHCP
and desktop computer systems should still use static IP addresses that are
issued via the IP request submission page located at http://cc.jlab.org/support/docs/IPrequest.html.
To
begin using DHCP for IP address assignment complete and submit the Computer
Center DHCP request form found at http://cc.jlab.org/support/docs/dhcp_register.html,
including the MAC address of your system. MAC addresses are the unique physical
address assigned network adapters. Every network device has this unique address
including the network adapter found in all PC’s. After the proper
configurations have been made to our DHCP configuration that allows your system
to use this service, you will be sent notification. After this notification has
been sent configuration to use the services can proceed.
The
MAC address for your PC can be found on Windows NT or 2000 machine by opening a
command prompt and typing:
ipconfig /all
This
will return the IP configuration information and Ethernet adapter information
for the computer where the command is being run. The MAC address is the
information that is found in the following line:
Physical Address ---------:00-10-4B-AD-81-48
The
MAC address is the six pairs of characters found after the colon in the above
line. This is the information that needs to be entered in the MAC address field
on the DHCP request form. The DHCP request form can be found at http://cc.jlab.org/support/docs/dhcp_register.html.
After receiving confirmation that your
computer is allowed to use DHCP, you must modify your IP configuration for its
use as follows for a Windows system:
1. Go
to Start
2. Settings
3. Control
Panel
4. Protocols
5. TCP/IP
6. Properties
7. IP
Address
8. Obtain
an IP address from a DHCP server
Instructions
for Linux DHCP configuration are currently in development. When instructions
are available they will be found at: http://cc.jlab.org/support/docs/dhcp_info.html.
Additionally any questions about Linux DHCP configuration can be directed to Kelvin.Edwards@jlab.org.
JLAB
Centrally Provided Unix SoftwareThere
are a large number of Unix software packages provided for use at Jefferson Lab
by the Computer Center. In order to access these packages the appropriate
applications directory must be mounted on your system. This directory is
already mounted on your system if you are using a CUE system or if your desktop
system is supported (for Linux systems only CUE level 1 or 2 will have the
/apps directory already available). All other users on site are able to mount
the appropriate /apps directory.
A
complete list of available packages is available at http://cc.jlab.org/services/cue/cue_software.html,
but a list of some of the more important ones are included below:
add
- version 3.1.1
A data display debugger for use with c, c++, fortran, perl, java
python... programs.
emacs
- version 20.3
HP-UX and Solaris only emacs is installed
locally on Linux and the version will depend upon which version of Linux you
have installed.
xemacs
- version 20.4
HP-UX and Solaris only xemacs is installed locally
on Linux and the version will depend upon which version of Linux you have
installed.
egcs
- version 1.1.2
A Gnu c/c++ compiler.
Framemaker
–
Word processing package
Solaris version is 5.5
HP-UX version is 5.5
gcc
- version 2.8.1
Another GNU c/c++ compiler
java
HP-UX version is 1.1.8
Solaris version is 2.2_001_ref
Linux
version is 1.1.6_v5
Maple - version
6.0
Mathematica
- version 4.0
MatLab
- version 5.3
perl
- version 5.005_03
root
- version 2.25-02
HP-UX, Solaris, and RedHat 6.0 and greater
Linux RedHat 5.2 uses version 2.24-02
Sun Forte
(Formerly Sun Workshop) –
Sun code development environment containing
compilers, debuggers, and analyzers. Available only on Solaris.
Star Office
–
Word processing, spreadsheets, and graphics
software compatible with Microsoft format file types. Available on Solaris and
Linux only.
Solaris version is 5.1
Linux version 5.1
tcl
- version8.0.4
These packages are updated as new versions become
available on all platforms. If you are using one of the CUE maintained packages
and you need a newer version than the one currently, please send mail to helpdesk@jlab.org to request the newer
version and we will update the package as time allows.
As part of the
effort to make the Jefferson Lab PC computing environment more secure, the
Computer Center will make some changes to PC systems (Windows 9x, Windows NT
and Windows 2000 Professional). Specifically the authentication protocol that
PCs use for authenticating usernames and passwords over the network.
To understand how
PCs transmit your username and password across the network some explanation is needed.
By default, all Windows platforms use both LAN Manager (LM) and NT LAN Manager
(NTLM) as the authentication protocol to communicate with servers and other
client machines. With Windows NT 4.0’s Service Pack 4, Microsoft introduced a
new enhanced authentication protocol called NTLM v2.
Here are brief
descriptions of those authentication protocols.
The eventual goal
for our network is to operate at NTLM v2. Currently, a bug in Windows 2000
prevents us from proceeding to a pure NTLM v2 environment. We will, however,
turn off LM Hash compatibility from and use NTLM and NTLM v2. When Microsoft
provides a fix for Windows 2000, we will use NTLM v2 exclusively.
What does that mean for users?
All Windows users
will need to install the following patches on their systems:
Users on all
platforms also will need to change their registry settings to reflect the
change of authentication protocols. The Computer Center will try to change
registry entries for all users on site, but those users at home (dial-in users)
will need to change their registry settings themselves. The Computer Center
will provide all patches and instructions on the Web as soon as they are completed,
and will send out notices indicating their availability. More information and
details concerning the change of authentication protocols will be posted as
soon as it becomes available.
The target date for turning off LM Hash on our network is January 1, 2001. All users will need to install all appropriate patches before this date. After this date Window’s systems not running the appropriate authentication protocols will no longer be able to access the JLab domain and its resources.
Secure Shell Application for MacintoshThere is now a free
SSH (Secure Shell) application available for Macintosh - Nifty SSH.
Currently, all Mac users connect to DB1 or other Unix systems via a telnet
client (typically PacerTerm ) to complete their Time Sheets
(ETR), REQS, STOCK and other MIS related applications. This is an insecure
connection as telnet transmits clear-text passwords across the network. Nifty
SSH is a secure replacement for PacerTerm and other
telnet clients. Nifty SSH provides encrypted network connections
for passwords, as well as any transmitted data. For more information on SSH
please see the Computer Center Newsletter from March 2000 found at http://cc.jlab.org/announce/newsletter/CCNLMar00.html.
All Macintosh users should discontinue using telnet clients such as PacerTerm
and install Nifty SSH immediately, as telnet access to DB1 will be
disabled at the end of this year.
On
September 2, 2000 Dell Computer Corporation made changes to the web pages for
purchasing Dell systems online from JLab. These changes included new features
intended to make the online purchasing of Dell systems online an easier
process. The Jlab Dell online purchasing page can now be customized for each
user of the system. Once authorized users of the system have logged onto their
new Premier Page they will have the ability to customize their own purchase
page. Theses customizations include the following:
·
a
personal password will allow log in to the system
·
location
of the most often used sections is easier to find
·
tracking
the location of an order with the order number that is returned through email
Although
the ability to make these customizations is available on an individual basis
via the new pages, the purchase is still being accomplished through established
Jlab/Dell purchasing agreements, and all price breaks and other benefits are
still intact for these purchases. Updated Dell online purchasing instructions
can be found at http://cc.jlab.org/desktop/docs/internal/Dell_PC_Purchase.html.
<
