Page History

The primary interfaces used to access the 

Spacevars
0 product

are the Embedded Management Application (EMA) GUI, EMA in Platform Mode GUI, Command Line Interface (CLI) and BMC (Baseboard Management Controller) GUI and REpresentational State Transfer Configuration Application Processing Interface (

Spacevars
0 model1

).

EMA

The EMA provides a comprehensive method to provision, maintain and administer the

Spacevars
0 product

platform from any Web browser. This is the most frequently used access method. For more details, refer to the EMA User Guide.

For login details, 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 CLI.

Baseboard Management Controller

Include Page
_Not_for_SWe _Not_for_SWe

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

RESTCONF API

Spacevars
0 model1

s provide access to RESTCONF API which is a simple, stateless architecture style (not a protocol) that uses the HTTP/HTTPS method ( such as GET, PUT, POST, DELETE) to retrieve the management information from the database. The main advantage is its simple interfaces and can be modified while the application is running.

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:

  Spacevars
  0 model1

  uses open standards. Any language may be used to access the API ( C++, Java, etc. ) resources via URI paths.

To use a

Spacevars
0 model1

, your application makes HTTPs requests and parses the responses. Currently, the only supported response format is XML. The methods used by developers are standard HTTP methods such as GET, PUT, POST, PATCH and DELETE. 

For access details, refer to Accessing RESTCONF API.

SOAP 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
0 model3

application maps each SOAP request to the corresponding RESTCONF request towards the SBC. In network configurations where

Spacevars
0 model3

is deployed,

Spacevars
0 model3

is also used to configure SBC Core using SOAP API for SBC. This interface supports provisioning as well the operations exposed by the yang models. For details, refer to the

Spacevars
0 model3

document "SBC SOAP API reference".

For access details, refer to Accessing SOAP API.

RAMP SBC Configuration Manager

If your network includes the 

Spacevars
0 model3

platform, and the SBC is added as a managed node or is part of a managed cluster, you can access a web-based management interface from the EMS. The SBC Configuration Manager application provides GUI configuration and management options similar to what the EMA GUI provides. The SBC Configuration Manager is accessible under Node Management by navigating to the Node Inventory, Registration and Other Functions window (Network > Node Management > Function Manager) and selecting the Configure function for a node.  The SBC Configuration Manager is also accessible under Cluster Management by navigating to the Configurations tab for a cluster (Network > Cluster Management > Manage VNFs > Configurations) and clicking on the Edit Configure option. Refer to 

Spacevars
0 model3

 documentation to Ribbon Application Management Platform Documentation for more information on node and cluster management.

Info
title Note about SFTP
The SBC Core includes the utility /opt/sonus/bin/SbcSftp with permissions -rwsr-xr-x, which allows you to securely transfer files to a remote server using the Linux shell.  When executed, the program SbcSftp: Creates the necessary Access Control List (ACL) to allow the sftp connection from the SBC Linux shell to a remote server Uploads/Downloads specified files to/from the remote server over a SFTP session, if the user has permissions to access the file Deletes the ACL The advantage of using SbcSftp over standard sftp is that SbcSftp automatically creates and deletes ACLs for accessing the remote server. For details, refer to SbcSftp - Secure File Transfers with Automated ACL Creation and Deletion.

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:

1. As the user: RAMP passes the end-user's username' in user field.

2. 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
title Note
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).