Page History
Panel | ||||
---|---|---|---|---|
In this section:
|
The primary interfaces used to access the
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
EMA
The EMA provides an easy a comprehensive method to provision, maintain and administer the
Spacevars | ||
---|---|---|
|
For login details, see refer to Logging Into EMA.
EMA in Platform Mode
The EMA in Platform Mode provides current status of the platform, application software version information and system information. The EMA in Platform Mode is also used to start, stop and restart the application as well as reboot the host. The EMA in Platform Mode supports upgrading the operating system and application. Additional features include a web interface for generic troubleshooting activities, security and remote access management.
For more information, refer to Logging into EMA in Platform Mode.
Command Line Interface
Command Line Interface (CLI) is the traditional method to configure systems from any machine with network access using a secure shell (SSH) client terminal emulator).
For login details, refer to Logging Into the CLI.
Baseboard Management Controller
Include Page | ||||
---|---|---|---|---|
|
The Baseboard Management Controller (BMC) supports the following functions:
- View basic system information
- Change mouse mode
- Configure BMC and EMA in Platform Mode network settings
- Add, edit or remove users
- Configure NTP settings
- View or change SSL certificate
- Perform remote control settings
- Update BMC firmware and reboot BMC
- Switch to EMA in Platform Mode
- Integrated Lights Out Management (LOM)
For login details, refer to Logging Into the BMC Include Page
SOAP API
spacevars
0 | series4 |
---|
The SBC SOAP API supports the following requests for each managed object:
- CREATE – creates a managed object in the SBC.
- UPDATE – updates a managed object in the SBC.
- DELETE – deletes a managed object in the SBC.
- SHOW– retrieves managed object details from SBC.
- User defined operations – For example, manual switchover of the SBC.
The EMS application maps each SOAP request to the corresponding RESTCONF request towards the SBC. In network configurations where EMS is deployed, the EMS is also used to configure
Spacevars | ||
---|---|---|
|
For access details, refer to Accessing SOAP API.
RESTCONF API
Spacevars | ||
---|---|---|
|
RESTCONF has the following properties:
- Stateless: No client context is stored on the server. A request from the client will contain all the necessary information required to process the request.
Client-Server model: In a client-server model, clients are associated with the user interface, and the servers manage data storage behind the interface. This allows a separation between the client and server.
- Cacheable: Improvement in scalability and performance when the client caches responses.
- Language–independent:
uses open standards. Any language may be used to access the API ( C++, Java, etc. ) resources via URI paths.Spacevars 0 model1
To use a
Spacevars | ||
---|---|---|
|
For access details, refer to Accessing RESTCONF API.
Insight EMSSOAP API
SOAP APIs provide access to Simple Object Access (SOAP) API which is protocol specification used to exchange structured information in the implementation of web services. It uses XML information set for its message format, and usually relies on other application layer protocols, such as Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission. The advantage of using SOAP is that it is very versatile and uses different transport protocols. The standard stacks use HTTP as a transport protocol.
The SBC SOAP API supports the following requests for each managed object:
- CREATE – creates a managed object in the SBC.
- UPDATE – updates a managed object in the SBC.
- DELETE – deletes a managed object in the SBC.
- SHOW– retrieves managed object details from SBC.
- User defined operations – For example, manual switchover of the SBC.
The
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
For access details, refer to Accessing SOAP API.
RAMP SBC Configuration Manager
If your network includes the Insight EMS the
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Info | |
---|---|
|
|
| |
The SBC Core includes the utility When executed, the program
The advantage of using |
Single Sign-On for the SBC CNe and SBC SWe using RAMP
The SBC SWe and SBC CNe use a RAMP configured for CNe as the single point of authentication for the SBC when using the SBC RESTCONF API or the SBC CLI. This single sign-on feature applies when the SBC CLI and SBC RESTCONF APIs are proxied from RAMP to the SBC (without requiring any knowledge on RAMP of the semantics of the request).
The SBC is enhanced with the following capabilities:
- Accessing SBC's Confd CLI over SSH through RAMP.
- Accessing SBC's RESTCONF interface through RAMP.
Deployment for Single Sign-on through RAMP
In a deployment, end-users are authenticated and authorized by RAMP when they connect to the SBC. RAMP may interface with external identity providers for this purpose. After authentication, RAMP determines the usergroup that the user belongs to. RAMP passes on this user and usergroup information to the ConfD through the mechanisms mentioned below.
RAMP uses the existing 'emsadmin' user account to interface with the SBC. When the SBC registers with the RAMP, the LCA (Life Cycle Agent) on the SBC requests a password for the 'emsadmin' user account. The LCA updates this account on the SBC with the password generated and returned by RAMP in its response.
Accessing SBC's Confd CLI over SSH through RAMP
RAMP provides a web-based CLI terminal to the end-user. RAMP connects to the SBC's CLI port over the SSH, and proxy requests and responses from/to the end-user's web-based CLI terminal. RAMP connects to the SBC's CLI port as explained below:
- As the user: RAMP connects over the SSH to the SBC using the configured proxy admin user account (i.e proxyAdminUser and proxyCaleaUser) that the EMS uses to manage the SBC.
End-user's username and groupname will be passed as the ssh ‘command’: The end-user's username and the groupname of the enduser's group is passed as arguments to the ssh command exactly as shown in the example below:
Code Block ssh -t emsadmin@10.34.175.181 "alice admin"
Here, the first argument ('alice') represents the end-user's username. The last argument ('admin') represents the group to which the end-user belongs.
Accessing SBC's RESTCONF interface through RAMP
RAMP proxies the RESTCONF requests from the end-user over HTTPS, after substituting the end-user's credentials with a special set of credentials. RAMP connects to the SBC as shown below:
- As the user: RAMP passes the end-user's username' in user field.
With a special password: The space (' ') , proxy admin username and groupname is appended to the password field in the format shown below:
Code Block <space><ramp username>;<end-user's groupname>;<proxy admin user's password>
Here, semi-colons are used to separate the various fields of the password.
Info | ||
---|---|---|
| ||
When logging into the SBC as a proxied user, if a user with the same name exists on the SBC and if the local user group matches the RAMP passed-in user group, then the authentication is allowed to proceed. If the local user group does not match the RAMP passed-in user group, then the authentication is rejected. Please note that in this case, if the user's local password has expired, they are prompted to change it before proceeding. This means that a REST API request is rejected until the user changes it through the CLI / UI. This feature is only supported when the SBC is configured to use local authentication. It does not work when using external authentication (e.g. RADIUS, LDAP). |