The configuration editor
lyno -config configs/lyno.yaml -configure
opens a terminal editor for the entire configuration: tenants, accounts, extensions, dialplan steps, time conditions, ring groups, routes, trunks and system settings.
lyno config unsaved changes
Configuration › Tenants › Tenant acme › Extensions › Extension 200
╭──────────────────────────────────────────────────────────────────────────╮
│ Steps run top to bottom. A dial that nobody answers falls through. │
│ │
│ ▸ ‹ properties › Support follow-me │
│ 1. greeting (play) play ../sounds/welcome.wav │
│ 2. follow-me (dial) dial follow-me (2 stages) · 40s · moh default │
│ 3. nobody-home (play) play ../sounds/closed.wav │
│ 4. done (hangup) hang up │
╰──────────────────────────────────────────────────────────────────────────╯
↑↓ move · enter edit · a add · d delete · shift+↑↓ reorder · esc back
Structure
The top level splits into Tenants and Global.
| # | Under a tenant | Under Global |
|---|---|---|
| 1 | Properties: domains, DIDs, caller ID, timezone | Trunks |
| 2 | Accounts | Inbound overrides |
| 3 | Extensions and their steps | Outbound routes and the default trunk |
| 4 | Ring groups | Music on hold |
| 5 | Inbound routes | System: SIP listeners, media, timezone, inter-tenant |
| 6 | Outbound routes | Data and recording |
| 7 | Music on hold | Object storage |
| 8 | Queues | Voicemail and mail |
| 9 | IVR menus | Management API |
| 10 | Mailboxes | Security: the guard, the ACLs and the fraud limits |
| 11 | Feature codes | Prompts: speech synthesis and the generated prompt text |
| 12 | Overrides: recording, storage, voicemail, mail, security |
Forms adapt to what you are editing: a dial step offers a target kind, timeout
and music-on-hold class, a play step asks for a file, and an ivr step offers
the tenant's menus by name.
Several forms edit configuration that nothing reads at run time — the whole
Security section apart from the guard's own settings, requireSrtp, the fraud
limits, feature codes, recording.retention and recording.beep, voicemail.mwi,
a queue's dynamic login, and api.recordings.presign (which actively breaks
downloads).
The editor's job is to write valid YAML, and all of these are valid YAML. Check the page for a feature before trusting a checkbox — each one is called out where it belongs, and they are listed together under the security guard.
Keys
| Key | Action |
|---|---|
↑ ↓ / k j | Move |
enter | Open, edit a field, or toggle a checkbox |
space | Toggle a checkbox |
← → / h l | Change a choice (step type, transport, strategy) |
a / n | Add an entry |
d / delete / backspace | Delete an entry |
shift+↑ shift+↓ (or K J) | Reorder steps, stages and routes — order matters |
ctrl+s | In a form: apply. Elsewhere: validate and save |
esc | Back, discarding the current form. While editing a field: cancel the edit |
ctrl+q | Quit, asking for confirmation if there are unsaved changes |
ctrl+c | Quit immediately |
What it guarantees
Saving validates first. The editor cannot write a file the PBX would refuse to load. If validation fails, the errors are shown and nothing is written.
Deleting something still referenced is refused, with an explanation — an account a ring group still rings, a trunk a route still names, a ring group an inbound route still points at.
Files are written atomically, mode 0600, because they contain SIP
passwords.
What it costs
Files are regenerated from the parsed configuration. Any comment you wrote by hand is gone after a save. If you maintain the configuration in version control with comments, edit the YAML by hand and use the editor read-only, or accept that the editor owns the files.
The PBX reads configuration only at startup, so restart it after saving.
Bootstrapping a new system
Pointing -config at a path that does not exist is not an error: the editor
starts from defaults. That is the fastest way to create a first configuration
without writing YAML by hand.
lyno -config /etc/lyno/configs/lyno.yaml -configure
Add a tenant, give it a domain, add an account and an extension, save, and you have a working tree on disk.
When to prefer the files
The editor is good at exploration and at one-off changes on a machine you are already logged into. Hand-edited YAML is better when:
- the configuration lives in version control and you review changes as diffs;
- you keep explanatory comments;
- you generate tenants from another system;
- you want to copy a tenant directory between environments.
Both produce the same format, so the two can be mixed — as long as you accept losing comments on any file the editor saves.