Manage Learn to apply best practices and optimize your operations.

Remote server management Q&A: Whirlwind Tech Tour

Remote server administration in an open source environment is best done with the tools recommended by these IT professionals.

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. 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):

  • The server hardware may have out-of-band management modules. In this case, the server can be maintained even if the OS is inoperable or if it has fallen off the networkand vendor-specific management frameworks such as Dell OpenManage, HP Systems Insight Manager, IBM Systems Director (some of which may also have extensions for managing certain components of Linux operation).
  • If a user has deployed blade servers, the chassis may have some specialized management functions, such as remote control of LAN and SAN connections like Dell FlexAddress, HP Virtual Connect, or IBM BladeCenter Open Fabric Manager.
  • When virtualization is introduced, the hypervisor may be controlled remotely through tools such as VMware VirtualCenter, Microsoft SystemCenter Virtual Machine Manager, or Citrix XenCenter, depending on which hypervisor is installed.
  • As a whole, Linux offers a wealth of remote management tools, some of which are optimized for particular distributions, such as Red Hat Network for Red Hat Enterprise Linux, or Novell ZENworks for SUSE Linux. Further, Linux administrators are often most comfortable controlling the OS with typed commands and customized scripts, which can be accomplished through a simple remote command-line shell.
  • Finally, larger organizations may have installed heterogeneous enterprise management frameworks such as IBM Tivoli or HP OpenView, or products from CA, BMC, Symantec, or other systems management vendors, and these could play a role in remotely controlling a Linux server in some way.

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:
  • create additional login sessions
  • switch between those sessions
  • copy and paste text between sessions
  • detatch the tty for a long running process, do something else, and reattach from another location.

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!

Dig Deeper on Linux servers

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.