A Perl script helps to catch a thief
During the night and weekend hours, RAM, CPUs, and high-end video cards began disappearing from PCs in my company. The thief would shut down the units, pry open the cases, and remove the components. The next morning, users would discover the disassembled units.
Security guards patrol the facility, but because of its size and the large number of PCs, they can't watch all the computers at once. But the guards did have an idea about how to catch the thief. Users turn off their monitors at night to save energy, but many leave their PCs on to receive software pushes. The guards thought that they could apprehend the culprit if they were notified immediately when PCs were turned off. My team developed a Perl script that pings the running PCs and pages the guards when a PC is shut down.
Requirements and Solutions
In a meeting, the security guards and my team developed a list of requirements for the script. We also discussed a couple of features the guards would like but that weren't absolute requirements. My team then translated the requirements into pseudocode—that is, sentences describing what the code would do—and later into a completed script. During the translation process, we decided which scripting language would work best for this project and how to meet each requirement. Here's the list of requirements, with our considerations and solutions for each requirement.
Requirement 1: Ping a list of target PCs and notify the security guard when a PC fails the ping test.
Considerations: We could have written this code in Windows shell script or one of several other languages, but we chose Perl because it has very low CPU overhead. The script will read from input files, and Perl is efficient for this type of operation.
Solution: Use the Perl modules Net::Ping for the ping test and Mail::Sendmail for the email and pager notifications. Possibly break the code into paging and testing subroutines.
Requirement 2: The page message must indicate the PC name and building location.
Considerations: Create an input list that contains name and location information for each PC. The location descriptions might contain spaces.
Solution: Create a Comma Separated Value (CSV) file, and use Perl's split function to split the line into PC name and location elements. Verify that this input file exists, and exit with an error message if it doesn't.
Requirement 3: The page-recipient list will change, so it must be easily modified.
Considerations: We could have hard-coded the recipient list in the script, but editing a tested script is usually risky because one small typo can send you back to the debugging stage. Using an input file that the script parses is always preferable.
Solution: Create an input list that contains the page recipients' addresses. Verify that this input file exists, and exit with an error if it doesn't.
Requirement 4: Record ping failures—including time, PC name, and failure-incident details—in a log file.
Considerations: Both the security guards and management want to have a log file that details the run results to use to analyze the time and location of theft incidents.
Solution: Create an output file for logging ping failures. Use the file-creation date and time as part of the log filename. Log ping-failure incidents—including time, PC name, and incident details—to the file.
Requirement 5: When the script is launched each day, it must poll the computers and remove from the list any machines that are offline at that time.
Considerations: When the script starts, it should ping all the nodes during an initialization run, then use this list for the testing period. The next time the script runs, it should delete this temporary list and create a new one.
Solution: Use the input file with the first script run, and collect the nodes that respond in an array that will hold their names and locations during the testing period. This initialization section might warrant its own subroutine.
Requirement 6: When an online PC goes offline, send a page only once to indicate the offline condition. If the PC comes back online, send an "all clear" page.
Considerations: Track the last state of a pinged node. When the state changes, initiate a page with an appropriate message indicating the offline or online condition. We could use one file, multiple files (one per node), NTFS file streams, or a Perl list to track the PCs' state. Reading files or NTFS file streams would add overhead.
Solution: Create a Perl list of failed nodes. A node that isn't on the list was online at last ping.
Requirement 7: Minimize false alarms while providing quick detection and notification.
Considerations: Ping results can be unreliable. A ping can fail once, then succeed on the next attempt. Basing the test result on one ping could mean that a momentary network glitch would result in a false alarm. Alternatively, we could use one ping with a long timeout value. However, this approach could slow notification.
Solution: If the first ping of a node fails, ping the node again. Page only after a second ping failure.
Optional Feature 1: Indicate in the page the likelihood of a real incident. A theft is more likely to be in progress if several PCs are offline than if only one PC is offline.
Considerations: We're already tracking whether machines are online or offline. We would just need to count the number of offline machines to assess the risk level.
Solution: Count the number of failed nodes on the Perl list created to meet Requirement 6. If the list has one node, the risk is low; if two nodes, medium; if three or more nodes, high.