Lantronix SLC Console Servers

The serial consoles of most of our servers are accessible either via locally-configured console servers based on the conserver application, or via commercial Lantronix SLC console server devices - "SLC's".

The use of the conserver-based consoles is documented elsewhere; this note explains how to use the Lantronix SLC console servers.

Contents

1. Setting up a new Lantronix SLC

There are four ways to configure an SLC:

  1. via the LCD front panel; or
  2. via a command line interface using a direct console connection cabled to the front panel; or
  3. via a command line interface via ssh (after basic networking has been set up); or
  4. via a web interface (again, after basic networking has been set up).

To establish basic networking, DHCP service and an appropriate .inf hostname need to be set up through the usual LCFG means.

In practice:

  • Choose a hostname for the SLC and set it up in dns/inf.
  • Set up and compile an appropriate LCFG profile for the SLC. (The profile 'lcfg/atbslc1' could be used as a template; the MAC address of the SLC is printed on a the base of the unit.)
  • Set the SLC up for DHCP via its front panel, reset it via its front panel, and confirm (via the front panel) that the correct IP address has been picked up.
  • Finalise the configuration via ssh over the network.

The default administration username for the SLC is 'sysadmin' and, on delivery, the corresponding password is 'PASS': this should be immediately changed using the command 'set localusers password sysadmin'.

For reference, the general configuration is as follows:

  1. Network Settings: use DHCP for eth1
  2. Routing: Enable RIPv1
  3. Date & Time: Enable NTP; Poll NTP servers ntp0.inf.ed.ac.uk, ntp1.inf.ed.ac.uk, ntp2.inf.ed.ac.uk
  4. User Authentication : Enabled Methods (in order) Local Users, Kerberos
    1. Local Users: sysadmin (only)
    2. Remote Users: Authenticate only users who are in the remote users list; all CO's DICE usernames added with full admin rights.
    3. Kerberos: Enable Kerberos; Realm INF.ED.AC.UK; KDC barrett.inf.ed.ac.uk; KDC IP Address 129.215.64.100
  5. Device Ports: Direct Connects: 10 (Maximum)

2. Connecting a new server to an existing Lantronix SLC

A new server should be connected to the next available free port of the appropriate SLC using a standard TP cable. It is necessary to use a special RJ45<->DB9F adaptor on the server to make this connection: such adaptors are currently available from the Appleton Tower Computer Support Office; they are wired to the specification of the Lantronix part number 200.2070A; and - in order to differentiate them from other similar adaptors in use within Informatics -, they are coloured green, and are also labelled 'SLC'.

By default, all incoming serial connections on the SLC are set to 9600,8,n,1 (this can be changed, but should normally be a good choice), so attaching the physical cable is all that's actually necessary to make a console available. But in order to make things slightly friendlier to use, there are a couple more set up steps:

Configure the SLC itself

ssh - using your normal DICE username and password - to the SLC to which the server has been connected, and issue the following three commands at the SLC's command line interface:

  set deviceport port <device port number> name <server name>
  set deviceport port <device port number or name> locallogging enable
  set deviceport port <device port number or name> sshin enable

(The device port number corresponds to the physical port numbering on the rear of the SLC.)

Example:

The serial console of the machine 'curlew' has been cabled to device port 1 of the SLC 'atbslc1':

  [exeter]idurkacz: ssh atbslc1
  Password: 
  Welcome to the SecureLinx Console Manager
  Model Number: SLC32
  For a list of commands, type 'help'.

  [atbslc1]> set deviceport port 1 name curlew
  [atbslc1]> set deviceport port curlew locallogging enable
  [atbslc1]> set deviceport port curlew sshin enable

Set appropriate LCFG resources

Add the following resources to the live/console_server.h header:

  !consoles.client                       mADD(<server name>)
  consoles.server_<server name>          <SLC name>
  consoles.directport_<server name>      <SLC device port number> + 3000

Example:

  !consoles.client                mADD(curlew)
  consoles.server_curlew          atbslc1
  consoles.directport_curlew      3001

3. Using the console of a server connected to the Lantronix SLC

Connecting to a console

In general there are two ways to access the console of a server being managed by the SLC:

  1. Directly via ssh:
      ssh <SLC name> -p <SLC device port number + 3000>
    
    In this case, the escape sequence is '~.' - the standard ssh escape.

    Example:

    The serial console of the machine 'curlew' has been cabled to device port 1 of the SLC 'atbslc1':

      [exeter]idurkacz: ssh atbslc1 -p 3001
      Password: 
    
      Fedora Core release 5 (Bordeaux)
      Kernel 2.6.18-1.2257_FC5_dice_1.2smp on an i686
    
      curlew.inf.ed.ac.uk login: 
      ...[snip]...
    

  2. Through the SLC's command line interface:

      ssh <SLC name>
      connect direct deviceport <server name>
    
    In this case, the escape sequence is ESC A.

    Example:

      [exeter]idurkacz: ssh atbslc1
      Password: 
    
      Welcome to the SecureLinx Console Manager
      Model Number: SLC32
      For a list of commands, type 'help'.
    
      [atbslc1]> connect direct deviceport curlew
      Connecting to Device Port curlew.
      Connected to port 1. Escape sequence is ESC A
    
      Fedora Core release 5 (Bordeaux)
      Kernel 2.6.18-1.2257_FC5_dice_1.2smp on an i686
    
      curlew.inf.ed.ac.uk login: 
      ...[snip]...
      Returning to command line
      [atbslc1]> logout
      Logging out...
    
      Connection to atbslc1 closed by remote host.
      Connection to atbslc1 closed.
      [exeter]idurkacz: 
    

Neither of the above methods are convenient, since both require the user to know the name of the relevant SLC, and the device port on that SLC to the which the target server has been connected. To make this easier, a 'console' wrapper script which uses the LCFG resources described in the previous section has been provided on all console server machines. To use it:

  1. ssh to any console server
  2. Type 'console <target machine>'

If the target machine is being served by an SLC device, this initiates the appropriate direct connection; otherwise - on the assumption that the target server is being managed by conserver - conserver's console command is invoked.

Example:

  [exeter]idurkacz: console curlew
  Connecting to Device Port curlew
  Escape sequence is ~~.
  Password: 

  Fedora Core release 5 (Bordeaux)
  Kernel 2.6.18-1.2257_FC5_dice_1.2smp on an i686

  curlew.inf.ed.ac.uk login: 
  ...[snip]...
  Connection to atbslc1 closed.

Sending a break

When attached to a remote console, the break sequence is ESC B.

Example:

To force a SysReq reboot in the same way as done for consoles managed via conserver:

  ESC B s
  ESC B u
  ESC B b

Displaying console log files

With local logging enabled, the SLC maintains a 256 kB log of I/O for each connected console. The contents of these log can be viewed via the SLC's command line interface.

  show locallog <device port number or name>

Example:

  [exeter]idurkacz: ssh atbslc1
  Password: 

  Welcome to the SecureLinx Console Manager
  Model Number: SLC32
  For a list of commands, type 'help'.

  [atbslc1]> show locallog curlew
  ...[snip]...

By default, the above command displays 1 kB of data starting from the beginning of the log. It is possible to display different parts of the log via the command:

  show locallog <device port number or name> bytes <bytes to display> startbtye <byte index>

Example:

  show locallog curlew bytes 1000 9000

Note that it is not possible to 'tail' a console log from the SLC's command line.

Again, neither of the above commands are convenient since they require the user to know the name of the SLC to which the server of intereset is connected. To help with this, the wrapper script mentioned in section 3 above can be used, if invoked with the '-l' switch, to connect to the appropriate SLC:

Example:

  [exeter]idurkacz: console -l curlew
  Connecting to console server atbslc1
  Password: 

  Welcome to the SecureLinx Console Manager
  Model Number: SLC32
  For a list of commands, type 'help'.

  [atbslc1]> show locallog curlew
    ...[snip]...

The log file can be cleared at the SLC command-line using the command:

  set locallog clear <device port number or name>

Example:

  [exeter]idurkacz: console -l curlew
  Connecting to console server atbslc1
  ...[snip]...
  [atbslc1]> set locallog clear curlew
  Local buffer for Device Port 1 cleared.

4. Other useful SLC commands

To get help at the SLC's command line:

  help

To show all connections currently active on the SLC:

  show connections

To terminate a particular connection:

  connect terminate <connection id>

To reboot/shutdown the SLC:

  admin reboot
  admin shutdown

5. Known issues and problems

Note: If you have used the SLC and have any comments, observations, or additions to make in this regard, please feel free to add them below.

Usability issues

  1. Access to console logs is cumbersome. It is not possible to 'tail' a console log being maintained locally by the SLC; the best that can be done is to seek to a starting byte number in a log, then display the following n bytes. Likewise, it's not possible to grep a console log. If this kind of log access is a requirement, then there seem to be two possible solutions, neither of which are very attractive:

    • Configure the SLC to log to external files via NFS, then access those log files directly. Not attractive, since it introduces a dependency on an external machine.
    • Configure the SLC to share its internally-held log files via CIFS, then arrange access to these shares.

    -- idurkacz, 20.8.2007

    Note: I have now (22.8.07) experimented with the latter, and it appears this facility is broken: it is possible to mount the SLC's CIFS share from a DICE box (using either /sbin/mount.cifs or smbclient), but the 'log files' being shared in this way turn out to be symlinks to underlying log files which are not themselves accessible. Presumably, this is another SLC firmware bug - perhaps an inappropriate Samba configuration option? Note also this this behaviour has not been fixed by the firmware update to rev 5.2a mentioned below. I have bugged this to Lantronix.

    -- idurkacz, 22.8.2007

    In this context, it's worth pointing out that it is possible to access complete console logs via the web interface presented by the SLC. (Point your browser to https://atbslc1; login; select the appropriate device port from the numbered bar at the top of the page; select 'Logging: Settings'; select 'View Local Log'; when finished, logout of the web session.) I wouldn't like to recommend use of the SLC's web interface as a general working practice - but perhaps it is the best option for usable access to the logs?

    -- idurkacz, 27.9.2007

    Further: introduced by firmware rev 5.2a is the ability to direct console logs to the SLC's internal system log output, which itself can then be directed to external syslog servers (either one, or two). I haven't tried this yet, but it offers a potential solution to the above console log problems.

    -- idurkacz, 12.10.2007

  2. The break sequence 'ESC B' can't be redefined for the SLC's 'remote' users; only for its 'local' users. Since all our users are in the former category, we cannot redefine the break sequence.

    -- idurkacz, 20.8.2007

  3. It is not possible to issue the command 'ssh <SLC name> <command>' against an SLC. This means it's not possible to automate the commands necessary to display console logs, for example.

    -- idurkacz, 20.8.2007

Problems

  1. The SLC does not reliably reboot after either a remote CLI 'admin reboot' command, or after a power cycle: it can hang either at stage where 'Lantronix SLC Boot 1.1.5.L4' is displayed on the front panel LCD display, or just after the same point (with nothing then being displayed on the LCD.) This is a serious problem: the manufacturer claims it's a known issue scheduled to be a cleared by a firmware update due at the end of August 2007. We'll see.

    -- idurkacz, 20.8.2007

    Note: I have now (on 20.9.07) updated the firmware to rev 5.2a, which was the promised update, and this seems to have cured the problem (or, at least, I've been unable to reproduce it): five successive CLI reboots, five successive CLI shutdowns, and five successive power off/power on cycles all worked as expected and the SLC correctly came back up. (Note that the SLC didn't come back on-line cleanly after the recent AT power loss though: it had to be power-cycled after the power came back in order to get it back on-line. And this event happened after the above-mentioned firmware update had been applied.)

    -- idurkacz, 12.10.2007

  2. The web interface appears to get confused - and can become completely unresponsive - when, for example, username configuration changes are tried. This would not be too serious a problem were it not for the above! The workaround, presumably, is not to use the web interface and instead do all configuration via ssh.

    -- idurkacz, 20.8.2007

  3. Attached consoles can present garbled output after the SLC has been rebooted - I don't know why. The effect seems to stabilise in time, however.

    -- idurkacz, 20.8.2007

6. Further information

  1. SecureLinx Console Manager User Guide

-- IanDurkacz - 20 Aug 2007

Edit | Attach | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r10 - 12 Oct 2007 - 14:22:16 - IanDurkacz
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies