Linux Serial Consoles for Servers and Clusters
Listing 3. lilo.conf with Serial Console Support
serial=0,9600n8 boot=/dev/hda map=/boot/map install=/boot/boot.b prompt timeout=50 message=/boot/message linear default=Linux image=/boot/vmlinuz-2.4.20-8 label=2.4.20-8 read-only initrd=/boot/initrd-2.4.20-8.img append="root=LABEL=/ console=ttyS0,9600n8"
SYSLINUX is a bootloader designed for use with DOS/FAT formatted bootable floppies. Red Hat/Fedora Core Linux uses SYSLINUX for both the install boot and rescue floppies. In order to install or recover from boot floppies over serial console, the floppies need to be modified. We have added the console= and text directive to the append line, and we have removed the extra boot selections present in Red Hat's original file. The first line initializes and directs SYSLINUX to use serial port 0 (aka /dev/ttyS0) and defaults to 9600n8. Using this modified boot floppy, we can install the OS over the serial console. Red Hat's text installation option works quite nicely this way. Using the above modifications, you can convert any SYSLINUX boot floppy to use serial consoles. This procedure also works for ISOLINUX, which is a spinoff of SYSLINUX used on bootable CD-ROMs.
Listing 4. syslinux.cfg File Configured for Serial Console
serial 0 default Linux prompt 1 timeout 100 label Linux kernel vmlinuz append initrd=initrd.img lang= text \ devfs=nomount ramdisk_size=8192 \ console=ttyS0,9600n8
As stated before, the console can become a login terminal after the system is up. For this to happen, the getty entries in /etc/inittab must be modified. The standard /etc/inittab starts mingetty on virtual consoles only. Because mingetty is not suitable for serial terminals, we must use something else. Many getty-type programs are available, but agetty is included with almost every Linux distribution, so we use it. Also, make sure the system boots to nongraphical mode, normally runlevel 3. Some Linux distributions default to an X login, usually at runlevel 5, if any X packages were installed. The default runlevel is determined on the initdefault line. To enable agetty on serial lines, you can modify the initdefault line in /etc/inittab:
and add a line for agetty:
co:2345:respawn:/sbin/agetty ttyS0 9600 vt100
This tells agetty to start waiting for logins on /dev/ttyS0 at 9,600bps, using vt100 terminal emulation. You may want to keep the original mingetty entries to allow a directly attached keyboard and monitor to be used for logins. If not, simply comment them out. Where root can log in from is controlled strictly; in order for root to log in from ttyS0, you must add the device to the /etc/securetty file.
Finally, if your system has created a /etc/ioctl.save file, delete or rename it. This file is used to save console settings between reboots. If the system was booted using a directly attached keyboard and monitor, this file attempts to restore improper settings. A new one is created when you reboot using the serial console.
Red Hat's bootup scripts use escape sequences, so the OK, PASS and FAIL messages show up in color. This can confuse serial consoles, so it is best to disable it. Simply modify /etc/sysconfig/init, and change the BOOTUP= line to say BOOTUP=serial. This will prevent the use of color messages.
Serial cabling can cause some confusion. Basically, there are two kinds of serial ports, DCE (Data Communication Equipment) and DTE (Data Terminal Equipment). The ports differ in how specific signals are connected to pins on the connector. Data communication with serial ports uses separate transmit and receive wires, so when connecting two pieces of equipment together, one must make sure the transmit wire on one side connects to the receive wire on the other side. As long as you are connecting a DCE device to a DTE device you can use a regular straight-through cable, where each pin is connected to the same pin on the other side of the cable. If you are connecting devices of the same type, however, you must use a special cable or adapter, called a null modem, so the signals are swapped properly. DTE devices usually are terminals, computers and printers. DCE devices are designed to connect directly to computers, such as modems and serial mice.
In addition to the data transmit and receive wires, a number of handshaking signals are used to control the flow of data, so one side is not talking too fast for the other to understand. These signals also must be swapped by the null modem. To add to the confusion, two popular connectors are in use for serial ports, the 9-pin DB9 and the 25-pin DB25. These can come in both male and female varieties. In almost every case, the devices used for serial consoles (terminals, computers and console servers) are all DTE, which means you need a null modem of some sort. These are available in the form of adapters and cables. Most off-the-shelf units work fine, but if you want to solder your own, check the on-line Resources section for links to pinouts and cable diagrams.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide