Skip to main content

Installation

Q247 can connect to the version control system in two ways: from Q247's secure cloud infrastructure (Cloud Plugin) or through a plugin installed locally, in the Client's infrastructure (Private Plugin). Functionally both modes work the same; they differ only in where the scanning process physically runs.

Deployments are managed in Configuration, in the Plugins section. Each deployment has its own mode marker on the list, Cloud or On-Premise, and its own list of Connectors.

Plugins section with the list of deployments and their connectors

Cloud Plugin​

This is the default mode. It requires no configuration in the Q247 UI, nor any involvement from the Client's DevOps team, apart from one thing: opening network access from the Cloud Plugin to the Client's SCM system. Cloud Plugin is available to every client and enabled by default.

At the Client's request, an additional layer of security can be added between the Cloud Plugin infrastructure and the Client's infrastructure, for example a dedicated VPN channel. Full security details are described in Enterprise Plugin Security.

Connection requirements for Cloud Plugin​

Network routing has to be opened between the Q247 cloud plugin's outbound address and the REST API endpoint of the Client's SCM system. The current address is provided by the Q247 deployment team.

Private Plugin​

The Client creates its own deployment in the panel, downloads the configuration file and the plugin file for it, and runs the process in its own infrastructure.

1. Creating a deployment​

In Configuration, in the Plugins section, the Add Plugin button opens a form with a single field.

Add plugin form with a name field

FieldWhat to enterExample
Namea unique deployment name, to recognize it on the listWarsaw Plugin

Once confirmed, the deployment appears on the list, marked as On-Premise, with an empty connector list.

2. Downloading the files​

Two files are needed, and they are downloaded from two different places:

  • Config, a button next to the specific deployment on the list. Downloads the configuration file generated for that deployment. The button appears next to On-Premise deployments.
  • Plugin File, a button in the header of the Plugins section. Downloads the latest version of the plugin itself. It appears once the organization has at least one On-Premise deployment.
Order of downloading the files

The configuration file is generated for a specific deployment, so create the deployment first, and only then download the files. Before adding the first On-Premise plugin, neither of these two buttons is on the screen.

Both files (config.cfg and q247-enterprise-plugin-linux-*) must land in the same directory on the target server.

3. Installation and startup​

Starting the plugin:

nohup ./q247-enterprise-plugin-linux --q247-ep-plugin-prod > q247-plugin.log 2>&1 &

Checking whether the process is actually running:

# ps -efww | grep -i q247
q247 1372705 1 5 Apr17 ? 15:59:29 ./q247-enterprise-plugin-linux --q247-ep-plugin-prod

While running, the plugin uses these files and directories:

  • q247-plugin.log: plugin logs.
  • q247-working: working directory, where the plugin temporarily stores data fetched from Git repositories.
  • plugin.data, plugin.data-shm, plugin.data-wal: the plugin's local data store files.

The configuration file downloaded from the panel is ready to use and requires no editing. It already contains the backend address and the deployment credentials, and settings such as Jira and Confluence integration support or the plugin's operating mode are prepared by the Q247 deployment team before handing over the file.

Preparing the Client's environment​

Beyond simply starting the process, the plugin requires a few things on the infrastructure side. All of these are agreed with the Q247 deployment team during the deployment phase.

Network access​

The plugin connects outbound: to the version control system, to the Jira and Confluence instances, and to the Q247 backend.

If the Jira or Confluence integrations run in the Data Center variant, inbound traffic from those instances to the plugin is added. The port on which the plugin listens for webhooks then has to be made available. The port number for a given deployment is provided by the deployment team, and the traffic stays inside the Client's network.

TLS certificate for the webhook receiver​

The webhook receiver can work over HTTPS, which requires providing a certificate and private key for the address under which the plugin will be visible to Jira and Confluence.

A missing certificate does not stop the plugin

The plugin will then start with unencrypted listening and keep working, with no error visible in the Q247 panel. Webhook traffic stops being encrypted even though the configuration looks complete, which is why it is worth confirming the certificate at the start of the deployment, not after the fact.

Proxy and TLS inspection at the firewall​

If outbound traffic from the Client's network goes through an explicit proxy, its address and any authentication data need to be given to the deployment team. A transparent proxy requires nothing.

If the firewall terminates TLS connections and re-signs them with its own certificate, the plugin will not recognize the Q247 backend's certificate and the connection will fail. In that case the Client provides a PEM file with the corporate CA certificate. The same applies to a situation where the Jira, Confluence or Git server instance has a certificate from a private CA.

See also​