Security and integrity

What you will do: run a sync task whose transport is encrypted, whose credentials are held in one place, and whose every file is verified and accounted for.

Flux moves files between XPLG instances, so it inherits the platform's transport and account model, and adds its own checksum and notification mechanisms per task. The wiki describes the result as fast, managed, encrypted and centralized synchronization with end-to-end encryption; the controls below are how that is configured.

Transport

• Hub to agent, and hub to proxy to agent, is HTTP/S on the agent's XPLG port; choose HTTPS on the Remote account and open the port in that direction only. Traffic is compressed by default (Compress Traffic on the account).
• Certificates and cipher policy are the customer's, as for every XPLG surface; no call-home channel exists. See Security posture.
• Isolated segments are reached through proxy instances declared in <ProxyRemote>, so the hub never needs a route into the segment; see Install agents.

Accounts and credentials

• Every agent and proxy is a Remote XpoLog account in the hub's Address Book (PortX > Data > Account); passwords are stored with industry-standard algorithms and verified from the console. The task XML names the account, never a credential.
• An agent in Agent Mode stores no data (the wiki recommends the mode for collection-only agents; see Install agents) and only needs read access to its sources; give it a scoped account on those sources.
• The agent typically runs under a more limited license.

Integrity

• A <Checksum> tag — at the configuration level or inside a node — computes MD5 or SHA-1 per file at the set interval, retries retryAttempts times and mails mailRecipients on a mismatch. Checksums on large files cost time; see Performance tuning.
• Force Log Sync (Checksum mismatch) re-syncs only the files that differ on the next run; Force Log Sync (All) re-syncs files deleted from the repository but still present at the source.
• metricevent.log records the state of every file (NEW, NOT_CHANGE, UPDATE, DELETE, FAIL, CHECKSUM, COMPLETED) with the task, job and source ids; metricinfo.log records bytes read and written per block, so the volume stored can be reconciled against the source.
• Data in the repository (file system or S3) is protected by the storage you choose; the platform supports encryption at rest by default and LUKS, BitLocker or cloud-KMS volumes underneath. The archive checksum of a Collection Policy is a separate mechanism for XPLG's own archive; see Collection policies and archive.

Failure handling

<NotificationsService> sets how many failures (failureNumberOfRetries) within what time (failureRetriesTime) raise an alert and how often it repeats (failureNotificationKeepSendTime); <Notifications supportedTypes="FILE_READ_FAILURE,FILE_WRITE_FAILURE,TASK_FAILED"> sends a script, an email or a REST call — for example into an XPLG HTTP/S listener so the failure becomes a searchable event and a monitor. FILE_COMPLETED and FILE_DELETE notifications give a positive record per file. See Sync task reference.

Steps

1. Set the Remote accounts to HTTPS and verify them from the hub.
2. Add a <Checksum> with an interval the data size allows and the operations mailbox as recipient.
3. Add a <NotificationsService> for the three failure types, with a REST task into the hub's listener, and markCompletedTime on every directory.
4. Ingest metricinfo.log and metricevent.log into XPLG; a monitor on FAIL and CHECKSUM states with a risk level closes the loop.
5. Keep the XPLG audit log of the hub: it records every change to tasks and accounts.

Next: Integrations overview

Source: XPLG wiki, pages 2199027716, 2199191556, 2198994949, 2199224325, 2353528833, 2199093250, 1594132790, 2054684673, 3161489464, 3162013701, 1594132942 (https://xpolog.atlassian.net/wiki/spaces/XPOL/pages/2199027716).