Demystifying iControl REST Part 5: Transferring Files
iControl REST. It’s iControl SOAP’s baby, brother, introduced back in TMOS version 11.4 as an early access feature but released fully in version 11.5.
Several articles on basic usage have been written on iControl REST so the intent here isn’t basic use, but rather to demystify some of the finer details of using the API. This article will cover the details on how to transfer files to/from the BIG-IP using iControl REST and the python programming language. (Note: this functionality requires 12.0+.)
The REST File Transfer Worker
The file transfer worker allows a client to transfer files through a series of GET operations for downloads and POST operations for uploads. The Content-Range header is used for both as a means to chunk the content. For downloads, the worker listens on the following interfaces.
Description | Method | URI | File Location |
Download a File | GET | /mgmt/cm/autodeploy/software-image-downloads/ | /shared/images/ |
Upload an Image File | POST | /mgmt/cm/autodeploy/software-image-uploads/ | /shared/images/ |
Upload a File | POST | /mgmt/shared/file-transfer/uploads/ | /var/config/rest/downloads/ |
Download a QKView | GET | /mgmt/shared/file-transfer/qkview-downloads/ | /var/tmp/ |
Download a UCS | GET | /mgmt/shared/file-transfer/ucs-downloads/ | /var/local/ucs/ |
Upload ASM Policy | POST | /mgmt/tm/asm/file-transfer/uploads/ | /var/ts/var/rest/ |
Download ASM Policy | GET | /mgmt/tm/asm/file-transfer/downloads/ | /var/ts/var/rest/ |
Binary and text files are supported. The magic in the transfer is the Content-Range header, which has the following format:
Content-Range: start-end/filesize
Where start/end are the chunk's delimiters in the file and filesize is well, the file size. Any file larger than 1M needs to be chunked with this header as that limit is enforced by the worker. This is done to avoid potential denial of service attacks and out of memory errors. There are benefits of chunking as well:
- Accurate progress bars
- Resuming interrupted downloads
- Random access to file content possible
Uploading a File
The function is shown below. Note that whereas normally with the REST API the Content-Type is application/json, with file transfers that changes to application/octet-stream. The workflow for the function works like this (line number in parentheses) :
- Set the Chunk Size (3)
- Set the Content-Type header (4-6)
- Open the file (7)
- Get the filename (apart from the path) from the absolute path (8)
- If the extension is an .iso file (image) put it in /shared/images, otherwise it’ll go in /var/config/rest/downloads (9-12)
- Disable ssl warnings requests (required with my version: 2.8.1. YMMV) (14)
- Set the total file size for use with the Content-Range header (15)
- Set the start variable to 0 (17)
- Begin loop to iterate through the file and upload in chunks (19)
- Read data from the file and if there is no more data, break the loop (20-22)
- set the current bytes read, if less than the chunk size, then this is the last chunk, so set the end to the size from step 7. Otherwise, add current bytes length to the start value and set that as the end. (24-28)
- Set the Content-Range header value and then add that to the header (30-31)
- Make the POST request, uploading the content chunk (32-36)
- Increment the start value by the current bytes content length (38)
def _upload(host, creds, fp): chunk_size = 512 * 1024 headers = { 'Content-Type': 'application/octet-stream' } fileobj = open(fp, 'rb') filename = os.path.basename(fp) if os.path.splitext(filename)[-1] == '.iso': uri = 'https://%s/mgmt/cm/autodeploy/software-image-uploads/%s' % (host, filename) else: uri = 'https://%s/mgmt/shared/file-transfer/uploads/%s' % (host, filename) requests.packages.urllib3.disable_warnings() size = os.path.getsize(fp) start = 0 while True: file_slice = fileobj.read(chunk_size) if not file_slice: break current_bytes = len(file_slice) if current_bytes < chunk_size: end = size else: end = start + current_bytes content_range = "%s-%s/%s" % (start, end - 1, size) headers['Content-Range'] = content_range requests.post(uri, auth=creds, data=file_slice, headers=headers, verify=False) start += current_bytes
Downloading a File
Downloading is very similar but there are some differences. Here is the workflow that is different, followed by the code. Note that the local path where the file will be downloaded to is given as part of the filename.
- URI is set to downloads worker. The only supported download directory at this time is /shared/images. (8)
- Open the local file so received data can be written to it (11)
- Make the request (22-26)
- If response code is 200 and if size is greater than 0, increment the current bytes and write the data to file, otherwise exit the loop (28-40)
- Set the value of the returned Content-Range header to crange and if initial size (0), set the file size to the size variable (42-46)
- If the file is smaller than the chunk size, adjust the chunk size down to the total file size and continue (51-55)
- Do the math to get ready to download the next chunk (57-62)
def _download(host, creds, fp): chunk_size = 512 * 1024 headers = { 'Content-Type': 'application/octet-stream' } filename = os.path.basename(fp) uri = 'https://%s/mgmt/cm/autodeploy/software-image-downloads/%s' % (host, filename) requests.packages.urllib3.disable_warnings() with open(fp, 'wb') as f: start = 0 end = chunk_size - 1 size = 0 current_bytes = 0 while True: content_range = "%s-%s/%s" % (start, end, size) headers['Content-Range'] = content_range #print headers resp = requests.get(uri, auth=creds, headers=headers, verify=False, stream=True) if resp.status_code == 200: # If the size is zero, then this is the first time through the # loop and we don't want to write data because we haven't yet # figured out the total size of the file. if size > 0: current_bytes += chunk_size for chunk in resp.iter_content(chunk_size): f.write(chunk) # Once we've downloaded the entire file, we can break out of # the loop if end == size: break crange = resp.headers['Content-Range'] # Determine the total number of bytes to read if size == 0: size = int(crange.split('/')[-1]) - 1 # If the file is smaller than the chunk size, BIG-IP will # return an HTTP 400. So adjust the chunk_size down to the # total file size... if chunk_size > size: end = size # ...and pass on the rest of the code continue start += chunk_size if (current_bytes + chunk_size) > size: end = size else: end = start + chunk_size - 1
Now you know how to upload and download files. Let’s do something with it!
A Use Case - Upload Cert & Key to BIG-IP and Create a Clientssl Profile!
This whole effort was sparked by a use case in Q&A, so I had to deliver the goods with more than just moving files around. The complete script is linked at the bottom, but there are a few steps required to get to a clientssl certificate:
- Upload the key & certificate
- Create the file object for key/cert
- Create the clientssl profile
You know how to do step 1 now. Step 2 is to create the file object for the key and certificate. After a quick test to see which file is the certificate, you set both files, build the payload, then make the POST requests to bind the uploaded files to the file object.
def create_cert_obj(bigip, b_url, files): f1 = os.path.basename(files[0]) f2 = os.path.basename(files[1]) if f1.endswith('.crt'): certfilename = f1 keyfilename = f2 else: keyfilename = f1 certfilename = f2 certname = f1.split('.')[0] payload = {} payload['command'] = 'install' payload['name'] = certname # Map Cert to File Object payload['from-local-file'] = '/var/config/rest/downloads/%s' % certfilename bigip.post('%s/sys/crypto/cert' % b_url, json.dumps(payload)) # Map Key to File Object payload['from-local-file'] = '/var/config/rest/downloads/%s' % keyfilename bigip.post('%s/sys/crypto/key' % b_url, json.dumps(payload)) return certfilename, keyfilename
Notice we return the key/cert filenames so they can be used for step 3 to establish the clientssl profile. In this example, I name the file object and the clientssl profile to the name of the certfilename (minus the extension) but you can alter this to allow the objects names to be provided. To build the profile, just create the payload with the custom key/cert and make the POST request and you are done!
def create_ssl_profile(bigip, b_url, certname, keyname): payload = {} payload['name'] = certname.split('.')[0] payload['cert'] = certname payload['key'] = keyname bigip.post('%s/ltm/profile/client-ssl' % b_url, json.dumps(payload))
Much thanks to Tim Rupp who helped me get across the finish line with some counting and rest worker errors we were troubleshooting on the download function.
Get the Code
- __J___262279Nimbostratus
In case anyone else struggled with this in powershell (I sure did for a bit). Here is an simple function that will do the trick.
function F5-RestFileUpload { < .SYNOPSIS Upload a file to the BigIP .DESCRIPTION Uploads file to the F5 in to /var/config/rest/downloads directory. .EXAMPLE F5-RestFileUpload -InFile "C:\certs\mycert.pxf" -BigIP "mybigip.local" -Credential $mycreds > [CmdletBinding()] PARAM ( [string][parameter(Mandatory = $true)][ValidateNotNullOrEmpty()]$InFile, [string][parameter(Mandatory = $true)][ValidateNotNullOrEmpty()]$BigIP, [System.Management.Automation.PSCredential]$Credential ) BEGIN { $file = Get-ChildItem $InFile $byte = Get-Content $file.FullName -Encoding Byte $ContentType = "application/octet-stream" $ContentRange = "0-{0}/{1}" -f ($file.length -1), $file.length $path = "/mgmt/shared/file-transfer/uploads" $uri = "https://{0}{1}/{2}" -f $BigIP, $path, $file.name $uri = New-Object System.Uri $uri } PROCESS { $webclient = New-Object System.Net.WebClient $webclient.Headers.Add("ServerHost", $uri.DnsSafeName); $webclient.Headers.Add("Content-Type", $ContentType) $webclient.Headers.Add("Content-Range", $ContentRange) $webclient.Credentials = $Credential try { $response = $webclient.uploaddata($uri.AbsoluteUri, $byte) } catch [Exception] { $PSCmdlet.ThrowTerminatingError($_) } finally { if($null -ne $webclient) { $webclient.Dispose() } } } END { } }
- clammersNimbostratus
hello jason,
sorry for late response but i got it working in 12.1.2 with uploading and also installing certificates with radius auth. Thanks for your support!
- JRahmAdmin
hi @Christian, thanks for the update. I'll test 12.1.2 as well to see if that improves on my end.
- Chris_Hiner_263Nimbostratus
This was very helpful. I ended up having my script build a pkcs12 file and import that, since otherwise I couldn't upload a new key/cert pair if the key changed without getting "profile X's key and certificate do not match".
After the file upload then POST to /mgmt/tm/sys/crypto/pkcs12 with a payload of:
command=install name=name_to_show_in_ssllist from-local-file=/var/config/rest/downloads/nameof.file.pkcs12 passphrase=password_for_pkcs12
- mchaasNimbostratus
Hi all! This post was very helpful indeed. Also the hint with the central authentication and the requirement to upgrade to 12.1.2. However, I probably need another little hint...
When I upload a text-file (haven't tried any binary data yet) to the BigIP with the method described above, the file has a leading 0-byte.
That's the file on my management-host:
[matt@linuxhost rest_bigip]$ hexdump testfile -C 00000000 31 32 33 34 35 36 37 38 39 30 61 62 63 64 65 66 |1234567890abcdef| 00000010 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 |ghijklmnopqrstuv| 00000020 77 78 79 7a 0a |wxyz.| 00000025
after posting it to the BigIP:
[matt@linuxhost rest_bigip]$ curl -X POST https://ixi3-lab-lb2-1/mgmt/shared/file-transfer/uploads/testname.txt -H "Content-Type: application/octet-stream" -H "Content-Range: 1-36/36" -H "X-F5-Auth-Token: XXXXXXXXXXXXXX" -d @testfile -vvv * About to connect() to ixi3-lab-lb2-1 port 443 (0) * Trying 10.150.250.156... connected * Connected to ixi3-lab-lb2-1 (10.150.250.156) port 443 (0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: xxxx CApath: none * SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA * Server certificate: * xxxxxx > POST /mgmt/shared/file-transfer/uploads/testname.txt HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > Host: ixi3-lab-lb2-1 > Accept: */* > Content-Type: application/octet-stream > Content-Range: 1-36/36 > X-F5-Auth-Token: XXXXXXXXXXXXXX > Content-Length: 36 > < HTTP/1.1 200 OK < Date: 15 Feb 2017 15:21:20 UTC < Server: com.f5.rest.common.RestRequestSender < X-Frame-Options: SAMEORIGIN < Strict-Transport-Security: max-age=16070400; includeSubDomains < Pragma: no-cache < Cache-Control: no-store, no-cache, must-revalidate < Expires: -1 < Content-Length: 241 < Content-Type: application/json < Content-Range: 1-36/36 < Local-Ip-From-Httpd: 10.150.250.156 < X-Forwarded-Server: localhost.localdomain < X-Forwarded-Proto: http < X-Forwarded-Host: ixi3-lab-lb2-1 < X-Content-Type-Options: nosniff < X-XSS-Protection: 1; mode=block < Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' http://127.4.1.1 http://127.4.2.1 < * Connection 0 to host ixi3-lab-lb2-1 left intact * Closing connection 0 {"remainingByteCount":0,"usedChunks":{"1":36},"totalByteCount":36,"localFilePath":"/var/config/rest/downloads/testname.txt","temporaryFilePath":"/var/config/rest/downloads/tmp/testname.txt","generation":0,"lastUpdateMicros":1487172080246573}
The file on the BigIP does not look quite the same (note byte 0 being 0x00, as opposed to 0x31 in the original file):
[matt@ixi3-lab-lb2-1:Active:Standalone] ~ xxd /var/config/rest/downloads/testname.txt 0000000: 0031 3233 3435 3637 3839 3061 6263 6465 .1234567890abcde 0000010: 6667 6869 6a6b 6c6d 6e6f 7071 7273 7475 fghijklmnopqrstu 0000020: 7677 7879 7a vwxyz
Also the original "\n" seems to be trimmed off, which isn't a problem in this case. Just mentioning it for the sake of completeness. I tried to use Content-Type: text/plain instead of "application/octet-stream", I tried binary-transfer, nothing seems to help. What am I missing here? Thanks for your help!
regards, Matt
update:
trace-ascii shows that curl seems to be sending the post data correctly
=> Send data, 36 bytes (0x24) 0000: 1234567890abcdefghijklmnopqrstuvwxyz <= Recv header, 17 bytes (0x11) 0000: HTTP/1.1 200 OK
- mchaasNimbostratus
Hi again,
I just fixed this.
-H "Content-Range: 0-35/35"
did the trick.
Thanks!
Regards, Matt
Hi Jason,
thanks for the nice article. Uploading works fine this way even through BIG-IQ used as REST proxy. I hoped
would be supported as well to clean up the temp file from the directory after importing it into the TMOS file store. As a workaround I tried aDELETE
command viarm
which fails with a "401". Allowing/mgmt/tm/util/bash
would help me to avoid aDELETE
to sanitize the upload directory. Cheers, Stephancron
- JRahmAdmin
bash works for me to remove the files, are you specifying the -c argument with it?
Hi Jason, you are right, thanks a lot!
I had a typo in my call. This one works as expected:
curl -svk -H "Content-Type: application/json" -H "X-F5-Auth-Token: ${token" -X POST -d "{\"command\":\"run\",\"utilCmdArgs\":\"-c 'rm /var/config/rest/downloads/mycert.crt'\"}" "https://${bigiq}/mgmt/shared/resolver/device-groups/cm-bigip-allDevices/devices/${bigipuuid}/rest-proxy/mgmt/tm/util/bash" | json-format
We are programmatically uploading files to our F5 devices.
The following command WORKS correctly, but does NOT follow RFC 7233 4.2:
curl -i -sk -u admin:admin -X POST -H "Expect:" \ -H "Content-Type: application/octet-stream" \ -H "Content-Range: 0-1333/1334" --data-binary "@domain.crt" \ "https://192.168.1.1/mgmt/shared/file-transfer/uploads/domain.crt"
The following command does NOT work correctly, but DOES follow RFC 7233 4.2: curl -i -sk -u admin:admin -X POST -H "Expect:" \ -H "Content-Type: application/octet-stream" \ -H "Content-Range: bytes 0-1333/1334" --data-binary "@domain.crt" \ ";
The main difference is the use of the HTTP Header
including the word "bytes" with the values. RFC 7233 4.2 indicates that this should be (example from RFC)Content-Range
Content-Range: bytes 42-1233/1234
However whenever we include the word "bytes" the F5 responds with a HTTP 400, error follows:
HTTP/1.1 400 Bad Request Date: 08 Dec 2017 23:51:54 UTC Server: com.f5.rest.common.RestRequestSender X-Frame-Options: SAMEORIGIN Strict-Transport-Security: max-age=16070400; includeSubDomains Pragma: no-cache Cache-Control: no-store, no-cache, must-revalidate Expires: -1 Content-Length: 135 Content-Type: application/json REMOTEROLE: 0 Local-Ip-From-Httpd: 127.0.0.1 Session-Invalid: true X-Forwarded-Server: localhost.localdomain X-Forwarded-Proto: http REMOTECONSOLE: /sbin/nologin X-Forwarded-Host: 192.168.1.1 X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' http://127.4.1.1 http://127.4.2.1 Connection: close {"code":400,"message":"Missing 'Content-Range' header","referer":"192.168.1.2","restOperationId":66478298,"kind":":resterrorresponse"}%
However whenever we do NOT include the word "bytes" the F5 responds with a HTTP 200 and the file is created on the F5 in the
directory, but again fails to follow follow RFC 7233 4.2 which our application code is enforcing./var/config/rest/downloads