538266ad83## Problem While working in a network form upcoming improvement, it was discovered that creating a connection and setting its device binding to "Chosen by name" (or "Chosen by MAC address") starts the form off bound to `lo`. The selector shows `lo` even though it never offers it as an option, and accepting the form submits a connection bound to the loopback device, which cannot reach anything. The form seeds its device fields from the first device the system reports, and that is the loopback one. The selectors do exclude it from their options, but by then the value is already set, and a value that is not among the options is simply printed as-is. ## Solution The list of devices a connection is never bound to now has one home in the form, and it is used both for the values the form starts from and for the options the selectors offer, so the two cannot drift apart. ## Details The test fixtures were part of why this went unnoticed: they mocked a device list with no loopback device. It is now first in that list, as the backend reports it, and adding it turned an existing test red, showing the payload carried `iface: "lo"`. A new test covers the case directly. ## Testing - `npm run test -- src/components/network`, `npm run check-types` and `npm run eslint` pass. - Manually: create a connection, set the device binding to "Chosen by name", and check the selector shows a real device. Same with "Chosen by MAC address". |
||
|---|---|---|
| .. | ||
| __mocks__ | ||
| package | ||
| public | ||
| scripts | ||
| share | ||
| src | ||
| .babelrc.json | ||
| .editorconfig | ||
| .gitignore | ||
| .prettierignore | ||
| .prettierrc | ||
| .stylelintrc.json | ||
| .svgrrc | ||
| babel.config.js | ||
| build_pot | ||
| build_pot_container | ||
| custom.d.ts | ||
| eslint.config.mjs | ||
| jest.config.js | ||
| LICENSE | ||
| org.opensuse.agama.metainfo.xml | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| svgo.config.js | ||
| tsconfig.json | ||
| webpack.config.js | ||
Agama Web UI
The Agama web user interface is a React-based application that offers a user interface to the Agama service.
Development
The easiest way to work on the Agama Web UI is to use the development server. The advantage is that you can use the [Hot Module Replacement] (https:// webpack.js.org/concepts/hot-module-replacement/) feature for automatically updating the code and stylesheet in the browser without reloading the page.
Using a development server
To start the webpack-dev-server use this command:
npm run server -- --open
The extra --open option automatically opens the server page in your default
web browser. In this case the server will use the http://localhost:8080 URL
and expects a running agama-web-server at http://localhost.
This can work also remotely, with a Agama instance running in a different machine (a virtual machine as well). In that case run
AGAMA_SERVER=https://<IP>:<port> npm run server -- --open
Where AGAMA_SERVER is the IP address, the hostname or the full URL of the
running Agama server instance. This is especially useful if you use the Live ISO
which does not contain any development tools, you can develop the web frontend
easily from your workstation.
Example of running from different machine:
# backend machine
# using ip of machine instead of localhost is important to be network accessible
# second address is needed for SSL which is mandatory for remote access
agama-web-server serve --address :::80 --address :::443
# frontend machine
# ESLINT=0 is useful to ignore linter problems during development
ESLINT=0 AGAMA_SERVER=https://10.100.1.1 npm run server
If you are using the Live ISO then you can use the predefined agama host name
configured via mDNS:
AGAMA_SERVER=https://agama.local npm run server
Debugging Hints
There are several places to look when something does not work and requires debugging.
The first place is the browser's console which can give
some hints. The second location to check for errors or warnings is output of npm run server
where you can find issues when communicating with the backend. And last but on least is
journal on backend machine where is logged backend activity journalctl -b.
If the journal does not contain the required info, you can inspect the D-Bus communication
which can give hint about data flow. Command is busctl monitor --address unix:path=/run/agama/bus
Special Environment Variables
AGAMA_SERVER - When running the development server set up a proxy to
the specified Agama web server. See the [using a development server]
(#using-a-development-server) section above.
LOCAL_CONNECTION - Force behaving as in a local connection, useful for
development or testing some Agama features. For example the keyboard layout
switcher is displayed only in local installation because it cannot work in
remote connection. This option will force displaying it even in a remote
connection.
Type-Checking Support
This module started as a JavaScript-only project. We have decided to add type-checking support, but instead of converting the code to TypeScript, we prefer to use TypeScript support for JSDoc annotations.
Run the following command to check the types:
npm run check-types
Not our JavaScript code is properly documented yet, so type-checking is an opt-in feature by now. If
you want a JavaScript file to be type-checked, please add a // @ts-check comment before any code.