The developer workstation
ohm install --workstation turns a machine into a developer's own copy of the product. From there
you can pull a customer instance down as a local working copy, edit its add-ons as yourself,
debug them, and publish the module pins back - without a copy of the customer's credentials ever
landing on your laptop.
This is not the code editor in the browser, which edits an instance in place on the server it runs on. A workstation is a separate machine, usually your own laptop, that holds a copy.
Same package, same three images, same agent, same master database, same job queue. There is no second product and no cut-down mode. What differs is where it listens, who owns the files, and a handful of things it declines to install.
Installing
sudo ohm install --workstation
Run it with sudo from the developer's own account. The install needs to know whose machine this
is, and it takes that from SUDO_USER. If that resolves to root or is absent it refuses rather
than guessing, and tells you to pass --workstation-user NAME.
That user is not cosmetic. The instance trees end up owned by their uid and gid, so you edit the checkouts as yourself - no group juggling, no ACLs, no editing as root.
| Input | Effect |
|---|---|
--workstation | The mode itself. Also ANTELAO_INSTALL_WORKSTATION=1, or "workstation": true in the bootstrap document |
--workstation-user NAME | Whose machine this is. Defaults to SUDO_USER |
--ide vscode|pycharm|both | The default editor recorded for new profiles. Defaults to vscode |
--no-docker-group | Skip adding the developer to the docker group |
--allow-unencrypted-disk | Proceed on a disk the installer cannot prove is encrypted |
The disk is checked before anything is written
The installer resolves the block device behind the instance directory and walks its chain looking
for dm-crypt/LUKS. An unencrypted disk is a refusal, naming the device, unless you pass
--allow-unencrypted-disk.
If you allow it, that is recorded rather than forgotten: the profiles page carries a standing warning, and pulling a Confidential or Restricted instance is refused for as long as it stands.
fscrypt and ZFS native encryption are not detected, and a machine using either will be refused
until you pass --allow-unencrypted-disk. The probe deliberately reports what it can prove
rather than what it can infer - but that means a false negative is possible, and allowing past it
turns off the Confidential and Restricted gate too.
What a workstation does differently
| On a server | On a workstation | |
|---|---|---|
| Listeners | The network | Loopback only, whatever the file said |
Who may reach the host agent (ANTELAO_BOOT_ALLOW) | As configured | This machine only: 127.0.0.1/32,::1/128 |
| Hostname | Set with hostnamectl | Left alone - a laptop is never renamed |
| GeoIP and Fail2Ban services | Installed | Skipped |
| Host name rules | Applied | Skipped |
| Portainer, pgAdmin, PostgreSQL, nginx | Published on the network | Published on 127.0.0.1 only |
| Instance trees | Owned by the service account | Owned by the developer |
| Removing an instance | Deletes the tree; the instance's backup archives are kept | Deletes the tree and the instance's backup archives, and refuses while the module checkouts hold uncommitted or unpushed work |
The last row is the one to be deliberate about. On a server, the backup archives outlive the
instance, so a restore from one is the way back. On a workstation they go with it, because the copy
is disposable and the customer's data should not accumulate on a laptop. Commit and push your module
work first: the removal stops if a checkout has changes you have not pushed, and
--discard-changes is the only way past that.
Your connection is written for you
The install writes ~/.local/share/ohm/conf/connections.json for the developer, owned by them and
mode 0600, holding a connection named workstation pointing at http://127.0.0.1:5311, marked
default.
From then on ohm dev ... runs as you, without sudo, as an ordinary remote command against the
local API. If you find yourself typing sudo ohm dev, something is wrong with the install rather
than with the command.
$ ohm dev workstationThat is the command to run first: it says what this machine is, and it is the quickest way to tell a workstation from an ordinary server you have wandered onto.
The docker group
The installer adds the developer to the docker group unless you pass --no-docker-group, and
prints a notice that a new login is needed before it takes effect.
This is the one change the install makes to the base OS beyond its own files, and it is there because both editors need it: VS Code's Attach to Running Container and PyCharm's Docker interpreter each reach the daemon as your account.
Licensing
The Developer edition is a free edition for development machines. It carries the development tools - the Developer tab, the browser editor, live debugging, workspace profiles, the command line in the browser, slow query insights, PostgreSQL dump and load, and cloning, moving and restoring whole instances - with unlimited instances and one console account. It does not carry what a production server needs, such as outgoing mail, Fail2Ban blocking, off-site and scheduled backups or alerting, and it is bounded by where it may run:
A public host name works on an unregistered server and is refused on Developer: Developer is for the machine in front of you. See Editions.
Connecting to a customer server
A profile pulls from a registered environment, so the customer's server has to be known to this workstation first:
$ ohm dev connect --name acme --url https://tofana.example.com:5312 --keyThe address is that server's management API on 5312, its HTTPS port. Passing --key with no
value prompts for it without echo. It wants an API key issued on that server's Security > API
keys (the prompt calls it the operator API key), not the console key; see
Keys and credentials.
The customer server's API admits only the server itself and the private ranges until told otherwise, so its administrator has to let this workstation's address in first, as First, let your address in describes.
If the customer server serves a self-signed certificate, pin it rather than disabling the check:
$ ohm dev connect --name acme --url https://tofana.example.com:5312 --key --trust-certificate <sha256>The connection then accepts a chain-valid certificate or exactly that fingerprint, and nothing else.
What never travels
This is the part worth reading before you pull anything.
- The customer's git credentials are blanked out of the exported configuration before it is stored, logged or serialised anywhere
- The customer's backup and restore provider credentials are dropped after the import
- The only git credential on the local instance is your own token, held as a cipher
What does come across is the shape of the instance: its Odoo version and edition, its classification, its module list with pins, its git provider names and repositories, its Python apt and pip packages, and its tuning options.