ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
There’s a scene in the 1987 movie “Robocop” where a security robot, programmed to kill anyone holding a weapon, trains its guns on a junior executive holding a pistol to demonstrate how the machine deals with criminals. “Drop your weapon,” intones the robot, “you have ten seconds to comply.” The young executive drops the gun. “Drop your weapon,” repeats the robot, “you have eight seconds to comply!” Panic ensues. The robot continues its countdown. Things don’t end well for the executive.
SGI is SCO’s target of the week; Samba goes 3.0, posing the question, ‘why Windows?’; a U.K. security audit finds holes in OpenSSL; and we review some of GNU screen’s numerous configuration options and commands.
Right about now, SGI may be feeling like that junior executive, and SCO is the robot training its guns on yet another alleged case of IP infringement. Tossing away the pistol of infringed code has evidently done SGI no good at all.
SGI is now officially in SCO’s sights over claimed violations of SCO’s IP, including elements of xfs, the journaling file system SGI donated to the Linux kernel a few years ago. SCO sent notice in August that it was terminating SGI’s Unix licenses where Irix (SGI’s own Unix variant) is concerned, but it hasn’t announced any plans to sue. Yet. SGI has until October 14th to comply with the termination. If what SGI has to say about the matter is any indication, SCO may be saved some embarrassment.
SGI’s response to SCO is part of what’s coming to be more and more the Kabuki theater of Unix litigation: The company has told SCO it doesn’t agree, and just as promptly taken its case to the open source community so we can all endure yet more open letters and responses to open letters while these companies slug it out.
According to SGI, it did contribute some lines of infringing code to the Linux kernel: about 200 out of more than 1 million. The company says it expunged the code, then conducted an audit and turned up other problem areas, which it is still in the process of fixing. SGI is doing the right thing, both in general terms and with regard to SCO’s demands, which were that SGI fix the matter.
SCO, on the other hand, is persisting with the license termination.
The immediate reaction of many (us included) was to laud SGI for being reasonable and fair, moving quickly to fix a problem and honor another company’s IP. Our other immediate reaction was to scold SCO for keeping its guns trained on SGI despite the company’s reasonable and honest efforts to honor its license. That reaction is reasonable in light of SCO’s inconsistent enforcement (as noted last week when we reported HP’s apparent free pass in the litigation frenzy) and general boorishness on the PR front. If SCO persists in terminating SGI’s licenses despite the company’s apparent good-faith efforts to clean up its code, SCO is wrong.
But further reflection must include the fact that SGI did cop to infringement and tried to mitigate the seriousness of it by pointing to the fact that the code it unlawfully contributed to Linux “appeared” to be in the public domain anyhow, and there just wasn’t that much of it. And that takes us back to the overall arc of the SCO case. and why, as much as we think SCO’s behavior is heavy-handed and overreaching, it’s best to reserve judgment on the core of the matter, which is SCO vs. IBM. If SGI did mistakenly infringe on SCO’s copyright then there’s no reason to believe that IBM would have been immune to the same mistake
In Other News
SCO and SCO-related dramatics hogged most of the Unix limelight this week, but not so much that we can’t take the time to note an important release of an important piece of software: Samba 3.0.
If Linux has found a place as glue in many organizations, it’s in no small part because of Samba, which allows Linux machines to act as Windows file and print servers in a manner that’s transparent to Windows clients. It’s a vital bridge between the world of Unix servers and Windows desktops, and we’re inclined to think of it as key to the success of Linux, right up there with Apache. With Apple’s adoption of Samba in its own OS X, Samba has become a, sort of, lingua franca for file and print sharing.
With the release of Samba 3.0, the software now provides Windows NT Primary and Backup Domain Controller functionality, as well as single sign-on Active Directory support, which enables Samba machines performing PDC duties to integrate seamlessly in Active Directory environments.
The Samba release announcement says “this enables significant cost of ownership savings over a Windows NT4 domain,” which is to say “Why pay for Windows when you can get Samba for free?” That’s a discussion we’ll leave for another time.
Security Roundup
The most noteworthy security issue this week was the discovery of several vulnerabilities that could lead to either denial of service attacks or a remote exploit through the OpenSSL package. The vulnerabilities were discovered during a security audit conducted by the U.K. government. No exploits have been demonstrated yet, and patches may be found, as usual, from your vendor or from the OpenSSL download page, where a patched version is available in source form.
Tips of the Trade
screen Revisited
Last week we made the case for giving GNU screen a try. It’s a piece of software that allows users to multiplex a single physical terminal into multiple login sessions on a server, detach the sessions, and reattach to them elsewhere on the network. What we didn’t go into were the numerous configuration options and commands screen requires to work.
Screen configuration is handled through a file in the home directory called .screenrc. Here are a few lines from our own .screenrc, with an explanation of what they mean:
vbell off: This controls whether screen uses a visual bell by flashing the terminal or an audible bell. If you tend to keep your screen sessions behind other windows, you will probably prefer to turn the visual bell off to be able to hear the audible bell.
caption always: screen can provide a small caption that tells you which session you’re looking at. Handy if you have to access several hosts and don’t have a good indication of which one you’re in.
screen -t production ssh production.acme.com: This line tells screen that when it starts up, it should automatically open a login session named “production” by running the command “ssh production.acme.com”. You can have as many “screen” lines as you like: They’ll all run when you start screen. We have several of these lines in our own .screenrc to connect us to a console mail client, a tail of our daemon log, and our news reader. Any command you would interact with from the shell will work here.
Here are some keystrokes you can use to manipulate screen.
ctrl-a space cycles between sessions.
ctrl-a “ brings up a list of all available sessions.
ctrl-a ‘: prompts for a session to switch to, either by name or by number.
ctrl-a c: opens a new session.
ctrl-a d: detaches the screen session, thus freeing up the terminal. You can reattach by logging into the same machine elsewhere and issuing the command “screen -r”.
If you ever leave a screen session running without detaching first, you can reattach to the same session from another terminal by using the command “screen -RD,” which forcibly detaches the session from the old terminal and reattaches it to the terminal you’re at.
One last tip: If you’re an emacs or bash user used to using “ctrl-a” to get to the beginning of the line, you may notice screen grabs the ctrl-a as its own escape key. How do you get around that? By using the command “ctrl-a a” to tell screen to ignore the escape. It takes a little getting used to. If you want to switch the command prefix from ctrl-a to ctrl-b, you can always use this line in your .screenrc: escape ^bb. With the keystroke examples we gave above, you’ll now be able to use ctrl-b.
