Running BASH commands via REST API
I am trying to run bash commands via the REST API but am getting an error. When trying to use the following syntax I am getting a 403 running with Admin authentication... GET: https://F5LTM/mgmt/tm/util/bash Output: {"code":403,"message":"Operation is not allowed on component /util/bash.","errorStack":[]} Does anyone know if this is possible, or have any syntax examples of how to run bash commands? I assume you need to submit a post request, but I am not sure how to structure the syntax in the body of the request and cannot find any examples.
REST API access right
Hi all, We're running F5 LTM (version 14.1.4.x) and sorry for any newbie question. We're trying to perform some tasks through REST API to the LTM: 1. Check system status, e.g. curl -ks -H "Content-Type: application/json" -u admin:admin "https://192.168.1.1/mgmt/tm" -d "{\"command\":\"show\", \"utilCmdArgs\":\"-c 'cm failover-status'\"}" 2. Perform failover, e.g. curl -ks -H "Content-Type: application/json" -u admin:admin "https://192.168.1.1/mgmt/tm" -d "{\"command\":\"run\", \"utilCmdArgs\":\"-c 'sys failover standby'\"}" We don't want to expose admin password in any script, while authentication token seems only valid for 10 hours at most and not suitable to be used in cronjobs.We create user for this specific purpose with user role Resource Administrator who can perform the task through ssh or GUI. However, both commands can run as that specific user (testuser1) in tmsh interactively, but fail when running through curl with error: {"code":401,"message":"Authorization failed: user=https://localhost/mgmt/shared/authz/users/testuser1 resource=/mgmt/tm verb=POST uri:http://localhost:8100/mgmt/tm referrer:192.168.1.8 sender:192.168.1.8","referer":"192.168.1.8","restOperationId":2225072,"kind":":resterrorresponse"} I'm afraid we've something missed or setting up based on wrong concept... Would anyone please help? Thanks and Rgds /st wongGetting active pool member connections using Python
If I want to see all of the client connections connecting to a pool member from the CLI I can do something like a "show sys connection ss-server-addr 1.2.3.4". I can also do this using Postman mapping to ";, but I cannot figure out how to do this via Python. Using Python if I try to connect to "bigip.sys.raw" I do not see a module called "connection" or anything similar. Does anyone know how, or have some sample code on how to accomplish this? Thanks!
How to attach TCP profile for server/client individually via REST API?
Hi, I was trying to attach the TCP profile to virtual server by REST API. But now what I only can do is to specify the context to "all", then call PATCH on /tm/ltm/virtual/VIRTUALNAME. The content is: {"ipProtocol":"tcp","profilesReference":{"items":[{"kind":null,"name":"VIRTUALNAME","partition":null,"fullPath":null,"generation":0,"selfLink":null,"context":"all"}]}} "Context = all" means I am setting both of the client and server side at the same time. But I would like to set them separately to two different profiles, then I tried context = clientside or context = serverside. Then an error like "Less than the required minimum number of profiles found on VIRTUALNAME: Exactly 1 of (UDP Profile (serverside), TCP Profile (serverside), SCTP Profile (serverside))" was returned. Looks like when only setting clientside/serverside profile, F5 will delete both profiles for clientside and serverside firstly, then update the user's profile. But at that time, the profile is only for server or client, the other part of the profile has been deleted in the previous step, which led to this error. Could anyone help figure out if I am doing in the incorrect way? Or if this might be a bug of setting TCP profiles? Heap thanks.iHealth API Part 2 - An Introduction to REST
In the last article, we got some ideas of the kinds of data that iHealth can provide by exploring the wealth of information through a standard web UI. This is a quick easy way to get answers about a couple of your F5 machines, or to do a one-off check of something, or if you are looking for a particular problem, or working with F5 Support to resolve an issue or answer a question. If you have a couple machines, or maybe many many more, however, and you want to do something periodically, like, say, check for new Diagnostics results (remember, we generally update them once a week), then you'll quickly find that opening your browser, logging in, uploading the QKViews, and then reading through the Diagnostics is not necessarily the most efficient method. It can become annoying and tedious for even one or two machines. Since iHealth is a web application, it made the most sense to make the iHealth API a web API as well. There is a dogs breakfast of different types of web APIs, but one of the most prevalent conceptual frameworks in use today is called Representational State Transfer, or REST. The wikipedia entry on Roy Fielding has links to his dissertation if you want to up your street cred significantly. REST provides a nice clean way of retrieving, modifying and deleting things using HTTP in all (well most all) of it's glory. It's hidden from most users (as it should be), and unless you are a web developer, or someone who is dealing with web traffic a lot, there isn't any reason you would need to know this, but the HTTP protocol specifies a number of different ways to ask the server to do something. Now that you will be working with an HTTP API, you're going to have to know a little more about HTTP. Generally the two verbs that a developer will be familiar with is GET and POST. But HTTP has many other verbs, and we'll use most of them in this article series (GET, POST, PUT, and DELETE for now, although there are others), REST gives us a framework for using those verbs to make changes, or view the properties of things on the web. They generally do what they sound like: GET - get information (generally read-only) POST - create a new object (or modify an existing object repeatedly) PUT - modify an object idempotently so that multiple PUTs will result in the same state DELETE - delete an object This is all very abstract, so let's come up with an extremely contrived example: imagine a barn full of goats ( yes, my first job was as a farmhand ). Let's say that you had a robot that you wanted to perform various tasks relating to this barn full of goats. Maybe the first one would be a survey of all the goats in the barn. If the robot spoke REST, then you might send a text message to your robot that looked like this: GET /barn/1/goats Because the robot knows that in REST, that means that you want to know about all the goats in barn 1, your robot would trundle off (or fly, or crawl) to barn 1, and might come back with this data: goat 1: name: Dopey goat 2: name: Speedy Maybe then you wanted to know more about Speedy, so you'd text your robot this: GET /barn/1/goats/2 and your robot would gather up some more information about goat 2: goat 2: name : Speedy eats : Himalayan Blackberry hates : Dopey Okay, so what the hell do goats and barns have to do with iHealth? Well, if we substitute in QKViews for goats, we can start to see some information about our data in the same way that we were able to examine our herds of goats: GET /qkview-analyzer/api/qkviews Will show us a list of the qkviews that we have in our account: This is a sample, and there is a special QKView that isn't show in the listing, but that you should always have in your account, a QKView with an ID of 0. It's a sample QKView that we allow everyone access to in order to see how iHealth works with requireing you to upload anything of your own. So let's pick QKView 0 and load it up. We'll see some details about that QKView: GET /qkview-analyzer/api/qkviews/0 Feel free to poke around. At the bottom of the listing are some "discovery" URLs. Load them up in your browser; there is a ton to explore here, and you can get an idea of the kind of data you can work with without writing a single line of code. Code will come later, as you'll need it for things like adding to your QKView collections, and modifying existing QKView entries, which are tricky to do with just a browser.
PowerShell - How to modify system iFile?
I use PowerShell to upload a text file containing a number of parameters that I want to use in an existing iRule. Through the web-gui I have already created an iFile named 'iFileApiKeys'. In PowerShell I use this procedure to upload the text file: $length = "0-" + ($fileContent.Length - 1) + "/" + $fileContent.Length $headers = @{ "Content-Range" = $length} $uploadResult = Invoke-WebRequest $URL -Method POST -Headers $headers -InFile $filePathPlusTextfile - ContentType "multipart/form-data" -TimeoutSec 20 -Credential $mycreds | ConvertFrom-Json Write-Host "Upload Result:" Write-Host $uploadResult According to the 'uploadResult' the file ends up in the folder:'var/config/rest/downloads/iFileApiKeys.txt' on my F5 LTM Using 'SuperPutty' I can via tmos (tmsh) modify the existing system iFile by executing: `tmos> modify /sys file ifile iFileApiKeys source-path file:///var/config/rest/downloads/iFileApiKeys.txt My problem is that I can't seem to find the correct PowerShell command to achieve the same result as the tmos (tmsh) command does. I want to use and actually think I should use: `Invoke-Webrequest -Method Put` I've been trying to emulate an example taken from a Jason Rahm post on this site: https://devcentral.f5.com/articles/getting-started-with-icontrol-working-with-the-system-20592 Like this: $sysIfilePath = "/mgmt/tm/sys/file/ifile/iFileApiKeys" `$sysPath = "https://" + $host_address + $sysIfilePath $updateresult = Invoke-WebRequest -Method Put -Uri $sysPath -Headers $headers -Credential $mycreds -Body $body But this command fails unfortunately, My assumption is that I don't fill $headers and/or $body with the correct values. When executing a GET for my sys iFile object the result is: ``{"kind":"tm:sys:file:ifile:ifilestate","name":"iFileApiKeys","fullPath":"iFileApiKeys","generation":10970077,"selfLink":"https://localhost/mgmt/tm/sys/file/ifile/iFileApiKeys?ver=13.1.0.2","chec ksum":"SHA1:878:52a261b5a113db5c9421a54e1e8b5685e7da7a4d","createTime":"2018-11-26T22:52:08Z","createdBy":"per.eriksson","lastUpdateTime":"2018-12-08T19:49:15Z","mode":33188,"revision":24,"size" :878,"sourcePath":"file:///var/config/rest/downloads/iFileApiKeys.txt","updatedBy":"per.eriksson"} Anyone out there that can point me in the right direction on how to update my sys iFile using PowerShell? Thank you! /PerF5 SSLO Unified Configuration API Quick Introduction
Introduction Prior to the introduction of BIG-IQ 8.0, you had to use the BIG-IQ graphical user interface (GUI) to configure F5 SSL Orchestrator (SSLO) Topologies and their dependencies. Starting with BIG-IQ 8.0, a new REST unified, supported and documented REST API endpoint was created to simplify SSLO configuration workflows. The aim is to simplify the configuration of F5 SSLO using standardized API calls.You are now able to store the configuration in your versioning tool (Git, SVN, etc.), and easily integrate the configuration of F5 SSLO in your automation and pipeline tools. For more information about F5 SSLO, please refer to this introductory video.An overview of F5 SSL Orchestrator is provided in K1174564. As a reminder the BIG-IQ API reference documentation can be found here.Documentation for the Access Simplified Workflow can be found here. The figure below shows a possible use for the SSLO Unified API. A few shortcuts are taken in the figure above as it is meant to illustrate the advantage of the simplified workflow. Example Configuration For the configuration the administrator needs to: -Create a JSON blurb or payload that will be sent to the BIG-IQ API -Authenticate to the BIG-IQ API -Send the payload to the BIG-IQ -Ensure that the workflow completes successfully The following aims to provide a step-by-step configuration of SSLO leveraging the API.In practice, the steps may be automated and may be included in the pipeline used to deploy the application leveraging the enterprise tooling and processes in place. 1.- Authenticate to the API API interactions with the BIG-IQ API requires the use of a token.The initial REST call should look like the following: REST Endpoint : /mgmt/shared/authn/login HTTP Method: POST Headers: -content-type: application/json Content: { "username": "", "password": "", "loginProviderName": "" } Example: POST https://10.0.0.1/mgmt/shared/authn/login HTTP/1.1 Headers: content-type: application/json Content: { "username": "username", "password": "complicatedPassword!", "loginProviderName": "RadiusServer" } The call above will authenticate the user “bob” to the API.The result of a successful authentication is the response from the BIG-IQ API with a token. 2.- Push the configuration to BIG-IQ The headers and HTTP request should look like the following: URI: mgmt/cm/sslo/api/topology HTTP Method: POST Headers: -content-type: application/json -X-F5-Auth-Token: [token obtained from the authentication process above] To send the configuration to the BIG-IQ you will need to send the following payload - the blurb is cut up in smaller pieces for readability. The JSON blurb is divided in multiple parts - the full concatenated text is available in the file in attachment. Start by defining an new topology with the following characteristics: Name: "sslo_NewTopology" Listening on the "/Common/VLAN_TRAP" VLAN The topology is of type "topology_l3_outbound" The SSL settings defined below named: "ssloT_NewSsl_Dec" The policy is called: "ssloP_NewPolicy_Dec" The JSON payload starts with the following: { "template": { "TOPOLOGY": { "name": "sslo_NewTopology ", "ingressNetwork": { "vlans": [ { "name": "/Common/VLAN_TAP" } ] }, "type": "topology_l3_outbound", "sslSetting": "ssloT_NewSsl_Dec", "securityPolicy": "ssloP_NewPolicy_Dec" }, The SSL settings used above are defined in the following JSON that creates a new profile with default values: "SSL_SETTINGS": { "name": "ssloT_NewSsl_Dec" }, The security policy is configured as follows: name: ssloP_NewPolicy_Dec function: introduces a pinning policy doing a policy lookup - matching requests are bypassed (no ssl decryp) with the associated service chain "ssloSC_NewServiceChain_Dec" that is defined further down below. "SECURITY_POLICY": { "name": "ssloP_NewPolicy_Dec", "rules": [ { "mode": "edit", "name": "Pinners_Rule", "action": "allow", "operation": "AND", "conditions": [ { "type": "SNI Category Lookup", "options": { "category": [ "Pinners" ] } }, { "type": "SSL Check", "options": { "ssl": true } } ], "actionOptions": { "ssl": "bypass", "serviceChain": "ssloSC_NewServiceChain_Dec" } }, { "mode": "edit", "name": "All Traffic", "action": "allow", "isDefault": true, "operation": "AND", "actionOptions": { "ssl": "intercept" } } ] }, The service chain configuration is defined below to forward the traffic to the "ssloS_ICAP_Dec" service. this is done with the following JSON: "SERVICE_CHAIN": { "ssloSC_NewServiceChain_Declarative": { "name": "ssloSC_NewServiceChain_Dec", "orderedServiceList": [ { "name":"ssloS_ICAP_Dec" } ] } }, The "ssloS_ICAP_Dec" service is defined with the JSON below with IP 3.3.3.3 on port 1344 "SERVICE": { "ssloS_ICAP_Declarative": { "name": "ssloS_ICAP_Dec", "customService": { "name": "ssloS_ICAP_Dec", "serviceType": "icap", "loadBalancing": { "devices": [ { "ip": "3.3.3.3", "port": "1344" } ] } } } } }, The configuration will be deployed to the target defined below: "targetList": [ { "type": "DEVICE", "name": "my.bigip.internal" } ] } After the HTTP POST, the BIG-IQ will respond with a transaction id.A sample of what looks like is given below: { […] "id":"edc17b06-8d97-47e1-9a78-3d47d2db70a6", "status":"STARTED", […] } You can check on the status of the deployment task by submitting a request as follows: -HTTP GET Method -Authenticated with the use of the custom authentication header X-F5-Auth-Token -Sent to the BIG-IQ to URI GET mgmt/cm/sslo/tasks/api/{{status_id}} HTTP/1.1 -With Content-Type header set to: Application/JSON Once the status of the task changes to FINISHED.The configuration is successfully completed.You can now check the F5 SSLO interface to make sure the new topology has been created.The BIG-IQ interface will show the new topology as depicted in the example below: The new topology has been deployed to the BIG-IP automatically.You can connect to the BIG-IP to verify, the interface should like the one depicted below: Congratulations, you now have successfully deployed a fully functional topology that your users can start using. Note that, you can also use the BIG-IQ REST API to delete the items that were just created.This is done by sending HTTP DELETE to the different API endpoints for the topology, service, security profile etc. For example, for the example above, you would be sending HTTP DELETE requests to the following URI’s: -For the topology: /mgmt/cm/sslo/api/topology/sslo_NewTopology_Dec -For the service chain: /mgmt/cm/sslo/api/service-chain/ssloSC_NewServiceChain_Dec -For the ICAP service: /mgmt/cm/sslo/api/ssl/ssloT_NewSsl_Dec All the requests listed above need to be sent to the BIG-IQ system to its management IP address with the following 2 headers: -content-type: application/json -X-F5-Auth-Token: [value of the authentication token obtained during authentication] Conclusion BIG-IQ makes it easier to manage SSLO Topologies thanks to its REST API.You can now make supported, standardized API calls to the BIG-IQ to create and modify topologies and deploy the changes directly to BIG-IP.
