| Article Index |
|---|
| Cluster Administration |
| Page 2 |
| Page 3 |
| Page 4 |
| All Pages |
Serial Consoles and Logging In
When the system starts to boot the OS, the init process is started.� The init process will read through the file /etc/inittab to do a number of essential startup tasks.� One of these tasks is to start �getty� processes [1] to wait for users to log on.� A getty process displays the �login:� prompt where you enter your username.� The getty process, in turn, starts up a login process that prompts you for your password.
In order to log in over a serial console, a getty process needs to be waiting for someone to connect via the serial port.� In Linux, the device names for the serial ports are /dev/ttyS0, /dev/ttyS1, etc.� We can instruct the init process to start a getty process for this purpose by adding a line to the /etc/inittab file as follows:
# Run gettys in standard runlevels
S0:12345:respawn:/sbin/agetty -h ttyS0 9600 vt100
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
The lines starting with �1:� and �2:� above are examples of the getty processes that are used by an attached keyboard/monitor.� We added another line starting with �S0:� to start a getty process to monitor the serial port ttyS0.� �S0� is used as the label since we used ttyS0 in the example.� You might want to use �S1� if you use ttyS1.� The field after the label (�12345�) indicates that this getty process should be started in runlevels 2, 3, 4 and 5 as well as runlevel 1 (single-user mode).� �respawn� indicates that when the process is killed it should be restarted by the init process.� The final field specifies that we should use the agetty program to monitor for connections.� The agetty program is a getty process that is appropriate for monitoring serial lines.� See the agetty man page for details on available parameters.� As indicated above, you will at least need to specify the serial port to use, the speed at which to communicate, and the terminal emulation to use.� In our example, these parameters are ttyS0, 9600 baud, and vt100, respectively.� Consult the agetty man page for other parameters that might be appropriate for you.� Once you have made this change, restart the init process (type telinit q to do this).
The file /etc/securetty lists all of the consoles from which root can log in.� Thus, now that you have created a getty process to monitor the serial line, you will want to add the name of this serial line to the list in /etc/securetty.� For example, if you started a getty process on ttyS0, you will add ttyS0 on its own line in /etc/securetty.
At this point, if you reboot the system and monitor the serial console, you will see the messages from your BIOS; you will be able to interact with your boot loader; you will see all of the kernel�s probing/initialization messages; you will see all of the output from your startup scripts.� Finally, the getty process you just created will display the �login:� prompt to you and the normal login process will continue.� Both normal users and root should be able to log in via the serial console.� You should now be able to completely control your system over a serial connection from BIOS configuration to login.
Remote Management Port
A remote management port is a special connection on a system that can allow certain services, such as power cycling, to take place remotely.� Many vendors offer proprietary cards to insert into your system to obtain a remote management port.� Some motherboards also provide an Emergency Management Port (EMP) that is usually accessed through one of the serial ports.� The method you use to access these cards will vary by vendor.� With systems that have an EMP, a cable can be run from the appropriate serial port to a serial port concentrator.� Whichever form of remote management port is used, this is an extremely useful feature to have to ensure that a system can be managed remotely.� The serial console can be helpful for all times that do not include the system being locked up.� In this case, the remote access to the serial console will not help.� You will need a way to remotely cycle the power on the system or to run other diagnostics (which may be vendor specific).
The advantages of using a remote management port are clear.� You will have the ability to remotely cycle the power and possible perform other diagnostics on a system regardless of the state of the OS.
If you choose to or need to use a vendor-supplied card, the disadvantage will be the cost of these cards.
SNMP
Simple Network Management Protocol (SNMP) is a very useful tool that is used by many vendors to report various statistics and information about their hardware (and software).� At the management stations, you may find it helpful to use SNMP to collect various vital statistics about your cluster systems.� This will give you a visual indicator of any problems that may be occurring on a particular system in the cluster.� The information you can collect will depend on the information provided by your vendor.� Usually only server products will provide useful information whereas systems designed for home use may not provide any information.� There are other products, such as BigBrother, that can monitor your systems using simple methods, such as pinging your systems, and indicating any systems which may be having problems.
