Installing the Linux agent

On Linux there is no installer to download and no build to wait for. The panel gives you a command line, you paste it on the server, and that is it.

This guide covers installation, verification, diagnosis and, above all, what the Linux agent does and does not do compared to the Windows one. That last part is what defines what you can promise a customer with Linux servers.

How it differs from the Windows agent

If you are coming from installing the Windows agent, here is what changes:

Getting the command

Go to Customers, open the customer, Computers tab, Installer card, Create Installer button. You need computer management permission.

In the dialog, the Linux tab. That tab has no fields to fill in: it shows the command and nothing else. Copy command button.

The command looks like this:

curl -fsSL https://app.kairoslink.io/install/TOKEN | sudo bash

The token is in the URL, not inside a file. It is that customer's enrollment credential, the same one the Windows MSI carries. Treat it like a password: whoever holds it can add computers to that customer.

The command does not expire. Unlike the MSI, which dies after 7 days, this line works as long as the customer's credential stays active. You can keep it in your internal documentation and reuse it.

Requirements

Four of them, and the script checks in this order:

1. Root. Not negotiable: the sudo in the command is there for a reason.
2. systemd. This is the hard requirement. Without systemd the agent does not install.
3. x86_64 architecture. There is no ARM agent. If you manage ARM servers, they are not covered today.
4. A recognized distribution. The main families are validated: Debian and derivatives, Red Hat and derivatives, SUSE.

If your distribution is not on the list but meets the other three requirements, installation can be forced with --forzar-distro. It works, but it sits outside what has been verified.

Outbound internet on 443 to the panel. As on Windows, the agent initiates every connection outbound: no public IP and no inbound ports needed.

The binary is statically linked (musl): it does not depend on the distribution's glibc, so there are no dependencies to install and no version conflicts. It is published from GitHub Releases, but the machine does not need to reach GitHub: the panel proxies the agent files, so the download always comes from the KairosLink domain, exactly as on Windows and macOS.

If the server goes through a proxy

There is a trap worth knowing: the first curl runs as your user, but the downloads inside the script run under sudo, which clears the environment variables.

If the server needs a proxy, use sudo -E so the variables are preserved.

Installing

You paste the command into the server's terminal and it runs on its own. The script checks the requirements, downloads the files, validates their integrity, writes the configuration, installs the service and starts it.

A good installation ends like this:

[  OK  ] El servicio io.kairoslink.agent.service esta ACTIVO
[ INFO ] El equipo deberia aparecer en el panel en menos de un minuto.
[ INFO ] Fingerprint de este equipo: ...

Keep that fingerprint. It is the same value recorded in the panel, so it is the most direct way to match a physical server with its row in the computer list.

If the service does not come up, the script prints the status and 40 lines of log, and exits with an error.

Useful options

The installer accepts parameters. The most used ones:

Installing without internet access

If the server cannot reach the panel, the dialog has an Agent files menu with direct URLs.

Download the four files, leave them all in the same folder on the server, and run:

chmod +x install.sh
sudo ./install.sh --token TOKEN --local

The chmod is needed because an HTTP download does not preserve the execute bit.

Mass installation

The panel has no mass deployment tool for Linux. There is no equivalent to the Windows GPO deployment.

The curl | sudo bash line is perfectly suited to Ansible, cloud-init or an SSH loop, but you build that yourself with your own tooling and the panel keeps no record of the campaign.

What gets installed

The service is called io.kairoslink.agent and starts with the machine.

The paths are not configurable: they are compiled into the binary.

One security detail that matters: agent.conf holds the customer's enrollment token in plain text, protected by 0600 permissions. A backup of that server's /etc carries the whole customer's credential. Keep it in mind when designing your backups.

Verifying

On the server:

systemctl is-active io.kairoslink.agent
journalctl -u io.kairoslink.agent -f

In the panel, the Devices screen. As on Windows, what confirms it is alive is the Last seen column, not the row existing.

What it does and does not do

This is what defines what you can sell a customer with Linux servers.

What works

• Resource monitoring and alerts, with disk usage per filesystem
• Patching with apt and dnf: selected, all, or security only, with live progress, history and scheduled reboot
• Control over the distribution's automatic updates, configurable per customer from Customers, Computers, patch control card. This setting is Linux-only: on Windows patching is handled by Windows Update
• A bash command console, with AI assistance that works in bash and rejects PowerShell
• Services as systemd units, processes, cron tasks and timers, applications and the file explorer

What is missing

• Remote control. There is no remote desktop for Linux. There is one on Windows and on macOS
• Updating from the panel. The Linux agent is updated by running the install command again, not by dispatching from the Agents screen
• Mass deployment from the panel
• A native package. There is no .deb, no .rpm and no repository: the agent does not appear in the package manager
• ARM

Tabs that do not appear on a Linux machine

Six tabs are hidden because there is no honest equivalent:

A trap worth knowing

The Linux agent runs inside a hardened systemd environment, and everything it executes inherits that. Among other things, it sees /usr as read-only.

Practical consequence: a command that installs packages, launched from the panel console, may fail with a read-only filesystem error that mentions systemd nowhere. The same goes for commands that need to write inside a user's home directory.

The patching module does install packages and it works: that is solved another way. What can fail is a manual command writing to those paths.

If you are coming from Windows, this is what will surprise you most: commands failing for reasons that are not in the command.

When it does not show up

The command returned an error and installed nothing. The script is explicit: it tells you if root is missing, if systemd is missing, if the architecture is not x86_64, or if the distribution is not on the list. Read the message.

The installer said OK, the service is active and the computer does not appear. Check the log with journalctl -u io.kairoslink.agent -f. The causes are the same as on Windows: rotated token, deleted customer, plan cap reached, or the server having no route to the panel on 443.

The computer appears but the panel treats it oddly. Check that the operating system was detected correctly on its record.

Reinstalling

Reinstalling over an existing installation does not duplicate the computer: it is recognized by its hardware fingerprint, and /var/lib/kairoslink also preserves its identity.

The script tells you when it detects a reinstall.

To update the agent, run the same install command again. Do not use the customer's Agents tab: that screen works with the Windows installer.

Uninstalling

On the server:

sudo /usr/local/bin/kairoslink-agent-uninstall.sh

If you want to keep the machine's identity so a later reinstall does not show up as a new computer, there is a --conservar-estado option.

On the panel side, the computer behaves as it does on Windows: if the agent manages to report, it disappears from the list; if not, it stays Offline and you take it out with Remove from list.

Frequently asked questions

Do I need to build anything before installing? No. The command already exists, you copy and paste it.

Does the command expire? No. It works as long as the customer's credential stays active.

Does the same command work on several servers of the same customer? Yes, with no time limit.

I have ARM servers. They are not covered today. The agent is x86_64 only.

My distribution is not on the list. If it has systemd and is x86_64, try --forzar-distro. It sits outside what has been verified, but it works.

Can I take remote control of a Linux server? No. Remote control works on Windows and macOS today; not on Linux.

How do I update the Linux agent? By running the install command again. The Agents screen does not dispatch updates to Linux.

A console command fails with "read-only file system". That is the systemd hardening: the agent sees /usr as read-only and whatever it runs inherits that.

Is there a .deb or an .rpm? No. Installation is by script and the agent does not appear in the package manager.

Can I install it with Ansible? Yes. The command line is well suited to that, but the panel offers no tooling and records no campaign.