guides:reference:compliance:cmpl_xch
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
guides:reference:compliance:cmpl_xch [2021/10/22 06:02] – ↷ Links adapted because of a move operation pgels | guides:reference:compliance:cmpl_xch [2024/07/03 12:31] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | {{indexmenu_n> | ||
+ | |||
+ | ===== Compliance XCH API ===== | ||
+ | |||
+ | At the moment we support four different API calls for NCCM and compliance: | ||
+ | * **nccm_run: | ||
+ | * **nccm_submit: | ||
+ | * **cmpl_run: | ||
+ | * **cmpl_report: | ||
+ | |||
+ | ==== Forcing an NCCM poll ==== | ||
+ | |||
+ | You can also force an NCCM poll through the exchange server. A sample exchange XML call looks like this: | ||
+ | |||
+ | <code xml> | ||
+ | < | ||
+ | <head | ||
+ | userid=" | ||
+ | passwd=" | ||
+ | task_type=" | ||
+ | task_name=" | ||
+ | /> | ||
+ | <request | ||
+ | node_name=" | ||
+ | fqdn=" | ||
+ | /> | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | The parameters you can send are simple: | ||
+ | * **node_name: | ||
+ | * **fqdn:** the node's fqdn. If no node_name is provided, we try to find the node based on its fqdn, which can be an ip or string. | ||
+ | |||
+ | These nodes will be scheduled for an NCCM poll and they will be picked up on the nccmd daemon' | ||
+ | |||
+ | |||
+ | ==== Submit a manual NCCM configuration | ||
+ | |||
+ | The configurations are normally retrieved from the nodes (jobs, nccm poll). But sometimes it could be desired to upload a configuration directly into the NCCM. For example when a node configuration cannot be retrieved directly and a NCCM report or Compliance check is required anyway. | ||
+ | |||
+ | The '' | ||
+ | |||
+ | The configuration can be submitted with an optional attribute, '' | ||
+ | |||
+ | As the configuration will be embedded in the XML-formatted API call, precautions must be taken to prevent conflicting XML characters in the configuration. Two options exists to achieve this. | ||
+ | |||
+ | First the configuration can be **encoded** using HTML codes. The ''<'' | ||
+ | |||
+ | An example of this call using encoding: | ||
+ | <code xml> | ||
+ | < | ||
+ | < | ||
+ | userid=" | ||
+ | passwd=" | ||
+ | log_level=" | ||
+ | task_type=" | ||
+ | task_name=" | ||
+ | xml_decode=" | ||
+ | <request > | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | # | ||
+ | # This configuration is automatically generated at 2022-06-09 16:59:00 | ||
+ | # | ||
+ | hostname & | ||
+ | |||
+ | snmp-server localhost | ||
+ | # | ||
+ | interface loopback | ||
+ | address 127.0.0.1 255.255.255.255 | ||
+ | # | ||
+ | end | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | The second option is to insert the configuration as **CDATA**. This encapsulates the configuration using the header ''< | ||
+ | |||
+ | The same example using CDATA for the configuration: | ||
+ | <code xml> | ||
+ | < | ||
+ | < | ||
+ | userid=" | ||
+ | passwd=" | ||
+ | log_level=" | ||
+ | task_type=" | ||
+ | task_name=" | ||
+ | <request node_name=" | ||
+ | < | ||
+ | # | ||
+ | # This configuration is automatically generated at 2020-06-09 16:59:00 | ||
+ | # | ||
+ | hostname < | ||
+ | |||
+ | snmp-server localhost | ||
+ | # | ||
+ | interface loopback | ||
+ | address 127.0.01 | ||
+ | # | ||
+ | end | ||
+ | ]]></ | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | The response to these calls: | ||
+ | <code xml> | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | nccm_status=" | ||
+ | request_error=" | ||
+ | request_status=" | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | action=" | ||
+ | job_descr=" | ||
+ | node_domain=" | ||
+ | node_fqdn=" | ||
+ | node_name=" | ||
+ | node_vendor=" | ||
+ | operator=" | ||
+ | session_type=" | ||
+ | state=" | ||
+ | verbose=" | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | If a configuration was determined as unchanged, the response '' | ||
+ | |||
+ | The response will also return the node details it used to create the NCCM entry like the fqdn, vendor and domain name. | ||
+ | |||
+ | ==== Forcing a Compliance check ==== | ||
+ | |||
+ | You can also force a Compliance check through the exchange server. A sample exchange XML call looks like this: | ||
+ | |||
+ | <code xml> | ||
+ | < | ||
+ | <head | ||
+ | userid=" | ||
+ | passwd=" | ||
+ | task_type=" | ||
+ | task_name=" | ||
+ | /> | ||
+ | <request | ||
+ | node_name=" | ||
+ | fqdn=" | ||
+ | /> | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | The parameters you can send are simple: | ||
+ | * **node_name: | ||
+ | * **fqdn:** the node's fqdn. If no node_name is provided, we try to find the node based on its fqdn, which can be an ip or string. | ||
+ | |||
+ | These nodes will be scheduled for compliance and they will be picked up on the nccmd daemon' | ||
+ | |||
+ | |||
+ | |||
+ | ==== Requesting reports ==== | ||
+ | |||
+ | You can request reports with the same search filters as you can in the reports form (for more information, | ||
+ | |||
+ | <code xml> | ||
+ | <task response=""> | ||
+ | <head | ||
+ | userid=" | ||
+ | passwd=" | ||
+ | task_type=" | ||
+ | task_name=" | ||
+ | /> | ||
+ | <request | ||
+ | type=" | ||
+ | report_template_id=" | ||
+ | hostname=" | ||
+ | policy_id=" | ||
+ | policy_name=" | ||
+ | rule_name=" | ||
+ | vendor_type=" | ||
+ | group_name=" | ||
+ | detail_level=" | ||
+ | status=" | ||
+ | severity=" | ||
+ | report_summary=" | ||
+ | /> | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | * **type:** The report type. Mandatory | ||
+ | * ' | ||
+ | * ' | ||
+ | * **report_template_id: | ||
+ | |||
+ | Either one of these following is mandatory, to prevent overloading the system | ||
+ | * **policy_id: | ||
+ | * **group_name: | ||
+ | |||
+ | Additional parameters to set as filters: | ||
+ | * **hostname: | ||
+ | * **policy_name: | ||
+ | * **rule_name: | ||
+ | * **vendor_type: | ||
+ | * **detail_level: | ||
+ | * 0: Only only the basic policy or node information | ||
+ | * 1: Up to conditions - default | ||
+ | * 2: Up to condition details | ||
+ | * 3: Up to condition full details - this will return everything | ||
+ | * **status:** 1 (" | ||
+ | * **severity: | ||
+ | * **report_summary: | ||
+ | |||
+ | |||
+ | A sample return is as follows: | ||
+ | |||
+ | <code xml> | ||
+ | < | ||
+ | <head abort_on_error=" | ||
+ | < | ||
+ | </ | ||
+ | <request Group_name=" | ||
+ | < | ||
+ | <reports Compliance=" | ||
+ | <reports Compliance=" | ||
+ | <reports Compliance=" | ||
+ | </ | ||
+ | </ | ||