Forums General Launch a Scripting Policy via API

Launch a Scripting Policy via API

Forums General Launch a Scripting Policy via API

Tagged: 

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #685
    Jim Birley
    Participant

    First question: Can you execute a script policy via API against a known target host?
    Second question: If yes, is the POST method using the /scriptingDeployments/ API endpoint the right place to accomplish this?
    Final Question: If yes, how do you structure the JSON Body required for a successful execution?

    I noticed in the swagger interface that the required Body’s sample is listed as follows:

    {
      "workspace": "/api/v3/onefuse/workspaces/1/",
      "scriptingPolicy": "/api/v3/onefuse/scriptingPolicies/1/",
      "templateProperties": {}
    }

    I assume that the workspaces id and the scriptingPolicies id are easy to understand and populate based on interrogating the /scriptingPolicies/ endpoint via GET request. My question is about the templateProperties section. I can see that it’s a nested construct, but I don’t know what properties (or nested sub-properties) that I need to provide.

    I wrote a PowerShell wrapper function to try to achieve this, but I am encountering an error that says “policy” is a required field, e.g.,

    Line |
    47 | $Response = Invoke-RestMethod @Params
    | ~~~~~~~~~~~~~~~~~~~~~~~~~
    | {“code”:400,”errors”:[{“message”:”policy: [‘This field is required.’]”}]}

    Here is my $Params hashtable that I splat to Invoke-RestMethod:

        $Params = @{
            Method               = 'POST'
            Uri                  = $Uri
            SkipCertificateCheck = $true
            ContentType          = "application/json"
            Headers              = $Headers
            Body                 = $JsonBody
        }

    (My $Headers variable just contains the Bearer token and I know that works because I use it in other functions).

    The $JsonBody variable contains:

    {                                                            
      "workspace": "/api/v3/onefuse/workspaces/2/",              
      "scriptingPolicy": "/api/v3/onefuse/scriptingPolicies/12/",
      "templateProperties": {                                    
        "hostname": "Server001",                 
        "policy": "LinuxCreateFile"                              
      }                                                          
    } 

    (hostname is obfuscated)

    Thanks for any help!
    Jim

    #687
    Sid Smith
    Keymaster

    Yes it is possible to call scripting policies via the api. You don’t want to call /api/v3/onefuse/scriptingPolicies/ though. You would call that to create a new scripting policy. If you want to execute a policy you want topost to /v3/onefuse/scriptingDeployments/. You can view the swagger interface at https://app.swaggerhub.com/apis-docs/cloudbolt/OneFuse/1.2. You can also go to https://yourOneFuseFQDN/api-docs.

    It may also help you if you do a dpeloyment using vRA and then go to the managed object, view the job and you can see the API call that was made as well as inputs that were passed in from the call. I looked at the API docs and it shows the available inputs you can pass but doesn’t show template_properties which you will want to pass as well for anything you configured as variables in your scripts.

    If you need more on this let me know.

    Sid

    #700
    Jim Birley
    Participant

    Thanks Sid. I’ve been “distracted” a bit the last day or so. You’re advice about looking at the inputs definitely helped. I also didn’t make it clear in my first post that I am using the POST method call to the /scriptingDeployments/ endpoint. The snippet I included came straight from the swagger interface as a sample Body payload to be used when targeting the POST /scriptingDeployments/ endpoint.

    {
      "workspace": "/api/v3/onefuse/workspaces/1/",
      "scriptingPolicy": "/api/v3/onefuse/scriptingPolicies/1/",
      "templateProperties": {}
    }

    I think there is an error in this sample because the API is looking for a “policy” property, not a “scriptingPolicy” property. I pieced this together by looking at the error response message and the inputs from a successful run from a build. So now it just comes down to filling in whatever it expects with the templateProperties section.

    Here is the thing with the inputs that we pass to the scripting API in OneFuse: we have a TON of properties! The vast majority cannot be used in the successful execution of a simple script. I am trying to take a minimalist approach and only add what is needed to get a simple script executed and work my way up to more complex scenarios. Here is the Json Body that I currently build in my script:

        $JsonBody = [pscustomobject]@{
            workspace          = "/api/v3/onefuse/workspaces/2/" 
            policy             = "/api/v3/onefuse/scriptingPolicies/12/"
            templateProperties = @{
                OneFuse_VmNic0 = @{
                    hostname = $HostName
                }
            }
        } | ConvertTo-Json

    I can now get the /scriptingDeployments/ to Initialize the Script Policy and create a Job. However the Job fails with the following error code:

    {"code": 400, "errors": [{"message": "Policy action job '90bf7b0a-1d8b-4940-a5d6-84f717f5bb18' failed: Host is required for SSH Provider"}]}

    I got further because I see the job gets initialized, but I am still at a loss for determining what properties MUST come over in the Body section. Like I said, I scoured the INPUTS from other job runs, but I cannot seem to find the right candidates. Also, I don’t think it would be wise to post the inputs on a public forum.

    Thanks again,
    Jim

    #701
    Jim Birley
    Participant

    I finally figured it out with much trial and error. This construct will execute a generic (no additional “template properties”) scripting policy. (The policy id and workspace id would vary as well as the fqdn, of course. I plan to parameterize these details in my function).

    {                                                   
      "workspace": "/api/v3/onefuse/workspaces/2/",     
      "policy": "/api/v3/onefuse/scriptingPolicies/12/",
      "templateProperties": {                           
        "OneFuse_VmNic0": {                             
          "fqdn": "server01.example.com"           
        }                                               
      }                                                 
    } 

    Now I’m confidant that I can add additional template properties alongside “OneFuse_VmNic0” when the specific scripting policy I am targeting requires it. (I’ll likely accept a hash table construct as an optional parameter and add the property/value pairs to the payload).

    To be honest, this should be the example Json body in the swagger interface. It would have saved me a ton, but I learned a lot along the way.

    Thanks again as always Sid,
    Jim

    #702
    Sid Smith
    Keymaster

    Jim,
    Sorry for the delayed response. Glad to see you figured out and great feedback! I added a note to create a blog around this topic. Thanks for sharing your experience and what you put together. Great stuff!

    Sid

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.

Comments are closed.

Skip to toolbar