Linux Migration

The command line may not be as sexy as point-and-click, but if you know the internals of an operating system, you'll be better able to customize and troubleshoot the machine. Command-line interface users tend to know (and want to know) how things are configured.

This depth of knowledge pays off because you can't point and click for every Linux server function. You can keep your CLI time to a minimum by utilizing Web-based administrative tools like WebMin (webmin.com), but even if you use user-interface-friendly distributors like those from Red Hat or SuSE, you'll still have to roll up your sleeves and delve into a terminal window occasionally.

Knowing the CLI also makes automation easier. If you're command line-proficient, you simply type in the command line, see if it works interactively and then type that same command line into the scheduler so it executes at a given time. GUI users, meanwhile, have to worry about whether their GUI application supports batch or scheduled processes.

Microsoft is now actively promoting scripting to its MCSEs (Microsoft Certified Systems Engineer), but don't look for that to make CLIs more attractive to MCSEs anytime soon. If you're a Windows administrator who's comfortable with command-line utilities like LINKD.EXE and NETSH, and could navigate .INI files in the glory days of Windows 9x, you'll do just fine with Linux.

Read the Fine Manual

The most important command in Linux is man, or manual pages. The option set and functionality of most Linux commands are documented in the man system, so expect to use it often.

For starters, try man man. This will give you a description of the man command, along with command-line options. Don't know which command you're looking for? Searching for something to do with partitions? Try man -k partition.

But first, get to know the three essential parts of Linux: the disk and file subsystem, the network subsystem and the windowing subsystem.

We'll begin with the disk and file subsystem: On an Intel platform, Linux uses the same "only four primary partitions allowed per physical disk" scheme you've come to know and love in the Wintel world, along with the same logical-partition scheme. These get formatted in much the same way as Windows partitions. There are several types of file systems. The NTFS-equivalent for Linux is ext2fs, but there are other file systems as well, such as journaling file systems.

Rather than represent different file systems with drive lettersas Windows does, Linux mounts everything in a subdirectory called a mount point, on the / (root) partition. So instead of a "C:" drive, you have a "/" drive, and instead of a "D:" drive (that you might use for data storage), you have a "/data" file system (see "Windows vs. Linux," right). The LSB may make you crazy at first, but remember that file systems, with the exception of the root file system, get mounted on subdirectories. What happens when you mount a file system on a directory that has files in it? Easy--those files aren't visible until you unmount the file system.

One major problem with early Unix efforts was file layout standardization. Fortunately, the LSB (Linux Standard Base), which specifies library interfaces, system-initialization standards and so on, came to the rescue. The LSB makes it easier to hire someone who is up to speed on your system even if he or she only has experience on a different distribution (see "Sites To See,").

In keeping with a healthy Unix tradition, however, just about everything is represented as a file in Linux, readable and writable by normal I/O operations. Most devices are represented as special file types, instead of Windows nomenclature like LPT1. Special file types let you rule in, or rule out, a subsystem in case of trouble: Ever send a print job to LPT1 rather than to the Windows spooler?

Device files are special types of files in the file system stored in the "/dev" subdirectory. Memory and all disk partitions are located in "/dev," so this subdirectory should be protected with the appropriate file permissions.

Another file system, "/proc," stores process status. It shows you the files opened by a particular process and which environment variables are set (PATH a nd other key variables), among other things. Having visibility into the process can help with troubleshooting.

There are three file permissions on a Linux file system: read, write and execute, which are grouped into categories--owner, group and other. This is the file (or directory) mode. If you need more information on Linux file modes and how to change them, type man chmod.

Linux's network and service subsystems both get started at boot time. The good news is that these services are brought up using command-line utilities. This results in consistent behavior when you try to reproduce a problem--a process that fails at boot will almost surely fail later at the command line. Then you can fix the problem more easily because you can trace it, vary the command, and poke and prod until you figure it out.

Here's a simple example of assigning a static IP address to your Ethernet card: # ifconfig eth0 192.168.0.55 netmask 255.255.255.0. Essential information for DNS is stored in the file "/etc/resolv.conf."

Some Linux systems--most notably Red Hat--abstract this functionality in "service" system scripts, batch files that are in human-readable format. You can run these scripts manually, and if you're feeling adventuresome, you can view and edit them, too. The syntax for any Linux service is # service network [ start | stop | restart ] .

These scripts are in the "/etc/init.d" directory for your viewing pleasure. (Think of them as multiple AUTOEXEC.BAT files--one for each service.) Many network services get started this way, though some start via Xinetd, a server that listens on behalf of the program and invokes the program only when an incoming socket is opened (on some systems, an older version of Xinetd, called Inetd, is used). If you want to drill down deeper into how this works, try man xinetd or man inetd.

The mother of all processes is "init." It keeps track of the system's state, and starts or stops processes accordingly. The system's state is also known as the "init state," or the "run level." When you're running in single-user (maintenance) mode, for example, this is init level 1. Multiuser mode with no network is init level 2; multiuser mode with networking is run level 3.

Doing X Windows

The Linux GUI isn't intrinsic to the operating system. This has its advantages. If the GUI isn't available, for instance, you can still get real work done, like recovering a system in a failure.

But it's nice to have a GUI around when you need it. Linux's GUI is made up of an X Windows server, a window manager for the X server and general client programs. X Windows is a client/server system: The X server runs on the host machine and provides a context for clients to display their information. Since there's no tight coupling between where the client program is running and where it displays, X Windows clients don't have to run on the same machines as the server. And they can display and receive their output and input remotely, without special remote-control software. While this does simplify administration, it can also pose a security risk.

Linux Superhero?

Learning Linux is a process. The OS offers stability and power; but as the uncle of Peter Parker (aka Spiderman) said, with great power comes great responsibility. If your organization doesn't support and encourage continuous learning, get off the Linux boat now--you're doomed to failure.

If you tinker with Linux in the lab, read and post to newsgroups or mailing lists, and even (gasp) load Linux on your home computer, your enterprise's transition to Linux should go smoothly. If not, get started in the lab and join some newsgroups (see "A Little Linux Netiquette,").

The lab is one of the primary sources of lifelong learning for your new platform. It helps you simplify your setups and understand how one subsystem affects another. Linux's command line is like a scalpel--it's crucial for delicate surgery, but if you're not experienced with it, you risk severing an artery. A single misplaced space character in a script or at the command line can wipe out your whole file system. The command rm -rf foo / is quite different from rm -rf foo/.

Meanwhile, you'll need to integrate your new Linux system with legacy non-Linux systems. Keep your support contracts for those legacy servers in place in the interim to prevent finger-pointing in case of downtime. It's all about experience.

Jonathan Feldman is the director of professional services for Entre Solutions, a Savannah, Ga., infrastructure consulting company. Write to him at [email protected].

Post a comment or question on this story.

SITES TO SEE