Configurable Settings - .NET Agent Controller on Windows for Dynamic Anaysis



How to apply changes to the Controller environment

Changes in the installation.yaml can be applied by running the install script or the upgrade script. Note that re-running the install script will delete any information that would have been stored previously.


Required fields in installation.yaml

Variable Name
Key Value
Explanation of the Variable and Key Values
controller.name
String This will be the identifier used in the VF Server UI. So, this should be as precise a name as possible, e.g. "UAT Viper" or "Prod App1"
controller.host
String The controller.host is the address that the vFunction Server address with which the Controller will connect. The value needs to start with http:// or https://. The value can be an IP Address or a FQDN
controller.org_id
controller.app_id
controller.client_id
controller.client_secret
Strings Once the Server is installed, the Admin can log into the UI and create the App. In the UI's Install Controller dialog box, the YAML values for the org_id, app_id, client_id and client_secret will be displayed. The values for this YAML file should be copied for the Server UI to here
controller.type
String "dotnet"
agent.version
String
  • The potential strings that can be used are: framework, dotnet
  • Use "dotnet" for .NET 6.0 / 7.0 / 8.0, .NET Core 3.x
  • Use "framework" for .NET Framework 4.x
agent.environment
String
  • The potential strings that can be used are: "iis", "service", "command"
  • This choice is defined by the startup workflow of the application
  • Use "iis" if the application starts as an IIS Web App
  • Use "service" if the application starts as a Windows Service
  • Use "command" if the application starts via the Command Line

Sample with required fields in installation.yaml

controller:
  name: Prod App1
  host: http://10.0.0.143
  org_id: 3cf59199-0a0a-0a0a-0a0a-7c63ffac776e
  app_id: 7b1ab58d-0a0a-0a0a-0a0a-098a113ad721
  client_id: 20761b99-0a0a-0a0a-0a0a-94c2e0bc1859
  client_secret: 6b5b7bc1-0a0a-0a0a-0a0a-2bd10db75e2f
  type: dotnet
  instrconf_additions:
    inclusions:
    exclusions:
server_application:
agent:
  version: dotnet
  environment: iis
viper:
  port: 8091
  aseemblies:
    - C:\appDir

Optional fields in installation.yaml


agent.application_command

Installation.yaml Configuration
Details

The Path in the Application Command will need to be escaped. This is why they example below includes two backslashes at each folder level.



agent:
   application_command: C:\\Windows\\system32\\inetsrv\\w3wp.exe -ap "DefaultAppPool"
  • Used to input the command to start the Application from the Command Line
  • Used when the Agent parameters are added to the Environment System Variables
  • Ensures that only the relevant Dotnet Application is hooked and that other processes do not pick up the vFunction Startup Parameters.
  • Used typically in Azure App Services deployments

agent.application_name
Installation.yaml Configuration
Details
agent:
   application_name: vfunction-dotnet-app
  • Used in Azure App Services deployments when the Agent parameters are added to the Environment System Variables
  • Ensures that only the relevant Dotnet Application is hooked and that other processes do not pick up the vFunction Startup Parameters

agent.architecture
Installation.yaml Configuration
Details
agent:
   architecture: x86
  • Used in Azure App Services deployments to define whether the application is 32-bit or 64-bit
  • The two available strings that can be used for values are "x86" and "x64"

controller.agent_port
Installation.yaml Configuration
Details
controller:
   type: dotnet
   agent_port: 9778
  • If the agent_port identified is in use, change the port to use an unused port.

controller.instance_id
Installation.yaml Configuration
Details
controller:
   instance_id: containerized
  • Used for containerized vFunction controllers
  • Can be set to any String value (e.g., ID1234)
  • Used to prevent an ongoing increase in the number of Down Controllers in the vFunction Server UI's Select Controllers page when Controllers are down
  • Maps a restarted controllers (i.e., a container that went down and came back up) with a controller in the down state that has the same ID

Optional fields in global.yaml


controller.poll_interval_secs
Global.yaml Configuration
Details
controller:
   poll_interval_secs: 10
  • Polling is the interval for the Controller to ask the vFunction Server what it should be doing
  • If the Controller is not in a state of active learning, the Controller will poll the server to see what it should be doing
  • If not explicitly defined, the default interval of 5 seconds is used

controller.upload_interval_secs
Global.yaml Configuration
Details
controller:
   upload_interval_secs: true
  • The interval when the Controller will attempt to upload all of the Application's Call Stacks to the vFunction Server
  • If not explicitly defined, the default interval of 15 seconds is used

general.custom_logs_folder
Global.yaml Configuration
Details
general:
   custom_logs_folder: C:\custom_log_directory\
  • If not explicitly defined, the default logs directory is BASE_INSTALL_DIRECTORY\logs\

general.custom_sleep_after_service_start
Global.yaml Configuration
Details
general:
   custom_sleep_after_service_start: 10
  • The amount of wait time after the Controller or Viper Services are started before looking for an associated Process ID
  • If not explicitly defined, the default value of 1 is used

general.custom_sleep_after_service_stop
Global.yaml Configuration
Details
general:
   custom_sleep_after_service_stop: 10
  • The amount of wait time after the Controller or Viper Services are stopped before looking for an associated Process ID
  • If not explicitly defined, the default value of 1 is used

proxy.url
Global.yaml Configuration
Details
proxy:
   url: http://proxy_url:8172
  • If traffic from a Controller to a vFunction Server needs to be routed through an intermediary, the Proxy address and Port can be defined here

Client Certificates for a Controller

Adding a Client Certificate and Key to the Controller allows for the vFunction Server and Controller to have some form of verification.

The Controller loads and sends the Client Certificates to a Server that verifies the source of the traffic. That Server could be set up as an intermediary that manages token validation, such as an IBM DataPower Gateway, before being sent onto the vFunction Server.

The vFunction Nginx Container could also be configured to “ssl_verify_client on” and point to the Client Certificate which would be loaded on the Nginx Container’s filesystem somewhere like /etc/nginx/certs/ca.crt.

To use Client Certificates, place a client_certificate.crt and client_certificate.key file into the vFunction Instance’s Configuration directory. For example:

  • C:\vfunction\config\installation\instances\default-java\client_certificate.crt
  • C:\vfunction\config\installation\instances\default-java\client_certificate.key

The contents of the client_certificate.crt should be formatted as:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

The contents of the client_certificate.key should be formatted as:

-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----