Replicating repositories and working with multiple repositories

Large organizations with remote sites and subsidiaries sometimes require services to be replicated locally to avoid bandwidth congestion (Edge Computing).

Replication and multiple repositories

Repository replication and multiple repositories

New in version WAPT: Enterprise 1.8

WAPT Enterprise offers the possibility to upgrade remote agents to serve as remote repositories that can be managed directly from the WAPT Console. All WAPT agents can then be centrally configured to automatically select the best repository based on a set of rules.

You’ll find in this part of the documentation how to implement such architectures.

Replicating a repository to preserve the bandwidth on remote sites

When WAPT is used on bandwidth limited remote sites, it makes sense to have a local device that will replicate the main WAPT repository to reduce the network bandwidth consumed when deploying updates on your remote devices.

With remote repositories, WAPT remains a solution with a low operating cost because you don’t have to implement high bandwidth fiber links to take advantage of WAPT.

Replicating WAPT repositories

Replicating WAPT repositories

It works as follows:

  • a small form factor and no maintenance appliance with the role of secondary repository is deployed on the local network of each remote site; a workstation can also be used, although it may not be up and running if you want to connect to it;

  • the remote repository replicates the packages from the main repository and other repositories;

  • the WAPT clients connect in priority with the repository that is the closest to them, the local repository;


The former method used to sync repositories was Syncthing and that method is available both for the Discovery and the Enterprise versions of WAPT.

You can find the old documentation here: (Deprecated) Replicating repositories with Syncthing.

The method explained below is for the Enterprise version only.

WAPT Agent replication role

New in version WAPT: 1.8 Enterprise

Starting with WAPT 1.8, repository replication can be enabled using a WAPT agent installed on an existing machine, a dedicated appliance or Virtual Machine.

The replication role is deployed through a WAPT package that enables the Nginx web server and configures scheduling, packages types, packages sync, and much more.

This feature allows WAPT agents to find dynamically their closest available WAPT repository from a list of rules stored on the WAPT server.

Replication behavior

Repository replication in WAPT is now handled by WAPT agents natively (Enterprise versions only).

It is based on a sync.json file which indexes every files present in these folders:

  • wapt;

  • waptwua;

  • wapt-host;

Enabling replication has the following effects:

  • once enable_remote_repo is enabled on a WAPT agent, it will sync packages locally inside the local_repo_path folder;

  • it adds the WAPT agent in the Repositories tab as a Remote repository, enabling new actions such as Force Sync or Check files;

  • by default, only the wapt folder is synchronized, you can select which folder to sync by adding up elements in remote_repo_dirs parameters;

  • synchronization period can be configured with local_repo_time_for_sync_start and local_repo_time_for_sync_stop parameters;

  • bandwidth allocated to sync can be configured with local_repo_limit_bandwidth;

Every parameters of WAPT repository sync must be set in the [repo-sync] section of the WAPT agent’s wapt-get.ini configuration file.

WAPT agent replication behavior

Replication role behavior

Enabling replication on WAPT Agent

To enable replication on an existing agent (Linux/Windows) you need to deploy a WAPT package. It’s role is to:

  • install and enable the Nginx web server;

  • configure nginx virtualhost;

  • enable remote repository configuration in wapt-get.ini;

A ready-to-use WAPT package is available in our public store to enable repository replication on Windows or Linux WAPT agents:

WAPT Agent replication configuration

WAPT Agent replication configuration is set in the [repo-sync] section in the wapt-get.ini configuration file of the WAPT agent:



Example value





Enables remote repository sync connections.




Sets local packages root repository path




Sets synchronization start time (HH:MM / 24h format)




Sets synchronization stop time (HH:MM / 24h format)




Sets synchronization periodicity (minutes)




Sets synchronization allowed bandwidth (Mbits/s)




Defines folders to synchronize (default: wapt,waptwua)

Below is an example of wapt-get.ini:

use_repo_rules = True

enable_remote_repo = True
local_repo_path = D:\WAPT\
local_repo_time_for_sync_start = 20:30
local_repo_time_for_sync_end = 05:30
local_repo_sync_task_period = 25
local_repo_limit_bandwidth = 4
remote_repo_dirs = wapt,waptwua,wapt-host
WAPT Server replication configuration

The WAPT server needs to be aware of repositories to sync in the [options] section of its waptserver.ini located in /opt/wapt/conf/:

WAPT Server replication configuration


Example value




Enables remote repository sync server side (sync.json)

Then we must restart both waptserver and wapttasks:

systemctl restart waptserver wapttasks

Repository rules

Repository rules behavior

By enabling repository rules support, the WAPT agents will automatically retrieve their rules.json file from the WAPT server.

The rules.json file is a signed .JSON file that contains a list of sorted rules to apply to the WAPT agent, so to redirect its downloads from the most appropriate repository.

If no rules can be matched, WAPT agent fallbacks onto the repo_url settings of the WAPT server wapt-get.ini configuration file.

WAPT agent replication behavior

Repository rules behavior

Enabling repository rules

Repository rules are configured in WAPT Console.

Rules can be based on several parameters:

Available parameters for repository rules


Example value


Domain name


Rule based on Active Directory domain name

Domain sites and services


Rule based on Active Directory Sites and Services

Agent IP

Rule based on Agent IP sub-network

Public IP

Rule based on Public IP (NATed hosts)



Rule based on hostname

Adding a rule in the WAPT Console

In Repositories, click on the Add rule button. The following window appears:

Creating a new repository rule

Creating a new repository rule

You can then choose from the different above parameters and affect values to a specific secondary WAPT repository. The option No Fallback will prevent from falling back to the main WAPT server and will avoid undesired network congestion if the secondary repository becomes temporarily unavailable.

The rules are applied from top to bottom, and the first rule that matches the conditions overrides all the other rules placed under.

Using repository rules on WAPT agents


If you have configured GeoIP redirects on Nginx, you should disable it as it might conflicts with repository rules.

To enable WAPT Agent repository rules, you must enable this setting in the [global] section of wapt-get.ini configuration of the WAPT agent:



Example value





Enables repository rules usage

Below is an example of wapt-get.ini:

use_repo_rules = True

Working with multiple public or private repositories

Multi-repository is now supported by WAPT. This functionality is useful in several use cases:

  • to use a secondary private repository, hosting business application packages, independently of your main repository;

  • to have remote repositories closer to users in a multi-site architecture scenario;

  • to allow the usage of an open repository and a secondary repository with restricted access (licensed software..);

Multi-repository WAPT architecture

Multi-repository WAPT architecture


When using repositories with different signers, the additional signer’s public certificates must be added to C:\Program Files (x86)\wapt\ssl on Windows or /opt/wapt/ssl on Linux and MacOS. You then must deploy WAPT agent with both keys.

Please refer to the documentation to create the WAPT agent.

Configuring the WAPT agents

  • repositories parameter:

    The parameter repository in the [global] section of the wapt-get.ini file allows to set several options for package repositories, for example private and tranquilit sections here, where their settings are set in additional sections of that file.

  • settings of secondary repositories


    With that configuration, WAPT clients will now see packages from the main repository and from the secondary repository.

    The WAPT agents will look for updates on both repositories.

    wapt-get search

    Packages from the secondary repository will also be visible using the web interface on WAPT equipped devices.

Configuring the WAPT console with several private repositories

After having configured the WAPT agent for using multiple repositories, we can make the two repositories show up in the WAPT console.

To do so, modify %appdata%localwaptconsolewaptconsole.ini file:



.. |deprecated| image:: wapt-resources/deprecated.png
  :scale: 100%
  :alt: This feature is deprecated

(Deprecated) Replicating repositories with Syncthing


WAPT repositories synchronization is now native in WAPT Enterprise.

You can find the new documentation here: Replicating a repository to preserve the bandwidth on remote sites.


This part of the documentation is no longer maintained. You may use it to collect ideas for doing your replication while using the Discovery version.

Introducing Syncthing

deprecated feature

Syncthing is a multi-OS open source peer to peer synchronization utility.

It allows to synchronize folders on several machines while guaranteeing the security, the authenticity and the integrity of the files.

The official Syncthing documentation is available online.

Implementing the replication


The following documentation is applicable to Linux Debian and CentOS/ RedHat based WAPT Servers and remote repositories.

Setting up the remote WAPT repository

Debian Linux
echo  "deb  ./  "  > /etc/apt/sources.list.d/wapt.list
apt update
apt upgrade -y
apt install tis-waptrepo
CentOS/ RedHat Linux

The remote WAPT repository is set up, we now must implement the Syncthing replication.

Configuring the Syncthing service

a2enmod ssl
a2ensite default-ssl.conf
  • modify the Apache configuration files to define the correct roots of the VirtualHosts:

  • change the value of DocumentRoot in each configuration file:

- DocumentRoot /var/www/html
+ DocumentRoot /var/www
  • finally, restart the Apache web service to apply the new configuration:

/etc/init.d/apache2 restart


It is advisable to specify valid SSL certificates in the Apache configuration of remote repositories.

  • empty the content of the folders /var/www/wapt and /var/www/wapt-host; Syncthing will fill again these folders with data from the main repository.

rm -rf /var/www/wapt/*
rm -rf /var/www/wapt-host/*

Installing Syncthing on main and remote WAPT repositories


This procedure is to be applied on the main repository and on the remote repositories.

## Debian
apt update
apt install sudo curl apt-transport-https
curl -s | apt-key add -
echo "deb syncthing stable" | tee /etc/apt/sources.list.d/syncthing.list
apt update
apt install syncthing

## CentOS 7
wget --no-check-certificate
yum install syncthing-0.14.7-0.el7.centos.x86_64.rpm

Configuring Syncthing

Operations to follow:

  • add the Syncthing service to systemd;

  • change the listening port to;

  • create an administrator account and enter a strong password;

  • activate the HTTPS protocole for the web access;

  • create the definition file for the waptsync service by editing /etc/systemd/system/waptsync.service:

    Description=WAPT respository sync with syncthing
    ExecStart=/usr/bin/syncthing -logflags=0 -home=/opt/wapt/.config/syncthing/ -no-restart
    SuccessExitStatus=3 4
    RestartForceExitStatus=3 4
  • create the tree structure required for the waptsync service to start:

mkdir /opt/wapt/.config/
mkdir /opt/wapt/.config/syncthing/
  • change the owner of the files:

chown -R wapt:www-data /opt/wapt/.config/
  • activate the waptsync service and start it. The configuration files will appear in the /opt/wapt/.config/syncthing/ folder:

systemctl enable waptsync
systemctl start waptsync
systemctl stop waptsync
  • change the listening port in the /opt/wapt/.config/syncthing/config.xml file:

<gui enabled="true" tls="true" debugging="false">
  • start the waptsync service:

systemctl start waptsync
Configuring Syncthing’s web service

Syncthing’s web interface is now accessible by visiting http://srvwapt.mydomain.lan:8384.

Operations to follow:

  • change the host name of the remote repository;

  • add a GUI authorized user;

  • add the password for the GUI authorized user;

  • check the box Use HTTPS for the GUI;

  • click on Save;

  • connect with SSH on the WAPT Server and restart the Syncthing service:

systemctl restart waptsync

Syncthing’s web interface is now only accessible with HTTPS on https://srvwapt.mydomain.lan:8384.

  • in the list of shared folders, remove the default folder: Modify ‣ Remove;

  • configure the replication:


    Those actions must be run on WAPT Server.

    In the list of shared folders (Shares):

    • add a shared folder with Add a Share;

    • fill in the path to the directory to be shared, ex: /var/www/wapt/;

    • in the scroll-down menu Directory Type ‣ Only Send;

    • in the scroll-down menu File Recovery Order ‣ Older First;

    • redo the same operation for wapt-host: /var/www/wapt-host/;

    • add the remote repository to WAPT Server’s Syncthing:

      Once Syncthing has been installed on the main and remote repositories, recover the remote repository’s ID (Actions ‣ Show My ID).

      This unique identifier appears like


      On the main repository, in the list of remote devices (Other Devices):

      • add the remote repository with Add a Device;

      • fill in the ID of the remote repository;

      • tick the checkbox for the shared folder wapt and wapt-host;

      On the remote repository, follow these steps:

      • the remote device receives a Syncthing notification that it has been approved and added to the main device’s replication schedule;

      • the client receives a popup form asking to accept the synchronized shares wapt and wapt-host;

    The replication is now operational.

  • secure the replication:

By default, the following parameters are active in Syncthing:

Syncthing parameters



Activate the NAT

Use a UPnP port mapping for incoming synchronization connections.

Local discovery

Syncthing will then broadcast to announce itself to other Syncthings.

Global discovery

Syncthing registers on an external cloud service and can use this cloud based service to search other Syncthing devices.

Possible relay

The use of relays allows to use external servers to relay the communications. The relay is activated by default but it will be used only if two devices can not communicate directly between themselves.

This operating mode simplifies the global setup but it is not the most advisable method in relation to security.

  • uncheck all boxes in network configuration;

  • define the listening port (by default port 22000);

  • replace default by tcp://;

Then go on the web interface of the remote repositories, click on Change and fill in the IP address of the remote repository:

  • replace dynamic by tcp://<remote_repo_ip_address>:22000;

This configuration is useful for limiting inbound connections to the Syncthing service.

Configuring the WAPT agents

WAPT clients on remote sites must now be configured to look for updates from their closest available repositories.

Two solutions exist:

  • use automatic detection via DNS SRV fields;

  • change manually or via a WAPT package the parameter repo_url in the WAPT agent’s wapt-get.ini file;

Configuration example of the WAPT agent - filled in local repository:


Example of a WAPT package designed to remotely change the repo_url in wapt-get.ini:

# -*- coding: utf-8 -*-
from setuphelpers import *

uninstallkey = []

def install():
  print('Modifier la configuration agent pour le site de Colmar')