# forticlient

The FortiClient VPN client on the workstations, as a module (novox/hq ADR 0208): its tray in the
operator's session and the vendor's service behind it. It requires `x11-display`, so it is assigned
only where a display server is held on the same machine.

**This is the operator's work VPN.** Nothing of its configuration is the mesh's: no profile, no
credential, no gateway, no certificate is declared, read, printed or stored by the module or its
tools. The tools report running and connected state only.

## Owns

| what | where |
|---|---|
| the vendor's scheduler service, which holds the tunnel | `forticlient.service`, running and enabled |

Nothing else. It holds no seat, makes no contribution and writes no file.

- **The client is kept as found.** `forticlient-vpn` (7.4.3) is not in the official repositories: on
  both workstations it is a foreign (AUR) package that repackages the vendor's build, installed
  explicitly. The host installs from the official repositories only, so the module cannot declare it.
  ADR 0205's pinned archive does not fit: it is a vendor binary set with a root service, a firewall
  helper and an install script. It waits for the mesh's package repository (research 027 question 1,
  option P2). Until then a fresh workstation installs it by hand.
- **The service is declared, and so depended on.** `forticlient.service` is the package's unit, running
  and enabled on both workstations. Declared running and enabled, it is held in that state, and on a
  machine without the package the host refuses it by name (*does not exist on this machine*): loud,
  never a silent pass. The `asus-zephyrus-g14` module does the same with its foreign daemons. The
  module never restarts it: a change to nothing of the module's would, and nothing of the module's
  changes.
- **The configuration stays the operator's, and unread.** `/etc/forticlient/`, the client's database
  under `/opt/forticlient/`, the account's FortiClient settings, the VPN profiles, saved credentials
  and certificates are set in the client's own window. They are found (ADR 0182), and unlike any other
  found file, the tools do not even read them.

## How it starts: the vendor's autostart entry, and nothing else

The tray has two processes: `fortitraylauncher`, which starts and watches `fortitray`. The package's
install script links `/etc/xdg/autostart/Fortitray.desktop` to the package's
`/opt/forticlient/Fortitray.desktop` (`Exec=/opt/forticlient/fortitraylauncher`). The session runs it
once at login through the `i3` module's `dex --autostart --environment i3`. **That entry is the tray's
one start.** The module adds no `xinitrc` slot and no `node-display-session` exec, because either would
start it a second time. The link is the vendor's, made by its install script; the mesh does not make
or remove it.

The tunnel is not the tray's: the service's processes hold it, as root. Ending the tray leaves a
connected tunnel connected.

## Tools

They are served by the node's runtime as the operator account (ADR 0175).

| tool | does |
|---|---|
| `forticlient_status` (r) | <ul><li>the installed version, and that it is from outside the official repositories</li><li>the service: active, enabled</li><li>whether the launcher and the tray run: pid, since, and the scope or unit they run in</li><li>what starts the tray at login</li><li>connected or not, as the number of the client's tunnel interfaces that are up</li></ul> |
| `forticlient_restart` (a) | asks the tray and its launcher to end (SIGTERM), forces them after 5 s, and starts the launcher in the operator's session as a transient user unit `mesh-forticlient-tray`, so it outlives the tools runtime. The launcher starts the tray. The service and the tunnel are not touched. Refused plainly when nobody is logged in to the desktop |
| `forticlient_check` (r) | <ul><li>the package is installed</li><li>the service is running and enabled</li><li>exactly one start: the vendor's entry is present and not hidden by an entry of the account, and `dex` is installed</li><li>no window-manager exec</li><li>one launcher and one tray run in a desktop session</li></ul>Being connected is never a finding: that is the operator's to decide. Each finding says what to do |

**What the tools never touch**, held by the tests (a fake machine carries a profile, a gateway, an
address, a secret and a certificate where the client keeps them, and no answer may hold any of them):

- no file under `/etc/forticlient` or the account's FortiClient settings is opened, and under
  `/opt/forticlient` only the tray's autostart entry, through its link (it names the launcher and
  nothing else);
- the vendor's command-line client and `fortivpn` are never run, and its logs are never read;
- a process is named by its command name only, never by its arguments;
- *connected* is whether an interface named `fctvpn…` is up, from its flags. The interface's name
  (it carries an identifier) and its addresses are never answered. A tunnel of a kind that brings up
  no such interface (IPsec) is not seen, and the answer says *not connected*.

## What changes when it is assigned

| | laptop | desktop |
|---|---|---|
| package | none: `forticlient-vpn` 7.4.3.5411, explicit, foreign | the same |
| service | none: running and enabled | the same |
| tray | none: dex starts it from the vendor's entry, in the login session's scope | none on disk. **No tray runs now:** that session began before `dex` was installed, and the predecessor's window manager never started it. The next login is the first that starts it |

## Migration (ADR 0182)

Nothing is required on either machine. On the desktop, log out and in once, or run
`forticlient_restart`, and the tray runs from its one start. `forticlient_check` then answers `ok`.

## Leaves as found

Everything of the client's: its configuration and database, the VPN profiles and credentials, its
logs, `/etc/xdg/autostart/Fortitray.desktop` (the vendor's link), the package itself.

## Relies on

- **The package, installed by hand.** Without it the host refuses the service by name.
- **`i3`'s `dex` line for the start**: XDG autostart has no seat. Assigned without `i3`, the tray does
  not start. `forticlient_check` says so.
- A display server on the same machine (`x11-display`, ADR 0208 §3).