|
|
|
@ -8,11 +8,13 @@ order they will be implemented. |
|
|
|
|
These items are listed more or less in the order they need to be completed, as |
|
|
|
|
they generally depend on the items previous to them. |
|
|
|
|
|
|
|
|
|
### Cross Compilation |
|
|
|
|
### Window Support + GUI |
|
|
|
|
|
|
|
|
|
Currently the only supported OS/CPU is Linux/amd64. This can be expanded |
|
|
|
|
_theoretically_ quite easily, using nix's cross compilation tools. First target |
|
|
|
|
should be OSX/arm64, but windows would also be quite the get. |
|
|
|
|
Support for Windows is a must. This requirement also includes a simple GUI, |
|
|
|
|
which would essentially act as a thin layer on top of `daemon.yml` to start |
|
|
|
|
with. |
|
|
|
|
|
|
|
|
|
Depending on difficulty level, OSX support might be added at this stage as well. |
|
|
|
|
|
|
|
|
|
### NATS |
|
|
|
|
|
|
|
|
@ -35,14 +37,6 @@ requiring a passphrase. |
|
|
|
|
Most likely this integration will require NATS as well, to coordinate cache |
|
|
|
|
invalidation and cert refreshing. |
|
|
|
|
|
|
|
|
|
### Web server + interface |
|
|
|
|
|
|
|
|
|
Have every `isle daemon` run a webserver as one of its sub-processes. Status and |
|
|
|
|
connectivity information for the local host could be provided via a simple web |
|
|
|
|
interface, which the user can open in their browser. This saves us the effort of |
|
|
|
|
needing to develop UIs for individual OSs. This could also make remotely |
|
|
|
|
debugging hosts easier for admins. |
|
|
|
|
|
|
|
|
|
### Invitation code bootstrapping |
|
|
|
|
|
|
|
|
|
Once an HTTP gateway/load-balancer is set up it should be possible to do host |
|
|
|
@ -99,15 +93,14 @@ It should theoretically be possible for the internal network IP range to be on |
|
|
|
|
IPv6 rather than IPv4. This may be a simple matter of just testing it to confirm |
|
|
|
|
it works. |
|
|
|
|
|
|
|
|
|
### DNS resolver settings |
|
|
|
|
|
|
|
|
|
The daemon should update the resolver settings of the host, so that it |
|
|
|
|
automatically serves DNS queries, unless set to not do so in `daemon.yml`. |
|
|
|
|
### Proper Linux Packages |
|
|
|
|
|
|
|
|
|
### Install sub-command |
|
|
|
|
|
|
|
|
|
It would be great to have a `isle install` sub-command which would |
|
|
|
|
auto-detect the installed operating system and install the daemon automatically. |
|
|
|
|
Rather than distributing raw binaries for Linux we should instead be |
|
|
|
|
distributing actual packages, e.g. deb files for debian/ubuntu, PKGBUILD for |
|
|
|
|
arch, rpm for fedora (if we care), etc... This will allow for properly setting |
|
|
|
|
capabilities for the binary at install time, so that it can be run as non-root, |
|
|
|
|
and installing any necessary `.desktop` files so that it can be run as a GUI |
|
|
|
|
application. |
|
|
|
|
|
|
|
|
|
### Mobile app |
|
|
|
|
|
|
|
|
@ -130,6 +123,12 @@ necessary ambient capabilities up-front, and then drop down to a specified user. |
|
|
|
|
This is how the tests work. Doing this with other OS's will depend on how they |
|
|
|
|
work. |
|
|
|
|
|
|
|
|
|
### DNS/Firewall Configuration |
|
|
|
|
|
|
|
|
|
Ideally Isle could detect the DNS/firewall subsystems being used on a per-OS |
|
|
|
|
basis and configure them as needed. This would be simplify necessary |
|
|
|
|
documentation and setup steps for operators. |
|
|
|
|
|
|
|
|
|
### Plugins |
|
|
|
|
|
|
|
|
|
It would not be difficult to spec out a plugin system using nix commands. |
|
|
|
|