canterburyairpatrol/flight-safety-system-server repository overview

⁠Flight-Safety-System

Flight-Safety-System is a system for maintaining control of RPAS.

FSS provides a means of sending basic commands (RTL, Hold, Resume, etc) to an aircraft while monitoring the position, battery status, and mission progress.

See CHANGELOG.md⁠ for a full history of changes.

⁠Basic Setup

⁠Dependencies

Dependencies are jsoncpp (load/read the config), gnutls/gnutlsxx (for secure connections), ecpg (for the server), and catch2 (for tests).

Building from source also requires autoconf, automake, and libtool to generate the build system.

On Debian/Ubuntu:

apt install autoconf automake libtool libjsoncpp-dev libgnutls28-dev libecpg-dev catch2

⁠Build/Install

You can build this package from source:

git clone https://github.com/canterbury-air-patrol/flight-safety-system.git
cd flight-safety-system
./autogen.sh
./configure --enable-server
make
make install

⁠Running the Server

The flight-safety-system server uses a postgresql⁠+postgis⁠ database for storing configuration, commands, and recording historic data.

The web frontend⁠ is a separate project and will need to be set up and connected to the database before the server is run.

Create a server.json⁠ file with the correct port and database settings.

Then start the server:

fss-server server.json

⁠Signal handling

⁠Client

There is no full client implementation shipped with flight-safety-system, however there is a library⁠ to use and an example client⁠ that can be used as a starting point.

⁠Redundancy

Redundancy is available by running multiple independent servers; the normal client configuration allows for specifying multiple servers to connect to.

Each server can also be configured with a list of all known servers, and this information is provided to clients periodically so they can discover and connect to all servers automatically.

⁠SSL Support

TLS is required to protect the connection between clients and servers. A shared CA is needed so that clients and servers can verify each other by certificate. The server uses the client certificate's Common Name as the asset identity.

⁠Generating certificates

Scripts are provided in the certs directory to help generate and sign certificates.

Generate a CA certificate:

cd certs
./generate-ca.sh

Keep ca.private.pem in a safe place — it is needed to sign all server and client certificates. If a certificate signed by this CA is compromised, you will need to either revoke it (see below) or recreate the CA and regenerate all certificates.

Generate a certificate for each server:

cd certs
./generate-server.sh server1.my.domain

Use the IP address or DNS name that clients will connect to. Clients verify both that the server is trusted and that they have connected to the correct host.

Generate a certificate for each client:

cd certs
./generate-client.sh client-name

Use the name of the client as enrolled in the database. The server matches the certificate CN against the asset registry to authenticate the client.

⁠Certificate revocation (CRL)

To revoke a certificate without replacing the CA, add a crl_file entry to server.json:

"ssl": {
    "ca_public_key": "certs/ca.public.pem",
    "server_private_key": "certs/server.private.pem",
    "server_public_key": "certs/server.public.pem",
    "crl_file": "certs/revoked.crl"
}

Send SIGHUP to a running server to reload the CRL and immediately disconnect any clients whose certificates appear on it. No restart is required.

⁠Other software

Primarily flight-safety-system is designed to run alongside Search Management Map⁠.

Canterbury Air Patrol⁠ has a client⁠ that integrates Flight-Safety-System and Search Management Map to control an aircraft running ArduPilot⁠.

There is an ADS-B Integration⁠ that allows position reports from ADS-B Out aircraft to be relayed to FSS clients.

⁠Release strategy

Stable releases are cut from long-lived release/X.Y branches. The develop branch carries ongoing work and merges into a release/X.Y branch when a release is prepared. Bug fixes are applied to develop first and then cherry-picked to the relevant release/X.Y branch, resulting in patch releases (X.Y.1, X.Y.2, etc.). The master branch always points to the latest stable release.

In short:

• master — latest stable release
• release/X.Y — maintenance branch for the X.Y line; source of all X.Y.Z tags
• develop — integration branch for the next release

⁠License

This project is licensed under GNU GPLv2 — see the LICENSE⁠ file for details.