AlterPath OnBoard Release Notes


These release notes describe outstanding issues and known bugs and provide useful information about the AlterPath OnBoard product. The firmware Upgrade Notes are described in a separate document that can be found on the Cyclades downloads page at: http://www.cyclades.com/support/downloads.php

V_1.1.0 April/2006

a) New features

b) Bug fixes

c) Known Bugs

d) Notes

e) Troubleshooting

V_1.0.0 January/2006

a) New features

·         All new

b) Bug fixes

·         None

c) Known Bugs

·         IPSec needs to be restarted after the public interface IP is changed.
Bug ID#: 5499
If the IP address on any of the public Ethernet interfaces is changed, the Local IP/netmask specified in the IPSec configuration does not reflect the change.
Workaround: The administrator should check the Local IP/netmask in the IPSec configuration, and update the values if necessary. The administrator should then restart the IPSec daemon manually.

·         Native IP tunnels should be explicitly closed before taking down an IPSec tunnel.
Bug ID#: 5633
Failing to close active Native IP connections before taking down an IPSec tunnel may lead to subsequent IPSec users being granted access to Native IP facilities without authentication or authorization.
Workaround:  Before taking down an IPSec tunnel to the OnBoard, the user must disable any Native IP connections that are active through that tunnel.

·         Snmptrapd authenticates traps instead of just forwarding them.
Bug ID#: 6411
To address issues with trap forwarding, OnBoard's version of net-snmp was upgraded to v5.3.0.1, which fixes the problems and also introduces a new security model for authenticating and authorizing the forwarding of snmp traps. The later changes primarily affect v3 traps, requiring the following additional line in snmptrapd.conf to enable backwards compatibility:
disableAuthorization yes
If the administrator wishes to use the new authorization features, they will need to edit snmptrapd.conf manually. A future firmware release will include enhanced support for this new functionality.
Forwarding of version 3 traps also requires the manual addition of createUser lines for traps to be forwarded. This is due to the fact that snmptrapd includes separate functionality to decode and authenticate incoming traps and re-encode outgoing traps. A createUser line takes the standard format; see http://net-snmp.sourceforge.net/tutorial/tutorial-5/ for further details.
Workaround:  Add the disableAuthorization line to /etc/snmp/snmptrapd.conf, along with createUser lines for the authentication details of each v3 trap that OnBoard will need to forward.

d) Change Log

·         None

e) Notes

·         Useful information and application notes can be found in the OnBoard under the directory /usr/share/docs/OnBoard/Application_Notes. Check our website or with our Sales Engineering or Tech Support for additional application notes that may be added after the product is released.

DISCLAIMER: The OnBoard Application Notes have not been checked/tested by our Quality Assurance and Technical Writer teams. The notes were put together by Cyclades R&D SW engineers as an additional help to our customers and sales engineers. All reasonable efforts have been taken with the documentation/testing of their functionality, but no obligations/responsibilities are offered. Cyclades supports these application notes on a best effort basis.

Following are summaries of the existing application notes.

o        Networking-related Application Notes

·         NativeIP: Native IP access allows for full (or direct) IP access to the Ethernet port of a device connected to the private Ethernet ports of the OnBoard. Users are authenticated and authorized as per the OnBoard configuration, and the default firewall rules are relaxed so that the OnBoard acts as a router forwarding packets between the user VPN (PPTP or IPSec) end-point and the device (and vice-versa). This application note describes Native IP applications and associated configuration and includes screen shots of the OnBoard WMI PPTP configuration, screen shots of Windows XP PPTP configuration, and a matrix of results of tests with HP iLO (and HP Insight Manager) and IBM RSA-II (and IBM Director). An alternative method of Native IP access is through SSH port forwarding (as described in the ssh_tunnel application note).

·         VirtualIP: Devices connected to the OnBoard private Ethernet ports can be grouped in subnets. This may suit functional or organizational purposes, and it also allows for connecting devices without having to change existing or default static IP addresses. Virtual IP addressing may be used with or without the DHCP server that comes with the OnBoard. This application note describes how subnets can be configured on the OnBoard and includes screen shots of their configuration through the Web Manager.

·         priv-to-pub: The OnBoard packet filtering rules, by default, do not forward packets from devices on the private Ethernet switch to the public networks. When devices on the private side need to contact servers on public side, for example, to send email via an email server on the public side, the administrator can add new filter rules to the FORWARD chain to allow certain traffic to flow between the networks and to stop NAT. This application note describes how to configure these changes.

·         ssh_tunnel: SSH port forwarding is one alternative way of getting Native IP access to devices managed through the OnBoard (see more details on Native IP in the NativeIP Application Note). SSH port forwarding in the OnBoard is disabled by default for security reasons, since it allows bypassing authorization rules and permits access to devices on the private network based only on authentication. If this security issue is not a problem in your environment and you are interested in enabling and using SSH tunneling, this application note has information on how it can be achieved. It includes screen shots of configuration and use of SSH tunneling using a popular SSH clients, including putty.

·         tftp: The system administrator may want to upgrade firmware on devices connected on the private side of OnBoard. This application note describes how the OnBoard’s built-in tftp server can be enabled and configured to support firmware upgrade.

·         new_device_IP_setup: When a new server is installed on the private side of OnBoard, you must setup an IP address for the BMC or Service Processor. This application notes provides some hints on how to configure the device’s IP address and how to enable DHCP service on OnBoard.

·         Nagios: Nagios is a powerful host, service and network monitoring program. Actual host and service checks are performed by separate plugins which return the host or service status to Nagios. With the introduction of baseboard management controller (BMC) or Service Processors (SP), Nagios is able to obtain information such as power status, fan speeds, temperatures and voltages. Unfortunately, each vendor has its own interface and commands which make it difficult to create Nagios plugins to check the information. This problem can be solved with using OnBoard which provides a single source for authentication, authorization, and management for multiple types of SPs.

o        Service_Processor-related Application Notes:

·         Alternate_Access: notes on using alternate means of communication with Service Processors

·         APC: notes on how to manage the APC RackPDU family of Inteligent Power Distribution Units

·         Cisco: notes on managing devices running Cisco's IOS

·         Devconsoles: notes on managing devices without service processors

·         Device_Clusters: notes on managing devices which in turn control other devices, such as Blade Servers and Intelligent Power Distribution Units

·         Grouping_Devices: notes and sample shell script provided to execute OnBoard commands on a group of devices

·         IBM: notes on the IBM RSA I and RSA II service processors

·         IPMI_2.0: notes on taking advantage of IPMIv2.0 service processors

·         Native_IP: notes on managing devices that require vendor supplied tools

·         Sun: notes on the Sun ALOM and ILOM service processors

·         Details on some tested Native IP applications can be found in the PDF file /usr/share/docs/OnBoard/Application_Notes/Network/NativeIP.pdf. These include HP Systems Insight Manager, IBM Director, and some web applications.

·         Besides PPTP and IPSec, another option for setting up tunneling for accessing Native IP applications is through the use of SSH tunneling (or SSH port forward). This is described in the application note ssh_tunnel.

·         Browser controls must not be used:
BugID#: 6390
The standard browser buttons Back, Forward, and Refresh should NEVER be used while logged in to the WMI. Instead, use the controls provided by the WMI. For example, after adding a user, the admin should not press Back to return to the previous screen. Instead, the admin should click the OK or Cancel buttons provided within the WMI.
Using the browser's Back, Forward, or Refresh buttons will cause unstable behaviour, and could even cause a transaction to occur twice.

·         Data buffering of Device Console:
BugID#: 6190
Due to storage restrictions, the console output from the managed devices is sent to syslog, but not otherwise stored on the OnBoard.  If additional space is added by remote NFS mounts, or PCMCIA flash or hard drive storage (unsupported), logs may be switched back on through cycli.  By default, all managed devices use the global setting, which may be changed by:

set onboard global default databuf [yes|no]

Each individual device may override the global setting:

set onboard server rsa_au databuf [yes|no|default]


·         Network Information Service (NIS) Authentication Issues
==========================================

1. Why are "NIS/local" and "local/NIS" the only authentication options offered by the Onboard?
Why does not Onboard offer the "NIS" and "NISdownlocal" options?

The OnBoard cannot function properly if NIS is used, because the OnBoard requires  system accounts such as "root", "rpc" and "sshd," and the UIDs for system accounts are not in the range allowed on most NIS servers.

Most NIS servers by default only include users with UIDs greater than 500 in the NIS maps, and none of the system users would be included in the maps.


2. Why is the device authentication type limited to "Local or NIS", even though "NIS/local" and "local/NIS" options are listed under "unit authentication"?

NIS and local (etc/passwd and /etc/shadow) authentication are both affected by the settings in the /etc/nsswitch.conf file.

If the "NIS/local" or "local/NIS" option is selected for unit authentication, then the nsswitch.conf file is changed. As a result, all devices with their authentication type set to "Local or NIS" automatically use the same NIS authentication type as the unit.


3. Which password applies when authentication is set to NIS/local or local/NIS, and the Onboard local database (/etc/shadow) and NIS server both contain the same username with different passwords?

Which password applies depends on whether or not an /etc/shadow map is available on the NIS server.

Onboard uses shadow passwords (/etc/shadow) for extra security. If the NIS server does not distribute an /etc/shadow map, then the local password is required  even if the authentication type is NIS/local or local/NIS.

Following are the details:

The OnBoard and the Pluggable Authentication Module (PAM) Onboard uses (called pam_unix2.so)looks for passwords in /etc/shadow instead of in/etc/passwd. So, even if the authentication type is NIS/local or local/NIS, if pam_unix2 finds the same user name in the NIS /etc/passwd map and the local /etc/shadow, pam_unix2 will require a match to the local /etc/shadow password, even if the authentication type is NIS/local.

If the NIS server is set up to distribute a /etc/shadow map, the authentication type NIS/local works as expected, and the password from the NIS server is accepted.


4. How does the OnBoard administrator assign normal users the required /usr/bin/rmenush as their default shells when NIS authentication is used?

Onboard "normal" users must be configured with the restricted shell called /usr/bin/rmenush. (Normal users with unrestricted (/bin/bash or /bin/sh) shell access would be able to bypass Onboard security.) The Onboard administrator needs to specifically configure the normal users' shell on the NIS server.

For the following reasons, if NIS is used, we recommend that the administrator set the shell for normal users as /usr/bin/rmenush in the NIS passwd map. NIS behaves just as if the user has been authenticated locally and provides all information that would normally be contained in the local /etc/passwd file.

That information includes the shell the user is to be given. If the NIS passwd map says the user's shell is supposed to be "/bin/bash", Onboard would give the user /bin/bash. It is possible for Onboard to override that information coming from the NIS server. That is achieved by creating the user on the local /etc/passwd and /etc/shadow files and adding special NIS (+/-) formatting in /etc/passwd, as shown in the following example:

+nis_user::::::/usr/bin/rmenush

+::::::

and setting the following in /etc/nsswitch.conf (making sure /lib/libnss_compat.so library file is present - it is currently not included in the Onboard firmware):

passwd: compat

The above is not an ideal solution as it defeats the purpose of using NIS if the user has to be added locally on Onboard. Therefore, if NIS is used, we recommend that the administrator set the shell for normal users in the NIS passwd map as /usr/bin/rmenush


5. Why does the Onboard Web Manager not allow me to log-in using my NIS credentials?

The authentication type may have been changed to NIS without the Web Manager being informed. The OnBoard administrator can notify the Web Manager of the change by either rebooting the Onboard, or by calling

$ killall cacpd

on the Onboard shell command line.

 

·         Additional useful information can be found at http://www.cyclades.com, under the Products, Resources and Support/Services menu options.

f) Troubleshooting:

·         The following service processors’ hardware/firmware versions have been tested on this release:

·         HP iLO firmware 1.70 and 1.82—With the iLO firmware 1.82, telnet connections do not close upon exit. The OnBoard SW works around this problem for most commands except for the command “spconsole,” in which case, the user must close the connection manually using the telnet escape sequence ^] . We have been in contact with HP, and we expect this problem to be fixed in an upcoming release of the iLO firmware.

·         HP RILOe—Not tested but could possibly be supported with a customized expect script and command template. Native IP access should be supported (see useful information under the directory: /usr/share/docs/OnBoard/Application_Notes/
Service_Processor_Related/Native_IP ).

·         IPMI 1.5 based firmware—Tested and supported

·         IPMI 2.0 based firmware—Possibly supported with a customer-created customized Expect script. Another option would be to configure the device as IPMI 1.5.

·         IBM RSA-II and RSA-I—The latter is not supported, unless with a customer-created customized Expect script and command template. See useful information under the directory: /usr/share/docs/OnBoard/Application_Notes/Service_Processor_Related/IBM.

·         Dell DRAC III/XT—Tested with firmware 3.20 and device type DRAC.

·         Dell DRAC IV—Not tested but could possibly be supported with IPMI 1.5 as device type and IPMI as communication protocol. IPMI 2.0 and a custom expect script may also be possible though this hasn't been tested.

·         Dell DRAC II, DRAC I and Dell ERA—Not supported unless possibly in Native IP and SNMP mode.

·         Dell DRAC III (non XT) hasn't been tested but it apparently can be managed through telnet and would thus behave in a similar way as the DRAC III XT.

·         Various other devices that can be managed over TCP/IP and Ethernet including servers, routers, firewalls, and so forth.

·         Sorting the Device List:
BugID#: 6204
The Web Manager displays devices only in the order in which they are added.  Alphabetical sorting is not available.
Workaround: An OnBoard administrator may configure the OnBoard to display device lists in alphabetical order using the cycli utility, as follows:

[root@OnBoard /] # cycli
cli> set onboard global sort server alpha
cli> commit
cli> quit

Acceptable values are "alpha" (sort into alphabetic order by device name) or "none" (unsorted; typically displayed in order of creation). The default value is "none". This parameter is used to determine the display order for all screens where a device list is shown, for all users.

·         Behaviour for power control and reset type commands:

Different service processors define power control and reset commands differently. A sample of the existing behaviors for some types is listed below:

- Hard power off - just remove the power

- Soft power off - ask the OS to shut down

- Hard power cycle - remove the power, wait several seconds and then reapply

- Soft power cycle - ask the OS to shut down, wait several seconds the reapply power

- Hard reset - trigger a hardware reset

- Soft reset - ask the OS to reboot

- Warm reset (or warm boot): only the Operating System in the server gets re-started

- Cold boot: the server gets fully re-started (same as power cycling)

In each case, OnBoard uses the hard options when executing the power control or reset commands.

g) Cyclades AlterPath PM-related:

·         IPDUs may be slow to respond

o        Sometimes IPDUs may be slow to respond after an IPDU firmware upgrade. Typically the user notices that the Web Manager screen that displays information about IPDUs is slow to display the desired information about an upgraded IPDU.  For example, two IPDUs are daisy-chained, and the firmware on the slave unit is upgraded via the Web Manager (Access->IPDU->Software Upgrade). After the upgrade completes, the Web Manager screen is refreshed, and the user expects to see both the master and slave unit. However, only the master unit is shown. The slave unit is not yet in a ready state. Most likely its outlets are still turning on one-by-one. During this time, the unit's status cannot be queried. The workaround is to wait until the IPDU unit is fully powered up and in a ready state. This will be about 1 second after all the outlets have finished powering up. After this point, Web Manager access to the IPDU should proceed as normal.

·         IPDU (PM) firmware version 1.7.0 does not display outlet names:

o        The Web Manager does not list outlet names when the PM is running firmware version 1.7.0; the bug is a result of the fact that the underlying 'pmCommand 1 status all' does not list the outlet names. The bug is resolved in 1.7.1, and older versions (such as 1.6 and 1.5) do not have the bug. Customers with PM firmware 1.7.0 should upgrade to 1.7.1; those with firmware older than 1.7.0 can stay with the older version if they wish.