3. Sync Appliance install¶

3.1. Environment¶

On successful install, the appliance will run as self-contained docker containers, with a few additional changes to the host environment:

1. a aeoncase user will be created in order to drop root privileges when running appliance services

2. appliance state will be saved in /var/lib/aeoncase:

   /var/lib/aeoncase/data

   storage backend

   /var/lib/aeoncase/writeback

   local storage backend, used as fallback when the main storage backend is down. Its data will be moved to the main storage backend when it becomes available.

   /var/lib/aeoncase/db

   main DB

   /var/lib/aeoncase/*.db

   support DBs of smaller size

3. /etc/aeoncase will hold files containing appliance configuration information

4. temporary data will be saved (and cleaned up automatically on a periodic basis) in the following directories:

   /var/cache/aeoncase/update

   Sync Appliance package data, downloaded by the updater

   /var/lib/aeoncase/staging-area

   data in transfer or recently transferred

   /var/tmp/aeoncase/upload

   files being uploaded to the web server

5. locally available appliance instances (containers) will be stored under /var/lib/docker. A Sync Appliance container requires around 300 MB, and a few are kept by the updater so as to allow easy up/downgrades.

File data under /var/lib/aeoncase/data is stored under 256 directories named 00 to ff (i.e., 0-255 in hexadecimal). It is possible to use a crude form of tiered storage by mounting different disks on them, but it is not recommended.

3.2. Install¶

In order to launch the installation procedure, run the following as root:

# curl -sSL https://get.aeoncase.com/repos/install.sh | bash

If you normally run commands as root using sudo, you can become root with:

$ sudo -i

Alternatively, download the installation script, inspect it at your leisure and execute it manually:

# wget https://get.aeoncase.com/repos/install.sh
# less install.sh
# bash install.sh

3.3. Configuration¶

When the installation script completes, it will indicate a localhost URL, as well as instructions to access it via a SSH tunnel if the server is headless.

The basic configuration is a 3-step procedure to:

1. validate the license key
2. create the administrator account
3. provide basic information required by the web and sync servers:
   • the hostname the clients (web browsers and sync clients) can use to reach the server
   • (optional) the X509 certificate used to secure TLS/SSL connections to the web service
   • the maximum allowed upload file size

The administrator account password and the basic setup can be changed at any time.

Changing the setup will restart the sync and web services, which will result in a sub-second service interruption. Sync clients will reconnect automatically, and browsers showing a self-updating page (like the dashboard or a project explorer) will reload it.

3.4. Sync Appliance launch¶

The Sync Appliance is downloaded and installed by the launcher while the basic configuration is performed. Once complete, the service will be launched and should become available at the address (hostname) given during setup.

The launcher will detect when the appliance has started and show a link to the web service.

3.5. Updates¶

Updates are performed automatically by the launch/update system. The update system follows The Update Framework‘s (TUF) design to provide secure updates using a comprehensive security framework that addresses all known attacks on the software update process and minimizes the impact of key compromise via well-defined roles with multiple keys.

In particular, it protects against these attacks:

Rollback attacks

Attackers should not be able to trick clients into installing software that is older than that which the client previously knew to be available.

Indefinite freeze attacks

Attackers should not be able to respond to client requests with the same, outdated metadata without the client being aware of the problem.

Endless data attacks

Attackers should not be able to respond to client requests with huge amounts of data (extremely large files) that interfere with the client’s system.

Slow retrieval attacks

Attackers should not be able to prevent clients from being aware of interference with receiving updates by responding to client requests so slowly that automated updates never complete.

Extraneous dependencies attacks

Attackers should not be able to cause clients to download or install software dependencies that are not the intended dependencies.

Mix-and-match attacks

Attackers should not be able to trick clients into using a combination of metadata that never existed together on the repository at the same time.

Attacks on mirrors

Malicious repository mirrors should not be able to prevent updates from good mirrors.

# docker images

3.6. Load testing¶

The Æoncase Sync Appliance includes a load generator tool that allows to analyze system performance when subject to thousands of simultaneous connections (users/devices), both inactive and engaged in active file sync.

# /opt/aeoncase/aeoncasectl make-test-users --password SOMEPASSWORD \
  --prefix loadtest01 2000

$ ulimit -n 500000

$ ./aeoncase-loadtest --prefix loadtest01 --ca ca.pem \
   --server SERVER_ADDRESS  --password SOMEPASSWORD --dir loadtest01 2000

$ ./aeoncase-loadtest --active N --prefix loadtest01 --ca ca.pem \
   --server SERVER_ADDRESS  --password SOMEPASSWORD --dir loadtest01 2000

$ ./aeoncase-loadtest --help

NAME
       aeoncase-loadtest - generate sync load test

SYNOPSIS
       aeoncase-loadtest --server SERVER --password PASSWORD [OPTION]...  USERS

DESCRIPTION
       Establish USERS simultaneous connections to the SERVER and generate
       sync activity corresponding to the specified number of active users.

       USER MODEL
           The generated user activity follows a Poisson model, with each
           user uploading on average 5 files (of 10 KB average size) every 10
           minutes.

       RESOURCE NEEDS
           The load generator uses the same sync engine as the regular
           client. The requirements per user/connection are: up to 20 file
           descriptors, one inotify instance, around 1 MB of RAM. Make sure
           the file descriptor limit is high enough (e.g. by editing
           /etc/security/limits.conf as root, logging in as the test user,
           and setting ulimit -n) and the inotify limits are set correctly
           (e.g. sysctl -w fs.inotify.max_user_instances=100000 and sysctl -w
           fs.inotify.max_user_watches=200000 as root).

ARGUMENTS
       --ca=FILE
           file holding the CA certificate (PEM format; use aeoncasectl cert
           to get it)

       -p PASSWORD, --password=PASSWORD
           password used to authenticate users

       -s SERVER, --server=SERVER
           server to connect to

       USERS
           total number of connections (= users) to establish

OPTIONS
       --active=N (absent=0)
           number of active users

       -d PATH, --dir=PATH
           directory to create synced dirs under (default: current dir); a
           directory named after the corresponding user will be created for
           each connection, under the specified dir.

       --help[=FMT] (default=pager)
           Show this help in format FMT (pager, plain or groff).

       --passphrase=PASSPHRASE
           passphrase used for client secrets (client-side encryption keys,
           user key) (default: password repeated)

       --port=PORT
           port to connect to (default 443)

       --prefix=PREFIX (absent=test)
           prefix for user names (the user names will be of the form
           PREFIX00001)

       --reuse-data
           use limited number of data patterns (allows to factor out file
           storage I/O)

       --version
           Show version information.