From 4f6a89ced0b18ac8814551185223133905224e29 Mon Sep 17 00:00:00 2001 From: Brian Picciano Date: Sun, 1 Sep 2024 12:20:37 +0200 Subject: [PATCH] Roadmap has been moved to micropelago.net --- README.md | 3 - docs/roadmap.md | 128 ------------------------------- go/cmd/entrypoint/daemon.go | 4 + go/cmd/entrypoint/daemon_util.go | 5 ++ go/daemon/child_dnsmasq.go | 8 ++ 5 files changed, 17 insertions(+), 131 deletions(-) delete mode 100644 docs/roadmap.md diff --git a/README.md b/README.md index 6a95b77..095afe5 100644 --- a/README.md +++ b/README.md @@ -105,7 +105,4 @@ Documentation for devs: Besides documentation, there are a few other pages which might be useful: -* [Roadmap][roadmap] * [Glossary](docs/glossary.md) - -[roadmap]: docs/roadmap.md diff --git a/docs/roadmap.md b/docs/roadmap.md deleted file mode 100644 index 8314b60..0000000 --- a/docs/roadmap.md +++ /dev/null @@ -1,128 +0,0 @@ -# Roadmap - -The following are rough outlines of upcoming work on the roadmap, roughly in the -order they will be implemented. - -## Main quest - -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. - -### Windows Support + GUI - -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 - -Garage is currently used to handle eventually-consistent persistent storage, but -there is no mechanism for inter-host realtime communication as of yet. NATS -would be a good candidate for this, as it uses a gossip protocol which does not -require a central coordinator (I don't think), and is well supported. - -### Integration of [Caddy](https://caddyserver.com/docs/) - -Integration of Caddy's will require some plugins to be developed. We want Caddy -to be able to store cert information in S3 (garage), so that all isle lighthouse -nodes can potentially become gateways as well. Once done, it would be possible -for lighthouses to forward public traffic to inner nodes. - -It should also be possible for users within the network to take use lighthouse -Caddy's to host their websites (and eventually gemini capsules) for them. - -Most likely this integration will require NATS as well, to coordinate cache -invalidation and cert refreshing. - -### Invitation code bootstrapping - -Once an HTTP gateway/load-balancer is set up it should be possible to do host -bootstrapping using invite codes rather than manually giving new users bootstrap -files. The bootstrap file would be stored, encrypted, in garage, with the invite -code being able to both identify and decrypt it. To instantiate a host, the user -only needs to input the network domain name and the invite code. - -### FUSE Mount - -KBFS style. Every user should be able to mount virtual directories to their host -which correspond to various buckets in garage. - -- "public": editable amongst all users on the host, shared publicly via HTTP - gateway. - -- "protected": editable amongst all users on the host, but not accessible - outside the network. - -- "private": only accessible to a particular user (client-side encrypted). - -Whether it's necessary to support directories which are shared only between -specific users remains to be seen. The identification of a single "user" between -different hosts is also an unsolved problem. - -## Side quests - -These items aren't necessarily required by the main quest, and aren't dependent -on any other items being completed. They are nice-to-haves that we do want to -eventually complete, but aren't the main focus. - -### Design System - -It would be great to get some help from a designer or otherwise -artistically-minded person to create some kind of design framework which could -be used across publicly-facing frontends. Such a system would provide a simple -but cohesive vision for how things should look, include: - -- Color schemes -- Fonts and text decoration in different situations -- Some simple, reusable layout templates (splash page, documentation, form) -- Basic components like tables, lists, media, etc.. - -### DHCP - -Currently all hosts require a static IP to be reserved by the admin. Nebula may -support DHCP already, but if it doesn't we should look into how this could be -accomplished. Depending on how reliable DNS support is it may be possible to use -DHCP for all non-lighthouse hosts, which would be excellent. - -### IPv6 network ranges - -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. - -### Proper Linux Packages - -Rather than distributing raw binaries for Linux we should instead be -distributing actual packages. - -* deb files for debian/ubuntu -* PKGBUILD for arch (done) -* rpm for fedora? -* flatpak? - -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 - -To start with a simple mobile app which provided connectivity to the network -would be great. We are not able to use the existing nebula mobile app because it -is not actually open-source, but we can at least use it as a reference to see -how this can be accomplished. - -### 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. -Existing components could be rigged to use this plugin system, and we could then -use the system to add future components which might prove useful. Once the -project is public such a system would be much appreciated I think, as it would -let other groups rig their binaries with all sorts of new functionality. diff --git a/go/cmd/entrypoint/daemon.go b/go/cmd/entrypoint/daemon.go index 4358c99..bcf53c4 100644 --- a/go/cmd/entrypoint/daemon.go +++ b/go/cmd/entrypoint/daemon.go @@ -10,6 +10,10 @@ import ( "dev.mediocregopher.com/mediocre-go-lib.git/mlog" ) +// TODO it would be good to have an `isle daemon config-check` kind of command, +// which could be run prior to a systemd service restart to make sure we don't +// restart the service into a configuration that will definitely fail. + var subCmdDaemon = subCmd{ name: "daemon", descr: "Runs the isle daemon (Default if no sub-command given)", diff --git a/go/cmd/entrypoint/daemon_util.go b/go/cmd/entrypoint/daemon_util.go index 776b41d..566abe6 100644 --- a/go/cmd/entrypoint/daemon_util.go +++ b/go/cmd/entrypoint/daemon_util.go @@ -22,6 +22,11 @@ func newHTTPServer( *http.Server, error, ) { socketPath := daemon.HTTPSocketPath() + + // TODO I restarted isle once and when it came back up it errored here + // because the socket file already existed. isle should delete the file + // during shutdown, but it should also check if the file exists on startup + // in case shutdown wasn't clean. l, err := net.Listen("unix", socketPath) if err != nil { return nil, fmt.Errorf( diff --git a/go/daemon/child_dnsmasq.go b/go/daemon/child_dnsmasq.go index 5bbe8d7..4cd361c 100644 --- a/go/daemon/child_dnsmasq.go +++ b/go/daemon/child_dnsmasq.go @@ -75,6 +75,14 @@ func dnsmasqPmuxProcConfig( Cmd: filepath.Join(binDirPath, "dnsmasq"), Args: []string{"-d", "-C", confPath}, StartAfterFunc: func(ctx context.Context) error { + // TODO consider a shared dnsmasq across all the daemon's networks. + // This would have a few benefits: + // - Less processes, less problems + // - Less configuration for the user in the case of more than one + // network. + // - Can listen on 127.0.0.x:53, rather than on the nebula address. + // This allows DNS to come up before nebula, which is helpful when + // nebula depends on DNS. return waitForNebula(ctx, logger, hostBootstrap) }, }, nil