Welcome!

Xema is a product developed by a startup @TechSudoku based in India. We serve the Call Center operators with customized call flows. We are happy to see you here and ready to support your evaluation. You can write to us at support@xema.in

Prerequisites

Xema runs on Ubuntu, the operating system choice of cloud.

Installation

Version 2

Supports Ubuntu 24, 22

curl -fsSL https://www.xema.in/install-xema.sh | sudo bash

Dev Branch

curl -fsSL https://www.xema.in/install-xema.sh | sudo bash -s -- -d -vvv

Version 1

Supports Ubuntu 18

curl -fsSL https://raw.githubusercontent.com/xema-in/install/master/xema-manager.sh | sudo bash

After installing

This script installs software. It does not decide what the server is for.

That is deliberate. It used to decide three things, all at the one moment nobody yet knew what the machine was for: which components to install, what database password to use, and what every service's settings should be. The last of those was the worst — a copy of a release's defaults in /etc/xema overrides the settings a cluster works out for itself, so servers sat quietly connected to the wrong machine with nothing to show for it.

So when the script finishes, the software is on the machine and only Manager is running. Everything else waits to be asked for.

1. Say what to connect to

sudo xema connect-database --server localhost --user xema --provision

--provision creates the database user with a password nobody has to choose or remember. It logs in to MariaDB as whoever is running the command, over the unix socket — which is how a stock install authenticates root — so sudo is the whole credential and nothing is typed or stored by hand. The generated password goes straight to /etc/xema/common.yaml, where every service reads it.

If your own Linux login has no rights to create a MariaDB user, add --trusted-user to log in as root instead. For a database that already exists, give --user and --pass and leave --provision out.

xema database shows what the server is set to connect to, and never the password.

2. Make it a site, or join one

A single server is the ordinary deployment and is a site of one:

xema cluster init --site <name>

To add a second server, mint a pass on the first and use it on the new one:

xema cluster token                  # on the server that is already a site
xema cluster join --token <pass>    # on the new one

A server joins a site empty. Joining points it at the site's database, so anything in its own would simply stop being read — not merged, not moved. Two working servers are never made into one site. To bring an existing server in, run cluster init on it and let the others join it.

A joining server also arrives with no roles, on purpose. Whatever it happened to be running before is not this site's business.

3. Say what the server runs

xema role add bff
xema role add queue        # bff queue dialer simplecdr metrics
                           # astermq fastagi tracer sipper ava
xema node apply

role add writes the decision down; node apply is what starts and stops things. A server that is out of contact picks up the decision when it returns.

4. Check it

xema site           # the whole site: servers, shared parts, what it holds, what each is running
xema status         # what is running on this machine

More than one server?

A single server is the ordinary deployment and needs nothing further.

• DEPLOYMENTS.md — the four standard shapes, what each gives you and what it does not, and which to choose
• CLUSTER.md — every command for building a site of several servers

Upgrading

Re-run the installer. It replaces the code and never switches anything off, so a server keeps running what it was.

Schema is not applied automatically — several servers sharing one database must not race each other to migrate it, and a deploy should not be the moment the schema changes. Manager says at startup when the database is behind the build:

xema database migrate

What goes where

Nothing is seeded into /etc/xema by installing. A release's defaults ship beside its code and are read from there; /etc/xema is for choices — the database from connect-database, the site's own settings from joining, and anything an administrator writes themselves, which beats both.