Insight administration and deployment

Capuris Insight may run as a single virtual appliance or as a multi-node analytics cluster. Plan hostname, DNS, time, addressing, storage, node roles, backup, and recovery before installation.

Plan the virtual environment

Prepare a supported hypervisor or cloud environment, the approved Insight installation image, the installation passcode or key, and the target network design.

Reserve rather than oversubscribe critical resources. Capacity depends on ingest rate, retained analytics data, concurrent searches, protocol processing, and cluster role.

Install an Insight node

1. Create the virtual machine with the approved CPU, memory, disk, firmware, and network settings.
2. Attach management and data interfaces to the intended virtual networks.
3. Mount the Insight installation ISO.
4. Boot the installer and provide the deployment passcode or key when requested.
5. Configure hostname, addresses, gateway, DNS, and time source.
6. Complete installation and detach the ISO before reboot.
7. Open the Insight interface and install the evaluation or production license.
8. Verify service health and perform a small search.

Record the as-built virtual hardware and every network-interface mapping. A reversed management and data interface can look like a software failure later.

Change the bound hostname

Changing the Insight hostname affects certificates, cluster membership, name resolution, and worker connections.

Before the change, confirm forward and reverse DNS, update any dependent firewall or certificate records, and back up the current configuration. Apply the new hostname through the supported administration workflow, restart only the required services, then validate:

• local hostname resolution;
• browser access and certificate identity;
• database and cluster connectivity;
• router and bootstrap peers;
• worker-agent connections;
• capture-appliance access.

“Temporary failure in name resolution” indicates that the node cannot resolve a required name. A worker connection failure after a rename usually means DNS, known-host, certificate, or bootstrap configuration still references the old identity.

Update Insight software

Use only an approved package for the installed version and architecture.

1. Review release notes, compatibility, required downtime, and rollback guidance.
2. Back up the analytics database and configuration.
3. Confirm cluster health, free space, and active jobs.
4. Copy the update archive to the documented staging directory, commonly /var/tmp.
5. Verify package checksum and ownership.
6. Switch to an authorized administrative account and run the supplied update procedure.
7. Allow the installer to finish; do not interrupt it because the interface temporarily disconnects.
8. Confirm version, services, roles, data, searches, reports, and worker connectivity.

In a cluster, follow the documented node order and verify health between stages. Preserve update logs if any validation fails.

Manage accounts and settings

Administration Manager creates, edits, and removes Insight accounts. Use named identities, least privilege, and a documented owner. Before deletion, reassign scheduled work, saved searches, or operational responsibility associated with the account.

Settings control platform behavior such as display theme and system-health thresholds. Apply health thresholds that match the actual node capacity; defaults may not reflect a large or small deployment.

Administration Logs record configuration and operational events. Some messages expose action buttons; review the full message, affected node, and change impact before invoking an action from a log entry.

Understand cluster roles

An Insight cluster can separate routing, bootstrap, database, and distributed-processing responsibilities. Exact role names and combinations depend on the installed release.

• Routers accept or direct work.
• Bootstrap servers help nodes form or rejoin the cluster.
• Database roles retain platform state and analytics data.
• Distributed roles process searches and other workloads.

Do not remove the last node carrying a required role. A service restart may temporarily disconnect routers or peers; wait for health to converge before making the next topology change.

Verify known hosts

Cluster Known Hosts protects node-to-node identity. Compare the displayed key or fingerprint through a trusted channel before accepting it. If a host is rebuilt or legitimately changes keys, remove the stale record only after verifying the new identity.

Never approve an unexpected key merely to clear a connection warning.

Build a cluster

Command-line workflow

Use the supplied management script for the installed version.

1. Confirm that every node resolves every peer and shares synchronized time.
2. Verify required ports and host keys.
3. Bootstrap the first cluster node.
4. Join additional nodes one at a time.
5. Assign database roles with the required redundancy.
6. Assign distributed-processing and router roles.
7. Verify cluster health and run a small test search.

Graphical workflow

The graphical setup follows the same order: bootstrap the cluster, add nodes, assign database roles, then assign distributed roles. Treat a connection error as a health signal; inspect DNS, routing, firewall, certificates, known hosts, and services before retrying.

Change roles or nicknames

Use nicknames that remain meaningful when addresses change, such as site and role. For a role update, verify redundancy and data movement requirements first. Change one node at a time and wait for restore or rebalance operations to complete.

Messages such as “Restoring data,” “Disconnect error,” or “Connection Error” need context. A temporary disconnect during a planned restart may be expected; a node that does not rejoin requires service, network, or cluster evidence before another change.

Back up and restore the analytics database

Back up the database on a schedule that matches the organization’s recovery-point objective. Store copies outside the cluster and protect them as sensitive operational data.

Test restoration on an isolated system. Record the backup version, cluster version, start and finish time, size, checksum, and restore result. A browser request timeout does not necessarily mean the server-side backup stopped; check job and log state before launching another copy.

Restart or stop cluster services

Before a service action, identify the node roles, active jobs, and redundancy that remain. Restart one node at a time unless the official procedure explicitly requires a coordinated stop. After each action, verify service state, cluster membership, database health, queue progress, and a representative user workflow.

Upload PCAP for analytics

PCAP data can be staged through File Manager or an approved Insight client. Choose an authorized destination, wait for transfer completion, verify size or checksum, and then refresh or index the source. Do not submit partial uploads for analysis.

For using the resulting dataset, continue with Insight analytics.