Perform all in-code renames which don't affect actual functionality
This commit is contained in:
Brian Picciano
parent
2b9601f031
commit
3d7651208f
24
README.md
24
README.md
@ -4,9 +4,9 @@ rely on it for anything._**
|
||||
|
||||
-----
|
||||
|
||||
# cryptic-net
|
||||
# Isle
|
||||
|
||||
The cryptic-net project provides the foundation for an **autonomous community
|
||||
The Isle project provides the foundation for an **autonomous community
|
||||
cloud infrastructure**.
|
||||
|
||||
This project targets communities of individuals, where certain members of the
|
||||
@ -14,7 +14,7 @@ community would like to host services and applications from servers running in
|
||||
their homes or offices. These servers can range from simple Raspberry Pis to
|
||||
full-sized home PCs.
|
||||
|
||||
The core components of cryptic-net, currently, are:
|
||||
The core components of Isle, currently, are:
|
||||
|
||||
* A VPN which enables direct peer-to-peer communication. Even if most hosts in
|
||||
the network are on a private LAN (e.g. their home WiFi network) or have a
|
||||
@ -28,7 +28,7 @@ The core components of cryptic-net, currently, are:
|
||||
within the network.
|
||||
|
||||
These components are wrapped into a single binary, with all setup being
|
||||
automated. cryptic-net takes "just works" very seriously.
|
||||
automated. Isle takes "just works" very seriously.
|
||||
|
||||
Participants are able to build upon these foundations to host services for
|
||||
themselves and others. They can be assured that their communications are private
|
||||
@ -37,9 +37,9 @@ third parties involved.
|
||||
|
||||
## Documentation
|
||||
|
||||
cryptic-net users fall into different roles, depending on their level of
|
||||
involvement and expertise within their particular network. The documentation for
|
||||
cryptic-net is broken down by these categories, so that the reader can easily
|
||||
Isle users fall into different roles, depending on their level of
|
||||
involvement and expertise within their particular network. The documentation
|
||||
is broken down by these categories, so that the reader can easily
|
||||
decide which documents they need to care about.
|
||||
|
||||
### User Docs
|
||||
@ -90,19 +90,19 @@ Documentation for admins:
|
||||
|
||||
### Dev Docs
|
||||
|
||||
Devs may or may not be users in any particular cryptic network. They instead are
|
||||
those who work on the actual code for cryptic-net.
|
||||
Devs may or may not be users in any particular isle network. They instead are
|
||||
those who work on the actual code for Isle.
|
||||
|
||||
Documentation for devs:
|
||||
|
||||
* [Design Principles](docs/dev/design-principles.md)
|
||||
* [`cryptic-net daemon` process tree](docs/dev/daemon-process-tree.svg): Diagram
|
||||
* [`isle daemon` process tree](docs/dev/daemon-process-tree.svg): Diagram
|
||||
describing the [pmux](https://code.betamike.com/micropelago/pmux) process tree
|
||||
created by `cryptic-net daemon` at runtime.
|
||||
created by `isle daemon` at runtime.
|
||||
* [Rebuilding Documentation](docs/dev/rebuilding-documentation.md)
|
||||
* [Releases](docs/dev/releases.md)
|
||||
* [Gateway](docs/dev/gateway.md): Tentative spec for gateway functionality in
|
||||
cryptic-net
|
||||
Isle.
|
||||
|
||||
## Misc
|
||||
|
||||
|
||||
18
default.nix
18
default.nix
@ -25,7 +25,7 @@
|
||||
in rec {
|
||||
|
||||
version = pkgs.stdenv.mkDerivation {
|
||||
name = "cryptic-net-version";
|
||||
name = "isle-version";
|
||||
|
||||
inherit buildSystem hostSystem revision releaseName;
|
||||
repoSrc = ./.;
|
||||
@ -80,7 +80,7 @@ in rec {
|
||||
};
|
||||
|
||||
rootedBootstrap = pkgs.stdenv.mkDerivation {
|
||||
name = "cryptic-net-rooted-bootstrap";
|
||||
name = "isle-rooted-bootstrap";
|
||||
|
||||
src = bootstrap;
|
||||
|
||||
@ -92,10 +92,10 @@ in rec {
|
||||
};
|
||||
|
||||
appDir = pkgs.stdenv.mkDerivation {
|
||||
name = "cryptic-net-AppDir";
|
||||
name = "isle-AppDir";
|
||||
|
||||
src = pkgs.buildEnv {
|
||||
name = "cryptic-net-AppDir-base";
|
||||
name = "isle-AppDir-base";
|
||||
paths = [
|
||||
|
||||
./AppDir
|
||||
@ -122,7 +122,7 @@ in rec {
|
||||
appimagetool = pkgs.callPackage ./nix/appimagetool.nix {};
|
||||
|
||||
appImage = pkgs.stdenv.mkDerivation {
|
||||
name = "cryptic-net-AppImage";
|
||||
name = "isle-AppImage";
|
||||
src = appDir;
|
||||
|
||||
nativeBuildInputs = [
|
||||
@ -133,19 +133,19 @@ in rec {
|
||||
|
||||
builder = builtins.toFile "build.sh" ''
|
||||
source $stdenv/setup
|
||||
cp -rL "$src" cryptic-net.AppDir
|
||||
chmod +w cryptic-net.AppDir -R
|
||||
cp -rL "$src" isle.AppDir
|
||||
chmod +w isle.AppDir -R
|
||||
|
||||
export VERSION=debug
|
||||
|
||||
# https://github.com/probonopd/go-appimage/issues/155
|
||||
unset SOURCE_DATE_EPOCH
|
||||
|
||||
appimagetool ./cryptic-net.AppDir
|
||||
appimagetool ./isle.AppDir
|
||||
|
||||
mkdir -p "$out"/bin
|
||||
chmod +w "$out" -R
|
||||
mv Cryptic_Net-* "$out"/bin/cryptic-net
|
||||
mv Isle-* "$out"/bin/isle
|
||||
'';
|
||||
};
|
||||
}
|
||||
|
||||
@ -4,16 +4,16 @@ This document guides an admin through adding a single host to the network. Keep
|
||||
in mind that the steps described here must be done for _each_ host the user
|
||||
wishes to add.
|
||||
|
||||
There are two ways for a user to add a host to the cryptic network.
|
||||
There are two ways for a user to add a host to the isle network.
|
||||
|
||||
- If the user is savy enough to obtain their own `cryptic-net` binary, they can
|
||||
- If the user is savy enough to obtain their own `isle` binary, they can
|
||||
do so. The admin can then generate a `bootstrap.yml` file for their host,
|
||||
give that to the user, and the user can run `cryptic-net daemon` using that
|
||||
give that to the user, and the user can run `isle daemon` using that
|
||||
bootstrap file.
|
||||
|
||||
- If the user is not so savy, the admin can generate a custom `cryptic-net`
|
||||
- If the user is not so savy, the admin can generate a custom `isle`
|
||||
binary with the `bootstrap.yml` embedded into it. The user can be given this
|
||||
binary and run `cryptic-net daemon` without any configuration on their end.
|
||||
binary and run `isle daemon` without any configuration on their end.
|
||||
|
||||
From the admin's perspective the only difference between these cases is one
|
||||
extra step.
|
||||
@ -43,7 +43,7 @@ To create a `bootstrap.yml` file for the new host, the admin should perform the
|
||||
following command from their own host:
|
||||
|
||||
```
|
||||
cryptic-net hosts create-bootstrap \
|
||||
isle hosts create-bootstrap \
|
||||
--hostname <name> \
|
||||
--ip <ip> \
|
||||
--admin-path <path to admin.yml> \
|
||||
@ -54,9 +54,9 @@ The resulting `bootstrap.yml` file should be treated as a secret file that is
|
||||
shared only with the user it was generated for. The `bootstrap.yml` file should
|
||||
not be re-used between hosts either.
|
||||
|
||||
If the user already has access to a `cryptic-net` binary then the new
|
||||
If the user already has access to a `isle` binary then the new
|
||||
`bootstrap.yml` file can be given to them as-is, and they can proceed with
|
||||
running their host's `cryptic-net daemon`.
|
||||
running their host's `isle daemon`.
|
||||
|
||||
### Encrypted `admin.yml`
|
||||
|
||||
@ -66,7 +66,7 @@ GPG is being used to secure `admin.yml` then the following could be used to
|
||||
generate a `bootstrap.yml`:
|
||||
|
||||
```
|
||||
gpg -d <path to admin.yml.gpg> | cryptic-net hosts create-bootstrap \
|
||||
gpg -d <path to admin.yml.gpg> | isle hosts create-bootstrap \
|
||||
--hostname <name> \
|
||||
--ip <ip> \
|
||||
--admin-path - \
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
# Creating a New Network
|
||||
|
||||
This guide is for those who wish to start a new cryptic network of their
|
||||
This guide is for those who wish to start a new isle network of their
|
||||
own.
|
||||
|
||||
By starting a new cryptic network, you are becoming the administrator of a
|
||||
By starting a new isle network, you are becoming the administrator of a
|
||||
network. Be aware that being a network administrator is not necessarily easy,
|
||||
and the users of your network will frequently need your help in order to have a
|
||||
good experience. It can be helpful to have others with which you are
|
||||
@ -42,7 +42,7 @@ A `daemon.yml` will need to be created for use during network creation. You can
|
||||
create a new `daemon.yml` with default values filled in by doing:
|
||||
|
||||
```
|
||||
cryptic-net admin create-network --dump-config > /path/to/daemon.yml
|
||||
isle admin create-network --dump-config > /path/to/daemon.yml
|
||||
```
|
||||
|
||||
Open this file in a text editor and perform the following changes:
|
||||
@ -70,7 +70,7 @@ be chosen with care.
|
||||
networks](https://en.wikipedia.org/wiki/IPv4#Private_networks), but within
|
||||
that selection the choice is up to you.
|
||||
|
||||
* Domain: cryptic-net is shipped with a DNS server which will automatically
|
||||
* Domain: isle is shipped with a DNS server which will automatically
|
||||
configure itself with all hosts in the network, with each DNS entry taking the
|
||||
form of `hostname.hosts.domain`, where `domain` is the domain chosen in this
|
||||
step. The domain may be a valid public domain or not, it's up to you.
|
||||
@ -86,7 +86,7 @@ be chosen with care.
|
||||
## Step 3: Prepare to Encrypt `admin.yml`
|
||||
|
||||
The `admin.yml` file (which will be created in the next step) is the most
|
||||
sensitive part of a cryptic network. If it falls into the wrong hands it can be
|
||||
sensitive part of a isle network. If it falls into the wrong hands it can be
|
||||
used to completely compromise your network, impersonate hosts on the network,
|
||||
and will likely lead to someone stealing or deleting all of your data.
|
||||
|
||||
@ -103,7 +103,7 @@ To create the `admin.yml` file, which effectively creates the network itself,
|
||||
you can run:
|
||||
|
||||
```
|
||||
sudo cryptic-net admin create-network \
|
||||
sudo isle admin create-network \
|
||||
--config-path /path/to/daemon.yml \
|
||||
--name <name> \
|
||||
--ip-net <ip/subnet-prefix> \
|
||||
@ -132,10 +132,10 @@ At this point you should have an `admin.yml.gpg` file in your current directory.
|
||||
|
||||
## Step 5: Run the Daemon
|
||||
|
||||
The cryptic-net daemon can be run now, using the following command:
|
||||
The isle daemon can be run now, using the following command:
|
||||
|
||||
```
|
||||
sudo cryptic-net daemon -c /path/to/daemon.yml
|
||||
sudo isle daemon -c /path/to/daemon.yml
|
||||
```
|
||||
|
||||
**NOTE** that you _must_ use the same `daemon.yml` file used when creating the
|
||||
@ -145,9 +145,4 @@ At this point your host, and your network, are ready to go! You can reference
|
||||
the [Getting Started](../user/getting-started.md) document to set up your
|
||||
host's daemon process in a more permanent way.
|
||||
|
||||
## Next Steps
|
||||
|
||||
* Add users
|
||||
* Fix directories
|
||||
|
||||
[ddns]: https://www.cloudflare.com/learning/dns/glossary/dynamic-dns/
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
@startuml
|
||||
hide empty description
|
||||
|
||||
state "./cryptic-net daemon -c ./daemon.yml" as init
|
||||
state "./isle daemon -c ./daemon.yml" as init
|
||||
|
||||
state AppDir {
|
||||
|
||||
|
||||
@ -1,21 +1,20 @@
|
||||
# Design Principles
|
||||
|
||||
The following points form the basis for all design decisions made within the
|
||||
cryptic-net project.
|
||||
Isle project.
|
||||
|
||||
* The UX is aggressively optimized to eliminate manual intervention by users.
|
||||
All other concerns are secondary. The concept of "UX" extends beyond GUI
|
||||
interfaces, and encompasses all interactions of any sort with a cryptic-net
|
||||
interfaces, and encompasses all interactions of any sort with a isle
|
||||
process.
|
||||
|
||||
* All resources within a cryptic-net are expected to be hosted on hardware owned
|
||||
by community members, for example home media servers or gaming rigs. Thus, a
|
||||
cryptic-net is fully autonomous.
|
||||
* All resources within an isle network are expected to be hosted on hardware
|
||||
owned by community members, for example home media servers or gaming rigs.
|
||||
Thus, an isle is fully autonomous.
|
||||
|
||||
* Hardware resources are expected to be heterogenous and geographically
|
||||
dispersed.
|
||||
|
||||
* It is expected that a single host might be a part of multiple, independent
|
||||
cryptic networks. These should not conflict with each other, nor share
|
||||
resources.
|
||||
isle networks. These should not conflict with each other, nor share resources.
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Gateway
|
||||
|
||||
This document acts as the spec for a general purpose gateway system built into
|
||||
the cryptic-net daemon.
|
||||
the isle daemon.
|
||||
|
||||
The high level goal of the gateway is to remove significant barriers to entry
|
||||
for individuals hosting data and services at their own domain names:
|
||||
@ -15,21 +15,21 @@ network they will have already solved these problems. By providing gateway
|
||||
functionality they can share that work with their community.
|
||||
|
||||
The gateway functions by serving requests for a user's DNS domain on their
|
||||
behalf. Requests are served by publicly facing hosts of a cryptic network using
|
||||
behalf. Requests are served by publicly facing hosts of an isle network using
|
||||
a backend configured by the user.
|
||||
|
||||
## Terminology
|
||||
|
||||
* "gateway process" refers to the the system process running on a single host
|
||||
which serves requests for a cryptic network's gateway.
|
||||
which serves requests for an isle network's gateway.
|
||||
|
||||
* "gateway" refers to the collection of all gateway processes which are
|
||||
configured and running for a cryptic network. All gateway processes exhibit
|
||||
configured and running for an isle network. All gateway processes exhibit
|
||||
the same behavior, and serve the same domain names, and so are conceived as
|
||||
being a single unit.
|
||||
|
||||
* "gateway DNS name" refers to the single DNS domain or subdomain which contains
|
||||
a A/AAAA record for each of the gateway processes of a cryptic network.
|
||||
a A/AAAA record for each of the gateway processes of an isle network.
|
||||
|
||||
## Gateway DNS Setup
|
||||
|
||||
@ -57,7 +57,7 @@ to serve requests at a domain. Backends could include:
|
||||
- Public git repositories (like how github pages works)
|
||||
- S3 buckets on the private garage cluster
|
||||
- IPFS files or IPNS names
|
||||
- Services which are available privately over cryptic network
|
||||
- Services which are available privately over an isle network
|
||||
|
||||
A backend is uniquely described and identified by an object containing a `type`
|
||||
field, and then further fields which depend on the type. The object for a git
|
||||
@ -73,14 +73,14 @@ repository backend would look like:
|
||||
|
||||
All backends essentially act as a static filesystem, from which requests are
|
||||
served by the gateway. For example, given a domain `example.com` which has been
|
||||
configured with a cryptic network gateway to serve a git repo, if
|
||||
configured with an isle network gateway to serve a git repo, if
|
||||
`example.com/foo/bar` is requested then the file at `/foo/bar` within the
|
||||
current tip of the git repo is served.
|
||||
|
||||
## User Experience
|
||||
|
||||
It should be noted up-front that a gateway user should not need to have any
|
||||
hosts registered on a cryptic network, or have any other material connection to
|
||||
hosts registered on an isle network, or have any other material connection to
|
||||
the network, in order to use the gateway.
|
||||
|
||||
### Setup a Domain
|
||||
@ -105,7 +105,7 @@ instructions. The instructions prompt the user to:
|
||||
|
||||
* Add a CNAME record to their DNS domain, pointing to the gateway DNS name.
|
||||
|
||||
* Add a TXT record to their DNS domain containing `cryptic_net_gateway=<opaque
|
||||
* Add a TXT record to their DNS domain containing `isle_gateway=<opaque
|
||||
string>`.
|
||||
|
||||
The page provides the user with an input box to input their domain name into,
|
||||
@ -194,7 +194,7 @@ They are not meant to be set in stone.
|
||||
|
||||
## Future Work
|
||||
|
||||
It should be possible for someone accessing a private domain on the cryptic
|
||||
It should be possible for someone accessing a private domain on the isle
|
||||
network to access the gateway web panel and use it _without_ requiring a secret
|
||||
passphrase. This way community members who have already been vetted (by being
|
||||
added to the VPN) can have even less friction.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Rebuilding Documentation
|
||||
|
||||
Most documentation for cryptic-net takes the form of markdown (`.md`) files,
|
||||
Most documentation for Isle takes the form of markdown (`.md`) files,
|
||||
which do not require any build step. There are a few other kinds of files, such
|
||||
as `.plantuml` files, which do require a build step. If these are changed then
|
||||
their artifacts should be rebuilt by doing:
|
||||
|
||||
@ -15,7 +15,7 @@ A release consists of:
|
||||
To create a release only a functional nix installation is required. Simply run
|
||||
the `./release.sh` script, and input a release name when prompted.
|
||||
|
||||
From here a cryptic-net binary will be cross-compiled for all supported
|
||||
From here an `isle` binary will be cross-compiled for all supported
|
||||
platforms. This will take a long time the first time you perform it on your
|
||||
machine.
|
||||
|
||||
|
||||
@ -4,14 +4,17 @@ The purpose of this document is define the specific terms which should be used
|
||||
for various concepts, with the goal of establishing consistency throughout
|
||||
documentation and source code.
|
||||
|
||||
- "user" - a person who takes part in the usage, operation, or administration of
|
||||
a cryptic network.
|
||||
- "Isle" - The name of this project, which is a proper noun and so should always
|
||||
be capitalized.
|
||||
|
||||
- "host" - A computer or device used by a user to connect to a cryptic network.
|
||||
- "isle" - The name of the binary or program produced by the Isle project. isle
|
||||
is the name of the file itself, and so is always lower-case.
|
||||
|
||||
- "cryptic network", "network" - A collection of hosts which communicate and
|
||||
share resources with each other via the mechanisms provided by the cryptic-net
|
||||
project.
|
||||
- "host" - A computer or device on which isle is run.
|
||||
|
||||
- "isle network", "network" - A collection of hosts which communicate and share
|
||||
resources with each other via the Isle project.
|
||||
|
||||
- "user" - A person who takes part in the usage, operation, or administration of
|
||||
an isle network.
|
||||
|
||||
- "cryptic-net" - The name of the binary or program which is used to interact
|
||||
with a cryptic network.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Contributing a Lighthouse
|
||||
|
||||
The [nebula][nebula] project provides the VPN component which is used by
|
||||
cryptic-net. Every nebula network requires at least one (but preferably more)
|
||||
Isle. Every nebula network requires at least one (but preferably more)
|
||||
publicly accessible hosts. These hosts are called lighthouses.
|
||||
|
||||
Lighthouses do _not_ route traffic between hosts on the VPN. Rather, they
|
||||
@ -10,7 +10,7 @@ NAT punching through any NATs that hosts might be behind. As such, they are very
|
||||
lightweight to run, and require no storage resources at all.
|
||||
|
||||
If your host machine has a public static IP, or a dynamic public IP with
|
||||
[dDNS][ddns] set up, then it can contribute a lighthouse for cryptic-net.
|
||||
[dDNS][ddns] set up, then it can contribute a lighthouse.
|
||||
|
||||
[nebula]: https://github.com/slackhq/nebula
|
||||
[ddns]: https://www.cloudflare.com/learning/dns/glossary/dynamic-dns/
|
||||
@ -30,7 +30,7 @@ Configure your host's firewall to allow all UDP traffic on that port.
|
||||
|
||||
First, if you haven't already, [create a `daemon.yml`
|
||||
file](../user/creating-a-daemonyml-file.md). This will be used to
|
||||
configure your `cryptic-net daemon` process with the public address that other
|
||||
configure your `isle daemon` process with the public address that other
|
||||
hosts can find your daemon on.
|
||||
|
||||
## Edit daemon.yml
|
||||
@ -41,6 +41,6 @@ port.
|
||||
|
||||
## Restart the Daemon
|
||||
|
||||
With the `daemon.yml` configured, you should restart your `cryptic-net daemon`
|
||||
With the `daemon.yml` configured, you should restart your `isle daemon`
|
||||
process. On startup the daemon will add its public address to the global
|
||||
configuration, which other hosts will pick up on and begin using.
|
||||
|
||||
@ -8,7 +8,7 @@ to the network, then this document is for you.
|
||||
|
||||
First, if you haven't already, [create a `daemon.yml`
|
||||
file](../user/creating-a-daemonyml-file.md). This will be used to
|
||||
configure your `cryptic-net daemon` process with the storage locations and
|
||||
configure your `isle daemon` process with the storage locations and
|
||||
capacities you want to contribute.
|
||||
|
||||
## Edit `daemon.yml`
|
||||
@ -31,13 +31,13 @@ storage:
|
||||
allocations:
|
||||
|
||||
# 1.2 TB are being shared from drive1
|
||||
- data_path: /mnt/drive1/cryptic-net/data
|
||||
meta_path: /mnt/drive1/cryptic-net/meta
|
||||
- data_path: /mnt/drive1/isle/data
|
||||
meta_path: /mnt/drive1/isle/meta
|
||||
capacity: 1200
|
||||
|
||||
# 100 GB (the minimum) are being shared from drive2
|
||||
- data_path: /mnt/drive2/cryptic-net/data
|
||||
meta_path: /mnt/drive2/cryptic-net/meta
|
||||
- data_path: /mnt/drive2/isle/data
|
||||
meta_path: /mnt/drive2/isle/meta
|
||||
capacity: 100
|
||||
```
|
||||
|
||||
@ -48,17 +48,17 @@ is properly set up for providing storage.
|
||||
|
||||
## Restart the Daemon
|
||||
|
||||
With the `daemon.yml` configured, you should restart your `cryptic-net daemon`
|
||||
With the `daemon.yml` configured, you should restart your `isle daemon`
|
||||
process.
|
||||
|
||||
The `cryptic-net daemon` will automatically allow the ports used for your
|
||||
The `isle daemon` will automatically allow the ports used for your
|
||||
storage allocations in the vpn firewall.
|
||||
|
||||
## Further Reading
|
||||
|
||||
cryptic-net uses the [garage][garage] project for its storage system. See the
|
||||
Isle uses the [garage][garage] project for its storage system. See the
|
||||
[Managing Garage](managing-garage.md) document for more
|
||||
information on how to interact directly with the garage instance being run by
|
||||
cryptic-net.
|
||||
isle.
|
||||
|
||||
[garage]: https://garagehq.deuxfleurs.fr/documentation/quick-start/
|
||||
|
||||
@ -10,29 +10,28 @@ the host's firewall, and the VPN firewall.
|
||||
|
||||
## VPN Firewall
|
||||
|
||||
cryptic-net uses the [nebula](https://github.com/slackhq/nebula) project to
|
||||
Isle uses the [nebula](https://github.com/slackhq/nebula) project to
|
||||
provide its VPN layer. Nebula ships with its own [builtin
|
||||
firewall](https://nebula.defined.net/docs/config/firewall), which only applies
|
||||
to connections coming in over the virtual network interface which it creates.
|
||||
This firewall can be manually configured as part of cryptic-net's
|
||||
This firewall can be manually configured as part of isle's
|
||||
[`daemon.yml`](../user/creating-a-daemonyml-file.md) file.
|
||||
|
||||
Any storage instances which are defined as part of the `daemon.yml` file will
|
||||
have their network ports automatically added to the VPN firewall by cryptic-net.
|
||||
have their network ports automatically added to the VPN firewall by isle.
|
||||
This means that you only need to configure the VPN firewall if you are hosting
|
||||
services for your cryptic network besides storage.
|
||||
services for your isle network besides storage.
|
||||
|
||||
## Host Firewall
|
||||
|
||||
The host you are running cryptic-net on will almost definitely have a firewall
|
||||
The host you are running isle on will almost definitely have a firewall
|
||||
running, separate from the VPN firewall. If you wish to provide services for
|
||||
your cryptic network from your host, you will need to allow their ports in your
|
||||
your isle network from your host, you will need to allow their ports in your
|
||||
host's firewall.
|
||||
|
||||
**cryptic-net does _not_ automatically configure your host's firewall to any
|
||||
extent!**
|
||||
**isle does _not_ automatically configure your host's firewall to any extent!**
|
||||
|
||||
One option is to open your host to all traffic from your cryptic network, and
|
||||
One option is to open your host to all traffic from your isle network, and
|
||||
allow the VPN firewall to be fully responsible for filtering traffic. To do this
|
||||
on Linux using iptables, for example, you would add something like this to your
|
||||
iptables configuration:
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
# Managing Garage
|
||||
|
||||
The garage project provides the network storage component for
|
||||
cryptic-net. If you're reading this document then you would likely benefit
|
||||
Isle. If you're reading this document then you would likely benefit
|
||||
greatly from reading the [garage documentation][garage] on their website. It's
|
||||
extremely well written and concise.
|
||||
|
||||
Note that the `cryptic-net daemon` process will handle all setup steps described
|
||||
Note that the `isle daemon` process will handle all setup steps described
|
||||
in that documentation, but it's still good to have an understanding of how
|
||||
garage works and what it can do.
|
||||
|
||||
@ -13,12 +13,12 @@ garage works and what it can do.
|
||||
|
||||
## Garage Runtime Note
|
||||
|
||||
There is an important thing to note regarding how cryptic-net runs garage. As
|
||||
There is an important thing to note regarding how isle runs garage. As
|
||||
described in the [Contributing Storage](contributing-storage.md) document, a
|
||||
single `cryptic-net daemon` process can be configured to provide any number of
|
||||
single `isle daemon` process can be configured to provide any number of
|
||||
storage allocations.
|
||||
|
||||
For each allocation which is configured, `cryptic-net daemon` will configure and
|
||||
For each allocation which is configured, `isle daemon` will configure and
|
||||
run a separate `garage server` instance as a sub-process. Each garage will use
|
||||
the host's name as its zone in the garage cluster layout, which means that the
|
||||
cluster will prefer to not replicate the same data within the same host, but may
|
||||
@ -26,14 +26,14 @@ do so if necessary.
|
||||
|
||||
## Garage CLI
|
||||
|
||||
Every `cryptic-net` binary contains a full `garage` binary embedded into it.
|
||||
Every `isle` binary contains a full `garage` binary embedded into it.
|
||||
This binary can be accessed directly like so:
|
||||
|
||||
```
|
||||
sudo cryptic-net garage cli <subcmd> <args>
|
||||
sudo isle garage cli <subcmd> <args>
|
||||
```
|
||||
|
||||
Before handing off execution to the `garage` binary, the `cryptic-net` process
|
||||
Before handing off execution to the `garage` binary, the `isle` process
|
||||
will automatically set up the RPC host and secret environment variables.
|
||||
|
||||
If the host which is running the command has more than one allocation
|
||||
@ -47,7 +47,7 @@ connected to.
|
||||
To display the current layout of the garage cluster:
|
||||
|
||||
```
|
||||
sudo cryptic-net garage cli layout show
|
||||
sudo isle garage cli layout show
|
||||
```
|
||||
|
||||
**(DO NOT CHANGE THE CLUSTER LAYOUT UNLESS YOU KNOW WHAT YOU'RE DOING!)**
|
||||
@ -55,11 +55,11 @@ sudo cryptic-net garage cli layout show
|
||||
To create a new bucket:
|
||||
|
||||
```
|
||||
sudo cryptic-net garage cli bucket create new-bucket
|
||||
sudo isle garage cli bucket create new-bucket
|
||||
```
|
||||
|
||||
To list existing buckets:
|
||||
|
||||
```
|
||||
sudo cryptic-net garage cli bucket list
|
||||
sudo isle garage cli bucket list
|
||||
```
|
||||
|
||||
@ -31,17 +31,17 @@ automatically serves DNS queries, unless set to not do so in `daemon.yml`.
|
||||
|
||||
### Install sub-command
|
||||
|
||||
It would be great to have a `cryptic-net install` sub-command which would
|
||||
It would be great to have a `isle install` sub-command which would
|
||||
auto-detect the installed operating system and install the daemon automatically.
|
||||
|
||||
### Web server + interface
|
||||
|
||||
One idea is to have every `cryptic-net daemon` run a webserver as one of its
|
||||
One idea is to have every `isle daemon` run a webserver as one of its
|
||||
sub-processes. This server could serve multiple functions:
|
||||
|
||||
- [Gateway service](./dev/gateway.md).
|
||||
|
||||
- Local interface for the `cryptic-net daemon` process. For example, status and
|
||||
- Local interface for the `isle daemon` process. For example, 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
|
||||
@ -65,7 +65,7 @@ needed would be:
|
||||
|
||||
### Don't run as root
|
||||
|
||||
It's currently a pretty hard requirement for `cryptic-net daemon` to run as
|
||||
It's currently a pretty hard requirement for `isle daemon` to run as
|
||||
root. This is due to:
|
||||
|
||||
- nebula's network interface root to be started.
|
||||
@ -73,7 +73,7 @@ root. This is due to:
|
||||
- dnsmasq listening on port 53, generally a protected port.
|
||||
|
||||
If we can't figure out how to get these things running from the start as
|
||||
non-privileged users, we at least need to get cryptic-net to drop priveleges
|
||||
non-privileged users, we at least need to get isle to drop privileges
|
||||
from root after initial startup.
|
||||
|
||||
### Plugins
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
pkgs ? (import ../nix/pkgs.nix).pkgs,
|
||||
|
||||
}: pkgs.mkShell {
|
||||
name = "cryptic-net-build-docs";
|
||||
name = "isle-build-docs";
|
||||
buildInputs = [ pkgs.plantuml ];
|
||||
|
||||
shellHook = ''
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Creating a daemon.yml File
|
||||
|
||||
The `cryptic-net daemon` process has generally sane defaults and does not need
|
||||
The `isle daemon` process has generally sane defaults and does not need
|
||||
to be configured for most users. This document describes how to use the
|
||||
`daemon.yml` file to handle those cases where configuration is necessary.
|
||||
|
||||
@ -10,11 +10,11 @@ First, create a `daemon.yml` file. You can create a new `daemon.yml` with
|
||||
default values filled in by doing:
|
||||
|
||||
```
|
||||
cryptic-net daemon --dump-config > /path/to/daemon.yml
|
||||
isle daemon --dump-config > /path/to/daemon.yml
|
||||
```
|
||||
|
||||
If you open that file in a text editor you can view all default values that
|
||||
`cryptic-net daemon` ships with, as well as documentation for all configurable
|
||||
`isle daemon` ships with, as well as documentation for all configurable
|
||||
parameters. Feel free to edit this file as needed.
|
||||
|
||||
## Using daemon.yml
|
||||
@ -23,10 +23,10 @@ With the `daemon.yml` created and configured, you can configure your daemon
|
||||
process to use it by passing it as the `--config-path` argument:
|
||||
|
||||
```
|
||||
sudo cryptic-net daemon --config-path /path/to/daemon.yml
|
||||
sudo isle daemon --config-path /path/to/daemon.yml
|
||||
```
|
||||
|
||||
If you are an operator then your host should be running its `cryptic-net daemon`
|
||||
If you are an operator then your host should be running its `isle daemon`
|
||||
process in systemd (see [Getting Started](getting-started.md) if
|
||||
not), and you will need to modify the service file accordingly.
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Getting Started
|
||||
|
||||
This document will guide you through the process of obtaining a cryptic-net
|
||||
binary and joining the network.
|
||||
This document will guide you through the process of obtaining an isle
|
||||
binary and joining a network.
|
||||
|
||||
NOTE currently only linux machines with the following architectures are
|
||||
supported:
|
||||
@ -15,7 +15,7 @@ supported:
|
||||
|
||||
More OSs and architectures coming soon!
|
||||
|
||||
## Obtaining a cryptic-net Binary
|
||||
## Obtaining an isle Binary
|
||||
|
||||
Every host can have a binary built for it which has all configuration for that
|
||||
host embedded directly into it. Such binaries require no extra configuration by
|
||||
@ -28,7 +28,7 @@ Note that if you'd like to join the network on multiple devices, each device
|
||||
will needs its own binary, so be sure to tell your admin how many you want to
|
||||
add and their names.
|
||||
|
||||
### Obtaining a cryptic-net Binary, the Hard Way
|
||||
### Obtaining an isle Binary, the Hard Way
|
||||
|
||||
Alternatively, you can build your own binary by running the following from the
|
||||
project's root:
|
||||
@ -37,7 +37,7 @@ project's root:
|
||||
nix-build -A appImage
|
||||
```
|
||||
|
||||
(*NOTE* Dependencies of `cryptic-net` seemingly compile all of musl and rust
|
||||
(*NOTE* Dependencies of `isle` seemingly compile all of musl and rust
|
||||
from scratch (it's not clear why, blame garage!). If you have not otherwise
|
||||
configured it, nix might be using a tmpfs as its build directory, and the
|
||||
capacity of this tmpfs will probably be exceeded by this build. You can change
|
||||
@ -59,7 +59,7 @@ Once you have a binary, you will need to run the `daemon` sub-command as the
|
||||
root user. This can most easily be done using the `sudo` command, in a terminal:
|
||||
|
||||
```
|
||||
sudo /path/to/cryptic-net daemon
|
||||
sudo /path/to/isle daemon
|
||||
```
|
||||
|
||||
This will start the daemon process, which will keep running until you kill it
|
||||
@ -83,12 +83,12 @@ Rather than running the daemon manually, you can install it as a systemd
|
||||
service. This way your daemon will automatically start in the background on
|
||||
startup, and will be restarted if it has any issues.
|
||||
|
||||
To do so, create a file at `/etc/systemd/system/cryptic-net.service` with the
|
||||
To do so, create a file at `/etc/systemd/system/isle.service` with the
|
||||
following contents:
|
||||
|
||||
```
|
||||
[Unit]
|
||||
Description=cryptic-net
|
||||
Description=isle
|
||||
Requires=network.target
|
||||
After=network.target
|
||||
|
||||
@ -96,13 +96,13 @@ After=network.target
|
||||
Restart=always
|
||||
RestartSec=1s
|
||||
User=root
|
||||
ExecStart=/path/to/cryptic-net daemon
|
||||
ExecStart=/path/to/isle daemon
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
Remember to change the `/path/to/cryptic-net` part to the actual absolute path
|
||||
Remember to change the `/path/to/isle` part to the actual absolute path
|
||||
to your binary!
|
||||
|
||||
Once created, perform the following commands in a terminal to enable the
|
||||
@ -110,17 +110,17 @@ service:
|
||||
|
||||
```
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable --now cryptic-net
|
||||
sudo systemctl enable --now isle
|
||||
```
|
||||
|
||||
You can check the service's status by doing:
|
||||
|
||||
```
|
||||
sudo systemctl status cryptic-net
|
||||
sudo systemctl status isle
|
||||
```
|
||||
|
||||
and you can view its full logs by doing:
|
||||
|
||||
```
|
||||
sudo journalctl -lu cryptic-net
|
||||
sudo journalctl -lu isle
|
||||
```
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Using DNS
|
||||
|
||||
Every `cryptic-net daemon` process ships with a DNS server which runs
|
||||
Every `isle daemon` process ships with a DNS server which runs
|
||||
automatically. This server will listen on port 53 on the VPN IP of that
|
||||
particular host.
|
||||
|
||||
@ -13,14 +13,14 @@ server will forward the request to a pre-configured public resolver. The set of
|
||||
public resolvers used can be configured using the
|
||||
[daemon.yml](creating-a-daemonyml-file.md) file.
|
||||
|
||||
This DNS server is an optional feature of cryptic-net, and not required in
|
||||
general for making use of the network.
|
||||
This DNS server is an optional feature of Isle, and not required in general for
|
||||
making use of the network.
|
||||
|
||||
## Example
|
||||
|
||||
As an example of how to make use of this DNS server, let's say my host's IP on
|
||||
the network is `10.10.1.1`, and my network's domain is `cool.internal`.
|
||||
In order to configure the host to use the cryptic-net DNS server for all DNS
|
||||
In order to configure the host to use the isle DNS server for all DNS
|
||||
requests, I could do something like this:
|
||||
|
||||
```
|
||||
@ -28,7 +28,7 @@ sudo su
|
||||
echo "nameserver 10.10.1.1" > /etc/resolv.conf
|
||||
```
|
||||
|
||||
From that point, all DNS requests on my host would hit the cryptic-net DNS
|
||||
From that point, all DNS requests on my host would hit the isle DNS
|
||||
server. If I request `my-host.hosts.cool.internal`, it would respond with the
|
||||
appropriate private IP.
|
||||
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
package admin
|
||||
|
||||
import (
|
||||
"cryptic-net/garage"
|
||||
"cryptic-net/nebula"
|
||||
"isle/garage"
|
||||
"isle/nebula"
|
||||
"io"
|
||||
|
||||
"gopkg.in/yaml.v3"
|
||||
|
||||
@ -3,9 +3,9 @@
|
||||
package bootstrap
|
||||
|
||||
import (
|
||||
"cryptic-net/admin"
|
||||
"cryptic-net/garage"
|
||||
"cryptic-net/nebula"
|
||||
"isle/admin"
|
||||
"isle/garage"
|
||||
"isle/nebula"
|
||||
"crypto/sha512"
|
||||
"fmt"
|
||||
"io"
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
package bootstrap
|
||||
|
||||
import (
|
||||
"cryptic-net/garage"
|
||||
"isle/garage"
|
||||
)
|
||||
|
||||
// GaragePeers returns a Peer for each known garage instance in the network.
|
||||
|
||||
@ -3,8 +3,8 @@ package bootstrap
|
||||
import (
|
||||
"bytes"
|
||||
"context"
|
||||
"cryptic-net/garage"
|
||||
"cryptic-net/nebula"
|
||||
"isle/garage"
|
||||
"isle/nebula"
|
||||
"fmt"
|
||||
"path/filepath"
|
||||
"strings"
|
||||
|
||||
@ -2,7 +2,7 @@ package bootstrap
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"cryptic-net/nebula"
|
||||
"isle/nebula"
|
||||
"fmt"
|
||||
"net"
|
||||
"strings"
|
||||
|
||||
@ -2,15 +2,15 @@ package main
|
||||
|
||||
import (
|
||||
"context"
|
||||
"cryptic-net/admin"
|
||||
"cryptic-net/bootstrap"
|
||||
"cryptic-net/daemon"
|
||||
"cryptic-net/garage"
|
||||
"cryptic-net/nebula"
|
||||
"crypto/rand"
|
||||
"encoding/hex"
|
||||
"errors"
|
||||
"fmt"
|
||||
"isle/admin"
|
||||
"isle/bootstrap"
|
||||
"isle/daemon"
|
||||
"isle/garage"
|
||||
"isle/nebula"
|
||||
"net"
|
||||
"os"
|
||||
"strings"
|
||||
@ -50,7 +50,7 @@ func readAdmin(path string) (admin.Admin, error) {
|
||||
|
||||
var subCmdAdminCreateNetwork = subCmd{
|
||||
name: "create-network",
|
||||
descr: "Creates a new cryptic network, outputting the resulting admin.yml to stdout",
|
||||
descr: "Creates a new isle network, outputting the resulting admin.yml to stdout",
|
||||
do: func(subCmdCtx subCmdCtx) error {
|
||||
|
||||
flags := subCmdCtx.flagSet(false)
|
||||
@ -237,7 +237,7 @@ var subCmdAdminCreateNetwork = subCmd{
|
||||
err = garageInitializeGlobalBucket(ctx, logger, hostBootstrap, daemonConfig)
|
||||
|
||||
if cErr := (garage.AdminClientError{}); errors.As(err, &cErr) && cErr.StatusCode == 409 {
|
||||
return fmt.Errorf("shared global bucket has already been created, are the storage allocations from a previously initialized cryptic-net being used?")
|
||||
return fmt.Errorf("shared global bucket has already been created, are the storage allocations from a previously initialized isle being used?")
|
||||
|
||||
} else if err != nil {
|
||||
return fmt.Errorf("initializing garage shared global bucket: %w", err)
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
package main
|
||||
|
||||
import (
|
||||
"cryptic-net/bootstrap"
|
||||
"isle/bootstrap"
|
||||
"errors"
|
||||
"fmt"
|
||||
"io/fs"
|
||||
|
||||
@ -10,16 +10,16 @@ import (
|
||||
"sync"
|
||||
"time"
|
||||
|
||||
"cryptic-net/bootstrap"
|
||||
"cryptic-net/daemon"
|
||||
"isle/bootstrap"
|
||||
"isle/daemon"
|
||||
|
||||
"code.betamike.com/micropelago/pmux/pmuxlib"
|
||||
"github.com/mediocregopher/mediocre-go-lib/v2/mctx"
|
||||
"github.com/mediocregopher/mediocre-go-lib/v2/mlog"
|
||||
)
|
||||
|
||||
// The daemon sub-command deals with starting an actual cryptic-net daemon
|
||||
// process, which is required to be running for most other cryptic-net
|
||||
// The daemon sub-command deals with starting an actual isle daemon
|
||||
// process, which is required to be running for most other Isle
|
||||
// functionality. The sub-command does the following:
|
||||
//
|
||||
// * Creates and locks the runtime directory.
|
||||
@ -196,7 +196,7 @@ func runDaemonPmuxOnce(
|
||||
|
||||
var subCmdDaemon = subCmd{
|
||||
name: "daemon",
|
||||
descr: "Runs the cryptic-net daemon (Default if no sub-command given)",
|
||||
descr: "Runs the isle daemon (Default if no sub-command given)",
|
||||
do: func(subCmdCtx subCmdCtx) error {
|
||||
|
||||
flags := subCmdCtx.flagSet(false)
|
||||
@ -213,7 +213,7 @@ var subCmdDaemon = subCmd{
|
||||
|
||||
bootstrapPath := flags.StringP(
|
||||
"bootstrap-path", "b", "",
|
||||
`Path to a bootstrap.yml file. This only needs to be provided the first time the daemon is started, after that it is ignored. If the cryptic-net binary has a bootstrap built into it then this argument is always optional.`,
|
||||
`Path to a bootstrap.yml file. This only needs to be provided the first time the daemon is started, after that it is ignored. If the isle binary has a bootstrap built into it then this argument is always optional.`,
|
||||
)
|
||||
|
||||
logLevelStr := flags.StringP(
|
||||
|
||||
@ -2,9 +2,9 @@ package main
|
||||
|
||||
import (
|
||||
"context"
|
||||
"cryptic-net/bootstrap"
|
||||
"cryptic-net/daemon"
|
||||
"cryptic-net/garage"
|
||||
"isle/bootstrap"
|
||||
"isle/daemon"
|
||||
"isle/garage"
|
||||
"fmt"
|
||||
"time"
|
||||
)
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
package main
|
||||
|
||||
import (
|
||||
"cryptic-net/bootstrap"
|
||||
"cryptic-net/daemon"
|
||||
"cryptic-net/dnsmasq"
|
||||
"isle/bootstrap"
|
||||
"isle/daemon"
|
||||
"isle/dnsmasq"
|
||||
"fmt"
|
||||
"path/filepath"
|
||||
"sort"
|
||||
|
||||
@ -9,7 +9,7 @@ import (
|
||||
|
||||
var subCmdGarageMC = subCmd{
|
||||
name: "mc",
|
||||
descr: "Runs the mc (minio-client) binary. The cryptic-net garage can be accessed under the `garage` alias",
|
||||
descr: "Runs the mc (minio-client) binary. The isle garage can be accessed under the `garage` alias",
|
||||
checkLock: true,
|
||||
do: func(subCmdCtx subCmdCtx) error {
|
||||
|
||||
@ -82,7 +82,7 @@ var subCmdGarageMC = subCmd{
|
||||
|
||||
var subCmdGarageCLI = subCmd{
|
||||
name: "cli",
|
||||
descr: "Runs the garage binary, automatically configured to point to the garage sub-process of a running cryptic-net daemon",
|
||||
descr: "Runs the garage binary, automatically configured to point to the garage sub-process of a running isle daemon",
|
||||
checkLock: true,
|
||||
do: func(subCmdCtx subCmdCtx) error {
|
||||
|
||||
@ -114,7 +114,7 @@ var subCmdGarageCLI = subCmd{
|
||||
|
||||
var subCmdGarage = subCmd{
|
||||
name: "garage",
|
||||
descr: "Runs the garage binary, automatically configured to point to the garage sub-process of a running cryptic-net daemon",
|
||||
descr: "Runs the garage binary, automatically configured to point to the garage sub-process of a running isle daemon",
|
||||
do: func(subCmdCtx subCmdCtx) error {
|
||||
return subCmdCtx.doSubCmd(
|
||||
subCmdGarageCLI,
|
||||
|
||||
@ -2,9 +2,9 @@ package main
|
||||
|
||||
import (
|
||||
"context"
|
||||
"cryptic-net/bootstrap"
|
||||
"cryptic-net/daemon"
|
||||
"cryptic-net/garage"
|
||||
"isle/bootstrap"
|
||||
"isle/daemon"
|
||||
"isle/garage"
|
||||
"fmt"
|
||||
"net"
|
||||
"path/filepath"
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
package main
|
||||
|
||||
import (
|
||||
"cryptic-net/bootstrap"
|
||||
"isle/bootstrap"
|
||||
"errors"
|
||||
"fmt"
|
||||
"os"
|
||||
|
||||
@ -12,7 +12,7 @@ import (
|
||||
"github.com/mediocregopher/mediocre-go-lib/v2/mlog"
|
||||
)
|
||||
|
||||
// The purpose of this binary is to act as the entrypoint of the cryptic-net
|
||||
// The purpose of this binary is to act as the entrypoint of the isle
|
||||
// process. It processes the command-line arguments which are passed in, and
|
||||
// then passes execution along to an appropriate binary housed in AppDir/bin
|
||||
// (usually a bash script, which is more versatile than a go program).
|
||||
|
||||
@ -2,10 +2,10 @@ package main
|
||||
|
||||
import (
|
||||
"context"
|
||||
"cryptic-net/bootstrap"
|
||||
"cryptic-net/daemon"
|
||||
"cryptic-net/yamlutil"
|
||||
"fmt"
|
||||
"isle/bootstrap"
|
||||
"isle/daemon"
|
||||
"isle/yamlutil"
|
||||
"net"
|
||||
"path/filepath"
|
||||
|
||||
@ -68,7 +68,7 @@ func nebulaPmuxProcConfig(
|
||||
"respond": true,
|
||||
},
|
||||
"tun": map[string]interface{}{
|
||||
"dev": "cryptic-net-nebula",
|
||||
"dev": "isle-tun",
|
||||
},
|
||||
"firewall": daemonConfig.VPN.Firewall,
|
||||
}
|
||||
|
||||
@ -13,7 +13,7 @@ import (
|
||||
"github.com/shirou/gopsutil/process"
|
||||
)
|
||||
|
||||
var errDaemonNotRunning = errors.New("no cryptic-net daemon process running")
|
||||
var errDaemonNotRunning = errors.New("no isle daemon process running")
|
||||
|
||||
func lockFilePath() string {
|
||||
return filepath.Join(envRuntimeDirPath, "lock")
|
||||
@ -29,7 +29,7 @@ func writeLock() error {
|
||||
|
||||
if errors.Is(err, os.ErrExist) {
|
||||
return fmt.Errorf(
|
||||
"lock file %q already exists, if the cryptic-net daemon is not already running you can safely delete this file",
|
||||
"lock file %q already exists, if the isle daemon is not already running you can safely delete this file",
|
||||
lockFilePath,
|
||||
)
|
||||
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
// Package daemon contains types and functions related specifically to the
|
||||
// cryptic-net daemon.
|
||||
// isle daemon.
|
||||
package daemon
|
||||
|
||||
import (
|
||||
"cryptic-net/yamlutil"
|
||||
"fmt"
|
||||
"io"
|
||||
"isle/yamlutil"
|
||||
"os"
|
||||
"path/filepath"
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
module cryptic-net
|
||||
module isle
|
||||
|
||||
go 1.17
|
||||
|
||||
|
||||
@ -159,7 +159,7 @@ func NewCACredentials(domain string, subnet *net.IPNet) (CACredentials, error) {
|
||||
|
||||
caCert := cert.NebulaCertificate{
|
||||
Details: cert.NebulaCertificateDetails{
|
||||
Name: fmt.Sprintf("%s cryptic-net root cert", domain),
|
||||
Name: fmt.Sprintf("%s isle root cert", domain),
|
||||
Subnets: []*net.IPNet{subnet},
|
||||
NotBefore: now,
|
||||
NotAfter: expireAt,
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
{
|
||||
description = "cryptic-net provides the foundation for an autonomous community cloud infrastructure";
|
||||
description = "isle provides the foundation for an autonomous community cloud infrastructure";
|
||||
|
||||
outputs = {
|
||||
self,
|
||||
|
||||
@ -16,14 +16,14 @@
|
||||
}).appImage;
|
||||
|
||||
in pkgs.stdenv.mkDerivation {
|
||||
name = "cryptic-net-release-${hostSystem}";
|
||||
name = "isle-release-${hostSystem}";
|
||||
inherit releaseName appImage hostSystem;
|
||||
|
||||
builder = builtins.toFile "build.sh" ''
|
||||
source $stdenv/setup
|
||||
|
||||
mkdir -p "$out"/
|
||||
cp "$appImage"/bin/cryptic-net "$out"/cryptic-net-$releaseName-$hostSystem
|
||||
cp "$appImage"/bin/isle "$out"/isle-$releaseName-$hostSystem
|
||||
'';
|
||||
};
|
||||
|
||||
@ -32,7 +32,7 @@
|
||||
in
|
||||
|
||||
pkgs.stdenv.mkDerivation {
|
||||
name = "cryptic-net-release-${releaseName}";
|
||||
name = "isle-release-${releaseName}";
|
||||
inherit releases;
|
||||
|
||||
nativeBuildInputs = [ pkgs.coreutils ];
|
||||
@ -42,7 +42,7 @@ in
|
||||
|
||||
mkdir -p "$out"
|
||||
for p in $releases; do
|
||||
cp "$p"/cryptic-net-* "$out"/
|
||||
cp "$p"/isle-* "$out"/
|
||||
done
|
||||
|
||||
(cd "$out" && sha256sum * > sha256.txt)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user