ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
A few weeks ago, we looked at Sun’s on-again, off-again relationship with Linux, which has involved unseemly outbursts of costumed penguin love followed by cold denunciations and an understandable desire to pump Solaris x86. Hot on the heels of its move to indemnify its Linux customers, Hewlett-Packard took another step in the penguin courtship dance, telling potential customers it isn’t too good for Linux, and it will reward them for dumping Sun.
HP goes digging for dissatisfied Sun customers; the Linux 2.6 kernel series is frozen; a perusal of the SANS Institute’s annual Security Vulnerabilities list reveals sloth and complacency to be bigger threats than the average buffer overflow; and we reveal a Jabber gem we unearthed, an obscure little app called restartd.
The HP “Linux Lifeline” program looks good on its face: Customers that switch from Solaris-based servers to Linux-based HP servers get a bundle of services and incentives HP values at around $25,000. The services include a TCO analysis, trade-in credits of up to 20 percent for some of HP’s high-end servers, and a rebate of up to 15 percent for HP ProLiant servers. HP is also offering software migration services in the bundle, to help customers get over the hump of losing their Sun-specific applications, like mail and Web servers. Good stuff, but we’re not here to make a sale for HP.
There’s a certain kind of Unix watcher who’s more interested in the Great Unix Horserace between Linux and All That Has Come Before than the realities of enterprises faced with actually deploying this stuff. HP’s program has one eye firmly fixed on these people, who represent a wonderful cheering block making a lot of positive noise over anyone who “embraces” Linux.
But migration is not a trivial task for an organization of any size, and a bundle of incentives to make a move is no more generous than it was when Sun was pushing its “grab HP’s e3000 customers” program six months ago. A light elbow in the ribs while the right people are watching isn’t the Pearl Harbor of marketing moves, no matter what some of the more enthusiastic analysts say.
As much as we think Sun is missing something with its “Linux has no place on the server” line, HP’s move strikes us as less than gush-worthy. Sun’s customers still get good value, even if the company has odd notions about how Solaris stacks up against Linux in some contexts. Unless we were already considering a move to Linux for reasons other than vague noise about how “it’s the future,” we’d leave this one to the race fans.
In Other News
- Speaking of Linux, project leader Linus Torvalds has announced a “stability” freeze of the 2.6 kernel series, the next stable release of the Linux kernel. It’s been over two years since Linux 2.4 was released. There’s a good chance 2.6, currently in test releases, will be “soup” by the end of the month.
- Another release milestone is approaching with the October 24 release of OS X 10.3, codenamed “Panther.” New features we believe server admins will appreciate include additional management tools, Active Directory integration, and the introduction of Postfix, replacing sendmail as the mail transport agent.
- Finally, Novell continues to make good on its newfound Linux focus with the announcement of a “Certified Linux Engineer” program. Discreet from its Certified NetWare Engineer program, the CLE program will focus on Linux in business environments.
Security Roundup
After one week of repeated ssh problems, and another week of SSL-related problems, it seems appropriate that this week would be somewhat quiet so we could all reflect on the SANS Institute’s annual “20 Most Critical Internet Security Vulnerabilities” list, which picked each of the top 10 vulnerabilities from the Windows and Unix worlds and discussed them. While we enjoyed a certain amount of Windows-related schadenfreude, the sorts of things posing problems in the Unix world made us wince: They have increasingly less to do with the software itself and more to do with the habits of the people using it.
If there’s one takeaway from the list (besides the obviously useful list of vulnerable ports we’d recommend newbie admins tape to their cubicle walls), it’s that sloth and complacency are probably bigger threats than the average buffer overflow. Several of the top Unix vulnerabilities listed are the result of disengaged administrators and careless configuration. In other words, keep up on your patches and take advantage of tools that enable you to enforce strong passwords and other security-conscious habits among your users. Buffer overflows are usually patchable in short order. Laziness is not.
Tips of the Trade
We spent part of our time over the past week getting to know Jabber, an open source instant-messaging server that allows users to use its own native IM protocol, or a variety of “transports” that act as gateways to other IM services like Yahoo! or AOL Instant Messenger (AIM).
Although our enthusiasm for Jabber is fairly high (it has some outstanding features, including a way to log in to a Jabber account at multiple computers and set the relative priority of each session so you never miss a message), our enthusiasm for Jabber’s bleeding edge is somewhat qualified. Over the course of setting up the AIM transport for use on our own machine, we discovered it has the nasty habit of failing every so often, especially when the server is first getting settled in. We found an obscure little app called restartd that came in handy for our server as we tried to get it settled in.
restartd is what its name implies: a daemon that keeps an eye out for a process and restarts it if necessary. Part of the Debian project, restartd is available via Debian’s package database in source form (download the tarball at the bottom of the page). It built and ran cleanly on a Red Hat machine for us. Just unpack the tarball, “cd” into the resulting directory, and run make && make install to build the binary and install the program, its man page, and a configuration file.
restartd is configured via the file /etc/restartd.conf, which takes four arguments per line: the name of the process to be monitored, a regular expression to look for in the active processes, and what to do if the process in question is running or not.
Each argument is separated by a tab.
Here’s how we set up /etc/restartd.conf for our jabber server:
Note: To keep the page width reasonable here, we’ve replaced the tabs with line breaks. Use tabs when you write your own restartd.conf file.
jabber "jabberd.*jabber.xml" "/usr/local/bin/jabberd - |
The first line says this is the generic label for the process (useful for debugging larger files, it doesn’t get used by restartd, so you can pick any name that makes sense to you).
The second line is a regular expression that matches what the process looks like when the command ps ax is run. When we start our jabber server we do it with this command:
/usr/local/bin/jabberd -c /etc/jabber/jabber.xml& |
So our regexp merely matches the “jabberd” and “jabber.xml” strings with anything between the two, which shows up in ps ax|grep jabber, like so:
17593 ? S 0:00 /usr/local/jabberd -c /etc/jabber/jabber.xml |
The third line is the command we want to run when restartd discovers a process isn’t around anymore. If the program you’re running doesn’t exit to the shell, make sure to background it by including “&” at the end. Otherwise, restartd will stop processing your commands after the first one. In a case like a jabber server, where several instances are running, failure to background each process when it’s restarted will result in only one process being restored.
The fourth line is for output if restartd finds everything is fine. In our case, we just echo the phrase “jabberd ok” to a file in /tmp.
