Technical documentation

NCCM stands for Network Configuration and Change Management. It keeps track of the configs of your nodes, and any changes that happen to them over time. It is stored in its own database, alongside compliance which is heavily dependant on it. You can view these tables in the Custom data form in the admin section.

The Nccm_selections table keeps track of all nodes that are maintained in the NCCM. These can be nodes in YCE or the CMDB. It has the following attributes:

• Nodename: The node name
• Server: This field is used by the yce_nccmd daemon to claim this node: if this field has a value, no other yce machine may claim this node.
• Schedule_servers: All possible servers that have access to this node, determined from the sched_rules.conf file
• Disable_polling: an number to determine whether this node should be polled:
  • 0: The node can be polled
  • 1: Something went wrong and polling is halted, the node will not be polled
  • 2: The node is disabled and will not be polled
• Current_base_id: The node's most recent nccm entry
• Marked_id: refers to the 'config diffs' tool where an operator can manually select the NCCM config to restore and mark it as such.
• Task_mask: a mask
  • Bit 1: on if the nccm poll should be followed up by a compliance check.
• Next_poll_time: The next time this node should be polled for compliance. This is determined by the values in the node's polling group.
• Last_successfull_poll: The last time the node was polled successfully
• Last_failed_poll: The last time the node was polled unsuccessfully
• Failed_polls: The number of failed polls. Whenever a threshold is reached, the node is disabled for NCCM. Whenever the node is successfully polled, this counter is reset
• Total_successfull_polls: The total number of successful polls for this node
• Total_failed_polls: The total number of unsuccessful polls for this node. This counter is not reset
• Comment_str: Any comment string for feedback

The Next_poll_time and how many Failed_polls should be tolerated are dependent on the node's polling groups.

Polling groups can contain a number of node groups. A node can therefore have more than one polling group. If any attributes conflict for such a node, the minimum value is picked. A polling group has the following attributes:

• Polling_group_id: The polling group's id
• Group_name: The polling group's name
• Polling_group_type: The polling group's type:
  • 0: This polling group consists of node groups
  • 1: This polling group consists of nodes
• Node_groups: The polling group's node groups or nodes, depending on its type, separated by pipes, can be zero or more
• Next_poll_interval: After an nccm poll finishes, how many hours should it take until the next poll?
• Max_retries: After how many timeouts a node should be disabled automatically from the NCCM poller. Minimum value of 0, maximum value of 999. Setting the value to '0' will always keep the node enabled for polling.

The Nccm_data table keeps track of all nccm polls. Since these tables can grow quite large, they are split into weekly tables for added stability. The table Nccm_data_all and Nccm_data_quarter combine those together into just one table for all records, or all records of the past three months respectively. They have the following attributes:

• Nccm_id: The record's id.
• Nodename: The node's name. Equivalent to hostname, links to the Nodename in Nccm_selection.
• Node_fqdn: The node's fqdn, if applicable
• Baseconfig_id: Links to the Nccm_id that is the base config for this poll.
• JobID: The job that lead to this record, if applicable
• Operator: The operator that scheduled this record. Or nccm if scheduled by the nccmd daemon.
• Nccm_cause: A description of what caused the nccm record.
• Nccm_status: The status of this nccm record

The Nccm_diff table contains the actual configs. Their records correspond one-on-one to the Nccm_data table, linked by their Nccm_id. This table too is split in weekly tables, and they are combined together in the Nccm_diff_all and Nccm_diff_quarter tables. This is where the Baseconfig_ids come in. Since most changes in configs only relate to a part of a config, saving the whole config for every single poll would create a lot of waste. Base configs are therefore saved as whole configs, and diffs just store the lines that are different from their base config.

The Nccm_diff tables have the following attributes:

• Nccm_id: The nccm id. A one-to-one link with the Nccm_data Nccm_id column.
• Nodename: The node's hostname.
• Config_text: The config's text in the case of a base config. The config diff in the case of a diff config.

Please note that any text that changes every time (for example cyphers and timestamps) are filtered out so that they don't trigger false positives. We also filter out passwords for security reasons.

Main article The NCCMD Daemon