cancel
Showing results for 
Search instead for 
Did you mean: 

Pulse Secure vADC

Sort by:
SteelApp includes some great tools for graphical analysis, and for drilling down into the details of individual transaction connections. But when you are trying to debug high-throughput production applications, the number of connections in the log history can make it very difficult to trace and identify critical transactions on the Activity > Connections GUI on the user interface.     Although you can use the “Filter” option to track down particular types of transaction, there is now a new way to include or exclude just the transactions you want to be stored in the connection history!   From SteelApp Traffic Manager 9.8, TrafficScript includes two new functions connection.getCompletionReasonCode() and connection.getCompletionReasonInfo() which are designed to be used in transaction completion rules to give information about why a transaction ended. For example, it might have completed normally, or it might have timed out, or there may even have been a client or server error.   By using these two functions to identify specific transaction faults, you can use recentconns.include() and recentconns.exclude() to save only the trace information for connections that encountered problems that need further analysis: these two functions allow close control of which transactions should be retained, which means that the Activity > Connections page will only show the transactions you specifically wanted to trace.   connection.getCompletionReasonCode() This function returns a single reason code for the transaction, which could include “COMPLETE” if the transaction was successful, or “TIMEOUT” or a number of other potential problems. Other reason codes include “NODE_LOST” and “BAD_REQUEST” – see the user documentation for a complete list. In the following example, we would trace all transactions which did not complete for any reason.   1 2 3 4 5 6 $reasonCode = connection.getCompletionReasonCode();       if ( $reasonCode != "COMPLETE" ) {        # Failed transaction        recentconns.include();  }    connection.getCompletionReasonInfo() However, there is a way of extracting even more detailed information about the completion: this function contains information about whether the transaction ended due to client error, or to server error and other, all encoded in a hash returned by the function:   Key Details code Reason (from connection.getCompletionReasonCode(); message A detailed message describing the reason code. Iserror 1 if the transaction ended due to an error. Isservererror 1 if the transaction ended due to a server error. Isclienterror 1 if the transaction ended due to a client error. Istimeout 1 if the transaction ended because it exceeding any timeout duration. isprocessingtimeout 1 if the transaction ended because it exceeded rule or optimization processing timeouts.   Using this detailed information, we can pick out particular types of failure in the Activity > Connections page. Alternatively, we could raise an external event or create a log record. In this example, instead of sending the transaction detail to the Activity > Connections display, we emit a log record with detailed information about this transaction, inserting the “code” and “message” into the log file:   1 2 3 4 5 6 7 8 $info = connection.getCompletionReasonInfo();       if ( $info [ 'iserror' ] ) {        log .info( "Transaction error detected. Code: " .                 $info [ 'code' ] . " Message: " .                 $info [ 'message' ]                 );  }    For more information on these new TrafficScript functions, as well as how to use with recentconns.include() and recentconns.exclude() to control capture of transaction information in functions in the Activity > Connections display, see the SteelApp TrafficScript Guide in the User Documentation.   The SteelApp Developer Edition allows you to use Riverbed SteelApp Traffic Manager completely free within your test and development environments to experiment with this and other TrafficScript features, and to support the applications that you're building before you put them into production.   Find out more - and download your free trial here.
View full article
SteelApp TrafficScript is a simple, yet powerful programming language, which gives you full control over applications, and is embedded right within the kernel of SteelApp Traffic Manager to run with the highest possible performance. And in SteelApp Traffic Manager 9.8 [URL], we have introduced a new switch() statement to help build complex rules which are easier to maintain and understand.   Let’s imagine you have an ecommerce application, which serves a number of different domains, and you have independent application nodes (resource pools) reserved for each domain. You want to inspect each request, and direct it to the nodes that are reserved for the desired domain. A simple way to do this would be to create a series of if/then statements:   $host = http.getHeader( “Host” ); if ( !$host ) break; if ( $host == “www.mystore.com”) { # Direct all requests for this host # to a pool reserved for this domain pool.use( “mybank” ); } else if ($host == “www.store-bbb.com”) { ... } else if ($host == “www.store-ccc.com”) { ... } else { # All other requests go to shared pool pool.use( “generic” ); }   TrafficScript now provides a "switch" statement for cases where one if-else expression can evaluate to a number of different values, each requiring Traffic Manager to take a different action. By checking the host value of the HTTP header, you can use the switch statement to select the correct host using a number of cases. The syntax for the switch statement is:   switch( [, ] ) { case : ; case : ; case : ; ... [default: ;] }   By default, the Traffic Manager executes the first case containing an expression that evaluates to be equal ("==") to the switch <expression>. There is also an optional default statement must only be used as the last case, and is always executed if no previous cases have been executed.   So using the switch() statement, our example now becomes:   $host = http.getHeader( “Host” ); switch( $host ) { case “www.mybank.com”: # Direct all requests for this host # to a pool reserved for this domain pool.use( “mybank” ); case “www.store-bbb.com”, “www.store-ccc.com”: pool.use( “store-bbb-ccc” ); default: # All other requests go to shared pool if ( $host ) { pool.use( “generic” ); } }   User-defined comparator function:   There is even an option to provide a user-defined comparator function for complex rules using the optional <function name> argument. This argument accepts the name of a user defined or built in function, declared without any brackets or arguments. The function must accept two arguments - each case statement will then be assessed by invoking the comparator function with the value being switched on as the first argument and the value in the case statement as the second. The function should evaluate to TRUE for a match in order to execute the corresponding case statement.   For example, to perform matches on regular expressions, we could set <function name> to the TrafficScript function "string.regexmatch". Then, for each case statement, you can specify either a single expression or a comma-separated list of multiple expressions to be used in the comparison. A case is executed if the evaluation function returns true for any of the case's expressions. In this case, the commas in the expression list act as the "or" logical operator.   In this example, we are selecting a resource pool depending on whether the host header starts with “secure” or “ssl” and discarding any other request which does not start with “www”   $host = http.getHostHeader(); switch( $host, string.startsWith ) { case "secure", "ssl": pool.use( "secure pool" ); case "www": pool.use( "non-secure pool ); default: pool.use( "discard" ); }   For more information on this new switch() statement, including use of the break keyword, see the SteelApp TrafficScript Guide in the User Documentation.   And our Developer Edition allows you to use Riverbed SteelApp Traffic Manager completely free within your test and development environments to experiment with this and other TrafficScript features, and to support the applications that you're building before you put them into production.   Find out more - and download your free trial here.
View full article
SAML is the Security Assertion Markup Language, used for example in Web Single Sign on scenarios. The current version 2.0 is specified at OASIS Open: SAML Specifications | SAML XML.org   SAML uses XML documents to transfer information, defined in assertion documents, protocol definitions and bindings how the protocol is transferred. The assertions and protocol is defined as XML Schema.   The protocol can be validated in SteelApp TrafficManager with the XML Schema validation as additional security measure for example to protect SAML Identity Providers (IdP).   This article explains a use case of validating SAML 2.0 for the HTTP POST binding, where the protocol is transferred as HTTP body, Base64 encoded. The rule checks an endpoint URL, where SAML validation should be performed and if the HTTP method is "POST".   Base64-encoded SAML request can be encoded and decoded for example with this online tool or with the offline tools "base64" on Linux systems. https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php   To test the SAML validation, "curl" can be used to post the encoded data&colon;   curl -X POST -H "Content-Type: text/plain" --data-binary "@SAML-example.txt" http://192.168.42.21/auth/test.php   Result of the validation can be observed in the STM event log.   xml.validate.xsd() returns the following test result:   1, then the validation is successful, the transfer is a well-formed and valid SAML protocol document 0, the document is not valid, containing illegal attributes but the document is well formed XML -1, the document is not well-formed (XML document errors)   # Validate HTTP POST body against the SAML Protocol schema # (c) Riverbed Technology GmbH, Juergen Luksch, # only run rule, if path is SAML endpoint $path = http.getPath(); if(!string.startsWithI($path, "/auth/")) break; # only POST binding supported in example if(http.getMethod() != "POST") break; #standard base64 encoded saml message decode: $samlAuth = string.base64decode(http.getBody(0)); $samlProtocolSchema = resource.get("saml-schema-protocol-2.0.xsd"); $result = xml.validate.xsd($samlAuth, $samlProtocolSchema); #log.info ("XML Validation: " . $result); if( $result != 1 ) { log.warn("XML Validation failed!"); # connection.discard(); # response with HTTP http.sendResponse("500 Server error", "text/plain", "XML Validation failed", ""); }   To be able to validate a SAML document, the XML schema definition (XSD) needs to be present on the STM in the extra files catalog. For the SAML protocol, there’s two schemas needed: saml-schema-protocol and saml-schema-assertion. These additionally import the XML signatures schema and XML encryption schema.   The schema documents can be downloaded from OASIS Open (Index of /security/saml/v2.0/) and the W3 consortium (http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd, http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd). As the imports refer to external resources in the original documents, the „schemaLocation=“ needs to be changed to the local file before uploading to STM.   When the document is checked and recognized as invalid, a HTTP error code could be returned or the connection discarded.   So, with downloading schemas, creating a XML validation rule and adding this rule to the virtual server, SAML protocol requests can be validated and actioned on.
View full article
  1. The Issue   When using perpetual licensing on a Traffic Manager, it is restricted to a throughput licensing limitation as per the license.  If this limitation is reached, traffic will be queued and in extreme situations, if the throughput reaches much higher than expected levels, some traffic could be dropped because of the limitation.   2. The Solution   Automatically increase the allocated bandwidth for the Traffic Manager!!   3. A Brief Overview of the Solution   An SSC holds the licensed bandwidth configuration for the Traffic Manager instance.   The Traffic Manager is configured to execute a script on an event being raised, the bwlimited event.   The script makes REST calls to the SSC in order to obtain and then increment if necessary, the Traffic Manager's bandwidth allocation.   I have written the script used here, to only increment if the resulting bandwidth allocation is 5Mbps or under, but this restriction could be removed if it's not required.  The idea behind this was to allow the Traffic Manager to increment it's allocation, but to only let it have a certain maximum amount of bandwidth from the SSC bandwidth "bucket".   4. The Solution in a Little More Detail   4.1. Move to an SSC Licensing Model   If you're currently running Traffic Managers with perpetual licenses, then you'll need to move from the perpetual licensing model to the SSC licensing model.  This effectively allows you to allocate bandwidth and features across multiple Traffic Managers within your estate.  The SSC has a "bucket" of bandwidth along with configured feature sets which can be allocated and distributed across the estate as required, allowing for right-sizing of instances, features and also allowing multi-tenant access to various instances as required throughout the organisation.   Instance Hosts and Instance resources are configured on the SSC, after which a Flexible License is uploaded on each of the Traffic Manager instances which you wish to be licensed by the SSC, and those instances "call home" to the SSC regularly in order to assess their licensing state and to obtain their feature set.   For more information on SSC, visit the Riverbed website pages covering this product, here - SteelCentral Services Controller for SteelApp Software.   There's also a Brochure attached to this article which covers the basics of the SSC.   4.2. Traffic Manager Configuration and a Bit of Bash Scripting!   The SSC has a REST API that can be accessed from external platforms able to send and receive REST calls.  This includes the Traffic Manager itself.   To carry out the automated bandwidth allocation increase on the Traffic Manager, we'll need to carry out the following;   a. Create a script which can be executed on the Traffic Manager, which will issue REST calls in order to change the SSC configuration for the instance in the event of a bandwidth limitation event firing. b. Upload the script to be used, on to the Traffic Manager. c. Create a new event and action on the Traffic Manager which will be initiated when the bandwidth limitation is hit, calling the script mentioned in point a above.   4.2.a. The Script to increment the Traffic Manager Bandwidth Allocation   This script, called  and attached, is shown below.   Script Function:   Obtain the Traffic Manager instance configuration from the SSC. Extract the current bandwidth allocation for the Traffic Manager instance from the information obtained. If the current bandwidth is less then 5Mbps, then increment the allocation by 1Mbps and issue the REST call to the SSC to make the changes to the instance configuration as required.  If the bandwidth is currently 5Mbps, then do nothing, as we've hit the limit for this particular Traffic Manager instance.   #!/bin/bash # # Bandwidth_Increment # ------------------- # Called on event: bwlimited # # Request the current instance information requested_instance_info=$(curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" \ -X GET -u admin:password https://ssc.example.com:8000/api/tmcm/1.1/instance/demo-1.example.com-00002) # Extract the current bandwidth figure for the instance current_instance_bandwidth=$(echo $requested_instance_info | sed -e 's/.*"bandwidth": \(\S*\).*/\1/g' | tr -d \,) # Add 1 to the original bandwidth figure, imposing a 5Mbps limitation on this instance bandwidth entry if [ $current_instance_bandwidth -lt 5 ] then new_instance_bandwidth=$(expr $current_instance_bandwidth + 1) # Set the instance bandwidth figure to the new bandwidth figure (original + 1) curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u adminuser:adminpassword -d \ '{"bandwidth":'"${new_instance_bandwidth}"'}' \ https://ssc.example.com:8000/api/tmcm/1.1/instance/demo-1.example.com-00002 fi   There are some obvious parts to the script that will need to be changed to fit your own environment.  The admin username and password in the REST calls and the SSC name, port and path used in the curl statements.  Hopefully from this you will be able to see just how easy the process is, and how the SSC can be manipulated to contain the configuration that you require.   This script can be considered a skeleton which you can use to carry out whatever configuration is required on the SSC for a particular Traffic Manager.  Events and actions can be set up on the Traffic Manager which can then be used to execute scripts which can access the SSC and make the changes necessary based on any logic you see fit.   4.2.b. Upload the Bash Scripts to be Used   On the Traffic Manager, upload the bash script that will be needed for the solution to work.  The scripts are uploaded in the Catalogs > Extra Files > Action Programs section of the Traffic Manager, and can then be referenced from the Actions when they are created later.   4.2.c. Create a New Event and Action for the Bandwidth Limitation Hit   On the Traffic Manager, create a new event type as shown in the screenshot below - I've created Bandwidth_Increment, but this event could be called anything relevant.  The important factor here is that the event is raised from the bwlimited event.     Once this event has been created, an action must be associated with it.   Create a new external program action as shown in the screenshot below - I've created one called Bandwidth_Increment, but again this could be called anything relevant.  The important factor for the action is that it's an external program action and that it calls the correct bash script, in my case called SSC_Bandwidth_Increment.     5. Testing   In order to test the solution, on the SSC, set the initial bandwidth for the Traffic Manager instance to 1Mbps.   Generate some traffic through to a service on the Traffic Manager that will force the Traffic Manager to hit it's 1Mbps limitation for a succession of time.  This will cause the bwlimited event to fire and for the Bandwidth_Increment action to be executed, running the SSC_Bandwidth_Increment script.   The script will increment the Traffic Manager bandwidth by 1Mbps.   Check and confirm this on the SSC.   Once confirmed, stop the traffic generation.   Note: As the Flexible License on the Traffic Manager polls the SSC every 3 minutes for an update on it's licensed state, you may not see an immediate change to the bandwidth allocation of the Traffic Manager.   You can force the Traffic Manager to poll the SSC by removing the Flexible License and re-adding the license again - the re-configuration of the Flexible License will then force the Traffic Manager to re-poll the SSC and you should then see the updated bandwidth in the System > Licenses (after expanding the license information) page of the Traffic Manager as shown in the screenshot below;     6. Summary   Please feel free to use the information contained within this post to experiment!!!   If you do not yet have an SSC deployment, then an Evaluation can be arranged by contacting your Partner or Riverbed Salesman.  They will be able to arrange for the Evaluation, and will be there to support you if required.
View full article
  1. The Issue   When using perpetual licensing on Traffic Manager instances which are clustered, the failure of one of the instances results in licensed throughput capability being lost until that instance is recovered.   2. The Solution   Automatically adjust the bandwidth allocation across cluster members so that wasted or unused bandwidth is used effectively.   3. A Brief Overview of the Solution   An SSC holds the configuration for the Traffic Manager cluster members. The Traffic Managers are configured to execute scripts on two events being raised, the machinetimeout event and the allmachinesok event.   Those scripts make REST calls to the SSC in order to dynamically and automatically amend the Traffic Manager instance configuration held for the two cluster members.   4. The Solution in a Little More Detail   4.1. Move to an SSC Licensing Model   If you're currently running Traffic Managers with perpetual licenses, then you'll need to move from the perpetual licensing model to the SSC licensing model.  This effectively allows you to allocate bandwidth and features across multiple Traffic Managers within your estate.  The SSC has a "bucket" of bandwidth along with configured feature sets which can be allocated and distributed across the estate as required, allowing for right-sizing of instances, features and also allowing multi-tenant access to various instances as required throughout the organisation.   Instance Hosts and Instance resources are configured on the SSC, after which a Flexible License is uploaded on each of the Traffic Manager instances which you wish to be licensed by the SSC, and those instances "call home" to the SSC regularly in order to assess their licensing state and to obtain their feature set. For more information on SSC, visit the Riverbed website pages covering this product, here - SteelCentral Services Controller for SteelApp Software.   There's also a Brochure attached to this article which covers the basics of the SSC.   4.2. Traffic Manager Configuration and a Bit of Bash Scripting!   The SSC has a REST API that can be accessed from external platforms able to send and receive REST calls.  This includes the Traffic Manager itself.   To carry out automated bandwidth allocation on cluster members, we'll need to carry out the following;   a. Create a script which can be executed on the Traffic Manager, which will issue REST calls in order to change the SSC configuration for the cluster members in the event of a cluster member failure. b. Create another script which can be executed on the Traffic Manager, which will issue REST calls to reset the SSC configuration for the cluster members when all of the cluster members are up and operational. c. Upload the two scripts to be used, on to the Traffic Manager cluster. d. Create a new event and action on the Traffic Manager cluster which will be initiated when a cluster member fails, calling the script mentioned in point a above. e. Create a new event and action on the Traffic Manager cluster which will be initiated when all of the cluster members are up and operational, calling the script mentioned in point b above.   4.2.a. The Script to Re-allocate Bandwidth After a Cluster Member Failure This script, called Cluster_Member_Fail_Bandwidth_Allocation and attached, is shown below.   Script Function:   Determine which cluster member has executed the script. Make REST calls to the SSC to allocate bandwidth according to which cluster member is up and which is down.   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 #!/bin/bash  #  # Cluster_Member_Fail_Bandwidth_Allocation  # ----------------------------------------  # Called on event: machinetimeout  #  # Checks which host calls this script and assigns bandwidth in SSC accordingly  # If demo-1 makes the call, then demo-1 gets 999 and demo-2 gets 1  # If demo-2 makes the call, then demo-2 gets 999 and demo-1 gets 1  #       # Grab the hostname of the executing host  Calling_Hostname=$(hostname -f)       # If demo-1.example.com is executing then issue REST calls accordingly  if [ $Calling_Hostname == "demo-1.example.com" ]  then           # Set the demo-1.example.com instance bandwidth figure to 999 and           # demo-2.example.com instance bandwidth figure to 1           curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u adminuser:adminpassword -d \                              '{"bandwidth":999}' \                              https://ssc.example.com:8000/api/tmcm/1.1/instance/demo-1.example.com           curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u adminuser:adminpassword -d \                              '{"bandwidth":1}' \                              https://ssc.example.com:8000/api/tmcm/1.1/instance/demo-2.example.com  fi       # If demo-2.example.com is executing then issue REST calls accordingly  if [ $Calling_Hostname == "demo-2.example.com" ]  then           # Set the demo-2.example.com instance bandwidth figure to 999 and           # demo-1.example.com instance bandwidth figure to 1           curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u adminuser:adminpassword -d \                              '{"bandwidth":999}' \                              https://ssc.example.com:8000/api/tmcm/1.1/instance/demo-2.example.com           curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u adminuser:adminpassword -d \                              '{"bandwidth":1}' \                              https://ssc.example.com:8000/api/tmcm/1.1/instance/demo-1.example.com  fi    There are some obvious parts to the script that will need to be changed to fit your own environment.  The hostname validation, the admin username and password in the REST calls and the SSC name, port and path used in the curl statements.  Hopefully from this you will be able to see just how easy the process is, and how the SSC can be manipulated to contain the configuration that you require.   This script can be considered a skeleton, as can the other script for resetting the bandwidth, shown later.   4.2.b. The Script to Reset the Bandwidth   This script, called Cluster_Member_All_Machines_OK and attached, is shown below.   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #!/bin/bash  #  # Cluster_Member_All_Machines_OK  # ------------------------------  # Called on event: allmachinesok  #  # Resets bandwidth for demo-1.example.com and demo-2.example.com - both get 500  #       # Set both demo-1.example.com and demo-2.example.com bandwidth figure to 500  curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u adminuser:adminpassword -d \                      '{"bandwidth":500}' \                      https://ssc.example.com:8000/api/tmcm/1.1/instance/demo-1.example.com-00002  curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u adminuser:adminpassword -d \                      '{"bandwidth":500}' \                      https://ssc.example.com:8000/api/tmcm/1.1/instance/demo-2.example.com-00002    Again, there are some parts to the script that will need to be changed to fit your own environment.  The admin username and password in the REST calls and the SSC name, port and path used in the curl statements.   4.2.c. Upload the Bash Scripts to be Used   On one of the Traffic Managers, upload the two bash scripts that will be needed for the solution to work.  The scripts are uploaded in the Catalogs > Extra Files > Action Programs section of the Traffic Manager, and can then be referenced from the Actions when they are created later.     4.2.d. Create a New Event and Action for a Cluster Member Failure   On the Traffic Manager (any one of the cluster members), create a new event type as shown in the screenshot below - I've created Cluster_Member_Down, but this event could be called anything relevant.  The important factor here is that the event is raised from the machinetimeout event.   Once this event has been created, an action must be associated with it. Create a new external program action as shown in the screenshot below - I've created one called Cluster_Member_Down, but again this could be called anything relevant.  The important factor for the action is that it's an external program action and that it calls the correct bash script, in my case called Cluster_Member_Fail_Bandwidth_Allocation.   4.2.e. Create a New Event and Action for All Cluster Members OK   On the Traffic Manager (any one of the cluster members), create a new event type as shown in the screenshot below - I've created All_Cluster_Members_OK, but this event could be called anything relevant.  The important factor here is that the event is raised from the allmachinesok event.   Once this event has been created, an action must be associated with it. Create a new external program action as shown in the screenshot below - I've created one called All_Cluster_Members_OK, but again this could be called anything relevant.  The important factor for the action is that it's an external program action and that it calls the correct bash script, in my case called Cluster_Member_All_Machines_OK.   5. Testing   In order to test the solution, simply DOWN Traffic Manager A from an A/B cluster.  Traffic Manager B should raise the machinetimeout event which will in turn execute the Cluster_Member_Down event and associated action and script, Cluster_Member_Fail_Bandwidth_Allocation.   The script should allocate 999Mbps to Traffic Manager B, and 1Mbps to Traffic Manager A within the SSC configuration.   As the Flexible License on the Traffic Manager polls the SSC every 3 minutes for an update on it's licensed state, you may not see an immediate change to the bandwidth allocation of the Traffic Managers in questions. You can force the Traffic Manager to poll the SSC by removing the Flexible License and re-adding the license again - the re-configuration of the Flexible License will then force the Traffic Manager to re-poll the SSC and you should then see the updated bandwidth in the System > Licenses (after expanding the license information) page of the Traffic Manager as shown in the screenshot below;     To test the resetting of the bandwidth allocation for the cluster, simply UP Traffic Manager B.  Once Traffic Manager B re-joins the cluster communications, the allmachinesok event will be raised which will execute the All_Cluster_Members_OK event and associated action and script, Cluster_Member_All_Machines_OK. The script should allocate 500Mbps to Traffic Manager B, and 500Mbps to Traffic Manager A within the SSC configuration.   Just as before for the failure event and changes, the Flexible License on the Traffic Manager polls the SSC every 3 minutes for an update on it's licensed state so you may not see an immediate change to the bandwidth allocation of the Traffic Managers in questions.   You can force the Traffic Manager to poll the SSC once again, by removing the Flexible License and re-adding the license again - the re-configuration of the Flexible License will then force the Traffic Manager to re-poll the SSC and you should then see the updated bandwidth in the System > Licenses (after expanding the license information) page of the Traffic Manager as before (and shown above).   6. Summary   Please feel free to use the information contained within this post to experiment!!!   If you do not yet have an SSC deployment, then an Evaluation can be arranged by contacting your Partner or Brocade Salesman.  They will be able to arrange for the Evaluation, and will be there to support you if required.
View full article
When using PHP to access the Stingray Traffic Manager (STM) RESTful API you can choose to interact directly with the API using cURL, or you can use one of the PHP REST Clients that are available.  I decided to create my own PHP REST Client, STMRESTClient, and instructions for using STMRESTClient are included in this article and the code is attached.   Overview   STMRestClient is a PHP class written specifically to work with the STM RESTful API.  So for example, it handles JSON conversions, authorization and understands the path hierarchy of the API.  The attached code has extensive comments that contain more detailed information then is included in this article.  The class contains default values for the hostname:port, user name, password and API version so the class can be edited to change these default values.  Any of these values can also be set when the class is instantiated by passing in an associative array with one or more of:   'STMHost' => '<host>:<port>' 'UserId' => '<user name>, 'Password' => '<password>' 'APIVersion' => '<version>'   The default value will be used for any of the values not specified.  So for example, all of the following are correct:   $client = new STMRestClient() $client = new STMRESTClient(array('UserId' => 'user', 'Password' => 'password'); $client = new STMRESTClient(array('STMHost' => 'stm.example.com:9070', 'UserId' => 'user',                                   'Password' => 'password', 'APIVersion' => '1.1'));   Once the class has been instantiated, any of the class methods can be invoked.  The following three methods are likely to be the most commonly used:   get: This method is used to get data for a resource. It takes two input parameters: resource: The end of the URI path for the resource.  So for example, to get the list of pools this would be "pools" and to get data for the pool, "testpool", it would be "pools/testpool". resource type: This parameter is optional.  It specifies the type of resource and can be one of the following constants: TYPE_CONFIG: causes the path to be /api/tm/<version>/config/active/<resource> TYPE_INFO: causes the path to be /api/tm/<version>/status/local_tm/information/<resource> TYPE_STATS: causes the path to be /api/tm/<version>/status/local_tm/statistics/<resource> The default is TYPE_CONFIG   For configuration resources, an object will be returned that has been created by decoding the JSON response.  For file resources, the file text will be returned.   Examples:   $pools = $client->get("pools"); $poolStats = $client->get("pools/testpool", TYPE_STATS);   put: This method is used to add or change a configuration resource. It takes two input parameters: resource: The end of the URI path for the resource. resource data&colon; An object or an associative array containing the resource data or file text.  For configuration resources, the data will be JSON encoded by STMRestClient. content type: The Content-Type header to use for this data.  This should be "application/octet-stream" for files and                      "application/json" for all other resources.  It defaults to "application/json".   For configuration resources, the new or changed resource is returned as an object.  For files, nothing is returned.   Example:   $vsData->properties->basic->pool = 'testpool'; $vsData->properties->basic->port = '80'; $newVS = $client->put("virtual_servers/newvs", $vsData);   $poolData->properties->basic->nodes = array('192.168.168.168:80'); $poolData = array('properties' => array('basic' => array('nodes' =>                   array('192.168.168.168:80'))));   $client->put("rules/newrule", "#test rule", "application/octet-stream");   delete: This method is used to delete a configuration resource. It takes one input parameter: resource: The end of the URI for the resource.   It returns true if the resource was deleted.   Example:   $client->delete("virtual_servers/newvs");   All three of these methods return the following exceptions:   STMAuthException: If there was an error logging into the STM STMConnectException: If there was error connecting to the STM STMResourceNotFoundException: If the resource requested is not found Exception: Any other errors   There are other methods that can be accessed and there are properties that can be set or retrieved and these are all documented in the class code.  The two public properties that are available are:   returnedContentType: This is the ContentType header returned by the last REST API request statusCode: This is the HTTP status code returned on the last REST API request   Examples   Several examples using STMRestClient can be found at: Read More   The REST API Guide in the Stingray Product Documentation Feature Brief: Stingray's RESTful Control API Collected Tech Tips: Using the RESTful Control API Tech Tip: Using the RESTful Control API with PHP - Overview
View full article
The following code uses Stingray's RESTful API to retrieve the statistics for a pool. The code is written in PHP and uses STMRESTClient.  This program does a single GET request for the statistics for the pool and then loops through response printing out each property and its value.   getpoolstats.php   <?php # Display the statistics for a pool require_once 'stmrestclient.inc'; $pool = "testpool"; print("<html><body>\n<br><b>Statistics for Pool $pool</b><br><br>\n"); print("<table>\n"); try { $client = new STMRestClient(); $response = $client->get("pools/$pool", TYPE_STATS); $stats = $response->statistics; foreach ($stats as $field => $value) { print("<tr><td>$field:</td><td>$value</td></tr>\n"); } print("</table>\n"); } catch (STMConnectException $e) { print ("Error connecting to the REST API: " . $e->getMessage()); } catch (STMAuthException $e) { print ("Error logging into the REST API: " . $e->getMessage()); } catch (exception $e) { print ('Error: ' . $e->getMessage()); } print("</body></html>\n"); ?>   Running the example   This code was tested with PHP 5.3.3 and uses the STMRestClient class that can be found here: Tech Tip: A Stingray Traffic Manager REST Client for PHP   To run this program, Make it available via a web server and the output should be:   Statistics for Pool testpool   algorithm:        roundrobin bytes_in:         16114052 bytes_out:        276005 conns_queued:     0 disabled:         1 draining:         1 max_queue_time:   0 mean_queue_time:  0 min_queue_time:   0 nodes:            2 persistence:      none queue_timeouts:   0 session_migrated: 0 state:            active total_conn:       4076   Read More   Stingray REST API Guide in the Stingray Product Documentation Feature Brief: Stingray's RESTful Control API Tech Tip: Using Stingray's RESTful Control API Tech Tip: Using the RESTful Control API with PHP - Overview Collected Tech Tips: Using the RESTful Control API
View full article
The following code uses Stingray's RESTful API to a file to the extra directory.   The code is written in PHP and uses STMRESTClient.  This program adds the file 'validserialnumbers' to the extra directory and if the file already exists it will be overwrite it.  If this is not the desired behavior, code can be added to to check for the existence of the file as was done in the addpool example.   addextrafile.   <?php require_once 'stmrestclient.inc'; $fileName = 'validserialnumbers'; $validSerialNumbers = "123456\n234567\n345678\n"; try { # Set up the connection $client = new STMRestClient(); $client->put("extra/$fileName", $validSerialNumbers, 'application/octet-stream'); # If the file already exists, it will be replaced with this version and 204 will be returned # otherwise 201 will be returned. print("<br>statusCode=" . $client->statusCode . "<br><br>"); if ($client->statusCode == 201) { print("File $fileName added"); } else { print("File $fileName replaced"); } } catch (STMConnectException $e) { print ("Error connecting to the REST API: " . $e->getMessage()); } catch (STMAuthException $e) { print ("Error logging into the REST API: " . $e->getMessage()); } catch (exception $e) { print ("Error: " . $e->getMessage()); } ?>   Running the example   This code was tested with PHP 5.3.3 and uses the STMRestClient class that can be found here: Tech Tip: A Stingray Traffic Manager REST Client for PHP   To run this program, Make it available via a web server and the output should be:   File validserialnumbers added   or   File validserialnumbers replaced   Notes   Since this is a file and not a configuration resource, JSON will not be used and the MIME type will be "application/octet-stream".  Another difference when dealing with files is how Stingray handles adding a file that already exists.  If the file already exists, Stingray will overwrite the it and return a HTTP status code of 204.  If the file doesn't already exist, the HTTP status code will be a 201.   Read More   Stingray REST API Guide in the Stingray Product Documentation Feature Brief: Stingray's RESTful Control API Tech Tip: Using Stingray's RESTful Control API Tech Tip: Using the RESTful Control API with PHP - Overview Collected Tech Tips: Using the RESTful Control API
View full article
The following code uses Stingray's RESTful API to delete a pool.  The code is written in PHP and uses STMRESTClient.  This program deletes the "phptest" pool created by the addpool.php example.  To delete a resource you do a HTTP DELETE on the URI for the resource.  If the delete is successful a 204 HTTP status code will be returned.   deletepool.php   <?php # Delete a pool require_once 'stmrestclient.inc'; $poolName = 'phptest'; try { # Set up the connection $client = new STMRestClient(); /* Check to see if the pool exists. If it doesn't exist, then a * ResourceNotFoundException exception will be thrown. */ $response = $client->get("pools/$poolName"); $client->delete("pools/$poolName"); print("Pool $poolName deleted"); } catch (STMResourceNotFoundException $e) { # The pool doesn't exist print("Pool $poolName not found"); } catch (STMConnectException $e) { print ("Error connecting to the REST API: " . $e->getMessage()); } catch (STMAuthException $e) { print ("Error logging into the REST API: " . $e->getMessage()); } catch (Exception $e) { print ('Error: ' . $e->getMessage()); } print("</body></html>\n"); ?>   Running the example   This code was tested with PHP 5.3.3 and uses the STMRestClient class that can be found here: Tech Tip: A Stingray Traffic Manager REST Client for PHP   To run this program, Make it available via a web server and the output should be:   Pool phptest deleted   Read More   Stingray REST API Guide in the Stingray Product Documentation Feature Brief: Stingray's RESTful Control API Tech Tip: Using Stingray's RESTful Control API Tech Tip: Using the RESTful Control API with PHP - Overview Collected Tech Tips: Using the RESTful Control API
View full article
The following code uses Stingray's RESTful API to add a pool.   The code is written in PHP and uses STMRESTClient. This program creates a new pool, "phptest", first doing a GET to make sure the pool doesn't already exist, and if the pool doesn't exist, the pool is created by doing a PUT with just the minimum data needed to create a pool.  In this case the program creates a properties object with just one node.  All other values will get default values when Stingray creates the pool.   addpool.php   <?php # Add a pool require_once 'stmrestclient.inc'; $poolName = 'phptest'; $node = '192.168.168.135:80'; try { # Set up the connection $client = new STMRestClient(); /* Check to see if the pool already exist. If it does not yet exist, then a * ResourceNotFoundException exception will be thrown. */ $response = $client->get("pools/$poolName"); print("Pool $poolName already exists"); } catch (STMResourceNotFoundException $e) { # The pool doesn't exist, so it can be created $poolConfig->properties->basic->nodes = array($node); #$poolConfig = array('properties' => array('basic' => array('nodes' => array($node)))); try { $response = $client->put("pools/$poolName", $poolConfig); print("Pool $poolName added"); } catch (Exception $e) { print ("Error creating Pool $poolName: " . $e->getMessage()); } } catch (STMConnectException $e) { print ("Error connecting to the REST API: " . $e->getMessage()); } catch (STMAuthException $e) { print ("Error logging into the REST API: " . $e->getMessage()); } catch (Exception $e) { print ('Error: ' . $e->getMessage()); } print("</body></html>\n"); ?>   Running the example   This code was tested with PHP 5.3.3 and uses the STMRestClient class that can be found here: Tech Tip: A Stingray Traffic Manager REST Client for PHP   To run this program, Make it available via a web server and the output should be:   Pool phptest added   Notes   The only difference between doing a PUT to change a resource and a PUT to add a resource is the HTTP status code returned.  When changing a resource 200 is the expected status code and when adding a resource, 201 is the expected status code.   Read More   Stingray REST API Guide in the Stingray Product Documentation Feature Brief: Stingray's RESTful Control API Tech Tip: Using Stingray's RESTful Control API Tech Tip: Using the RESTful Control API with PHP - Overview Collected Tech Tips: Using the RESTful Control API
View full article
The following code uses Stingray's RESTful API to enable or disabled a specific Virtual Server.   The code is written in PHP and uses STMRESTClient.  This program checks to see if the Virtual Server "test vs" is enabled and if it is, it disables it and if it is disabled, it enables it.  A GET is done to retrieve the configuration data for the Virtual Server and the "enabled" value in the "basic" properties section is checked.  This is a boolean value, so if it is true it is set to false and if it is false it is set to true. The changed data is then sent to the server using a PUT.   startstopvs.php   <?php # Start or stop a virtual server require_once 'stmrestclient.inc'; $resource = 'vservers/test vs'; print("<html><body>\n"); try { # Set up the connection $client = new STMRestClient(); # Get the config data for the virtual server $vsConfig = $client->get($resource); if ($vsConfig->properties->basic->enabled) { $vsConfig->properties->basic->enabled = false; print("test vs is enabled. Disable it<br>\n"); } else { $vsConfig->properties->basic->enabled = true; print("test vs is Diabled. Enable it<br>\n"); } $response = $client->put($resource, $vsConfig); } catch (STMConnectException $e) { print ("Error connecting to the REST API: " . $e->getMessage()); } catch (STMAuthException $e) { print ("Error logging into the REST API: " . $e->getMessage()); } catch (exception $e) { print ('Error: ' . $e->getMessage()); } print("</body></html>\n"); ?>   Running the example   This code was tested with PHP 5.3.3 and uses the STMRestClient class that can be found here: Tech Tip: A Stingray Traffic Manager REST Client for PHP   To run this program, Make it available via a web server and the output should be:   test vs is enabled. Disable it.   or test vs is disabled. Enable it.     Read More   Stingray REST API Guide in the Stingray Product Documentation Feature Brief: Stingray's RESTful Control API Tech Tip: Using Stingray's RESTful Control API Tech Tip: Using the RESTful Control API with PHP - Overview Collected Tech Tips: Using the RESTful Control API
View full article
The following code uses Stingray's RESTful API to list all the pools defined for a cluster and for each pool it lists the nodes defined for that pool, including draining and disabled nodes. The code is written in PHP and uses STMRESTClient. This example builds on the previous listpools.php example.  This program does a GET request for the list of pool and then while looping through the list of pools, a GET is done for each pool to retrieve the configuration parameters for that pool.   listpoolnodes.php   <?php # Display a list of all nodes in all pools require_once 'stmrestclient.inc'; print("<html><body>\n<br><b>Pools:</b><br>\n"); try { $client = new STMRestClient(); $response = $client->get('pools'); $pools = $response->children; foreach ($pools as $pool) { $poolName = $pool->name; $poolConfig = $client->get("pools/$poolName"); $nodes = $poolConfig->properties->basic->nodes; $draining = $poolConfig->properties->basic->draining; $disabled = $poolConfig->properties->basic->disabled; print("<br>Pool: $poolName<br>\n"); print ' Nodes: '; foreach ($nodes as $node) { print "$node "; } print "\n"; if (count($draining)) { print ' Draining Nodes: '; foreach ($draining as $node) { print "$node "; } print "<br>\n"; } if (count($disabled)) { print ' Disabled Nodes: '; foreach ($disabled as $node) { print "$node "; } print "<br>\n"; } print "<br>\n"; } } catch (exception $e) { print ("Error: " . $e->getMessage()); } print("</body></html>\n"); ?>   Running the example   This code was tested with PHP 5.3.3 and uses the STMRestClient class that can be found here: Tech Tip: A Stingray Traffic Manager REST Client for PHP   To run this program, Make it available via a web server and the output should be:   Pools:   Pool1     Nodes:  192.168.1.100 192.168.1.101     Draining:  192.168.1.101     Disabled:  192.168.1.102   Pool2     Nodes:  192.168.1.103 192.168.1.104   Read More   Stingray REST API Guide in the Stingray Product Documentation Feature Brief: Stingray's RESTful Control API Tech Tip: Using Stingray's RESTful Control API Tech Tip: Using the RESTful Control API with PHP - Overview Collected Tech Tips: Using the RESTful Control API
View full article
The following code uses Stingray's RESTful API to list all the pools defined on a cluster. The code is written in PHP and uses STMRESTClient. This example has more extensive comments then the following examples and most of these are applicable to all the examples. This program does a single GET request for the list of pools and then loops through that list, each element of which is an associative array, and then outputs the pool name.   listpools.php   <?php # Display a list of pools require_once 'stmrestclient.inc'; print("<html><body>\n<br><b>Pools:</b><br><br>\n"); try { # Setup the connection to the REST API $client = new STMRestClient(); # Do the HTTP GET to get the lists of pools $response = $client->get('pools'); # Get the list of pools from the response as an object $pools = $response->children; # Loop through the list of pools foreach ($pools as $pool) { print($pool->name . "<br>\n"); } } catch (STMConnectException $e) { /* We weren't able to connect to the Stingray Traffic Manager REST API The most likely reasons for this are: - the hostname of the Stingray instance is incorrect - this client doesn't have network access to the Stingray instance or port 9070 - the RESTful API is disabled - the RESTful API is using using a different port */ print ("Error connecting to the REST API: " . $e->getMessage()); } catch (STMAuthException $e) { /* We were able to connect to the Stingray Traffic Manager REST API but could not log in The user name or password were incorrect. If they weren't specified then the default values are being used and may need to be changed or the user name and password can be specified */ print ("Error logging into the REST API: " . $e->getMessage()); } catch (exception $e) { print ('Error: ' . $e->getMessage()); } print("</body></html>\n"); ?>   Running the example   This code was tested with PHP 5.3.3 and uses the STMRestClient class that can be found here: Tech Tip: A Stingray Traffic Manager REST Client for PHP   To run this program, Make it available via a web server and the output should be:   Pools: Pool1 Pool2   Read More   Stingray REST API Guide in the Stingray Product Documentation Feature Brief: Stingray's RESTful Control API Tech Tip: Using Stingray's RESTful Control API Tech Tip: Using the RESTful Control API with PHP - Overview Collected Tech Tips: Using the RESTful Control API
View full article
This document covers how to migrate from a software version of our SSC product to the Virtual Appliance version.
View full article
Stingray Traffic Manager version 9.5 includes some important enhancements to the RESTful API.  These enhancements include the following:   A new API version The API version has moved to 2.0.  Versions 1.0 and 1.1 are still available but have been deprecated.   Statistics and Version Information A new resource, "status", is available that contains the child resources "information" and "statistics", under the host name.  Data can only be retrieved for these resources; no updates are allowed.  The URL for "information" is: http(s)://<host>:<port>/api/tm/2.0/status/<host>/information   and the URI for "statistics" is:   http(s)://<host>:<port>/api/tm/2.0/status/<host>/statistics   <host> can also be "local_tm", which is an alias for the Traffic Manager processing the REST request.  For this release, only statistics for the local Traffic Manager are available.   The "information" resource contains the version of the Stingray Traffic Manager, so for example the request:   http(s)://<host>:<port>/api/tm/2.0/status/local_tm/information   for version 9.5 would return:   tm_version9.5   The "statistics" resource contains the Stingray statistics that are also available with SNMP or the SOAP API.  The following child resources are available under "statistics":   actions, bandwidth, cache, cloud_api_credentials, connection_rate_limit, events, glb_services, globals, listen_ips, locations, network_interface, nodes, per_location_service, per_node_slm, pools, rule_authenticators, rules, service_level_monitors, service_protection, ssl_ocsp_stapling, traffic_ips, virtual_servers   The statistics that are available vary by resource.   Example:   To get the statistics for the pool "demo" on the Stingray Traffic Manager "stingray.example.com": https://stingray.example.com:9070/api/tm/2.0/status/local_tm/statistics/pools/demo { "statistics": { "algorithm": "roundrobin", "bytes_in": 20476976, "bytes_out": 53323, "conns_queued": 0, "disabled": 0, "draining": 0, "max_queue_time": 0, "mean_queue_time": 0, "min_queue_time": 0, "nodes": 1, "persistence": "none", "queue_timeouts": 0, "session_migrated": 0, "state": "active", "total_conn": 772 } } Resource Name Changes Some resources have been renamed to be more clear:   actionprogs-> action_programs auth-> user_authenticators authenticators-> rule_authenticators cloudcredentials-> cloud_api_credentials events-> event_types extra-> extra_files flipper-> traffic_ip_groups groups-> user_groups scripts-> monitor_scripts services-> glb_services settings.cfg-> global_settings slm-> service_level_monitors vservers-> virtual_servers zxtms-> traffic_managers   New Resource   One new resource, "custom" has been added to support the new Custom Configuration Sets feature.  This allows arbitrary name:value configuration pairs to be stored in the Traffic Manager configuration system. As part of the Traffic Manager configuration, this data is replicated across a cluster and is accessible using the REST API, SOAP API and ZCLI.  All data structures supported by the Stinray REST API are also supported for Custom Configuration Sets.  Please see the REST API Guide for more information.
View full article
This article discusses how to use the Stingray Traffic Manager's RESTful Control API with PHP.  The are different options for accessing the RESTful API with PHP, but I decided to create my own PHP REST Client, STMRESTClient, to make working with RESTful API easier, and this has been used in the PHP examples. Instructions for using STMRESTClient and the code can be found here: Tech Tip: A Stingray Traffic Manager REST Client for PHP   Resources   The RESTful API gives you access to the Stingray Configuration and statistics, presented in the form of resources.  The format of the data exchanged using the Stingray RESTful API will depend on the type of resource being accessed:   Data for Configuration ans Status Resources, such as Virtual Servers and Pools are exchanged in JSON format using the MIME type “application/json”, so when getting data for a resource with a GET request, the data will be returned in JSON format and must be deserialized or decoded into a PHP data structure.  When adding or changing a resource with a PUT request, the data must be serialized or encoded from a PHP data structure into JSON format.  Files, such as rules and those in the extra directory are exchanged in raw format using the MIME type “application/octet-stream”.   Working with JSON and PHP   PHP provides functions for JSON encoding and decoding. To take a PHP data structure and encode it into JSON format, use json_encode() and to decode a JSON formatted string into a PHP structure, use json_decode(). If using STMRestClient, JSON encoding and decoding will be done for you.   Working with the RESTful API and PHP   The base form of the URI for the Stingray RESTful API is:   https://<host>:<port>/api/tm/<version>   followed by paths to the different resource types:   For configuration resources: /config/active/ For statistic resources: /status/<host>/information/ "local_tm" can be used in place of <host> For information resources: /status/<host>/statistics/ "local_tm" can be used in place of <host>   followed by a actual resource, so for example to get a list of all the pools from the Stingray instance, stingray.example.com, it would be:   https://stingray.example.com:9070/api/tm/2.0/config/active/pools   and to get the configuration information for the pool, “testpool” it would be:   https://stingray.example.com:9070/api/tm/2.0/config/active/pools/testpool   and to get statistics for the pool "testpool", it would be:   https://stingray.example.com:9070/api/tm/2.0/status/local_tm/statistics/pools/testpool   Prerequisites   If your PHP environment does not have cURL installed, you will need to install it, even if you are using STMRestClient.   If using apt (assuming apache is the web server):   sudo apt-get install php5-curl sudo service apache2 restart   Data Structures   The PHP functions json_decode and json_encode convert between JSON strings and PHP data structures.  The PHP data structure can be either an associative array or an object.  In either case, the array or object will have one element.   The key to this element will be:   'children' for lists of configuration resources.  The value will be a PHP array with each element in the array being an associative array with the key, 'name', set to the name of the resource and the key, 'href', set to the URI of the resource. 'properties' for configuration resources.  The value will be an associative array with each key value pair being a section of properties with the key being set to the name of the section and the value being an associative array containing the configuration values as key/value pairs.  Configuration values can be scalars, arrays or associative arrays. 'statistics' for statistics resources.  The value will be an associative array. 'information' for information resources.  The value will be an associative array.   Please see Feature Brief: Stingray's RESTful Control API for examples of these data structures and something like the Chrome REST Console can be used to see what the actual data looks like.   Read More   The REST API Guide in the Stingray Product Documentation Feature Brief: Stingray's RESTful Control API Collected Tech Tips: Using the RESTful Control API Tech Tip: A Stingray Traffic Manager REST Client for PHP
View full article
The following code uses Stingray's RESTful API to delete a pool.  The code is written in TrafficScript.  This rule deletes the "tstest" pool created by the stmrest_addpool example.  To delete a resource you do a HTTP DELETE on the URI for the resource.  If the delete is successful a 204 HTTP status code will be returned.  Subroutines in stmrestclient are used to do the actual RESTful API calls.  stmrestclient is attached to the article Tech Tip: Using the RESTful Control API with TrafficScript - Overview. stmrest_deletepool ################################################################################ # stmrest_deletepool # # This rule deletes the pool "tspool". # # To run this rule add it as a request rule to an HTTP Virtual Server and in a # browser enter the path /rest/deletepool. # # It uses the subroutines in stmrestclient ################################################################################ import stmrestclient; if (http.getPath() != "/rest/deletepool") break; $pool = "tspool"; $resource = "pools/" . string.escape($pool); $accept = "json"; $html = "<br><b>Delete Pool " . $pool . "</b><br><br>"; # Check to make sure that the Pool exists $response = stmrestclient.stmRestGet($resource, $accept); if ($response["rc"] == 1) {    $response = stmrestclient.stmRestDelete($resource);    if ($response["rc"] == 1) {       $html = $html . "Pool " . $pool . " deleted";    } else {       $html = $html . "There was an error deleting pool " . $pool . ": " . $response['info'];    } } else {    if ($response['status'] == 404) {       $html = $html . "Pool " . $pool . " not found";    } else {       $html = $html . "There was an error getting the configuration for pool " . $pool . ": " . $response['info'];    } } http.sendResponse("200 OK", "text/html", $html, ""); Running the example This rule should be added as a request rule to a Virtual Server and run with the URL: http://<hostname>/rest/deletepool Pool tstest deleted Read More Stingray REST API Guide in the Stingray Product Documentation Tech Tip: Using the RESTful Control API with TrafficScript - Overview Feature Brief: Stingray's RESTful Control API Collected Tech Tips: Using the RESTful Control API
View full article
The following code uses Stingray's RESTful API to add a pool.   The code is written in TrafficScript. This rule creates a new pool, "tstest", first doing a GET to make sure the pool doesn't already exist, and if the pool doesn't exist, the pool is created by doing a PUT with just the minimum data needed to create a pool.  In this case the rule creates a properties hash with just one node.  All other values will get default values when Stingray creates the pool.  Subroutines in stmrestclient are used to do the actual RESTful API calls.  stmrestclient is attached to the article Tech Tip: Using the RESTful Control API with TrafficScript - Overview. stmrest_addpool ################################################################################ # stmrest_addpool # # This rule adds the pool "tspool" with the node "192.168.168.135:80" # # To run this rule add it as a request rule to an HTTP Virtual Server and in a # browser enter the path /rest/addpool. # # It uses a set of subroutines in stmrestclient ################################################################################ import stmrestclient; if (http.getPath() != "/rest/addpool") break; $pool = "tspool"; $node = "192.168.168.135"; $resource = "pools/" . string.escape($pool); $accept = "json"; $html = "<br><b>Add Pool " . $pool . "</b><br><br>"; # Check to make sure that the Pool doesn't already exist $response = stmrestclient.stmRestGet($resource, $accept); if ($response["rc"] == 1) {    $html = $html . "Pool " . $pool . " already exists"; } else {    $poolConfig =["properties" => ["basic" => ["nodes" => [$node . ":80"]]]];    $response = stmrestclient.stmRestPut($resource, $accept, $poolConfig);    if ($response["rc"] == 1) {       $html = $html . "Pool " . $pool . " created";    } else {       $html = $html . "There was an error creating pool " . $pool . ": "  . $response['info'];    } } http.sendResponse("200 OK", "text/html", $html, ""); Running the example This rule should be added as a request rule to a Virtual Server and run with the URL: http://<hostname>/rest/addpool Pool tstest added Notes The only difference between doing a PUT to change a resource and a PUT to add a resource is the HTTP status code returned.  When changing a resource, 200 is the expected status code and when adding a resource, 201 is the expected status code. Read More Stingray REST API Guide in the Stingray Product Documentation Tech Tip: Using the RESTful Control API with TrafficScript - Overview Feature Brief: Stingray's RESTful Control API Collected Tech Tips: Using the RESTful Control API
View full article
The following code uses Stingray's RESTful API to enable or disabled a specific Virtual Server.   The code is written in TrafficScript.  This rule checks to see if the Virtual Server "test vs" is enabled and if it is, it disables it and if it is disabled, it enables it.  A GET is done to retrieve the configuration data for the Virtual Server and the "enabled" value in the "basic" properties section is checked.  This is a boolean value, so if it is true it is set to false and if it is false it is set to true. The changed data is then sent to the server using a PUT.  Subroutines in stmrestclient are used to do the actual RESTful API calls.  stmrestclient is attached to the article Tech Tip: Using the RESTful Control API with TrafficScript - Overview. stmrest_startstopvs ################################################################################ # stmrest_startstopvs # # This rule toggles the enabled status of virtual server "test vs". # # To run this rule add it as a request rule to an HTTP Virtual Server and in a # browser enter the path /rest/startstopvs. # # It uses the subroutines in stmrestclient ################################################################################ import stmrestclient; if (http.getPath() != "/rest/startstopvs") break; $vs = "test vs"; $resource = "vservers/" . string.escape($vs); $accept = "json"; $html = "<br><b>Toggle the status of Virtual Server " . $vs . "</b><br><br>"; $response = stmrestclient.stmRestGet($resource, $accept); if ($response["rc"] == 1) {    $vsConfig = $response["data"];    if ($vsConfig["properties"]["basic"]["enabled"]) {       $vsConfig["properties"]["basic"]["enabled"] = false;    } else {       $vsConfig["properties"]["basic"]["enabled"] = true;    }    $response = stmrestclient.stmRestPut($resource, $accept, $vsConfig);    if ($response["rc"] == 1) {       if ($vsConfig["properties"]["basic"]["enabled"]) {          $html = $html . $vs . " is Disabled.  Enable it";       } else {          $html = $html . $vs . " is Enabled.  Disable it.";       }    } else {       $html = $html . "There was an error updating the virtul server configuration for " . $vs . ": " . $response["info"];    } } else {    if ($response["status"] == 404) {       $html = $html . "Virtual Server " . $vs . " not found";    } else {       $html = $html . "There was an error getting the virtul server configuration for " . $vs . ": " . $response["info"];    } } http.sendResponse("200 OK", "text/html", $html, ""); Running the example This rule should be added as a request rule to a Virtual Server and run with the URL: http://<hostname>/rest/startstopvs test vs is enabled. Disable it. Notes This rule it is sending only the "enabled" value to the server by creating a new hash with just this value in the "basic" properties section.  Alternatively, the entire Virtual Server configuration could have been returned to the server with just the "enabled" value changed.  Sending just the data that has changed reduces the chances of overwriting another user's changes if multiple programs are concurrently accessing the RESTful API. Read More Stingray REST API Guide in the Stingray Product Documentation Tech Tip: Using the RESTful Control API with TrafficScript - Overview Feature Brief: Stingray's RESTful Control API Collected Tech Tips: Using the RESTful Control API
View full article
The following code uses Stingray's RESTful API to list all the pools defined for a cluster. The code is written in TrafficScript. This example has more extensive comments then the other examples and most of these are applicable to all the examples. This rule does a single GET request for the list of pools and then loops through that list, each element of which is a hash, and outputs the pool name to a web page. A subroutine in stmrestclient is used to do the actual RESTful API call.  stmrestclient is attached to the article Tech Tip: Using the RESTful Control API with TrafficScript - Overview. stmrest_listpools ################################################################################ # stmrest_listpools # # This rule gets the lists of pools and creates a webpage to display the list. # # To run this rule add it as a request rule to an HTTP Virtual Server and in a # browser enter the path /rest/listpools. # # It uses the subroutines in stmrestclient ################################################################################ import stmrestclient ; # Only run the rule for the path /rest/listpools if ( http.getPath ( ) != "/rest/listpools" ) break ;    $resource = "pools" ; # The configuration resource $accept = "json" ; # The format of the response $html = "<b>Pools:</b><br><br>\n" ; # Do the HTTP GET to get the lists of pools $response = stmrestclient.stmRestGet ( $resource , $accept ) ; if ( $response [ "rc" ] == 1 ) {    # Since we are getting a list of pools we expect the first element to be 'children'     $pools = $response [ "data" ] [ "children" ] ;    # The value for the key 'children' will be a hash containing an array for each pool     # with the key, 'name', set to the name of the pool and the key, 'href', set to the    # URL of the pool     foreach ( $pool in $pools ) {       $html = $html . $pool [ "name" ] . "<br>" ;    } } else {    # Either the attempt to connect to the Stingray REST API failed, or the request had an    # error.  $response['info'] should provide some information.  If The connection attempt    # failed, the most likely reasons for this are that the port, username or password for    # the Stingray REST API are incorrect, or the REST API is disabled.   The above request    # should not have an error, but the most common reason for a GET error is that the    # incorrect resource is specified.     $html = $html . "There was an error getting the pool list: " . $response [ 'info' ] ; } http.sendResponse ( "200 OK" , "text/html" , $html , "" ) ; Running the example This rule should be added as a request rule to a Virtual Server and run with the URL: http:// <hostname>/rest/listpools Pools: Pool1 Pool2 Read More Stingray REST API Guide in the Stingray Product Documentation Tech Tip: Using the RESTful Control API with TrafficScript - Overview Feature Brief: Stingray's RESTful Control API Collected Tech Tips: Using the RESTful Control API
View full article