Intel Multi Server Manager (IMSM) · already managed using Nagios-NRPE, IMSM can impose its features on the existing Nagios* plugin and provide the user with more information about

Intel® Multi Server Manager (IMSM)

User Guide Rev 3.00

Nov 2017

ii Intel® Multi Server Manager User Guide

Legal Statements

No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this

document.Intel disclaims all express and implied warranties, including without limitation, the implied warranties of

merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course

of performance, course of dealing, or usage in trade.

The products described in this document may contain design defects or errors known as errata which may cause the

product to deviate from published specifications. Current characterized errata are available on request.

All information provided here is subject to change without notice. Contact your Intel representative to obtain the

latest Intel product specifications and roadmaps.

Copies of documents which have an order number and are referenced in this document, or other Intel literature, may

be obtained by calling 1-800-548-4725, or go to: http://www.intel.com/design/literature.

Intel is a trademark of Intel Corporation in the U.S. and/or other countries.

*Other names and brands may be claimed as the property of others

Copyright © 2017 Intel Corporation. All rights reserved. Intel Corporation, 2200 Mission College Blvd., Santa Clara,

CA 95052-8119, USA.

http://www.intel.com/design/literature

Intel® Multi Server Manager Guide iii

Contents

1 Introduction ................................................................................ 6

1.1 Document Scope ........................................................................................ 6

1.2 System Requirements ................................................................................ 6

1.3 Supported Language .................................................................................. 7

1.4 Target Audience ......................................................................................... 7

1.5 Terminology .............................................................................................. 7

1.6 Features and Benefits ................................................................................. 8

1.6.1 Discovery ..................................................................................... 8

1.6.2 Provision .................................................................................... 10

1.6.3 Inquire System Information .......................................................... 10

1.6.4 Monitor Systems ......................................................................... 11

1.6.5 Get Performance Data .................................................................. 11

1.6.6 Configure BMC and RAID .............................................................. 11

1.6.7 Chassis Identification and Power Action .......................................... 11

1.6.8 Update System Firmware ............................................................. 11

1.6.9 Get BMC Debug Log ..................................................................... 12

1.6.10 Compare Hardware Configurations ................................................. 12

1.7 Related Documents .................................................................................. 12

1.8 Intel® Support ......................................................................................... 12

2 Get Started ................................................................................ 13

2.1 Prerequisites for Installation ...................................................................... 13

2.1.1 Prerequisites for In-Band .............................................................. 13

2.1.2 Prerequisites for Out-of-Band ........................................................ 14

2.1.3 Required Add-on Packages ........................................................... 16

2.2 Installation Steps ..................................................................................... 17

2.3 Update Steps ........................................................................................... 17

2.4 Uninstallation Steps ................................................................................. 18

2.5 Understanding IMSM Structure .................................................................. 18

2.6 Configuration Flow ................................................................................... 21

3 Configurations ........................................................................... 22

3.1 General Configuration File ......................................................................... 22

3.2 Script-Specific Configuration Files .............................................................. 27

3.2.1 ism_sensorconfig.xml .................................................................. 27

3.2.2 ism_bmcconfig.xml ...................................................................... 28

3.3 Database File .......................................................................................... 36

3.4 Network Shared Drive .............................................................................. 37

4 Feature Scripts .......................................................................... 39

4.1 General Rules .......................................................................................... 39

4.2 Usage Flow ............................................................................................. 40

4.3 Prerequisite Check ................................................................................... 41

4.4 Add New Hostgroup.................................................................................. 41

iv Intel® Multi Server Manager User Guide

4.5 Delete a Host .......................................................................................... 42

4.6 Move a Host ............................................................................................ 43

4.7 Delete a Hostgroup .................................................................................. 44

4.8 List Host and Hostgroup ............................................................................ 44

4.9 Discovery ................................................................................................ 45

4.10 Provision ................................................................................................. 47

4.11 System Information Inquiry ...................................................................... 49

4.12 Monitor System Health ............................................................................. 53

4.13 Performance Data Inquiry ......................................................................... 57

4.14 BMC Configuration ................................................................................... 59

4.15 RAID Configuration .................................................................................. 61

4.16 Chassis Identification ............................................................................... 64

4.17 Power Setting Action ................................................................................ 66

4.18 System Firmware Update .......................................................................... 68

4.19 System Firmware Update (OOB) ................................................................ 71

4.20 Cleanup .................................................................................................. 73

4.21 Get BMC Debug Log ................................................................................. 75

4.22 Compare Hardware Configurations ............................................................. 76

4.23 Custom Deploy ........................................................................................ 77

5 Troubleshooting Tips ................................................................. 80

5.1 IMSM Installation ..................................................................................... 80

5.2 Discovery ................................................................................................ 80

5.3 System Information Inquiry ...................................................................... 81

5.4 Monitor System Health ............................................................................. 83

5.5 Performance Data Inquiry ......................................................................... 83

5.6 System Firmware Update .......................................................................... 83

5.7 System Firmware Update OOB ................................................................... 84

5.8 Custom Deploy ........................................................................................ 85

5.9 Nagios Configuration ................................................................................ 85

Intel® Multi Server Manager User Guide 5

Tables

Table 1. Operating Systems and Intel® Server Boards Supported ........................................................ 6

Table 2. Terminology .................................................................................................................................. 7

Table 3. In-Band System Configuration Requirements ......................................................................... 13

Table 4. Out-Of-Band System Configuration Requirements ................................................................ 14

Table 5: Required Add-on RPM Packages ................................................................................................. 16

Table 6. Directory Structure of IMSM ...................................................................................................... 19

Table 7. Directory Structure of ism_scripts ........................................................................................... 19

Table 8. Categories of IMSM files ............................................................................................................ 20

Table 9. Categories of IMSM configuration files .................................................................................... 22

Table 10. Configuration Parameters of “ism_config.xml” .................................................................... 23

Table 11. Configuration Parameters of “ism_sensorconfig.xml” ........................................................ 27

Table 12. Configuration Parameters of “ism_bmcconfig.xml”............................................................. 28

Figures

Figure 1: IMSM Management Server and Managed Servers in CLI Mode. ............................................ 9

Figure 2: IMSM Management Server and Managed Servers using Nagios* and NRPE. ...................... 9

Figure 3: IMSM provision feature. ........................................................................................................... 10

Figure 4: Query managed server’s information using IMSM. ............................................................... 10

Figure 5: Update and configure managed servers using IMSM. .......................................................... 11

Figure 6. IMSM Configuration Flowchart. ............................................................................................... 21

Figure 7. The flowchart of IMSM Feature Script usage. ........................................................................ 40

6 Intel® Multi Server Manager User Guide

1 Introduction

The Intel® Multi Server Manager (IMSM) is a multi-server management tool to manage in-

band and out-of-band Intel® Server Boards and Systems in a datacenter with a simple and

easy-to-use interface. IMSM currently offers two types of management interface: (i)

Command Line (CLI) and (ii) as a Nagios* plugin to use as-is. It is an innovative tool-of-tools

which attaches with various server management utilites developed by Intel. Also, IMSM is

easy-to-use, low in maintenance, and it provides seamless integration with your Intel® Server

Boards and Systems in a datacenter. IMSM is designed to work with the following Intel® Server

Boards families:

Intel® Server Board and System S2600WT/S2600WTR family

Intel® Server Board S2600KP/S2600KPR family

Intel® Server Board S2600TP/S2600TPR family

Intel® Server Board S2600CW/S2600CWR family

Intel® Server Board S1200SP family

Intel® Server Board S7200AP family

Intel® Server Board S2600WFT family

Intel® Server Board S2600BP family

Intel® Server Board S2600STB family

1.1 Document Scope The purpose of this document is to help system/server administrators to install and use the

Intel® Multi Server Manager (IMSM). It provides you detailed information on the features and

benefits of IMSM and how to use them. It describes the system and software requirements,

supported operating systems and platforms. This document also explains the installation and

uninstallation process.

1.2 System Requirements

Table 1. Operating Systems and Intel® Server Boards Supported

Intel® Server Boards Operating Systems Version (64-bit only)

Intel® Server Board S2600WT/S2600WTR

family

Intel® Server Board S2600KP/S2600KPR family

Intel® Server Board S2600TP/S2600TPR family

1. Red Hat Enterprise Linux* 6.8 and 7.3

2. SuSE Linux Enterprise Server* 11.4 and 12.2

3. CentOS 7.3


Intel® Server Boards Operating Systems Version (64-bit only)

Intel® Server Board S2600CW/S2600CWR

family

Intel® Server Board S1200SP family

Intel® Server Board S7200AP family

Intel® Server Board S2600WFT family

Intel® Server Board S2600BP family

Intel® Server Board S2600STB family

Note: Refer to the release notes for known issues on installation and usage.

1.3 Supported Language User Guide is available in English only.

1.4 Target Audience

This User Guide is intended for administrators and users who will use IMSM for the

management of multiple Intel® Server Boards and Systems in a datacenter.

1.5 Terminology

Table 2. Terminology

Term Definition

BMC Baseboard Management Controller

CLI Command-Line Interface

DHCP Dynamic Host Configuration Protocol

FRU Field Replaceable Unit

IN-BAND In-band managed server refers to any system which could be SSH from

management server via normal configured network interface connection.

IPMI Intelligent Platform Management Interface. Operates independently of the

operating system (OS) and allows you to manage a system remotely, even in

the absence of the OS.

LAN Local Area Network


Management

Server

Intel® Server System where IMSM is installed. It will be acting as host server

which has network connectivity to the rest of the managed servers.

Managed Server Intel® Server System in a cluster or data center that will be managed by

Management Server.

NRPE Nagios* Remote Plugin Executor

OUT-OF-BAND Out-of-band managed server refers to any system which is configured with

valid IPMI lan channel and logon account to allow remote management via

IPMI protocol.

SDR Sensor Data Record

SEL System Event Log

SNMP Simple Network Management Protocol

SNMP-SA Intel® SNMP Subagent

SOL Serial-over-LAN

SSH Secure Shell network protocol to allow remote login in a client-server network

1.6 Features and Benefits

IMSM is designed to simplify the process of managing multiple Intel® Server Systems in a

cluster or datacenter. The following are the main features of IMSM.

Discover Intel® Server Systems

Provision Intel® Server Systems

Inquire system information

Monitor systems

Get performance data

Configure BMC and RAID

Chassis Identification and Power Action

Update system firmware

Get BMC debug log

Compare hardware configurations

Current release support both command line interface (CLI) mode and thirdparty mode utilizing

Nagios* Core 4.x with or without NPRE.

1.6.1 Discovery

Use the IMSM discovery feature to detect all Intel® Server Systems and Boards in your

datacenter with ease. Discovery feature offers the option for user to add a discovered server

into the IMSM database as a “Managed Server”. Only an IMSM managed server can use other


IMSM management features and IMSM’s Nagios* plugins.

Relevant Feature Script: (section 4.9) ism_discover.pyc

Figure 1: IMSM Management Server and Managed Servers in CLI Mode.

Figure 2: IMSM Management Server and Managed Servers using Nagios* and

NRPE.

Management Server

Managed Server 1 In-Band (using SSH connection)

Managed Server 2 In-Band (using SSH connection)

Managed Server 3 Out-of-Band (using BMC credentials)

In-Band or Out-of-Band LAN connections

Managed Server 4 Out-of-Band (using BMC credentials) Command Line Interface

Management Server Installed with Nagios*

and NRPE

Managed Server 1 Installed with NRPE

Managed Server 2 Installed with NRPE

Managed Server 3 OOB, without NRPE

Managed Server 4 OOB, without NRPE

In-band or Out-of-Band LAN connection

Nagios*-NRPE Interface


1.6.2 Provision

Use the IMSM Provision feature to send an IMSM-client package from Management Server to

Managed Servers for installation and configuration. The provision feature may incorporate the

IMSM-client into NRPE based on user’s choice if user has already been using Nagios-NRPE in

datacenter.

Relevant Feature Script: (section 4.10) ism_provisioning.pyc

Figure 3: IMSM provision feature.

1.6.3 Inquire System Information

IMSM offers the ability to query system information of managed servers. If the datacenter is

already managed using Nagios-NRPE, IMSM can impose its features on the existing Nagios*

plugin and provide the user with more information about Intel® Server Systems.

Relevant Feature Script: (section 4.11) ism_sysinformation.pyc

Figure 4: Query managed server’s information using IMSM.

Management Server Installed with IMSM

Managed Server 1 Install IMSM-client package locally

Package copied to Managed Server

Management Server Installed with IMSM

Managed Server Installed with IMSM-client package

In-Band or Out-of-Band Connections

System Information,

System Health,

Performance Data

IMSM-client

package


1.6.4 Monitor Systems

IMSM is capable of monitoring the status of BMC and RAID for Managed Servers, and further

analyse this status information, including the system event logs and RAID error logs.

Relevant Feature Script: (section 4.12) ism_monitoring.pyc

1.6.5 Get Performance Data

Use IMSM to collect power supply data and temperature sensor data of Managed Servers.

User may customize the sensor data to be collected through a common configuration file.

Relevant Feature Script: (section 4.13) ism_getperformance.pyc

1.6.6 Configure BMC and RAID

Use IMSM to configure BMC settings of a cluster of in-band and/or out-of-band managed

servers; and/or configure RAID settings of in-band managed servers, using a common

configuration file.

Relevant Feature Script: (section 4.14) ism_bmcconfig.pyc, (section 4.15) ism_raid.pyc

1.6.7 Chassis Identification and Power Action

Use IMSM to control chassis identification LED and/or power action of a cluster of out-of-band

managed servers.

Relevant Feature Script: (section 4.16) ism_identify.pyc , (section 4.17) ism_power.pyc

1.6.8 Update System Firmware

Use IMSM to update system firmware of all managed servers from Linux* OS environment.

The firmware which can be updated using IMSM are BIOS, BMC, ME and SDR.

Relevant Feature Script: (section 4.18) ism_updsysfw.pyc

Figure 5: Update and configure managed servers using IMSM.

Management Server Installed with IMSM Managed Server 1

Installed with ISMT-client package

In-Band Connection

Out-of-Band Connection

Firmware Update, RAID Config.

Managed Server 2

Firmware Update,

BMC Config. Chassis ID LED, Power Action


1.6.9 Get BMC Debug Log

Generates an encrypted debug log zip file that contains BMC debug information which is useful

to the system manufacturer for problem resolution.

Relevant Feature Script: (section 4.21) ism_bmcdebuglog.pyc

1.6.10 Compare Hardware Configurations

Compares hardware configurations of managed servers with that of a GOLD server’s.

Relevant Feature Script: (section 4.22) ism_checksysconsistency.pyc

1.7 Related Documents

Following are the related documents for reference:

IPMI-Intelligent Platform Management Interface Specification, 2nd Generation, v2.0

(available here)

1.8 Intel® Support

Visit http://www.intel.com/p/en_US/support/ to get the latest and most complete technical

support information.

For an updated support contact list, see http://www.intel.com/support/9089.htm/.

http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html

http://www.intel.com/p/en_US/support/

http://www.intel.com/support/9089.htm/


2 Get Started

2.1 Prerequisites for Installation

This section explains the prerequisite settings that have to be installed and configured at the

Management Server and Managed Servers prior to IMSM installation. Refer to Section 2.1.1

if you are using In-Band Managed Servers, and refer to Section 2.1.2 if you are using Out-of-

Band Managed Servers. Section 2.1.3 provides the details of required add-on packages that

should be installed on these Linux* systems before start using IMSM.

2.1.1 Prerequisites for In-Band

The table below lists the required tools and configurations for In-Band Management Servers

and In-Band Managed Servers respectively.

Table 3. In-Band System Configuration Requirements

Management Server Managed Server

Linux* OS with full

32-bits compatible

libraries.

√(1) √(1)

Additional Python*

modules installation

i.e. Pynag, Paramiko,

ECDSA and

subprocess32.

√(2)

Requires python-devel for

compilation from module

source.

Ipmitool √ √

OpenIPMI driver √(3) √(3)

Sudoers file

configurations

(/etc/sudoers)

1) For SuSe Linux* systems, add the line below to

allow secure command execution.

Defaults secure_path="/usr/sbin:/usr/bin:/sbin:/bin"

2) For SuSe Linux* systems, uncomment the

following lines.

#Defaults targetpw # ask for the password of the

target user i.e. root

#ALL ALL=(ALL) ALL # WARNING! Only use this

together with 'Defaults targetpw'!

3) The username for Managed Servers is not limited to

‘root’ user but include other trusted users who are

already in sudoer list with administrative access

privileges. For example:


(1) If you choose to run the IMSM Utilities from a network shared path, you need to make sure the network shared server is

equipped with the required add-on packages to ensure successful execution of IMSM scripts locally or through an SSH

connection from the Management Server.

(2) For Paramiko module installation, install ECDSA module first, and finally the Paramiko module itself. Pynag module

installation can be omitted if you do not intend to use the Nagios plugins from IMSM.

(3) IMSM scripts will start the driver service if it is not yet started.

(4) Skip this step if your Managed Server is not managed by Nagios*. IMSM Provisioning script will perform update on this

nrpe.cfg to load new IMSM plugins.

(5) Skip this if you do not intend to use the Nagiosgraph. Please refer to Nagiosgraph website for the installation package and

instructions i.e. http://sourceforge.net/projects/nagiosgraph/files/nagiosgraph/.

2.1.2 Prerequisites for Out-of-Band

The table below lists the required tools and configurations for Out-of-Band Management

Servers and Out-of-Band Managed Servers respectively.

Table 4. Out-Of-Band System Configuration Requirements

Management Server Managed Server

Linux* OS with full

32-bits compatible

libraries.

√(1)

Additional Python*

modules installation

i.e. Pynag, Paramiko,

ECDSA and

√(2)

Requires python-devel for compilation from

module source.

user1 ALL=(ALL) ALL: ALL

4) If your Managed Server is managed by Nagios®,

please add the following bolded lines on your Managed

Server to allow IMSM Nagios plugins execution

permission.

# Disable "ssh hostname sudo <cmd>", because it will

show the password in clear.

# You have to run "ssh -t hostname sudo <cmd>".

#

Defaults requiretty

Defaults:nagios !requiretty

……

……

……

## Same thing without a password

# %wheel ALL=(ALL) NOPASSWD: ALL

nagios ALL=(ALL) NOPASSWD: ALL

Nagios* Nagios* plugins

installation and

check_nrpe ready

Nagios* plugins installation and nrpe.cfg file ready √(4)

Nagiosgraph Add-On

installation

Nagiosgraph Add-On

installation √(5)

http://sourceforge.net/projects/nagiosgraph/files/nagiosgraph/


subprocess32.

Ipmitool √

OpenIPMI driver √(3)

Out-Of-Band

Configurations

If you want to enable Nagios* for IMSM plugins,

update the managed host definition file with the

Managed Server IPMI LAN addresses.

Example:

define host {

use linux-server

alias 128.101.1.30

host_name nagios-mn03

address <IPMI LAN Address>

}

The systems must be pre-configured

with IMSM LAN address to allow

execution of IMSM Discovery and

Provisioning scripts.

Sudoers file

configurations

(/etc/sudoers)

1) If your Management Server runs Nagios®

and requiretty is a default, please add the

following bolded lines on your Management

Server to allow ISMT Nagios® plugins execution

permission.

# Disable "ssh hostname sudo <cmd>",

because it will show the password in clear.

# You have to run "ssh -t hostname sudo

<cmd>".

#

Defaults requiretty

Defaults:nagios !requiretty

……

……

……

## Same thing without a password

# %wheel ALL=(ALL) NOPASSWD: ALL

nagios ALL=(ALL) NOPASSWD: ALL

Nagios* installation Nagios installation ready √(4)

Nagiosgraph Add-On

installation

√(5)

(1) If you choose is to run the IMSM Utilities from a network shared path, you need to make sure the network shared server

is equipped with the required add-on packages to ensure successful execution of IMSM scripts locally or through an SSH

connection from the Management Server.

(2) For Paramiko module installation, install ECDSA module first, and finally the Paramiko module itself. Pynag module

installation can be omitted if you do not intend to use the Nagios plugins from IMSM.

(3) IMSM scripts will start the driver service if it is not yet started.

(4) Skip this step if your Managed Server is not managed by Nagios.

(5) Skip this if you do not intend to use the Nagiosgraph. Please refer to Nagiosgraph website for the installation package and

instructions i.e. http://sourceforge.net/projects/nagiosgraph/files/nagiosgraph/.

http://sourceforge.net/projects/nagiosgraph/files/nagiosgraph/


2.1.3 Required Add-on Packages

For Management and in-band managed server(s), the below additional add-on packages are

required to be installed to ensure proper functionality of IMSM. Majority of the add-on

packages listed in below table are legacy 32-bits libraries which are needed to run Intel®

Utilities binaries.

Table 5: Required Add-on RPM Packages

Operating Systems RPM PackagesRedHat

Red Hat Enterprise

Linux 6.8 x86_64

libgcc rpm (32-bit)

glibc rpm (32-bit)

libstdc++ rpm (32-bit)

ncurses-libs rpm (32-bit)

python-devel rpm (64-bit)

Red Hat Enterprise

Linux 7.3 x86_64

libgcc rpm (32-bit)

glibc rpm (32-bit)




CentOS 7.3 x86_64 libgcc rpm (32-bit)

glibc rpm (32-bit)




SUSE Linux

Enterprise Server

11.4 x86_64

libgcc_s1 rpm (32-bit)

glibc rpm (32-bit)

libstdc++6 rpm (32-bit)

libncurses6 rpm (32-bit)


SUSE Linux

Enterprise Server

12.2 x86_64

libgcc_s1 rpm (32-bit)

glibc rpm (32-bit)

libstdc++6 rpm (32-bit)

libncurses6 rpm (32-bit)



2.2 Installation Steps

Do not use rpm command to install IMSM. Use ism_install.sh instead.

To install IMSM,

Step 1. On Management Server, copy the IMSM installer <zip file> to target machine.

Create an installer directory folder and unzip the zip file to it.

Step 2. After unzip, run this shell script to install IMSM.

./ism_install.sh. IMSM will be installed to directory /usr/local/ism/.

Step 3. After installation, The user can customize the setting of IMSM to the user’s

preferences (Refer to Section 3. Configurations).

Step 4. The user must execute the Discovery script and the Provision script before other

Feature Scripts, please refer to Section 4 Feature Scripts for detailed usage of the

scripts.

2.3 Update Steps Do not use rpm command to update IMSM. Use ism_update.sh instead.

Follow the steps below to update IMSM version, configuration files (database/cfg/txt/xml)

from the previous version will be restored to new version once update is completed. Old XML

files other than ism_sensorconfig.xml will be backed up to /tmp directory.

To update IMSM,

Step 1. On Management Server, copy the IMSM installer <zip file> to target machine.

Create an installer directory folder and unzip the zip file to it.

Step 2. After unzip, run this shell script to update IMSM.

./ism_update.sh. IMSM will be updated to directory /usr/local/ism/.

Step 3. After the update, user can verify that all the configuration files along with the

database have been properly restored. Prior to the update, a copy of the

configuration files is saved in /tmp folder in case user needs to restore them.


Step 4. After the update, user must execute the Provision script (as explained in Section

4) to also update IMSM files in the managed servers.

python ism_provisioning.pyc --ALL

2.4 Uninstallation Steps

Do not use rpm command to uninstall IMSM. Use ism_uninstall.sh instead.

Follow the steps below to uninstall IMSM, this will remove the database and all the

configuration files.

To uninstall IMSM,

Step 1. Use ism_cleanup.pyc to uninstall IMSM-client package on all Managed Servers,

and also uninstall IMSM Nagios configuration added by IMSM on the

Management Server (if it was previously configured).

python ism_cleanup.pyc --ALL

Refer to Section 4.20 for more details.

Step 2. On Management Server, run the shell command on the path /usr/local/ism/

./ism_uninstall.sh. IMSM will be completely uninstalled and removed from

/usr/local/ism directory.

2.5 Understanding IMSM Structure The following directory structure is created in your Management Server after installation.

IMSM is installed to the directory /usr/local/ism. Default subfolders are ism_setup,

ism_data, and ism_scripts, ism_customDeployPackage, ism_fwPackage, Logfiles

and Licenses. Additional subfolders like Perfdata will be generated after user configured and

executed the Feature Scripts.


Table 6. Directory Structure of IMSM

/usr/local/ism

/ism_setup Stores files which is used during

provisioning.

/ism_data /ism_dataBase.db

Note: ism_dataBase.db is the default

database filename provided in xml config

file. This database file will be created when

addNewGroup.pyc is executed.

/ism_customDeployPackage Default location for checking deploy.nsh

script folders required for performing

custom deploy using the deploy.nsh and

related files and utilities.

/ism_fwPackage Default location for checking SFUP folders

required for performing system firmware

update.

/ism_scripts Stores all executables and configuration

files.

Refer to Table 7

/Logfiles Stores logs.

/Licenses Stores IMSM binaries’ licenses.

/Perfdata Stores performance data.

Table 7. Directory Structure of ism_scripts

Folders

1. /oem

2. /lib

3. /libssh

4. /SDPTool

Files

1. auto_sysupdate.pyc

2. bmcip_sample.txt

3. db_wrapper.pyc

4. InsISMTSvc

5. ism_addNewGroup.pyc

6. ism_bmcconfig.pyc

7. ism_bmcconfig.xml

8. ism_bmcdebuglog.pyc

9. ism_checkprerequisite.pyc

10. ism_checkProvisioned.pyc

11. ism_checksysconsistency.pyc

12. ism_cleanup.pyc

13. ism_config.xml

14. ism_customdeploy_OOB.pyc

15. ism_deleteGroup.pyc

16. ism_deleteHost.pyc

17. ism_discover.pyc

18. ism_getperformance.pyc

19. ism_identify.pyc

20. ism_listGroup.pyc

21. ism_monitoring.pyc

22. ism_moveHost.pyc

23. ism_power.pyc

24. ism_provisioning.pyc

25. ism_raid.pyc

26. ism_sensorconfig.xml

27. ism_sysinformation.pyc

28. ismt_ver.txt

29. ism_updsysfw_OOB.pyc

30. ism_updsysfw.pyc

All IMSM configuration files, feature scripts, and setup files are located inside the folder

/usr/local/ism/ism_scripts. They can be categorized into three groups by their purposes:

Configuration Files, Feature Scripts, and Setup Files.


Configuration Files are the only ones requiring editing from the user. Feature Scripts are

executable scripts which contents should stay intact, and Setup Files are used by IMSM for

installation and setup purposes, hence user can safely ignore the files.

Table 8. Categories of IMSM files

Configuration Files Feature Scripts Setup Files

Configuration files are files which requires user to edit for IMSM configuration.

Feature Scripts are the execution script to achieve IMSM functionalities and purposes.

Setup files are files strictly used for the purpose of installation and setup of IMSM.

How to edit these files? Refer to Section 3 for IMSM Configurations

How to execute these scripts? Refer to Section 4 for IMSM Feature Script Usage

ism_config.xml

ism_sensorconfig.xml

ism_bmcconfig.xml

db_wrapper.pyc

auto_sysupdate.pyc

ism_addNewGroup.pyc

ism_bmcconfig.pyc

ism_bmcdebuglog.pyc

ism_checkprerequisite.pyc

ism_checkProvisioned.pyc

ism_checksysconsistency.pyc

ism_cleanup.pyc

ism_customdeploy_OOB.pyc

ism_deleteGroup.pyc

ism_deleteHost.pyc

ism_discover.pyc

ism_getperformance.pyc

ism_identify.pyc

ism_listGroup.pyc

ism_monitoring.pyc

ism_moveHost.pyc

ism_power.pyc

ism_provisioning.pyc

ism_raid.pyc

ism_sysinformation.pyc

ism_updsysfw_OOB.pyc

ism_updsysfw.pyc

hrs_enu.ini

InsISMTSvc

bmcip_sample.txt

ism_monitor.pyc

ism_perfdata.pyc

ism_sysinfo.pyc

ismt_ver.txt


2.6 Configuration Flow

The following flow chart shows the configuration steps for post-installation. The user can

choose whether or not to save the IMSM-client package on the managed servers. Choosing

“No” requires the user to set up a shared network repository manually (see Section 3.4);

choosing “Yes”, the IMSM-client package will be copied and send to the managed servers

when user is executing ism_provisioning.pyc.

Figure 6. IMSM Configuration Flowchart.

Nagios

CLI

DONE

NO

YES

Run Discovery and Provision Scripts

Do you want to save the

IMSM-client package on

the Managed Servers ?

DONE

DONE

Start Here

Installation

See Section 2.2

Manually install IMSM-

client package to a

Network Shared Drive

See Section 3.4

Configuration

See Section 3 (Skip Section 3.4)

Run Other Feature Scripts

Inquire System Information,

Health, Performance Data;

Update Firmware, Configure

RAID & BMC

Visit Nagios* homepage for

the Managed Servers’

information, health, and

performance data


3 Configurations

IMSM is a customizable product that allows user’s configuration to align with: user’s

definitions, system requirements and an optimal usability experience. This section explains

the configuration files and setting of IMSM in details.

IMSM has two categories of configuration files: the General Configuration Files and the Script-

Specific Configuration Files. The categories are explained in Table 9.

Table 9. Categories of IMSM configuration files

General Configuration File Script-Specific Configuration Files

By default this file refers to ism_config.xml, which is

the main configuration file for IMSM. This file is required

by all Feature Scripts and it affects the functionality of

IMSM in overall.

How to edit this file?

Refer to Section 3.1 General Configuration File

Configuration files which are used by specific Feature

Scripts only.

How to edit these files?

Refer to Section 3.2 Script-Specific Configration

Files

ism_config.xml ism_sensorconfig.xml

ism_bmcconfig.xml

3.1 General Configuration File

The default configuration file for IMSM is ism_config.xml, which is located in the directory

/usr/bin/ism/ism_scripts. After installation, the user must edit the file and provide all

required parameters before executing Feature Scripts. All feature scripts do provide an

optional flag –x to allow user to use a different xml configuration filename, but this is only

applicable for CLI mode use case. For Nagios* with or without NRPE use case, user must use

the default configuration file for successful provisioning and execution of IMSM with Nagios*

plugins.

Note: All parameter names, symbols, and values are case-sensitive and space-sensitive.

Please be cautious when editing the configuration files.


Table 10. Configuration Parameters of “ism_config.xml”

Parameter Name Description

ism_dataBaseLocation Default:

<ism_dataBaseLocation>/usr/bin/ism/ism_data/ism_dataBase.db</is

m_dataBaseLocation>

Description:

This parameter specifies the database filename that will be used by IMSM features

to store the managed server’s information such as IP address, login credentials,

firmware versions, etc. User should not have to modify this parameter.

ismSetupLocation Default:

<ismSetupLocation>$(homedir)/</ismSetupLocation>

This parameter specifies the directory where IMSM binaries will be installed by the

Provisioning script. IMSM binaries will be installed to the SSH user home directory.

For example, when accessing a remote RHEL Managed Server by logging in as the

user “ALEX”, IMSM binaries will be installed to /home/ALEX/ismkit/rhel/.

Note: The directories ismkit/sles or ismkit/rhel will be generated according to the

host’s OS.

If the user preference is not to install IMSM binaries on every Managed Server, but

only to a dedicated server host. Then this parameter will need to be edited to

include the network share path where the IMSM binaries had been installed.

For example:

<ismSetupLocation>/mnt/nfs_mount/</ismSetupLocation>

With this example, IMSM binaries will be obtained from the path:

/mnt/nfs_mount/ismkit/rhel, and /mnt/nfs_mount/ismkit/sles

thirdparty Default: (value is empty)

<thirdparty></thirdparty>

This parameter specifies the third party server management tool (third party tool,

TPT) that co-exists with IMSM within the network of managed servers.

This parameter determines if IMSM will provision the managed servers in such a

way that adds IMSM features as service plugins to the TPT. When the parameter is

filled, the IMSM provisioning script will automatically update the TPT’s configuration

files accordingly to support IMSM features in place.

Note: Currently the only acceptable parameter value is “nagios”. Edit this

parameter from empty string to below if the update of TPT configuration files or

the installation of new IMSM plugins are needed.

Currently supported thirdparty plugins:

a) Nagios Core 4.x

<thirdparty>nagios</thirdparty>

nagios_install_path Default:

<nagios_install_path>/usr/local/nagios/</nagios_install_path>

This parameter specifies the installation path of Nagios. It allows the IMSM

provisioning script to locate the Nagios main configuration file and plugin directory.


communitystring Default:

<communitystring>public</communitystring>

This parameter specifies the “communityname” to allow SNMP remote access to

the Intel® SNMP Subagent. The provisioning script will configure the snmpd.conf

content with this parameter to allow the Intel® SNMP Subagent to communicate

with the NET-SNMP Master Agent.

Note: This value is only needed when the <alertserver_ip> value is not empty.

alertserver_ip Default: (value is empty)

<alertserver_ip></alertserver_ip>

This parameter specifies the target machine’s IP address for all SNMP Subagent

nodes to send their alerts to. The default parameter is empty - the user may need

to update it manually. The user will be prompted to enter it during execution of

provisioning script, and the parameter will be updated.

When the value is empty, provisioning and cleanup script will ignore to take any

action for install and uninstall of Intel® SNMP Subagent package.

Note: If the setup of the Intel® SNMP Subagent in the managed server is not

desired, leave this parameter empty (as default). If prompted for entry during

execution of the provisioning script, skip it by pressing [ENTER].

mgtserver_ip Default: (value is empty)

<mgtserver_ip>[user must fill]</mgtserver_ip>

This parameter specifies the IPv4 Address of the Management Server. It is empty

by default and the user MUST provide this parameter if <thirdparty> parameter

value is ‘nagios’.

The IPv4 provided by the user will be the node that all remote managed server-

nodes in the network regard as the central IMSM system. It stores and supervises

the access of a centralized database serving every managed server-node.

ism_logsLocation Default:

<ism_logsLocation>/usr/local/ism/Logfiles/serverName</ism_logsLoc

ation>

This parameter specifies IMSM log file path. System Events Log, RAID Events Log

and BMC debug log of a managed server are stored here on the management

server.

Note: Some scripts will replace the variable “serverName” of this parameter with

the IP Address of the managed host to create a dedicated directory for that

managed host. ALWAYS append to the parameter one occurrence of

“/serverName” and “/serverName” must not be removed.

ism_perfDataLocation Default:

<ism_perfDataLocation>/usr/local/ism/PerfData/serverName</ism_pe

rfDataLocation>

This parameter specifies the directory where ism_getperformance.pyc can store

the generated performance data of a managed server in a CSV file on the

management server.

Note: ism_getperformance.pyc will replace the variable “serverName” of this

parameter with the IP Address of the managed host to create a dedicated directory

for that managed host. ALWAYS append to the parameter one occurrence of

“/serverName” and “/serverName” must not be removed.


defaultHealthyTimeStamp Default:

<defaultHealthyTimeStamp>04/01/2015-01:01:00AM</def

aultHealthyTimeStamp>

This parameter specifies the first point-in-time where system health can be

assessed. IMSM regards this parameter as the retrospective time-of-reference for

which system’s health has became important. System health status before this

time-of-reference will be ignored in data analysis.

Note: The format is mm/dd/yyyy-HH:MM:SSZZ; ZZ is either “AM” or “PM” and

time is in 12-hour format.

ism_fwPkgLocation Default:

<ism_fwPkgLocation>/usr/local/ism/ism_fwPackage/<ism_fwPkgLocat

ion>

This parameter specifies the default path SFUP/SUP package will be unzipped to

perform System Firmware Update task.

If the user preference to use network share path, then specify the network share

location where the SFUP/SUP package is unzipped.

For example:

<ism_fwPkgLocation>/mnt/nfs_mount/ism_fwPackage/</ism_

fwPkgLocation >

Ensure the SFUP/SUP package is unzipped to this same path, if the package name

is stated in the below <platform ID> parameter.

<S2600WT>

<S2600KP>

<S2600TP>

<S2600CW>

<S1200SP>

<S7200AP>

<S2600WFT>

<S2600BP>

<S2600STB>

<S2600WT_SUP>

<S2600KP_SUP>

<S2600TP_SUP>

<S2600CW_SUP>

<S1200SP_SUP>

<S7200AP_SUP>

<S2600WFT_SUP>

<S2600BP_SUP>

<S2600STB_SUP>

Default:

<S2600WT></S2600WT>

<S2600KP></S2600KP>

<S2600TP></S2600TP>

<S2600CW></S2600CW>

<S1200SP></S1200SP>

<S7200AP></S7200AP>

<S2600WFT></S2600WFT>

<S2600BP></S2600BP>

<S2600STB></S2600STB>

<S2600WT_SUP></S2600WT_SUP>

<S2600KP_SUP></S2600KP_SUP>

<S2600TP_SUP></S2600TP_SUP>

<S2600CW_SUP></S2600CW_SUP>

<S1200SP_SUP></S1200SP_SUP>

<S7200AP_SUP></S7200AP_SUP>

<S2600WFT_SUP></S2600WFT_SUP>

<S2600BP_SUP></S2600BP_SUP>

<S2600STB_SUP></S2600STB_SUP>


These <platform ID> parameters specify the SFUP/SUP package name for different

platform ID systems. These parameters are used in system firmware update. For

<platform ID with SUP>, SUP package is used, whereas, for <platform ID without

SUP>, FSUP package is used. SUP package contains efi files and typically have ‘EFI”

in its name.

Example:

<S2600WT>S2600WT_SFUP_BIOSR01_01_0008_ME030007154_BMC01

187601_FRUSDR106</S2600WT>

<S2600WT_SUP>S2600WT_EFI_BIOS01010016_ME030103021_BMC014

39685_FRUSDR113</S2600WT_SUP>

The latest SFUP package is available on the Intel website.

<S2600WT> is for product ID : S2600WT/S2600WTR family

<S2600KP> is for product ID : S2600KP/S2600KPR family

<S2600TP> is for product ID : S2600TP/S2600TPR family

<S2600CW> is for product ID: S2600CW/S2600CWR family

<S1200SP> is for product ID : S1200SP family

<S7200AP> is for product ID : S7200AP family

<S2600WFT> is for product ID : S2600WFT family

<S2600BP> is for product ID : S2600BP family

<S2600STB> is for product ID : S2600STB family

ism_customDeployLocation Default:

<ism_customDeployLocation>/usr/local/ism/ism_customDeployPackag

e/<ism_ customDeployLocation>

This parameter specifies the default location of custom deploy folders.

Ensure the custom deploy folders specified in the <platform ID with Deploy>

parameter below are placed at this location.

<S2600WT_Deploy>

<S2600KP_Deploy>

<S2600TP_Deploy>

<S2600CW_Deploy>

<S1200SP_Deploy>

<S7200AP_Deploy>

<S2600WFT_Deploy>

<S2600BP_Deploy>

<S2600STB_Deploy>

Default:

<S2600WT_Deploy></S2600WT_Deploy>

<S2600KP_Deploy></S2600KP_Deploy>

<S2600TP_Deploy></S2600TP_Deploy>

<S2600CW_Deploy></S2600CW_Deploy>

<S1200SP_Deploy></S1200SP_Deploy>

<S7200AP_Deploy></S7200AP_Deploy>

<S2600WFT_Deploy></S2600WFT_Deploy>

<S2600BP_Deploy></S2600BP_Deploy>

<S2600STB_Deploy></S2600STB_Deploy>

These <platform ID with Deploy> parameters specify the custom deploy folder

name for different platform ID systems. These parameters are used in custom

deploy operation. Users will need to create their own custom deploy folder and

provide the deploy.nsh script to run specific commands. Deploy folder should

contain required deploy.nsh and related files/utilities needed by deploy.nsh script.


Example:

<S2600WT_Deploy>S2600WT_Deploy/</S2600WT_SUP>

Example of the contents in deploy.nsh:

iflash32.efi –i

In this example, users will have to provide deploy.nsh with the content above and

also iflash32.efi utility inside the custom deploy folder specified for S2600WT

platform.

threadCount Default:

<threadCount>16</threadCount>

This parameter specifies the number of Managed Servers being updated in one

cycle. If the number of Managed Servers is more than the value of threadCount

specified, the update can take more than one cycle to complete.

ipmitool_additional_options Default:

<ipmitool_additional_options></ipmitool_additional_options>

This parameter specifies additional ipmitool command to run with whenever

ipmitool command is executed in IMSM scripts.

Example:

<ipmitool_additional_options>-I lanplus</ipmitool_additional_options>

3.2 Script-Specific Configuration Files

Script-specific configuration files are configuration files which are required by, and applicable

to certain Feature Scripts only. The files determine the behavior of the corresponding Feature

Scripts. User may customize these files to the user’s preferences, or use the default values.

Note: All parameter names, symbols, and values are case- and space-sensitive, please be

cautious when editing the configuration files.

3.2.1 ism_sensorconfig.xml

Use by feature script: ism_getperformance.pyc

Default path: /usr/local/ism/ism_scripts/ism_sensorconfig.xml

Table 11. Configuration Parameters of “ism_sensorconfig.xml”


<sensor_name> The contents specify the power and temperature sensors to be queried in

ism_getperformance script.

The file has entries of the format:

<sensor_name> yes | no </sensor_name>


where “sensor_name” refers to the IPMI sensor name. “yes | no” is the query

choice, sensors marked with “yes” will be queried and sensors marked with “no”

will be ignored.

The default script has a list of sensors optimized for getperformance script’s usage,

users may edit it to add or remove sensor entries.

Note: Users should not add additional sensor names that are not valid IPMITool

Sensor Data Record (SDR) sensors. Invalid sensors might not return a value.

3.2.2 ism_bmcconfig.xml

Use by feature script: ism_bmcconfig.pyc

Default path: /usr/local/ism/ism_scripts/ism_bmcconfig.xml

Table 12. Configuration Parameters of “ism_bmcconfig.xml”


bmcDefaultUserName Default: (value is empty)

<bmcDefaultUserName></bmcDefaultUserName>

This parameter specifies the BMC username used to create a new BMC user to

BMC user list. This parameter will be overwritten if user specifically provided

new BMC login credentials as an in-line argument [-b username/password]

while executing the script.

BMC_user_account Default: (value is empty)

< BMC_user_account ></ BMC_user_account >

This parameter specifies the BMC USER ID if user would like to create a new

BMC user into BMC user list. Default value is empty. The value allowed for BMC

User ID is in range 4-15.

Supported value: 4 - 15

Example:

< BMC_user_account>5</ BMC_user_account >

LAN_failover Default: (value is empty)

<LAN_failover> </LAN_failover>

This parameter is used to enable the LAN failover feature. If it is set to “disable",

then it will disable the LAN failover feature. Lan Fail Over only can be set in

LAN Channel 1. Once lan failover is set to enable, other BMC channel cannot be

edited except channel 1.

Supported values: enable | disable | <empty>

Example:

<LAN_failover>enable</LAN_failover>

IP_source Default: (value is empty)


<IP_source> IP_source>

This parameter is used to set the IP source for BMC IP. Only options are

“STATIC” or “DHCP” or “<empty>”. If it is STATIC, user needs to provide of

BMC IP assigned for all the HOST IP in file specified in <Static_filename>. If

<empty>, then it will not perform BMC IP configuration.

Supported values: STATIC | DHCP | <empty>

Example:

<IP_source>DHCP</IP_source>

Default_gateway_IP Default:

<Default_gateway_IP>192.168.1.96</Default_gateway_IP>

This parameter is used to set the default gateway ip for the bmc ip setup.

subnet_mask Default:

<subnet_mask>255.255.255.0</subnet_mask>

This parameter is used to set the subnet mask for the bmc ip setup.

Static_filename Default:

<Static_filename>bmcip_sample.txt</Static_filename>

This parameter is used to configure static bmc ip. User may write a list of host

ip with the BMC IP to be assigned. The format is “192.168.1.1:128.101.1.1”.

Host IP is on the left side while BMC IP to set is on the right side after the colon.

Each host must be in new line. Notes: Please make sure no duplicate of IP in

the file.

Serial_over_LAN Default: (value is empty)

<serial_over_LAN></serial_over_LAN>

This parameter is used to enable serial over lan setting. If set to “disable”, it

will disable serial over lan. If it is <empty>, then it will not perform this action.


Example:

<serial_over_LAN>enable</serial_over_LAN>

LAN_alerting Default: (value is empty)

<LAN_alerting></LAN_alerting>

This parameter is used to enable the LAN alerting. If set to “disable”, it will not

enable LAN alerting. However, it will not disable the LAN alerting if it had

previously set to enable.


Example:

<LAN_alerting>enable</LAN_alerting>

LAN_alerting_dest_1_ty

pe

Default: (value is empty)

<LAN_alerting_dest_1_type> </LAN_alerting_dest_1_type>

This parameter specifies the LAN alerting type for destination

Supported values: SNMP | email | <empty>

Example:


<LAN_alerting_dest_1_type>SNMP</LAN_alerting_dest_1_type>

LAN_alerting_dest_2_ty

pe


<LAN_alerting_dest_2_type></LAN_alerting_dest_2_type>

This parameter specifies the LAN alerting type for destination

Supported values: SNMP | email | <empty>

Example:

<LAN_alerting_dest_2_type>email</LAN_alerting_dest_2_type>

LAN_snmp_alert_dest_1

_serverIP

Default:

<LAN_snmp_alert_dest_1_serverIP>192.168.1.1</LAN_snmp_alert_

dest_1_serverIP>

This parameter specifies the target machine IP address for SNMP to send out

alert trap message.


_MAC

Default:

<LAN_snmp_alert_dest_1_MAC>00-00-00-00-00-

00</LAN_snmp_alert_dest_1_MAC>

This parameter specifies the target machine MAC address for SNMP to send out

alert trap message.


_serverIP

Default:

<LAN_snmp_alert_dest_2_serverIP>192.168.1.1</LAN_snmp_alert_

dest_2_serverIP>

This parameter specifies the target machine IP address for SNMP to send out

alert trap message.


_MAC

Default:

<LAN_snmp_alert_dest_2_MAC>00-00-00-00-00-

00</LAN_snmp_alert_dest_2_MAC>

This parameter specifies the target machine MAC address for SNMP to send out

alert trap message.

LAN_email_alert_dest_1

_recipient_Email


< LAN_email_alert_dest_1_recipient_Email

></ LAN_email_alert_dest_1_recipient_Email

>

This parameter specifies the recipient email address to send out the alert

message for alert destination 1.

Example:


>[email protected]</ LAN_email_alert_dest_1_recipient_Email

>


LAN_email_alert_dest_2

_recipient_Email



></ LAN_email_alert_dest_2_recipient_Email

>

This parameter specifies the recipient email address to send out the alert

message for alert destination 2.

Example:


>[email protected]</ LAN_email_alert_dest_2_recipient_Email

>

LAN_email_alert_mailser

ver_machinename


< LAN_email_alert_mailserver_machinename

></ LAN_email_alert_mailserver_machinename

>

This parameter specifies the email server machine name.

Example:

< LAN_email_alert_mailserver_machinename

>mgt-server01</ LAN_email_alert_mailserver_machinename

>

LAN_email_alert_sender

_Email


<LAN_email_alert_sender_Email></LAN_email_alert_sender_Email>

This parameter specifies the sender’s email address who send out this alert

message.

Example:

< LAN_email_alert_sender_Email

>[email protected]</ LAN_email_alert_sender_Email

>

LAN_email_alert_mail_s

erverIP


< LAN_email_alert_mail_serverIP

></LAN_email_alert_mail_serverIP

>

This parameter specifies the email server IP.

Example:

< LAN_email_alert_mail_serverIP

>192.168.1.11</ LAN_email_alert_mail_serverIP

>


LAN_email_alert_mail_s

erver_port


<LAN_email_alert_mail_server_port

></LAN_email_alert_mail_server_port

>

This parameter specifies the email server port. If not specified, the server port

is auto-assigned if LAN_email_alert_mail_serverIP is provided.

Example:

< LAN_email_alert_mail_server_port

>99</ LAN_email_alert_mail_server_port

>

SMTP_authentication_m

ethod


<SMTP_authentication_method

></SMTP_authentication_method

>

This parameter specifies the SMTP authentication method. Acceptable

parameters are none | STARTTLS | TLSSSL. If left empty, SMTP

authentication method will not be configured.

Example:

<SMTP_authentication_method

>TLSSSL</SMTP_authentication_method

>

SMTP_authentication_us

er


<SMTP_authentication_user

></SMTP_authentication_user

>

This parameter specifies the SMTP authentication user name. If left empty,

SMTP authentication user will not be configured. If filled in, user will be

prompted for the SMTP user password during script execution.

Example:

<SMTP_authentication_user

>SMTPUserName1</SMTP_authentication_user

>

PEF_configuration Default: (value is empty)

<PEF_configuration></PEF_configuration>

This parameter is used to enable the PEF configuration.

Supported values: enable | disable

Example:

<PEF_configuration>enable<PEF_configuration>


PEF_globally_enable_PE

F

Default:

<PEF_globally_enable_PEF>enable</PEF_globally_enable_PEF>

This parameter is used to enable Platform Event Filtering.


PEF_log_event_on_filter

_action

Default:

<PEF_log_event_on_filter_action>disable</PEF_log_event_on_filter

_action>

This parameter is used to enable log event for Platform Event Filtering


temperature_sensor_out

_of_range

Default:

<temperature_sensor_out_of_range>yes</temperature_sensor_out_

of_range>

This parameter is used to enable “temperature sensor out of range” event to

send alert for

Supported values: yes | no

(other values will be treated as “no”)

system_restart Default:

<system_restart>yes</system_restart>

This parameter is used to enable “system restart” event to send alert for



fan_failure Default:

<fan_failure>yes</fan_failure>

This parameter is used to enable “fan failure” event to send alert for



power_supply_failure Default:

<power_supply_failure>yes</power_supply_failure>

This parameter is used to enable “power supply failure” event to send alert for



BIOS_post_error_code Default:

<BIOS_post_error_code>yes</BIOS_post_error_code>

This parameter is used to enable “BIOS post error code” event to send alert for




node_manager_exceptio

n

Default:

<node_manager_exception>yes</node_manager_exception>

This parameter is used to enable “node manager exception” event to send alert

for



watchdog_timer Default:

<watchdog_timer>yes</watchdog_timer>

This parameter is used to enable “watchdog timer” event to send alert for



voltage_sensor_our_of_r

ange

Default:

<voltage_sensor_out_of_range>yes</voltage_sensor_out_of_range

>

This parameter is used to enable “voltage sensor out of range” event to send

alert for



chassis_intrusion Default:

<chassis_intrusion>yes</chassis_intrusion>

This parameter is used to enable “chassis intrusion” event to send alert for



memory_error Default:

<memory_error>yes</memory_error>

This parameter is used to enable “memory error” event to send alert for



FRB_failure Default:

<FRB_failure>yes</FRB_failure >

This parameter is used to enable “FRB failure” event to send alert for



hard_disk_failure Default:

<hard_disk_failure>yes</hard_disk_failure>

This parameter is used to enable “hard disk failure” event to send alert for




power_unit_redundancy

_failure

Default:

<power_unit_redundancy_failure>yes</power_unit_redundancy_fail

ure>

This parameter is used to enable “power_unit_redundancy_failure” event to

send alert for



inlet_temperature_overh

eat_shutdown

Default:

<inlet_temperature_overheat_shutdown>yes</

inlet_temperature_overheat_shutdown>

This parameter is used to enable “inlet_temperature_overheat_shutdown”

event to send alert for



fan_redundancy_failure Default:

<fan_redundancy_failure>yes</fan_redundancy_failure>

This parameter is used to enable “fan_redundancy_failure” event to send alert

for



power_unit_status Default:

<power_unit_status>yes</power_unit_status>

This parameter is used to enable “power_unit_status” event to send alert for



processor_therm_trip Default:

<processor_therm_trip>yes</processor_therm_trip>

This parameter is used to enable “processor_therm_trip” event to send alert for



processor_dimm_therm_

trip

Default:

<processor_dimm_therm_trip>yes</processor_dimm_therm_trip>

This parameter is used to enable “processor_dimm_therm_trip” event to send

alert for




3.3 Database File

IMSM uses a database file in .db format to store the information of the managed servers. The

database file will be created when the user executes the Feature Script

ism_addNewGroup.pyc. The name of the database file is provided by the general

configuration file ism_config.xml, and the default file name is ism_dataBase.db.

Default directory and filename:

/usr/local/ism/ism_data/ism_dataBase.db

If user wishes to use different filename, the change can be made by editing the parameter

<ism_dataBaseLocation> in ism_config.xml -- changing [ism_dataBase].db to

[new_name].db. The dataBase file must be placed in the directory /ism_data.

For further details of editing ism_config.xml, please refer to Section 3.1 General Configuration

File


3.4 Network Shared Drive

IMSM offers the versatility for the user to install IMSM-client package to the Managed Server

from the installer package located in a network shared drive on the Management Server’s disc

space, instead of saving the installer package in the managed server’s own disc space, thus

saving the disc space of the Managed Server.

To set up this feature, the user must complete the following steps.

Step 1. Create a shared directory on Management Server’s network with accessibility from

all Managed Servers. The shared directory will act as the centralised installer

repository.

Shared directory path = [network shared]

Example: Shared directory path = /mount/ismt_repo/

Step 2. Change the following parameter within the general configuration file (default file

is ism_config.xml):

From

<ismSetupLocation>$(homedir)</ismSetupLocation>

To

<ismSetupLocation>[network shared]</ismSetupLocation>

For details on editing this file, please refer to Section 3.1 General Configuration File

Step 3. Create necessary directories.

Shell Commands:

a) mkdir -p [network shared]/14_0/ismkit/rhel/snmpsa

b) mkdir -p [network shared]/14_0/ismkit/sles/snmpsa

c) mkdir -p [network shared]/14_1/ismkit/rhel/snmpsa

d) mkdir -p [network shared]/14_1/ismkit/sles/snmpsa

Step 4. Extract zipped files from IMSM to this network share directories. These zipped files

can be found at “/usr/local/ism/ism_setup/” after IMSM installation.

Shell Commands:

a) unzip -q -u -d [network shared]/14_0/ismkit/rhel/

/usr/local/ism/ism_setup/rhel-ismutils-14_0.zip

b) unzip -q -u -d [network shared]/14_0/ismkit/rhel/

/usr/local/ism/ism_setup/rhel-ismAgent.zip

c) unzip -q -u -d [network shared]/14_0/ismkit/rhel/


/usr/local/ism/ism_setup/rhel-snmpsa-14_0.zip

d) unzip -q -u -d [network shared]/14_0/ismkit/sles/

/usr/local/ism/ism_setup/sles-ismutils-14_0.zip

e) unzip -q -u -d [network shared]/14_0/ismkit/sles/

/usr/local/ism/ism_setup/sles-ismAgent.zip

f) unzip -q -u -d [network shared]/14_0/ismkit/sles/

/usr/local/ism/ism_setup/sles-snmpsa-14_0.zip

g) unzip -q -u -d [network shared]/14_1/ismkit/rhel/

/usr/local/ism/ism_setup/rhel-ismutils-14_1.zip

h) unzip -q -u -d [network shared]/14_1/ismkit/rhel/

/usr/local/ism/ism_setup/rhel-ismAgent.zip

i) unzip -q -u -d [network shared]/14_1/ismkit/rhel/

/usr/local/ism/ism_setup/rhel-snmpsa-14_1.zip

j) unzip -q -u -d [network shared]/14_1/ismkit/sles/

/usr/local/ism/ism_setup/sles-ismutils-14_1.zip

k) unzip -q -u -d [network shared]/14_1/ismkit/sles/

/usr/local/ism/ism_setup/sles-ismAgent.zip

l) unzip -q -u -d [network shared]/14_1/ismkit/sles/

/usr/local/ism/ism_setup/sles-snmpsa-14_1.zip


4 Feature Scripts

The Feature Scripts are the main engines of IMSM. The power of IMSM is achieved through

customized execution of the Feature Scripts. This section explains the ways to execute IMSM

Feature Scripts, and the objectives the user can accomplish by using them.

4.1 General Rules

1. To display a helpful guide on how to execute each script, you can enter the shell

command:

python <feature script>.pyc

Examples: python ism_addNewGroup.pyc

2. If the user is using the default general configuration file ism_config.xml, the user

may provide it as argument [–x] after the Feature Script’s name. However, this is

optional and only applicable for CLI use case. Changing general configuration filename

will incur error in Nagios* use case.

python <Feature Script>.pyc -x ism_config.xml

If user wants to use a configuration file other than ism_config.xml, the user must

provide the filename as an argument –x.

python <Feature Script>.pyc -x <config_filename>.xml

3. It is recommended that all servers in the same network managed by IMSM are

synchronous in time. A Management Server and multiple Managed Servers with

different time settings may cause chronological confusion and conflict when the data

are collected and analyzed.

4. Terminology used in this section

managed server, host, member*

Refers to the server managed by a central Management Server on same network and having at least one accessible IPv4 Address

management server Refers to the server where IMSM binaries reside and are executed from. It also stores the database file.

hostgroup, group Refers to the grouping of host(s) under a group name. A group’s

entities are called “members” or “hosts” interchangeably. Members* are managed servers in a group.

Feature Script Refers to any Python-based script, which represents a IMSM feature, specified from Section 4.3 to 4.23


4.2 Usage Flow

New installation requires user to execute discovery and provision for once to set up the

environment and database. IMSM has the capability to discover, provision, and manage new

Intel® Server Systems connected to the network in datacenter while maintaining the existing

database.

The following flowchart shows the recommended sequence of executing Feature Scripts. The

user is advised to follow this flow sequence.

Figure 7. The flowchart of IMSM Feature Script usage.

First-Time Installation New Intel® Server System added

to existing network ?

Add to existing group?

If yes, skip this step

If no, create new group

Discover the new server and add

it to group

Provision the new server

Configurations

Section 3 Configurations

ism_addNewGroup.pyc

Refer Section 4.4

ism_discover.pyc

Refer Section 4.9

ism_provisioning.pyc

Refer Section 4.10

User can now execute other Feature Scripts

ism_checkprerequisite.pyc

Refer Section 4.3


4.3 Prerequisite Check

The execution of this script checks the environment setting of the Management Server and

reports any unsatisfied requirements prior to the execution of other Feature Scripts.

Shell Command:

python ism_checkprerequisite.pyc [-x xml config filename]

[-x xml config filename] The Filename for the general configuration file

located in the same directory as the Feature

Scripts. i.e. /usr/local/ism/ism_scripts/

This argument is optional; if not provided, the

default general configuration file ism_config.xml

will be used.

Examples of Usage:

python ism_checkprerequisite.pyc -x ism_config.xml

4.4 Add New Hostgroup

The execution of this script creates a hostgroup in the database and configuration files. The

hostgroup will accommodate the hosts added to it as “members”. A hostgroup must be

created before executing the Discovery script, and each managed server must be associated

with a hostgroup.

Shell Command:

python ism_addNewGroup.pyc [-x xml config filename] [-g groupname] [--verbose]






will be used.

[-g groupname] A groupname forms with alphanumerical

character to be added to the IMSM database. [-i


IP address] will be added as its member during

discovery.

[--verbose] Displays all execution details. If not provided,

Terminal displays essential messages only.

Examples of Usage:

python ism_addNewGroup.pyc -x ism_config.xml -g IntelGroupAlpha

python ism_addNewGroup.pyc -x ism_config.xml -g IntelGroupBeta

4.5 Delete a Host

The execution of this script deletes a previously-added host (managed server) from the

database.

Shell Command:

python ism_deleteHost.pyc [-x xml config filename] [-i IP Address] [--verbose]






will be used.

[-i IP address] A valid IP address previously added to the IMSM

database, it will be removed from the database.



Examples of Usage:

python ism_deleteHost.pyc -x ism_config.xml -i 192.168.1.15

python ism_deleteHost.pyc -i 192.168.1.20


4.6 Move a Host

The execution of this script changes the residing hostgroup of a host. The host will be removed

from its residing “source group” and added to the “destination group”. For the script to take

effect, the host must exist as a member of the “source group”, and the “destination group”

must already has been created.

Shell Command:

python ism_moveHost.pyc [-x xml config filename] [-i IP address] [-S source

groupname] [-D destination groupname] [--verbose]






will be used.


database, it will be moved from the member-list

of [-S source groupname] to the member-list of [-

D destination groupname].

[-S source groupname] A valid groupname previously added to the IMSM

database. [-i IP address] will be removed from its

member list.

[-D destination

groupname]

A valid groupname previously added to the IMSM

database. [-i IP address] will be added to its

member list.




Examples of Usage:

python ism_moveHost.pyc -x ism_config.xml -i 192.168.1.15 -S IntelGroupAlpha -D IntelGroupBeta

python ism_moveHost.pyc -x ism_config.xml -i 192.168.1.20 -S IntelGroupBeta -D IntelGroupAlpha

4.7 Delete a Hostgroup

The execution of this script deletes an existing group. This script requires the group to already

exist in the database and configuration files. All previously-added hosts that are members of

the hostgroup will be removed from database after script execution.

Shell Command:

python ism_deleteGroup.pyc [-x xml config filename] [-g groupname] [--verbose]






will be used.

[-g groupname] A valid groupname previously added to the IMSM

database. It will be removed from IMSM database

and third-party tool configuration file.



Examples of Usage:

python ism_deleteGroup.pyc -x ism_config.xml -g IntelGroupAlpha

python ism_deleteGroup.pyc -x ism_config.xml -g IntelGroupBeta

4.8 List Host and Hostgroup

The execution of this script lists the host IP and groups in database. The user can choose to

search by providing a host IP or a group name, or simply list everything by providing the

correct argument.


Shell Command:

python ism_listGroups.pyc [-x xml config filename] [-i IP Address] [-g groupname]






will be used.

[-i IP address] Lists the affiliated group of the IP address.

[-g groupname] Lists the members (host IP address) of the

groupname.

[--ALL] Lists all the groups and corresponding members in

database.

Examples of Usage:

python ism_listGroups.pyc -x ism_config.xml --ALL

python ism_listGroups.pyc -x ism_config.xml -g IntelGroupBeta

4.9 Discovery

The execution of this script discovers Intel® Server Systems in datacenter’s network from a

range of IPv4 provided by user. For the discovery to be successful, user must provide either

one of the SSH or BMC login credentials or both. The argument [-a groupname] is used to

add the discovered server to a database’s hostgroup for easier management. Intel® Server

Systems which have been discovered and added to IMSM database will thus known as

“Managed Servers”.

Shell Command:

python ism_discover.pyc [-x xml config filename] [-i IP address] [-c

username/password] [-b username/password] [-a groupname] [--netshare] [--

verbose]







will be used.

[-i IP address] A valid IP address (in dot-decimal notation) of a

single server, or a valid IP address range

represented in the format of start IP address and

the end IP address separated by a dash (‘-’)

character; for example: 192.168.1.1-

192.168.1.30, or several valid IP address entries

(single, range or combination of both styles)

separated by comma(‘,’) character; for example:

-i 192.168.2.45,192.168.2.20-192.168.2.30,

192.168.3.20-192.168.3.30,192.168.4.11

[-c username/password] Valid pair of SSH login with username and

password separated by forward slash(‘/’)

character to discover remote server(s) within the

network. The username is not limited to ‘root’ user

but include other trusted users who are already in

sudoer list with administrative access privileges.

This argument could be omitted if all the systems

for discovery are pre-configured with BMC settings

for out-of-band access. Refer to the -b optional

flag for the out-of-band system discovery

requirements.

[-b username/password] Valid pair of BMC username and password. This

entry is only useful if the servers in network have

been pre-configured with BMC settings that

allow IPMI lan channel access from a management

server.

This argument could be used along with the [-c

username/password] flag if user intends to do a

discovery for EPSD servers mixed network

environment of in-band systems and out-of-

systems.


[-a groupname] Groupname is used for adding the discovered

EPSD server(s) into the IMSM database. It must

be a valid groupname that was already created in

the IMSM database.

This argument is optional; if not provided,

discovered server(s) will not be added to the IMSM

database.

[--netshare] Provide this flag if the Intel® Utilities binaries are

installed only at a network shared path. Discovery

will check if the remote server(s) is mounted to

the network share path.



Examples of Usage:

python ism_discover.pyc -i 192.168.1.15 -c root/secretpassword

python ism_discover.pyc -x ism_config.xml -i 192.168.1.15 -c root/secretpassword -a epsd

python ism_discover.pyc -i 192.168.1.20 -c root/secretpassword --netshare

python ism_discover.pyc -i 192.168.1.15-192.168.1.100 -c alan/alansecretpassword -a epsd

python ism_discover.pyc -i 192.168.1.15-192.168.1.100,192.168.3.20-192.168.3.50 -b test2/test2secret

python ism_discover.pyc -i 192.168.1.15-192.168.1.100,192.168.3.20-192.168.3.50 -b test2/test2secret -a epsd

python ism_discover.pyc -i 192.168.1.15-192.168.1.100,192.168.3.20-192.168.3.50 -c root/secretpassword -b

test2/test2secret –a epsd

4.10 Provision

The execution of this script installs the IMSM-client package on the managed servers, so that

subsequent feature scripts are able to access the installed binaries to perform the feature

tasks such as execution of storcli for raid configuration, execution of flashupdt to do firmware

upgrade or downgrade and execution of syscfg for system information retrieval. If users do

not wish every managed server get installed with the IMSM-client package, users can opt to

install the IMSM-client package manually (refer section 3.4), and provide the [--netshare]

argument when running the provision script.

For integration with Nagios* Management Tools, provision will help to update the Nagios*

configuration path with additional configuration files. The files are ismcommands.cfg, ism-

inband.cfg and ism-outband.cfg respectively.


If managed server was discovered earlier is an in-band Nagios* ready, provisioning will install

the IMSM nagios plugins to the managed server’s install path, such as

<nagios_install_path>/libexec/ISM.

If there is an out-of-band Nagios* managed server to provision for, IMSM nagios plugins will

be installed locally at the Management Server (which is the Nagios* Management Server), at

the Nagios install path defined in XML configuration file, i.e

<nagios_install_path>/libexec/ISM.

The provision script will not install net-snmp (snmpd) which is a prerequisite for SNMP

Subagent if snmpd is not found in the Management Server. If snmpd is present, the provision

script does support Intel® SNMP Subagent installation if user wants this to be set up by the

provision script (refer section 3.1). Provision script will skip the installation if another version

is already exists. The IMSM cleanup script will only uninstall the Intel® SNMP Subagent(SA),

if the SNMP-SA was installed by the script. If SNMP-SA was installed by another method

besides the script, it will not be uninstalled. For managed server which has Intel® SNMP

Subagent installed manually or through other automation script, IMSM cleanup script will

ignore the uninstallation of the Intel® SNMP Subagent package.

Shell Command:

python ism_provisioning.pyc [-x xml config filename] {--ALL | –i IP address | -g

groupname} [--netshare] [--verbose]






will be used.

[--ALL] When this flag is provided, all servers in IMSM

database will be accessed via SSH for provisioning

if they are in-band servers. For out-of-band

servers in the IMSM database, provisioning on

those servers will only be limited to set up of the

Nagios* configuration files to load IMSM service

plugins by Nagios Management Server.

[-i IP address] A valid IP address previously added in IMSM

database for a server during discovery. If a group


of servers in IMSM database are required for

provisioning, use [-g groupname] argument

option. This [-i IP address] is only meant for

representation of a single server which was added

previously in IMSM database.

[-g groupname] A valid groupname previously added in IMSM

database, with at least one server associated to

the group.

[--netshare] Provide this flag if the binaries files of the software

utilities for Intel® Server Systems are to be

installed at a network shared path. Provisioning

will only verify managed server has access to the

mounted network share path, but will not install

the utilities on the network share path.



Examples of Usage:

python ism_provisioning.pyc -i 192.168.1.15

python ism_provisioning.pyc -x ism_confignew.xml -i 192.168.1.15

python ism_provisioning.pyc -g IBSERVER

python ism_provisioning.pyc -g OBSERVER

python ism_provisioning.pyc -g IBSERVER --netshare

4.11 System Information Inquiry

This script checks and displays queried information from the specified managed systems.

Execution time is controlled by the arguments “NOW” and “RunAtTime”; the amount of

information returned is controlled by the argument “InfoALL” (query everything) or one of the

following: “BIOS” / “ME” / “BMC” / “SDR” / “RMM” / “POWER” / “FRU” / “CPU” / “MEM”/

“SENSOR” / “NETWORK” / “STORAGE” / “baseboard” / “riser” / “frontpanel” / “backplane” /

“powersupply” / “sas” / “ocp” / “phi”. FRU, CPU, MEM, SENSOR, NETWORK, STORAGE,

baseboard, riser, frontpanel, backplane, powersupply, sas, ocp and phi queries can only be

made on OOB-managed servers.


Shell Command:

python ism_sysinformation.pyc [-x xml config filename] {--NOW | --RunAtTime | --

LOOP} {--ALL | –i IP address | -g groupname} {--InfoALL | --BIOS | --ME | --BMC |

--SDR | --RMM | --POWER | --FRU | --CPU | --MEM | --SENSOR | --NETWORK | --

STORAGE | --baseboard | --riser | --frontpanel |--backplane | --powersupply | --sas

| --ocp | --phi}






will be used.

[--NOW] Execute the script at the current system time.

This argument and [--RunAtTime or --LOOP]

argument has to be used exclusively; script

will accept only one per instance.

[--RunAtTime]

Execute the script at the user’s set time. This

option requires user to enter timer’s duration.

If this argument and [--NOW or --LOOP] are not

provided, script will execute at the current system

time. This argument and the [--NOW or --

LOOP] argument has to be used exclusively;

script will accept only one per instance.

The format for the HOUR value is [00-23]; the

format for the MINUTE value is [00-59]. You will

be prompted for input.

[--LOOP]

Execute the script at the user’s set time with

repetitive mode.

1. Run at execution time every day

2. Run at execution time same day every

week

[--ALL] When this flag is provided, all servers in the IMSM

database will be accessed via SSH for queries if

they are in-band servers that could be connected

with SSH logon credential stored in database;


alternatively, they may be accessed via the BMC

LAN for queries if they are out-of-band servers

that could be connected with BMC logon credential

stored in database

[-i IP address] A valid IP address previously added in the IMSM


of servers in the IMS database are required for

querying the system information, use the [-g

groupname] argument option.

[-g groupname] A valid groupname previously added in the IMS

database, with at least one server associated with

the group.

[--InfoALL] Script returns the versions of BIOS, BMC, SDR,

status of RMM, Power, FRU, CPU, MEM and

SENSOR of the inquired system(s).

[--BIOS] Script returns the BIOS version of the inquired

system(s).

Returns: <BIOS version>

[--ME] Script returns the ME version of the inquired

system(s).

Returns: <ME version>

[--BMC] Script returns the BMC version of the inquired

system(s).

Returns: <BMC version>

[--SDR] Script returns the SDR version of the inquired

system(s).

Returns: <SDR version>


[--RMM] Script returns the RMM status of the inquired

system(s).

Returns: ‘RMM Not Present’, ‘RMM3 Present’,

‘RMM4 Lite Present’

[--POWER] Script returns the Power status of the inquired

system(s).

Returns: ‘Power ON’ or ‘Power OFF’

[--FRU] Script returns the FRU (baseboard, riser,

frontpanel, backplane, powersupply, sas, ocp,

phi) information of the inquired system(s).

[--CPU] Script returns the CPU information of the inquired

system(s).

[--MEM] Script returns the memory information of the

inquired system(s).

[--SENSOR] Script returns the SENSOR information of the

inquired system(s).

[--NETWORK] Script returns the NETWORK (firmware version,

device id, etc) information of the inquired

system(s).

To ensure successful retrieval of information,

users have to enable RSD mode and reset the

managed server after enabling the RSD mode.

Only BMC LAN channel 3 is supported.

[--STORAGE] Script returns the STORAGE (connector type,

storage capacity, firmware version) information of

the inquired system(s).

To ensure successful retrieval of information,

users have to enable RSD mode and reset the

managed server after enabling the RSD mode.

Only BMC LAN channel 3 is supported.


[--baseboard] Script returns the FRU (only baseboard)

information of the inquired system(s).

[--riser] Script returns the FRU (only riser) information of


[--frontpanel] Script returns the FRU (only frontpanel)


[--backplane] Script returns the FRU (only backplane)


[--powersupply] Script returns the FRU (only powersupply)


[--sas] Script returns the FRU (only sas) information of


[--ocp] Script returns the FRU (only ocp) information of


[--phi] Script returns the FRU (only phi) information of


Examples of Usage:

python ism_sysinformation.pyc -x ism_config.xml --NOW -i 192.168.1.15 --SDR

python ism _sysinformation.pyc --NOW -i 192.168.1.15 --InfoALL

python ism _sysinformation.pyc --RunAtTime -g IBSERVERS --RMM

python ism _sysinformation.pyc --RunAtTime --ALL --BMC

python ism _sysinformation.pyc -x ism_config.xml --NOW -g OOBSERVERS --POWER

4.12 Monitor System Health

The execution of this script checks and displays the health status of the referred systems. The

time to execute is controlled by “NOW” and “RunAtTime”. By default, the script checks for

BMC system health status to determine if System Event Log (SEL) will be collected. User is


given the option SAVE to retrieve the SEL regardless of the system health status. However,

for in-band managed servers, the SEL would always be retrieved if the system has been

rebooted.

Shell Command:

python ism_monitoring.pyc [-x xml config filename] {--NOW | --RunAtTime | --LOOP

} {--ALL | –i IP address | -g groupname} { --BMC | --RAID} {--SAVE | --SKIP}






will be used.



argument has to be used exclusively; script will

accept only one per instance.

[--RunAtTime]





time. This argument and the [--NOW or --LOOP]






[--LOOP]


repetitive mode.



week





with SSH logon credential stored in database;

alternatively, they may be accessed via BMC LAN

for queries if they are out-of-band servers which

could be connected with BMC logon credentials

stored in the database.



of servers in the IMSM database are required for

querying the system information, use the [–g


[-g groupname] A valid groupname previously added in the IMSM

database, with at least one server associated with

the group.

[--BMC] When this flag is provided, the script will not check

for the RAID contribution to health. The script will

check the BMC Status LED and will return the state

of inquired system(s).

This argument and the --RAID argument are

optional; if both are not provided, the script will

check both BMC and RAID contribution to health.

Example A:

BMC Health Status :Critical (04)

Get SEL Log :Successful

Log at:/usr/local/ism/Logfiles/172.21.133.36/selLog.txt

System Events occurred since Last Healthy Time:

Critical :0

Warning :416

Informational :3032

[--RAID] When this flag is provided, the script will not check

for the BMC contribution to health. The script will

check the RAID log and return the overall disk

health report of inquired system(s).


This argument and --BMC argument are


check both BMC and RAID contribution to health.

Example A:

RAID Health Status :Healthy

Get RAID Log :Successful

Log at:/usr/local/ism/Logfiles/172.21.133.36/raidLog.txt

Example B:

RAID Health Status :Unhealthy

Get RAID Log :Successful

Log at:/usr/local/ism/Logfiles/172.21.133.36/raidLog.txt

RAID Events detected:

Failed :0

Critical :0

Offline :2

Degraded :0

[--SAVE] When this flag is provided, the script will save a

copy of current total SEL in log file folder

regardless of system health state.

This argument and the --SKIP argument are


run the default way, where SEL log is only

collected when bmc system LED indicates an

unhealthy state.

[--SKIP] When this flag is provided, the script will never

save a copy of current total SEL log in log file

folder regardless of system health state.

This argument and the --SAVE argument are


run the default way, where sel log is only collected

when bmc system LED indicates an unhealthy

state.

Examples of Usage:

python ism_monitoring.pyc -i 192.168.1.15 --NOW

python ism_monitoring.pyc -i 192.168.1.15 --NOW --SAVE

python ism_monitoring.pyc -i 192.168.1.15 --NOW --SKIP

python ism_monitoring.pyc -x ism_config1.xml -g INBAND --RunAtTime


python ism_monitoring.pyc --ALL --NOW --BMC

python ism_monitoring.pyc --ALL --NOW --RAID

4.13 Performance Data Inquiry

The execution of the script checks and displays the performance data of the referred system.

The performance data is defined as the readings of the system’s power supply sensors and

temperature sensors. The sensor must be listed in the script-specific configuration file

ism_sensorconfig.xml.

Shell Command:

python ism_getperformance.pyc [-x xml config filename] {--NOW | --RunAtTime | --

LOOP} {--ALL | -i IP address | -g groupname} {--POWER | --THERMAL}






will be used.





[--RunAtTime]





time. This argument and the [--NOW or --LOOP]







[--LOOP]


repetitive mode.



week




with SSH logon credential stored in the database;

alternatively, they may be accessed via BMC LAN

for queries if they are out-of-band servers that

could be connected with BMC logon credential

stored in database.



of servers in IMSM database are required for

querying the system information, use [–g




the group.

[--POWER] When this flag is provided, the script will check the

reading of power sensors of inquired system(s)

stated in [--ALL] or [–i IP address] or [-g

groupname], and print the readings.

This argument and --THERMAL argument are

optional; if both are not provided, script will

check sensors from both categories.

[--THERMAL] When this flag is provided, the script will check the

reading of temperature sensors of inquired

system(s), and print the readings.

This argument and --POWER argument are


check sensors from both categories.


Examples of Usage:

python ism_getperformance.pyc -i 192.168.1.15 --NOW

python ism_getperformance.pyc -x ism_config1.xml -g INBAND --RunAtTime

python ism_getperformance.pyc --ALL –NOW --THERMAL

python ism_getperformance.pyc --ALL –NOW --POWER

4.14 BMC Configuration

The execution of this script updates the BMC configuration of the managed servers to settings

written in ism_bmcconfig.xml. The features that it can be configured through this script are

Lan Fail Over, Serial Over Lan, Set BMC IP, Set BMC User and Set SNMP alert.

Shell Command

python ism_bmcconfig.pyc [-x xml config filename] [--ALL | –i IP address | -g

groupname] [-b username/password] [-l LAN1|LAN2|LAN3] [--nextboot=<bootdev>] [--

persistent] [--force] [--verbose]






will be used.


database will be accessed for bmc configuration.



of servers in the IMSM database are required for

bmc configuration, use [–g groupname] argument

option. This [-i IP address] is only meant for


previously in the IMSM database.

[-g groupname] A valid groupname previously added to IMSM


the group.


[-b username/password] A pair of BMC user and password needed by bmc

configuration to add new bmc user.

This argument could be omitted if no value

assigned to <BMC_User_Account> in

ism_bmcconfig.xml as no new user will be added

to bmc configuration

[-l LAN1|LAN2|LAN3] IPMI lan channel for use to setup the BMC lan

channel settings.

This argument is optional; if not provided,

script will assume LAN1 for the setup.

[--nextboot=<bootdev>] Change next boot device. Supported Inputs are:-

pxe : Force PXE boot

disk : Force boot from default Hard-drive

cdrom : Force boot from CD/DVD

bios : Force boot into BIOS Setup

floppy: Force boot from Floppy/primary

removable media

efi: Force boot from the efi shell

[--persistent]

[--force]

Boot from the previously set boot option always.

Will always program new bmc ip to the LAN even

though the LAN BMC IP is not default 0.0.0.0

[--verbose]

Displays all execution details. If not provided,


Examples of Usage:

python ism_bmcconfig.pyc -i 192.168.1.15

python ism_bmcconfig.pyc -g Inband

python ism_bmcconfig.pyc -i 192.168.1.15 -l LAN1

python ism_bmcconfig.pyc -g Inband

python ism_bmcconfig.pyc -g Inband -b ISMUser/ISMPassword

python ism_bmcconfig.pyc --ALL -b ISMUser/ISMPassword


python ism_bmcconfig.pyc -g Inband -b ISMUser/ISMPassword --nextboot=disk --persistent

4.15 RAID Configuration

IMSM provides you with a convenient interface for RAID configuration that can be re-applied

to a group of managed servers with similar RAID hardware setup. Currently, only LSI

MegaRAID*, Intel® Integrated RAID modules, and Intel® ESRT2 (LSI*) controller are

supported. Intel® RSTe software RAID is not supported.

When multiple RAID controllers are available in the server system, script will show a list of all

available RAID cards. The user may choose the detected RAID controllers display on console

to proceed in setting up a new RAID array. Script will display the available physical hard disks

which is at “Unconfigured Good” status or still have remaining disk space to assist user in

RAID array setup.

Note: Do clear the old RAID configuration to make the disks status as Unconfigured Good if

script unable to find any available physical hard disks that could be used to start setup a new

RAID array.

You can make use the [–-RUN] flag with this script to clear configuration as well.

For example, prepare ism_raid.lst with below command line entry to clear v1 RAID array from

controller c0.

storcli64 /c0/v1 delete

Caution: Verify on your own if you have an Operating System installed on a RAID array and

make sure you will not erase the wrong volume during clear RAID configuration.

Current IMS RAID configuration only support RAID Level 0, 1 and 5. For RAID Level 1, it

requires at least two hardware drives. For RAID Level 5, it requires at least 3 hardware drives

in a server system. If the controller does not support the chosen RAID Level, IMSM will return

you with a error message and you will need to rerun the script again. Current version of IMS

will use majority of default ‘storcli’ utility values for the controller to complete the selected

RAID configuration.

Use [--SIM] flag to prepare a useful ism_raid.lst input file so it can be applied to a group of

managed servers with similar RAID hardware setup. Use [--RUN] flag to load all the

commands in ism_raid.lst on another server or group of servers. Users can modify the

ism_raid.lst offline to add more commands before apply it with [--RUN] flag.

Shell Command:

python ism_raid.pyc [-x xml config filename] {--ALL | –i IP address | -g groupname} {

--SIM | --RUN} {--NOW | --RunAtTime}







will be used.

[--NOW] Execute the script at current system time.

This argument is optional; if this argument and

[--RunAtTime] are not provided, script will

execute at the current system time. This

argument and the [--RunAtTime] argument

has to be used exclusively; script will accept

only one per instance.

[--RunAtTime] Execute the script at user’s set time. This option

requires user to enter timer’s duration.

This argument is optional; if this argument and

[--NOW] are not provided, script will execute at

the current system time. This argument and the

[--NOW] argument has to be used

exclusively; script will accept only one per

instance.




[--ALL] When this flag is provided, all in-band servers

(with RAID Controllers enabled) in IMS database

will be accessed via SSH for RAID configuration.

Note: RAID configuration feature is only

applicable to in-band servers stored in IMS

database.


database for a server during discovery.

Always use this argument instead of [-g

groupname] or [--ALL] when utilizing this script to

generate inputfile ism_raid.lst. Refer [--SIM]


argument flag usage.



the group.

[--SIM] When this flag is provided, the script will assist

user to simulate RAID configuration on the

Managed Server stated in [-i IP address] and

generate a command list input file ism_raid.lst

upon successfully executed commands.

This argument can be used together with [--

RUN] argument; script will apply the raid

configuration on the Managed Server while input

file ism_raid.lst is created.

[--RUN] When this flag is provided, the script will execute

each command line listed in the input file

ism_raid.lst.

Caution: Use this flag carefully with the correct [-

g groupname] argument to include only the

correct group of Managed Servers that have exact

similar RAID drives/array hardware configuration

to avoid failure while execution of all command

lines listed in the inputfile ism_raid.lst.

Ensure you have at least prepare a ism_raid.lst

manually or have one generated from running this

script with [--SIM] argument previously.

Note:

Intel® RST or Intel® RSTe RAID are not supported by IMSM.

Examples of Usage:

python ism_raid.pyc -i 192.168.1.15 --SIM

python ism_raid.pyc -i 192.168.1.15 --SIM --RUN

python ism_raid.pyc -x ism_config1.xml -g INBAND --RunAtTime --RUN

python ism_raid.pyc --ALL –-RUN

python ism_raid.pyc -i 128.101.1.30 --RUN


4.16 Chassis Identification

The execution of this script turns on or turns off the Chassis Identification LED light for the

purpose of tracking the physical server. With [--ON] argument provided, the LED stays on

permanently until a [--OFF] argument is sent from Management Server, user may use [-t]

argument to control the LED stay-on interval. If --ON, --OFF or -t is not provided, the script

runs with -t 15 which turns on the LED for an interval of 15 seconds.

Shell Command:

python ism_identify.pyc [-x xml config filename] {--ALL | –i IP address | -g

groupname} {--ON | --OFF | -t interval} {--RunAtTime} [--verbose]






will be used.



This argument is optional; if this argument is

not provided, script will execute at the current

system time.





database which has a IPMI logon credentials

stored will be accessed via IPMI channel session

for setting the chassis identify LED status

accordingly.

[-i IP address] A valid IP address which is a IPMI lan IP address

in IMSM database or its associated network IP

address which is host IP address in IMSM

database.




the group. Server that belongs to this groupname

and has a IPMI logon credentials stored in IMSM

database will be applied with the chassis identify

setting.

[--ON] When this flag is provided, the script will turn on

the chassis identify LED permanently on Managed

Server stated in [-i IP address] or [-g groupname]

or [--ALL].

This argument and [--OFF] or [-t interval]



[--OFF] When this flag is provided, the script will turn off

the chassis identify LED permanently on Managed


or [--ALL].

This argument and [--ON] or [-t interval]



[-t interval] When this flag is provided, the script will turn on

the chassis identify LED for an interval of t

seconds on Managed Server stated in [-i IP

address] or [-g groupname] or [--ALL].

This argument and [--ON] or [--OFF]





Examples of Usage:

python ism_identify.pyc -i 192.168.1.30 --ON

python ism_identify.pyc --ALL --OFF --RunAtTime

python ism_ identify.pyc -g OB --OFF -x ism_config2.xml

python ism_ identify.pyc -i 192.168.1.30 -t 30 --NOW


4.17 Power Setting Action The execution of this script sets a power action on managed servers via ipmitool command.

Power setting actions including turn on [--ON], turn off [--OFF], a hard reset on chassis

intrusion sensor [--RESET], and cold shutdown [--COLD]. This feature currently does not

execute graceful or clean shutdowns when sending over power off/shutdown/reset command

to the systems running on operating systems.

Shell Command:

python ism_power.pyc [-x xml config filename] {--ALL | –i IP address | -g groupname}

{ --ON | --OFF | --RESET | --COLD} {--RunAtTime} [--verbose]






will be used.





system time.





database which has a IPMI logon credentials

stored will be accessed via IPMI channel session

for setting the chassis power action accordingly.

[-i IP address] A valid IP address which is a IPMI lan IP address

in IMSM database or its associated network IP

address which is host IP address in IMSM


database.



the group. Server belongs to this groupname and

has a IPMI logon credentials stored in IMSM

database will be applied with the chassis power

action.

[--ON] When this flag is provided, the script will power up

the Managed Server stated in [-i IP address] or [

-g groupname] or [--ALL].

This argument and [--OFF], [--RESET] and [-

-COLD] argument has to be used exclusively;

script will only accept either one per instance.

[--OFF] When this flag is provided, the script will power

down chassis to soft S4/S5 state for Managed


or [--ALL].

This argument and [--ON], [--RESET] and [-

-COLD] argument has to be used exclusively;


Caution: This command does not initiate a clean

shutdown of the operating system prior to

powering down the system.

[--RESET] When this flag is provided, the script will perform

a hard reset on the chassis for Managed Server

stated in [-i IP address] or [-g groupname] or [--

ALL].

This argument and [--ON], [--OFF] and [--

COLD] argument has to be used exclusively;



reboot of the operating system prior to system

reset.


[--COLD] When this flag is provided, the script will provide

a power off interval of at least 1 second for

Managed Server stated in [-i IP address] or [-g

groupname] or [--ALL].

Note: No action should occur if chassis power is in

S4/S5 state.

This argument and [--ON], [--OFF] and [--

RESET] argument has to be used exclusively;



shutdown of the operating system prior to

powering down the system.



Examples of Usage:

python ism_power.pyc -i 192.168.1.30 --ON

python ism_power.pyc --ALL --OFF --NOW

python ism_ power.pyc -g OB --RESET -x ism_config2.xml --RunAtTime

python ism_ power.pyc -i 192.168.1.30 --COLD

4.18 System Firmware Update This section explains the system firmware update applied to those managed servers which

could be connected via in-band connectivity only. For purely out-of-band managed servers in

the IMSM database, refer to Section 4.19 System Firmware Update (OOB) or Section 5

Firmware Update via PXE.

The execution of this script updates the firmware of managed Intel® Server Systems to new

versions available in ism_fwPackage. Firmwares which can be updated using this script are

BIOS, ME, BMC, and SDR. User can either update one of them using their respective

argument, or update all using the argument [--UPDATEALL]. The System Firmware Update

Package (SFUP) must be located at the path specified in ism_config.xml where parameter is

<ism_fwPkgLocation>. The script will check the existence of SFUP on local management

server at the path specified in <ism_fwPkgLocation>. If the --netshare option is used, the

script will SSH to managed systems then only check the existence of SFUP on the network

share path specified in <ism_fwPkgLocation> on the managed servers.

Notes: This script will create a local temporarily folder “/var/tmp/” on managed server to


store SFUP. This temporary folder will be removed after system firmware update.

Shell Command:

python ism_updsysfw.pyc [-x xml config filename] [--ALL | –i IP address | -g

groupname] [--UPDATEALL | --BIOS | --ME | --BMC | -- SDR] [--NAC] [--CFG] [--

RunAtTime] [--netshare]






will be used.


database will be accessed via SSH for system

firmware update.


database during discovery. If a group of servers in

IMSM database are required for system firmware

update, use [-g groupname] argument option.

This [-i IP address] is only meant for





the group.

[--UPDATEALL] System firmware update includes BIOS, BMC, ME

and SDR.

To update system firmware, user needs to get

System Firmware Update Package for their Intel®

System Servers and unzip it into ism_fwPackage

folder. If different path is used, user needs to edit


parameter <ism_fwPkgLocation> in

ism_config.xml main configuration file.

User needs to modify the ism_config.xml for the

SFUP folder name according the Product name of

Intel® Server systems or Boards they use. Refer

to Table 10 Configuration Parameters of

“ism_config.xml” for more information

regarding IMSM general configuration file.

[--BIOS] Update system BIOS. May update Flash Descriptor

firmware too depending on the server platforms.

[--ME] Update system ME only.

[--BMC] Update system BMC only.

[--SDR] Update system SDR only. It will run Auto-SDR by

default.

[--NAC] Update system SDR via the legacy method. Needs

to be used with [--SDR] flag.

[--CFG] Update system SDR using using the inputs from

“sdrinputs.cfg” to supply the answers for the

interactive questions. User needs to know the

answer for each interactive prompt and write it in

sdrinputs.cfg. Different platform products may

have different sdr prompt questions, so user

needs to have different sdrinputs in all the SFUP

package folder.

Example of contents in sdrinputs.cfg:

1

y

4

y

y


y

y

y





system time.




[--netshare] Provide this flag if the Intel® firmware packages

(SFUP) are located at a network shared path.

ism_updsysfw will copy the firmware packages

from network share path to local path at managed

server and perform the firmware update. It will

remove the firmware package after the update.

Examples of Usage:

python ism_updsysfw.pyc -i 192.168.1.15 --UPDATEALL

python ism_updsysfw.pyc -i 192.168.1.15 --UPDATEALL

python ism_updsysfw.pyc -g groupname --BIOS

python ism_updsysfw.pyc -g groupname --SDR --CFG

python ism_updsysfw.pyc -i 192.168.1.10 --SDR

python ism_updsysfw.pyc --ALL --BMC

4.19 System Firmware Update (OOB) This section explains the system firmware update applied to those managed servers which

could be connected via out-of-band(OOB) connectivity only. For purely in-band managed

servers in the IMSM database, refer to Section 4.18 System Firmware Update.

Note: For each host (managed server), only 1 OOB NIC is allowed to be connected within the

group. OOB system firmware update will be failed if 1 host has more than 1 OOB NIC

connected within the group.

The execution of this script updates the firmware of managed Intel® Server Systems to new


versions available in ism_fwPackage. This script updates BIOS, ME, BMC, and SDR.

Individual firmware update is not allowed. For individual firmware update on OOB-managed

servers, refer to Section 4.23 Custom Deploy. The uEFI System Update Package (SUP)

must be located at the path specified in ism_config.xml where parameter is

<ism_fwPkgLocation>. The script will check the existence of SUP on local management server

at the path specified in <ism_fwPkgLocation>.

Shell Command:

python ism_updsysfw_OOB.pyc [-x xml config filename] [--ALL | –i IP address | -g

groupname] [--RunAtTime] [--softreset] [--verbose] [--no_user_interaction]






will be used.

[--ALL] When this flag is provided, all OOB managed-

servers in IMSM database will be updated.



IMSM database are required for system firmware

update, use [-g groupname] argument option.

This [-i IP address] is only meant for





the group.





system time.





[--softreset] Performs graceful reset on the managed

server(s).



[--no_user_interaction] Runs script without requiring user interactions.

Examples of Usage:

python ism_updsysfw_OOB.pyc -i 192.168.1.15

python ism_updsysfw_OOB.pyc -i 192.168.1.15 --verbose --softreset

python ism_updsysfw_OOB.pyc -g groupname

python ism_updsysfw_OOB.pyc -g groupname --softreset

python ism_updsysfw_OOB.pyc -i 192.168.1.10 --RunAtTime

python ism_updsysfw_OOB.pyc --ALL

4.20 Cleanup

Use this script to uninstall the previously installed IMSM client-package (including IMSM

installed NRPE plugins) performed by provisioning script from a single or group of managed

servers or all managed servers. This script is intended to do a cleanup on managed servers

whenever users wish to discontinue the use of IMSM and need to restore management server

and managed servers before performing the final rpm uninstallation step.

On system which was previously installed with Intel® SNMP Subagent during provision script

run, cleanup script will also work to uninstall the package. If Intel® SNMP Subagent is

preferred not to be uninstalled by cleanup script, user has to modify the main configuration

file’s alertserver_ip parameter value to default empty (refer Section 3.1).

This script can help to remove all Nagios* configuration files added by IMSM during

provisioning and unload these added ISMT Nagios* configuration files from Nagios* main

configuration file <nagios_install_path>/etc/nagios.cfg.

<nagios_install_path>/etc/objects/ism-inbands.cfg

<nagios_install_path>/etc/objects/ism-outbands.cfg

<nagios_install_path>/etc/objects/ismcommands.cfg


To remove the abovementioned configuration files and Nagios* Plugins that were installed

during provisioning from Management server, user will need to run this script with --ALL or

[-i 127.0.0.1] option flags.

Shell Command:

python ism_cleanup.pyc [-x xml config filename] {--ALL | –i IP address | -g

groupname} [--netshare]






will be used.


database will be accessed via SSH for cleanup if

they are in-band servers. For out-of-band servers

in the IMSM database, cleanup will only be limited

to removing the Nagios* configuration files

previously added by IMSM provisioning.



IMSM database are required for cleanup, use [-g

groupname] argument option. This [-i IP address]

is only meant for representation of a single server

which was added previously in IMSM database.

In addition, specifying IP address value of

127.0.0.1 is supported in this script exclusively.

This will instruct the script to cleanup/restore

Management Server from any IMSM-added files

during provisioning script execution.



the group.

[--netshare] Provide this flag if the software utilities binaries

for Intel® Server systems are to be uninstalled


from network shared path specified from

directive <ismSetupLocation> in ism_config.xml.

Examples of Usage:

python ism_cleanup.pyc -i 192.168.1.15

python ism_cleanup.pyc -x ism_confignew.xml -i 192.168.1.15

python ism_cleanup.pyc -g IBSERVER --netshare

python ism_cleanup.pyc -g OBSERVER

python ism_cleanup.pyc -i 127.0.0.1

4.21 Get BMC Debug Log This script generates an encrypted zip file (debuglog.zip) that contains the debug

information of a managed server which is useful to the system manufacturer for problem

resolution. The information collected includes Baseboard Management Controller (BMC)

status, BMC configuration settings, BMC Sensor readings, Power supply data, System Event

Log, sensor readings, SMBIOS tables, CPU machine check registers and PCI configuration

space information.

This log file should be sent to the system manufacturer for analysis.

Shell Command:

python ism_bmcdebuglog.pyc [-x xml config filename] [-i IP address] [--force] [--

verbose]






will be used.


database during discovery.

[--force] Force exit the BMC debug log transfer mode

before proceeding with the debug log retrieval. If

not provided, this script exits if the BMC is already

in the debug log transfer mode.




Examples of Usage:

python ism_bmcdebuglog.pyc -i 192.168.1.15

python ism_bmcdebuglog.pyc -x ism_confignew.xml -i 192.168.1.15

python ism_bmcdebuglog.pyc -i 192.168.1.15 --verbose --force

4.22 Compare Hardware Configurations This script compares system hardware configuration of managed servers with Gold

configuration (reference_checksysconsistency.ini). Gold configuration contains

hardware configurations information of a single IP (Gold server). The configuration

differences between a Gold server and managed servers will be listed in the result table according to their respective sections.

It is recommended to compare a Gold server and managed servers of the same platform

type. For example, comparing a Gold server (S2600KP) with a managed server (S2600KP).

Note:

a) This script runs on OOB-managed servers only.

b) Users have the option to omit comparing items in reference_checksysconsistency.ini by

listing these items in exempt_checksysconsistency.ini at /usr/local/ism/ism_scripts. In

the example below, voltage of [CPU: CPU1], board mfg of [FRU: Baseboard] and all items of [MEM:DIMM_A1] will not be taken into account during the comparison process.

Example:

[CPU: CPU1]

voltage

[FRU: Baseboard]

board mfg

[MEM: DIMM_A1]

*

Shell Command:

python ism_checksysconsistency.pyc [-x xml config filename] {--ALL | -i IP address |

-g groupname} [--GOLDINI] [--verbose]







will be used.



IMSM database are required for this operation,

use [-g groupname] argument option. This [-i IP

address] is only meant for representation of a

single server which was added previously in IMSM

database.



the group.


servers in IMSM database will be compared with

the Gold server.

[--GOLDINI] Generates Gold configuration of a managed

server. Can only be used with [-i IP address] flag.



Examples of Usage:

python ism_checksysconsistency.pyc -i 192.168.1.15 --GOLDINI

python ism_checksysconsistency.pyc -x ism_confignew.xml -i 192.168.1.15

python ism_checksysconsistency.pyc -i 192.168.1.15 --verbose

python ism_checksysconsistency.pyc -g groupname --verbose

python ism_checksysconsistency.pyc --ALL

4.23 Custom Deploy This script runs custom deploy script (deploy.nsh) on managed servers through EFI.

User will need to create their own customized deploy.nsh script and update the folder path


according to their respective server platform in the IMSM general configuration file (e.g.

ism_config.xml). The script will reboot the managed servers and clear their respective EFI

mailbox.

Note:

1) This script runs on OOB-managed servers only.

2) For RHEL6.8 management server, thread count is set to 1 regardless of the thread count

value set in the IMSM general configuration file.

Shell Command:

python ism_customdeploy_OOB.pyc [-x xml config filename] {--ALL | -i IP address | -

g groupname} [-p "parameter(s)"] [--softreset] [--RunAtTime] [--verbose] [--

no_user_interaction]






will be used.



IMSM database are required for this operation,

use [-g groupname] argument option. This [-i IP

address] is only meant for representation of a

single server which was added previously in IMSM

database.



the group.


servers in IMSM database will be involved in the

custom deploy operation.

[-p "parameter(s)"] When parameter is provided, it will be passed as

argument(s) to deploy.nsh. Enclose the parameter(s) with double quotes, “”.

Users can use the following files

(deploy_result.log & deploy_details.log) for


output redirection:

deploy_result.log – the output from deploy.nsh

can be redirected to this filename; the file will be

saved to Logfiles/ip folder and content will be

displayed to terminal after custom_deploy script with extra argument(s) is executed.

Example:

In deploy.nsh, to redirect the output of the

operation to deploy_result.log, add “>>deploy_result.log”:

echo %1 >> deploy_result.log

where %1 is the first parameter provided with –p

flag.

The output in deploy_result.log will be displayed on the Terminal.

deploy_details.log – the output from deploy.nsh

can be redirected to this filename; the file will be

saved to Logfiles/ip folder after custom_deploy

script with extra argument(s) is executed.

Example:

In deploy.nsh, to redirect the output of the

operation to deploy_result.log, add “>>deploy_details.log”:

echo %1 >> deploy_details.log

where %1 is the first parameter provided with –p flag.

[--softreset] Performs graceful reset on the managed

server(s).





system time.







[--no_user_interaction] Runs script without requiring user interactions.

Examples of Usage:

python ism_customdeploy_OOB.pyc -i 192.168.1.15

python ism_customdeploy_OOB.pyc -x ism_confignew.xml -g groupname

python ism_customdeploy_OOB.pyc -i 192.168.1.15 --verbose --softreset

python ism_customdeploy_OOB.pyc -g groupname -p “-X -Y” --verbose

python ism_customdeploy_OOB.pyc --ALL --RunAtTime

5 Troubleshooting Tips

This section lists the possible errors you may encounter during the use of this product, and

workarounds to address the errors.

5.1 IMSM Installation 1. Error: You may encounter the error, “/lib/ld-linux.so.2: bad ELF interpreter” during

IMSM installation.

Workaround: Install 32-bit glibc library.

5.2 Discovery

1. Error: You may encounter this error on a RHEL 6.8 Management Server when running

the Discovery script (Section 4.9).


Workaround: Remove the pre-installed python-crypto package by running the

command “yum remove python-crypto”. Reinstall ECDSA and Paramiko packages again.

These packages can be found in the open_source folder provided together with the

product.

2. Error: You may encounter the following error when running the Discovery script

(Section 4.9). Notice that the table is empty.

Workaround: Run Discovery with the --verbose argument to display all errors.

(Example: python ism_discover.pyc -i 128.101.1.43 -b test1/test1 -a GroupA --

verbose). Refer to Section 4.9 for more information on running the Discovery script.

5.3 System Information Inquiry

1. Error: If you encounter the following error upon running System Information Inquiry

(Section 4.11) on an out-of-band managed server, it is possible that the password

provided for the server is incorrect.

Workaround: Change the password for the out-of-band managed server and run

ism_discover.pyc (Section 4.9) on the server with the new password.

2. Error: If you encounter the following error upon running System Information Inquiry

(Section 4.11) on an out-of-band managed server, it is possible that “Force HTTPS” is


enabled. “Force HTTPS” is currently not supported on server boards S2600WT, S2600KP,

S2600TP, S2600CW, S1200SP and S7200AP families.

Workaround: Uncheck “Force HTTPS”.


5.4 Monitor System Health

1. Error: If you encounter the following error upon running Monitor System Health





5.5 Performance Data Inquiry

1. Error: If you encounter the following error upon running Performance Data Inquiry





5.6 System Firmware Update

1. Error: You will encounter the following error if the firmware packages listed in the IMSM

General Configuration File (default: ism_config.xml) are not found in

/usr/local/ism/ism_fwPackage/ when you run the firmware update.

Workaround: Place the required firmware packages in the ism_fwPackage directory.

Refer to Section 3.1, General Configuration File, for more details.

2. Error: You will encounter the following error if the parameter for the firmware package

name is not found in the IMSM General Configuration File. Example: You want to update

S2600WT server but no required parameter in ism_config.xml.


Workaround: Add the required parameter in ism_config.xml. Refer to Section 3.1,

General Configuration File, for more details.

5.7 System Firmware Update OOB 1. Error: You will encounter the following error on a SLES11.4 management server if you

are using the default openssl and wget libraries.

Workaround:

a) Download openssl source code 1.0.1t - https://www.openssl.org/source/old/1.0.1/

b) Remove existing openssl:

rpm -ev --nodeps openssl

c) Configure and build:

tar -xvf openssl-1.0.1t.tar.gz

cd openssl-1.0.1t

./config shared --prefix=/usr --openssldir=/etc/ssl --libdir=/lib

make && make install

d) Download wget source code - wget http://ftp.gnu.org/gnu/wget/wget-1.15.tar.gz

e) Remove existing wget:

rpm -ev --nodeps wget

f) Configure and build:

tar -xvf wget-1.15.tar.gz

cd wget-1.15

./configure --prefix=/usr --sysconfdir=/etc --with-ssl=openssl


https://www.openssl.org/source/old/1.0.1/

http://ftp.gnu.org/gnu/wget/wget-1.15.tar.gz



5.8 Custom Deploy

1. Error: You will encounter the following error on a SLES11.4 management server if you

are using the default openssl and wget libraries.

Workaround:

g) Download openssl source code 1.0.1t - https://www.openssl.org/source/old/1.0.1/

h) Remove existing openssl:

rpm -ev --nodeps openssl

i) Configure and build:

tar -xvf openssl-1.0.1t.tar.gz

cd openssl-1.0.1t

./config shared --prefix=/usr --openssldir=/etc/ssl --libdir=/lib


j) Download wget source code - wget http://ftp.gnu.org/gnu/wget/wget-1.15.tar.gz

k) Remove existing wget:

rpm -ev --nodeps wget

l) Configure and build:

tar -xvf wget-1.15.tar.gz

cd wget-1.15

./configure --prefix=/usr --sysconfdir=/etc --with-ssl=openssl


5.9 Nagios Configuration

https://www.openssl.org/source/old/1.0.1/




1. Error: Status information of IMSM Services on Nagios webpage shows ‘socket timeout’

error.

Workaround:

a) On management server, increase the timeout period for running the NRPE command

by using the -t timeout_period flag. For example:

b) On managed server, increase the command timeout value in nrpe.cfg. For example:

2. Error: Status information of IMSM Services on Nagios webpage shows ‘service check

timed out’ error.

Workaround: Increase the service check timeout period in nagios.cfg by increasing the value. For example: