|
The past year has seen changes in the Computer Center and in the general computing environment. Some of these changes are readily apparent to the users and staff, others are much less obvious. This newsletter is an opportunity to relate to you the changes that have taken place, those that will soon take place and the reasons behind them.
As you probably know Jefferson Lab is funded by the Department of Energy and run by SURA. There is a contract between SURA and the DoE that specifies how the laboratory is to be run. The contract contains metrics by which the laboratory is tested to ensure that the requirements of the contract are addressed. In the last few years the Federal Government has become increasingly concerned about the security of its computer installations. This concern stems partly from the increase in computer viruses, worms, Trojans and hackers that followed the huge popularity of the Internet but also from concerns about national security and the threat of terrorism. Cyber security has been a part of the laboratory's contractual requirements for some time but in 2004 something new happened. In May of that year an assessment team was sent by the Department of Energy to evaluate our cyber security. This was not an isolated test. The same team was charged with assessing all of the department’s laboratories. Jefferson lab was the first open science laboratory to be tested. The review was in two parts: The first consisted of interviews and reviews of procedures and documentation. The second was a technical evaluation by several team members on Jefferson Laboratory computer systems. This evaluation took the form of an external attack to simulate someone on the outside trying to get in and an internal attack that simulated an employee or user attempting to gain unauthorized access to systems. As can only be expected when a group of dedicated experts is invited to come for a week and hack your systems they were quite successful in their attempt! They did not manage to get in from the outside since our firewall and automated defenses were strong. From inside there were a number of ways in which we were vulnerable. This is understandable since cyber security is a risk analysis where a trade is made between giving users and staff the access they need to work freely and trying to prevent undesirable events. The team left and produced a report that, rightly, praised our strong team of experts but also pointed out our weaknesses. As a response to that report we are required, under our contract with the DoE, to take corrective actions. With your best interests in mind we are again attempting the balancing act to provide as much freedom to work as possible while protecting you, your data and the Department’s considerable investment.
One issue that has been a constant source of problems for Computer Center and other staff was highlighted by the cyber security review: configuration and asset management. Currently many computer systems at this laboratory are administered by the machine’s primary user. The user buys the hardware and software and does the installation and configuration themselves. Although this gives the user the greatest flexibility and would appear to reduce the burden on the Computer Center, it does introduce other problems.
The most obvious issue is with people who just plain don’t know what they’re doing. With all due respect, not everyone at the lab is a computer expert but they still have to work with computers. Software or hardware is installed, poorly configured or just fiddled with until something breaks. The Help Desk is called and Computer Center support is expected. The cyber security review highlighted the security problems presented by such situations where inexperienced computer users leave doors open for hackers and viruses to enter.
Flaws in software design or bugs in implementation often lead to vulnerabilities that are exploited by hackers and viruses. Software vendors release patches to fix these vulnerabilities. A typical computer has many software packages installed, including the operating system itself. Keeping all of these pieces of software patched for just one machine is difficult. When the problem is magnified to the scale of Jefferson Lab it becomes a major issue. We are making progress in this area; keeping up with patches can be a difficult job but it is one that is required by our contract.
Another urgent problem is that the Computer Center has to work very hard to physically locate a computer causing problems on the network and its owner or administrator. There have been several incidents where a laptop or desktop system infected with a virus has been brought on site and started hunting for machines to infect. Locating the owner and the physical location of the machine has been a problem.
During the time that a computer user uses a machine they obtain software to match their role at the laboratory; office tools, CAD, scientific packages such as Mathematica. Often this software is commercially licensed and paid for by the laboratory. When a computer user leaves the laboratory, or changes roles internally, we currently make no attempt to reclaim the licenses and reissue them to other staff or users. There are probably many instances of licensed software sitting unused which is being repurchased in a different part of the laboratory.
To prevent, or at least reduce the impact of, such issues the computer center has been working in the following direction: We are implementing a system of different levels of computer ownership.
Our first task is to categorize systems according to the level of ownership. Once this is done we have tools that can be applied to manage the configuration of the system and allow us to do some asset tracking to determine, for example, what software and hardware is installed. We ask users and staff to carefully consider the level of ownership that they really require. One should remember that for level two and three systems the support burden falls on the non-Computer Center administrator or, in the case of level four systems, on the user themselves.
In the last eighteen months the Computer Center has gradually replaced network hardware around the site to the point where we can now start to make use of two technologies which were previously not available to us. The first technology is virtual networks or VLANs. Previously the network at this laboratory was segmented unto subnets according to physical location. So, for example, a computer in ARC had a different IP address from a computer in CEBAF Center. Such a system has inherent problems, IP addresses must be reassigned when machines are physically relocated and machines cannot be grouped on subnets according to logical function. Under the new VLAN based architecture we can, for example, take all of the network capable air conditioning units and group them together on a subnet. This subnet can then be protected via an access control list (ACL) to prevent people from tampering with the AC systems. This has obvious advantages from the cyber security viewpoint and was highlighted in last year’s review. An advantage from the user’s perspective is that machines that are inherently vulnerable can be grouped on a protected network. Examples are the IOC’s in the halls and accelerator that are very easy to crash via commands sent over the network. Conversely the level four machines can be grouped in a VLAN that restricts the amount of harm that they can cause if something goes wrong.
The second technology that we are preparing to implement is the 802.1x standard for secure networking. This is a complex technology that is impossible to fully explain in this article. What this system will allow is for us to attach ownership and other information to a machine on the network. This will fix one of our main headaches, which is finding the physical location of a machine and then identifying the owner and administrator. The main advantage from a user’s perspective is that, once a machine is registered with the system and placed in the correct network, the machine can be moved around the site and still be on that same network.
Wireless networking is a huge problem for us. Our current system has grown ad-hoc as requests for wireless access in different locations were submitted. We are currently deploying a new, planned, wireless network architecture which is a complete replacement of the existing system. In combination with the other networking technologies discussed in the previous section will provide a robust, secure, and easier to manage system.
As part of our security mandate from the DoE we are required to give an annual briefing of physical and cyber security. This is now required of all staff and users. At the moment this briefing is rudimentary since so much of our cyber security environment is changing, however, it will be expanded to provide useful information on how to use the new systems as they become available.
For many years purchases of computer hardware and software via the requisition system have been subject to the ADP approval process. There are several reasons for this process:
The cyber security reviewers pointed out a hole in the ADP process. Holders of JLab purchase cards could essentially buy whatever they wanted if their approving official signed off on it. Often the approving officials are not computer experts. The most glaring aspect of this was that people were buying hardware such as wireless access points that were then attached to the JLab network which introduced security holes or interfered with the proper functioning of the network. As a response to this, purchases made with purchase cards are now subject to ADP approval. Because the paper trail for purchase cards starts after the purchase is made and these purchases may take place outside normal working hours the following policy applies:
The Storage Resource Manager is available for transferring large amounts of scientific data between the lab and users' home institutions, providing grid-enabled access to JLab's mass storage system for offsite users. The SRM provides the management necessary to retrieve files from the silo, stage them for copying, then perform the copy to move data offsite. In the reverse, data is copied from offsite directly into the mass storage system. The data movement occurs without requiring users to prestage the files on a local JLab storage area. Additionally, the SRM is designed to interface with other grid sites' SRM implementations.
Two SRM services are running at JLab: version 2 implements the latest defined SRM specifications; version 3 is a prototype that implements a proposed core SRM service, with interfaces for adding additional components as required. The v2 implementation uses GridFTP to move files, including parallel streams; v3 uses HttpGet/HttpPut with up to10 concurrent file copies. Curtis Meyer, a CLAS and GlueX collaborator at Carnegie Mellon University, has tested both versions, and plans to use the SRM to transfer a total of 10 Terabytes (10,000 Gigabytes) to CMU, for processing the data on their Physics Department cluster. Typical transfers to CMU are 500GB at a time, which is the best fit for their computing and data storage environment. Transfers with 10 parallel streams achieve higher than 10MB/sec, making it easy to transfer 500GB in a day. The SRM can use as much bandwidth of our offsite connection to ESnet (OC-3, 155Mbps) as is available.
Future work for the SRM includes providing it to the Open Science Grid (OSG - http://www.opensciencegrid.org) collaboration, to include in the Virtual Data Toolkit (VDT) distribution of grid middleware services, and hosting a developer's meeting at JLab in the fall.
The SRM implementations are developed jointly at JLab by the Computer Center and High Performance Computing groups, as part of our work with the Particle Physics Data Grid (PPDG http://www.ppdg.net) collaboration. More information on the SRM project itself, led by the Scientific Data Management Research Group at Lawrence Berkeley National Laboratory, is at http://sdm.lbl.gov/srm and at the DoE website http://www.doecollaboratory.org/research2/storage .
Sites who want to use the SRM can get an SRM client from JLab and install it at their home institution. Users need a DoE Science Grid certificate as well as a JLab computer account. For more information about using JLab's SRM services, see http://cc.jlab.org/scicomp/srm , or email farm@jlab.org .
During the accelerator down time in September, the Scientific Computing systems will be shut down for planned upgrades. All JASMine and Auger systems, including all mass storage (/mss, /work, /cache) and batch and interactive farm nodes (IFARM*, FARM*), will be unavailable.
The JASMine/Auger outage is scheduled for September 6-7, to install a new Central Dispatcher for JASMine data movement, and to update data mover clients to use the new dispatcher. The system will then undergo production testing through September 12.
This upgrade will increase data throughput for the mass storage system, and paves the way for the upcoming project to compress data and reuse tapes, saving a significant amount of money over purchasing new blank tapes. Another important change is the increase in supported file sizes from 2GB to 10GB.
The tape copy/compression project will begin shortly thereafter. This project reuses tapes previously written at a lower density of 60GB per tape with StorageTek 9940A tape drives. The same media can store 200GB per tape when written with our current 9940B tape drives. Approximately 8000 9940A-formatted tapes will be rewritten with the 9940B drives, freeing over 5000 tapes for reuse at the higher density. At approximately $80 per tape, we're eager to get started!
The mass storage system at JLab currently stores 1.3 petabytes of data in two StorageTek Powderhorn 9310 silos that hold almost 6000 tapes each. With less than 10% of slots currently unused, we would only be a short time away from exceeding capacity. When replaced with all 200GB tapes, the silo capacity reaches just over 2PB. Each year the amount of data written by the experiments increases, with an expected 400 terabytes (0.4PB) to be written during this fiscal year. Current planning includes a new silo purchase early in FY08, with some of the oldest data being moved offline in FY07.
911 - You can reach local Emergency authorities by dialing 911 as well as 9911. Dialing 911 without the extra 9 (access to outside lines) will probably take a few seconds longer so it is advised to dial 9911, but either way will work.
The Crisis Alert program displays on designated specially programmed telephones warning that someone here at the lab has dialed 911 or 9911. Those phones belong to "First Responders" such as our Security Guard Services, Medical Services and other personnel who are tasked with specific responsibilities in an emergency situation. When the Crisis Alert program is activated, the programmed phone sets display the name and location of the initiating caller. The number of phones programmed this way is very limited and is reserved only for those who must respond immediately.
If you are a designated First Responder and have been assigned a Crisis Alert feature you should turn your two-way radio to channel 6 to monitor the emergency to determine whether your particular expertise is needed. Do not call the initiating caller, Guard Services or Medical Services; they will be busy rendering proper aid and your call will hinder them from rendering aid, following emergency procedures, and directing emergency vehicles and personnel to the emergency.
When trying to reach someone in an urgent manner via an Alphanumeric, Digital or Two-Way pager; you should input the number you wish your party to call, followed by the * symbol and then four 9’s. Example: 2697361*9999. You should never input “911” unless the call is regarding something with the potential to be life threatening. Using “911” on a regular basis when it does not signify imminent danger to life or property will only weaken the significance of a real emergency page. Inputting 4 nines after the * will let the party know that while their response may be important, it is not a life or property-critical issue.
When given the opportunity to purchase a new computer, each of us wants to buy the best technology has to offer. It’s rare that we buy new pcs; only one every three years (or longer) for most JLab folks. The question we all ask ourselves is, “How do I buy a computer that will keep up with advances in technology for three years without spending Lab money irresponsibly?”
Before you start shopping, consider what computer-based tasks you normally perform as part of your job. If you use a computer to read email, write documents and spreadsheets and update your timesheet, you are a very good candidate for a thin client. (Please see the article titled Windows Cleaning: New Windows Workstation Configuration for CUE found elsewhere in this newsletter.) A thin client offers an inexpensive, very low maintenance choice for users whose job tasks don’t require non-CUE software, copying data to CDs, etc. However, if you use a computer to design, draw, or engineer, you may indeed need a full computer at your desk. If you work as administrative support for a group here, you may be involved in web page design and modification, or in publishing/managing documents for your group. You may need a full computer at your desk, but you should explore the thin client option before you submit a purchase request.
Items JLab requires that you purchase with a desktop computer:
Options which increase or reduce the total purchase price:
When your new pc arrives, please see http://cc.jlab.org/services/winodws/transferpcs.html for directions to transfer from your old system to your new one. As always, if you need help, browse through the Computer Center web pages. There is a plethora of useful information to be found there. However, if you still need assistance, you can contact the Computer Center helpdesk for assistance.
Since RedHat has released its latest enterprise software, RedHat Enterprise Linux 4 (RHEL4), the Computer Center has been evaluating its use here at JLab. This version of the operating system has many improvements, including support for the Linux 2.6 kernel and SELinux, a secure linux environment useful for servers. These features may make you anxious to install this latest version of RedHat Enterprise Linux and the Computer Center is working to make this available. However, this will take a few months as we work to provide all of the necessary infrastructure support. Although we may provide an ability for you to install RHEL4 on your desktop, there are no immediate plans on updating the Scientific Computing infrastructure, including the batch farm, to this version. Programs compiled on RHEL4 systems may not run correctly (or at all) on the Scientific Computing batch farm due to differences between RHEL4 and RHEL3. If you compile software on your desktop for use in analysis on the scientific computing batch farm, please continue to use RHEL3.
In addition, RedHat has recently released update 5 for RedHat Enterprise Linux 3 (RHEL3). If you are not currently running this latest update release, please run "up2date -uif" on your system as root and then reboot to fully install the latest patches and kernel.
Over the past several years, JLab’s CUE environment has provided users with easy access to a wide variety of powerful central facilities and tools. The Computer Center has continued to grow and expand this environment to accommodate changes requested by users and also to accommodate changes in the computing and technology environment in which the lab operates.
A number of important changes are currently planned that will affect the vast majority of systems on site. These plans include a number of items of particular interest to Windows systems. Over the next year or so, the Computer Center plans to
A description of the overall workstation configuration is provided at http://cc.jlab.org/docs/services/windows/WorkstationConfig.pdf.
Our security review and penetration test last year by DOE’s Office of Assessment showed that the lab has significant security weaknesses associated with configuration management of Windows desktop and “benchtop” computers within our site. Significant factors in this exposure include:
If you don’t understand these topics, and you are currently the one who configures your desktop workstation, there is a good chance that your system could benefit from better configuration (wink).
An area in which the lab did very well was in our network perimeter protection systems. In general, it is very difficult for an intruder from outside the lab to penetrate our firewall and attack our interior systems. Once inside, however, our systems were generally very vulnerable. This is the “hard crusty outside and soft, chewy middle” that our security people like to refer to.
Our perimeter security has protected us very well, but it has limitations. There are numerous ways or “vectors” through which interior attacks might be introduced. Many of these are via email or web browsers on Windows systems. One particularly insidious technique is the “drive by download”. This is a mechanism where a link or hotspot on a web page is used to trigger a download (and execute) of a program when the user rolls his or her mouse over the hotspot. This doesn’t even require the user to click on anything. From there, depending on the system’s configuration, the user might be presented with a dialog asking if he or she wishes to trust the publisher of the application, etc. But these dialogs are complicated, and frequently ignored by users since they tend to get many of them in the course of normal operations.
While we attempt to provide additional protection for email with virus scanning and filtering software, there is little that can be done centrally or at our perimeter to further protect from browser based attacks of this sort. Addressing these problems requires configuration management on each local system.
A topic that is controversial is the removal of system Administrative privileges for most users. Many users are not even aware of the fact that they enjoy administrative privileges on the system they use. This means that they have the ability to perform virtually any function on the system. It is important to understand how far-reaching these privileges are. For instance, an administrative user can:
If a user with these privileges receives a virus-bearing email, program, etc. and executes it, there is nothing to stop the program from completely ravaging your system. Such a compromise of an interior system is a significant event since it gives an intruder access to many of our resources that are protected from the outside.
A Corrective Action Plan has been developed to address these (and other) issues. It includes a project to divide our network into several segments, each having varying levels of access to site resources like home directories, other central filesystems, web servers, interactive login to other systems, printing, etc. Desktop and other systems around the site will be categorized into 4 different groups or “levels”. It is envisioned that Windows workstations will generally be migrated into this new scheme as they are rebuilt. In fact, under a pilot program, nearly 100 systems have already been rebuilt as Level 1 (preferred) or level 2 systems.
The process of migrating all systems into the appropriate configuration will be challenging indeed. The Computer Center will strive to make this process as simple and convenient for users as possible. Creative solutions to handle user’s special requirements will be needed to ease this transition. Many new resources are already in place –
In the past, the process of installing Windows, getting it patched, installing MS Office, common applications, etc. has been very time consuming. It has also provided numerous opportunities to introduce configuration errors either through misunderstanding or simple mistakes. Speaking from experience – a simple typo in the wrong form field during setup can turn an otherwise perfectly good system into an incoherent mass of electronic parts. The new system is designed to allow users to rebuild an existing system with a minimum of trouble. Once rebuilt, the system will conform to the Windows Workstation Configuration defined by the Computer Center.
The Computer Center is excited to offer a new tool to simplify this process. Just navigate to https://cc.jlab.org/services/windows/BuildSystem/ to review the details and submit a request for construction. Once the request is submitted, it will be reviewed by CC staff and approved for construction. Once that is done, simply rebooting your system from the network is all that it will take to completely rebuild your existing system with Windows. The steps performed include:
Overall, the new build process is intended to provide a stable, reliable windows desktop platform that is well integrated into our environment. For users, this means a system that does what you want, when you want, and with fewer hassles.
Well, sort of… After a long struggle, the Computer Center last year completed an agreement with Microsoft to purchase their products at a reduced rate, and in a single purchase. The result is that the lab is now licensed for all Windows systems to upgrade to Windows XP Professional. Further, these systems are also licensed to install or upgrade to Microsoft Office 2003 Professional. If you don’t believe me, just go to your control panel (Windows 2000 and XP only – remember, we’re dropping support for NT4.0), select “Add or Remove Programs” then click on the “Add New Programs” button in the pane on the left. You should see a list of available software that can be installed with a click. The list should include MS Office 2003 Professional! All JLab systems have the right to upgrade as needed to whatever the current versions of these packages are (or previous supported versions) for the next five years.
Note that this agreement is not a “site license” as people typically think of it. The Microsoft agreement is based on actual system counts. All licenses are accounted for and paid for, just at a reduced rate, and set up to be much easier for an organization like ours to manage. We get a number of important management features by purchasing licensing for Microsoft’s products in this way. For instance, tools and importantly, the rights to produce installable media and network-based installs are included.
Under the terms of the contract, we must purchase initial OEM licenses for Windows XP Pro when new systems are purchased, but these systems can then be upgraded under the contract as needed over its duration. We need not, however, purchase licenses for Office Pro. This software can be installed on site as the system joins the domain. In fact, aside from initial OEM operating system licenses purchased with new systems, all purchases of Microsoft products will be through our volume licensing contract.
The agreement enables the lab to develop and promote a standard Windows workstation configuration that centers on a single operating system and common desktop productivity software (MS Office). Providing universal access to the most modern versions of these products enables the Computer Center to use the newest and most productive tools and techniques to build, configure and manage the large number of systems on our site. This is an extremely important feature for us in our environment of heavy demands and short resources.
And, since support for Windows NT4.0 is no longer available, this license agreement is just in time! It means that users needing to upgrade these obsolete systems can do so immediately, without having to procure additional licenses, etc. Note that this applies to any systems that may still be lingering around at Windows 95/98/ME, etc. As long as the hardware will support Windows XP, the system can be upgraded.
For the details of the new Windows Workstation configuration, visit our web page at: http://cc.jlab.org/docs/services/windows/WorkstationConfig.pdf . To get started rebuilding your system, go to the web page at http://cc.jlab.org/services/windows/BuildSystem/ to review the process.
Another interesting feature of the current Microsoft licensing system is the ability to operate a second installation of Microsoft Office for each primary installation. This can be done along the lines of an 80% use / 20% use ratio. For instance, if you have a desktop workstation that you use most (80%) of the time and a laptop that you use occasionally (20%), you consume only a single license for Microsoft Office. Note that this is true only for MS Office – not for the Windows operating system itself. Each machine must have a Windows XP license for the operating system.
There also are provisions for an employee purchase program that enables employees to purchase Microsoft products at a nice (modest) discount. There is also a “Home Use Program” in which a single copy of Microsoft Office can be purchased by individual users for home use for the cost of media alone (~$20). More information on these features is available in a separate article in this newsletter.
Overall, the adoption of these new bulk licensing procurements and procedures will reduce our software costs, but importantly, greatly improves the Computer Center’s ability to provide stable, dependable systems for users at Jefferson Lab.
As cyber security becomes a top priority for computing users around the world, much attention and interest has been focused on firewalls. If you’ve heard the term, and haven’t been quite sure what everyone was talking about, a firewall is just a program or a device that makes it so that one computer cannot connect to another by blocking incoming network traffic. Generally, they can be made to block only certain computers, or certain types of connections, etc.
There is a large, very sophisticated firewall that exists between the lab’s interior network and the open internet. This device is constantly updated to block intrusion attempts, and limits the connections coming in to the site to only those destined for specific services on specific computers that we want to be visible from outside. Attempts to connect to other computers in the lab are blocked.
Within the lab itself, our network is becoming increasingly segmented, with firewall-like rules at work at the boundaries between the network segments. These rules are referred to as “Network ACLs” and are used for example to limit the network traffic between the conference network and the site network to roughly the equivalent of what a visitor would see from the open internet.
Finally, on individual systems, firewalls – occasionally known as “personal firewalls” are used on a specific system to prevent unwanted network connections from other systems. These firewalls are commonly implemented as software on the specific system that can be configured by the user to allow or disallow connections on specific ports. These also usually include the ability to block outgoing connections from your computer. This is intended to help prevent the spread of various malware that makes connections from your computer without your knowledge. For these personal firewall products, a couple of important issues come up at the lab…
Generally, individual system firewalls are a great idea. They contribute to our “defense in depth” strategy wherein our security is developed as a series of tough layers. But, these products can interfere with normal operations in a network environment like Jefferson Lab and must be properly configured.
Authors of personal firewall software generally assume that the system is located at someone’s home with a connection to the internet. The default settings for these firewalls are such that they block all connections to the system. In our network environment, this behavior will prevent centrally automated management processes like anti-virus and hotfix monitoring from occurring. The Computer Center forces a setting onto JLAB domain Windows Workstations that turns off the windows firewall that is built in to Windows XP (and recently updated in Service Pack 2). Note, however, that if you have installed a different product like ZoneAlarm or BlackICE, you must manually configure these products so they do not disable automatic functionality. This also applies if your system is not correctly configured as a domain member.
In the future, the Computer Center expects to provide proper firewall configuration to domain computers. This will be based on the provided Windows Firewall or another centrally managed product. This centralized configuration management is not available for other third-party products, so individual future purchases of these products is discouraged.
There are several benefits from the Microsoft/JLab Enterprise Agreement other than discounted cost and increased managability for JLab owned systems. Two additional benefits are the Home Use Program and the Employee Purchase Program.
The Employee Purchase Program (EPP) provides discounted prices from Microsoft on many of their products. The EPP has no restrictions on how software is to be used, and offers a longer list of products than the Home Use Program. If you are going to install the software on your home pc for personal use, or for installation on a family member's computer (including your children going away to college), the EPP is the correct program to use. More information is available from http://cc.jlab.org/docs/services/windows/MS_Employee_Purchase_program.htm
Using the Home Use Program (HUP), employees of Jefferson Lab can purchase Microsoft products directly from Microsoft (including MS Office, Project, Frontpage and Visio). Programs purchased with the HUP can be installed on a single home system and shared with family members. The HUP purchase is discounted to the cost of the installation media (~$20) because (1) you agree that you are working with JLab files on your home computer and (2) the home license terminates when you terminate employment with Jefferson Lab and you agree that you will uninstall the software and destroy the installation media at that time. More information is available from http://cc.jlab.org/docs/services/windows/MS_Home_Use_program.htm
The Cyber Security Review in May 2004 identified the lab’s network as being flat and needing to be segmented into enclaves based on security requirements. One of the enclaves identified was for Scientific Computing. This enclave includes the networks and computers for the batch farm, mass storage system (tape silo), the DAQ networks in the halls, and the LQCD clusters.
To resolve this issue the Scientific Computing networks will be segmented from the rest of the site by imposing an Access Control List (ACL) at the ingress and egress points of the network during the September down. Once in place, users will not be able to directly login to DAQ systems. Access to the Scientific Computing Enclave will be limited to the ifarm systems. Users attempting to login to the DAQ systems from their desktop will have to first login to an ifarm system via ssh. X-windows displays will have to be tunneled through their ssh connection to the ifarm systems. This configuration is similar to the way offsite access is currently done through the login.jlab.org computers.
The goal is to create the Scientific Computing Enclave and deploy the required ACLs during the September down. Every attempt is being made to identify protocols that need to pass through the ACL for DAQ. If there are unexpected issues impacting DAQ and the experiments during the September deployment that cannot be resolved in a timely manner, then the ACLs will be removed and the network restored to its previous configuration. A second attempt to enclave the Scientific Computing networks would then be scheduled for the December down.
The Computer Center has recently deployed a new Wireless LAN (WLAN) for the site as part of a Cyber Security project. The new WLAN solution takes into account requirements for Cyber Security as well as the concerns of Computer Center administrators and the users of the wireless network. The Secure Wireless Network Working Group was formed after the Cyber Security Review in May 2004 to define the specific requirements for the new WLAN. The group consists of network, systems and security administrators, and users. The following requirements were made by the group and were used to design and implement the new WLAN:
Based on these requirements and the tight integration with our existing wired LAN (composed principly of Cisco hardware), the Computer Center selected the Cisco distributed WLAN. The solution was selected after a strenuous 30 day evaluation of the products in our environment.
Windows XP and Mac OS X users can try the new secure WLAN configuration with their own wireless clients (laptops). Linux, however, has had issues with the current versions of drivers and supplicants supporting 802.1x and WPA. Until the issues with Linux have been resolved, the existing WEP protected WLAN called 'jlab' will remain active. However, monthly WEP key changes may be initiated in the near future.
The new Cisco wireless access points are capable of simultaneously supporting the new secure WLAN configuration and the existing jlab and jlab_conf WLAN configurations. This allows us to support the new secure WLAN for users utilizing operating systems that support it and phase out the older WLANs over time once the Linux issues have been addressed. Future news regarding the progress of the upgrade will be in coming issues of the CC Weekly News.
As part of this project wireless coverage has been expanded. The following areas have already been upgraded and have an expanded area of coverage:
The CAD workstation hardware migration was completed in July 2005. All designers in the Mechanical CAD design groups at JLAB have been moved from HP-UX workstations to new DELL workstations running the MS Windows XP Pro operating system. The new MS Windows workstation configuration is based on the latest high-end Dell 670 Precision Workstation. When compared to our current HP-UX systems, these Dell Windows workstations provide increased CAD performance at significantly lower cost to JLAB.
This CAD hardware migration project coincides with the Computer Center’s plans to ultimately replace all of their HP-UX central server systems with Sun Solaris, Linux, or Windows systems. All of the new CAD Windows workstations are being managed within a common Windows “Organizational Unit” that provides for standard configuration management and administration. The migration to a new MS Windows based standard for CAD workstation configuration and administration will continue to provide significant benefits for JLAB in the coming years.
Side note:
As a result of this CAD hardware migration project, certain JLAB CAD design groups have begun excessing their HP-UX C-class workstations. Any JLAB group that is interested in obtaining one or more of these workstations may contact Todd Coates (x5537).
The main software that is being used for 3-D mechanical design at JLAB is called I-DEAS. UGS, the company that owns the I-DEAS software has announced that it will retire I-DEAS and stop supporting the software sometime after 2008. Their replacement offering is a 3-D mechanical design software called NX. With the impending retirement of the I-DEAS CAD software looming, the JLAB ME CAD Steering Committee is working on a plan to migrate our I-DEAS software and data installation to NX. This migration will begin in FY06, and will likely take two or more years to complete.
The software migration from I-DEAS to NX is accomplished in two major steps. The first step, which will be accomplished in FY06 is to migrate all of the I-DEAS metadata that defines the current design data organization, to a new software that uses an Oracle database. This new software is called NX Manager. The NX Manager software is capable of managing both I-DEAS design data and NX design data. The second step, which will be accomplished in FY07 or FY08 is to translate all of our I-DEAS design data (parts, assemblies, and drawing files) to the NX format and to install the new NX software as a replacement for I-DEAS.
Both of these steps will require much time and effort in evaluating, implementing, and training. The software licenses of NX Manager and of NX will be provided by UGS to JLAB as replacements for the I-DEAS software, under our current software license maintenance agreement. The only added software licensing costs will be those associated with the added Oracle licenses that must be purchased.
The JLAB ME CAD Steering Committee is working on a plan for this CAD software migration. More plan details will be released as they are developed.
Questions regarding the information provided in this article can be directed to Todd Coates, x5537, tcoates@jlab.org
This document is maintained by {helpdesk@jlab.org}
Copyright Jefferson Lab 2007