
SECURITY
Remote server management Q&A: Whirlwind Tech Tour
Caroline Hunter, Assistant Editor 10.24.2008
Rating: --- (out of 5)




|
In our first installment of the Whirlwind Tech Tour, we tackle the subject of remote server administration and feature five expert responses to a question.
Here is this week's question:
What is the best remote administration tool in a Linux environment? Why?
Jay Lyman, Open Source Analyst for The 451 Group
I would say the GPL-licensed Virtual Network Computing (VNC) system because it is open source, multi-OS and provides a user interface, to which I am partial since my geekiness and command line prowess are limited.
Click here to see CAOS Theory, The 451 Group's blog on open source in the enterprise.
Serge Wroclawski, Sr. Linux System Administrator at IS Mavens
I'm sure the popular answer to this question will be SSH. After all, SSH is the single most used remote management system for GNU/Linux and other *nix systems. But I think that as a profession we need to move forward,. We can do so by steppingaway from individual host management and into comprehensive configuration management.
Just as software developers have moved from manually editing source files to version control and now automated builds, so must system administrators, as a profession, move from manually logging into a shell and modifying a configuration file to having automated processes handle these tasks.
To that end, I recommend two tools: bcfg2 and puppet. Both are modern, high quality configuration management tools, and do much the same job.
Both work hand-in-hand with version control, package management and both are generative, meaning they can create the configuration files which will ultimately reside on your system.
Kristian Erik Hermansen, Security and Open Source Specialist
You can do just about anything over SSH. OpenSSH has numerous features which are quite useful for remote management. For instance, a remote and secure shell. RSH and TELNET are older, insecure protocols. They should never be utilized.
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseLinux.com
');
// -->

However, in addition to shell access, one can also forward graphical applications to remote machines, create a series of tunnels, redirect traffic over a SOCKS proxy, and perform way too many other features to mention. So why would a savvy sysadmin need anything more?
To see Kristian's blog, click here.
Tony Iams, Vice President and Senior Analyst – System Software Research, Ideas International
Remote server management is a multi-dimensional problem, and managing the Linux OS is only a part of it. There are many layers in the "stack" of a Linux server workload, all of which can potentially introduce separate management requirements (virtualization introduces yet another layer):
So the "best" tool for managing Linux remotely is going to be different for every user environment. The optimal choice will depend on several factors, including a user's unique mix of server hardware and configurations, virtualization maturity, installed Linux distributions, and enterprise management frameworks. Perhaps the most important factor in choosing a remote Linux management tool, though, is to make sure it integrates smoothly into the dominant management tools and procedures that are already in place.
See the Ideas International blog.
Joshua Kramer, Middleware Developer at Belron US
I'm a command line guy all the way. Therefore, without a doubt, the best tool for interactive remote server management under Linux is screen.
Screen is a tty multiplexer that helps you manage interactive sessions.
With screen, you can do things such as:
Best of all, your hands don't leave the keyboard when you do these things.
You'll get the most use out of screen when you have to perform a maintenance exercise using a limited capability device, such as an Asus EEE PC. When you're at your desk, it's easy to spread a number of Putty sessions across your 22" monitor. On small devices that isn't as easy, unless you use unreadable type.
Consider a typical exercise of migrating a database from one server to another. On the first server, you might login and fire up a screen session. When you see the prompt, you might proceed to start a long-running database backup. Because you need to do some work on the second server, you hit Ctrl-A, which brings up another completely separate session. You ssh in to the second server, only to find out that there is an error with the disk array. Pressing Ctrl-D disconnects your screen and allows you to logout and walk back to the datacenter.
To read Joshua's blog, click here.
Has this round of questions and answers sparked a question that you have been meaning to ask? Email it to editor@searchenterpriselinux.com!
 |

|
|
 |
|
 |