Linux and Samba in a Federal Lab
Linux and Samba recently answered the needs of the Army Research Lab (ARL) at Adelphi, Maryland. Our branch does state-of-the-art research into a specific type of lasers and amasses large amounts of data during the performance testing of these devices. We were able to connect our test equipment over the network to a Samba server. The twist to this approach is that our configuration makes it appear to the users that they access the data through the branch's NT fileserver. I'll explain the setup in detail, but the main trick is creating a network shortcut on the NT box to point to the Samba share while making the Linux box invisible on the network. Figure 1 depicts the setup of the network.
Our branch develops extremely small lasers called VCSELs (vertical-cavity, surface-emitting lasers), which fall under the general category of photonics research. We easily can put over 60 lasers into a square millimeter, and the full wafer containing the lasers can be three inches in diameter. Therefore, we can have thousands of devices on a single wafer. Figure 2 shows a picture of a typical VCSEL. The main tests we run to characterize the performance of each VCSEL are called ILV curves for current, light and voltage. Basically, we see how much light comes out for the power that was put in. Also, most of the analysis software is on the user's desktop machine so they need to be able to access the raw data from there. Users are creatures of habit. Getting data pertinent to the branch has historically meant going to the NT server. Since the users were used to getting data from the NT box, we did not want to make them go somewhere else. We tried to make everything transparent to the user and make it appear as though they were getting the data from the NT server. To force the users to go through the NT box, we make the Linux box invisible to the network. We rely on the security of the NT box to authenticate users accessing the data.
Two pieces of equipment are key to characterizing the VCSELs. First is the probe station that is basically just a microscope with some tiny probes and a light meter. The probes apply the power to the device, and we measure the power produced with the light meter. A 4155B parameter analyzer from Agilent is the second piece of equipment. This analyzer is programmed to sweep the current level and measure the voltage and light. It has two main ways of being controlled: front panel and the GPIB interface. Granted, the GPIB port is a popular scientific interface and allows us to do fancier tests by controlling the test setup with a computer as well as collect the data, but our controlling computer is about five feet down the lab bench and cannot be moved closer. This makes it difficult to start the test when the probes are in place. Fortunately our main test is simple to program through the front panel. Our test routine is to position the probes by looking through the eyepiece of the microscope, reach up carefully and push the test button on the parameter analyzer and then save the data. Figure 3 shows the lab hardware.
After we get a clean run, we need to save the data. The 4155B has three ways to save the data: GPIB, floppy and TCP/IP. Since we aren't controlling the analyzer with the GPIB, that's not an option. The floppy supports 3.5" disks, but these disks fill up quickly and you have to walk around with them. Since we have several lab areas where we work, it's not unheard of to have to backtrack to recover a temporarily misplaced disk. The answer we put together works because of the TCP/IP support.
The parameter analyzer supports TCP/IP, specifically NFS. You can even ping the analyzer. Since it's registered in the lab's DNS, the ping can be done by way of IP address or name. We were able to put together a Linux box out of obsolete or broken equipment. Literally, we pulled together parts of three computers into one. It didn't cost the government anything, and it fills the need. For the installation, the newest distribution that we had and that the P-133 hardware would support is Red Hat 6.2, so we put that on and hardened it with Bastille and the latest patches. Additionally, all the unnecessary services were turned off and SSH was added. We sliced the hard drive space carefully and ended up with about 1.5GB of space for data. Total time of install and configuration was three hours.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- Tips for Optimizing Linux Memory Usage
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Non-Linux FOSS: .NET?
- Play for Me, Jarvis
- diff -u: What's New in Kernel Development