s
This commit is contained in:
parent
6e1f478ce5
commit
da14091106
@ -3,23 +3,23 @@
|
||||
|
||||
|
||||
|
||||
We are more than just Container or VM technology, see [our Beyond Container Document](beyond_containers).
|
||||
We are more than just Container or VM technology, see [our Beyond Container Document](beyond_containers.md).
|
||||
|
||||
A 3Node is a Zero-OS enabled computer which is hosted with any of the TF_Farmers.
|
||||
|
||||
There are 4 storage mechanisms which can be used to store your data:
|
||||
|
||||
- ZOS_FS is our dedupe unique filesystem, replaces docker images.
|
||||
- ZOS_Mount is a mounted disk location on SSD, this can be used as faster storage location.
|
||||
- QSFS, this is a super unique storage system, data can never be lost or corrupted. Please be reminded that this storage layer is only meant to be used for secondary storage applications.
|
||||
- ZOS_Disk, a virtual disk technology, only for TFTech OEM partners.
|
||||
- Zero-Image is our dedupe unique filesystem, replaces docker images.
|
||||
- Zero-Mount is a mounted disk location on SSD, this can be used as faster storage location.
|
||||
- Quantum Safe Storage System, this is a super unique storage system, data can never be lost or corrupted. Please be reminded that this storage layer is only meant to be used for secondary storage applications.
|
||||
- Zero-Disk, a virtual disk technology, only for TFTech OEM partners.
|
||||
|
||||
There are 4 ways how networks can be connected to a Z-Machine.
|
||||
|
||||
- Planetary_network : is a planetary scalable network, we have clients for windows, osx, android and iphone.
|
||||
- zos_net : is a fast end2end encrypted network technology, keep your traffic between your z_machines 100% private.
|
||||
- zos_bridge: connection to a public ipaddress
|
||||
- web_gw: web gateway, a secure way to allow internet traffic reach your secure Z-Machine.
|
||||
- Mycelium : is a planetary scalable network, we have clients for windows, osx, android and iphone.
|
||||
- Zero-Net : is a fast end2end encrypted network technology, keep your traffic between your z_machines 100% private.
|
||||
- Zero-Bridge: connection to a public ipaddress
|
||||
- Web-Gateway: web gateway, a secure way to allow internet traffic reach your secure Z-Machine.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1 +0,0 @@
|
||||
# Zero-OS Install
|
||||
@ -1,17 +1,24 @@
|
||||
- [Overview](tech/overview.md)
|
||||
- [The Internet Today](tech/internet_today.md)
|
||||
- [Status Today](tech/statustoday.md)
|
||||
- [The Cloud Today](tech/cloud_today.md)
|
||||
- [The Internet Today](tech/internet_today.md)
|
||||
- [History of Computers](tech/history/c64.md)
|
||||
- [Too Many Layers](tech/history/layers.md)
|
||||
- [The Internet Re-invented](tech/how_does_it_work.md)
|
||||
- [Cloud Re-invented](tech/how_does_it_work.md)
|
||||
- [World Records](tech/world_records.md)
|
||||
- [Architecture](tech/architecture.md)
|
||||
- [Key Innovations](tech/key_innovations_overview.md)
|
||||
- [Compute](tech/compute_inno.md)
|
||||
- [Zero-OS](tech/zos_innovation.md)
|
||||
- [Zero-Images](tech/flist_innovation.md)
|
||||
- [Zero-Images](tech/zero_image_inno.md)
|
||||
- [Deterministic Deploy](tech/zero_deploy_inno.md)
|
||||
- [Zero-Install](tech/zero_install_inno.md)
|
||||
- [Network](tech/network_inno.md)
|
||||
- [Mycelium](tech/mycelium_innovation.md)
|
||||
- [Mycelium](tech/mycelium_inno.md)
|
||||
- [Shortest Path Routing](tech/mycelium_shortest_path_routing_inno.md)
|
||||
- [Whitelists](tech/mycelium_whiltelist.md)
|
||||
- [Network Wall](tech/network_wall_innovation.md)
|
||||
- [Virtual Browser](tech/virtual_browser.md)
|
||||
- [Storage](tech/storage_inno.md)
|
||||
- [Quantum Safe Storage](tech/zstor_innovation.md)
|
||||
- [Quantum Safe Filesystem](tech/qsfs_innovation.md)
|
||||
@ -19,17 +26,17 @@
|
||||
- [Energy Efficient](tech/energy_efficient.md)
|
||||
- [Status/Roadmap](tech/tfgrid_roadmap.md)
|
||||
- [Hero Roadmap](tech/hero_roadmap.md)
|
||||
- [ThreeFold Core Components](tech/features.md)
|
||||
- [ThreeFold Core Features](tech/features.md)
|
||||
- [Compute](tech/compute.md)
|
||||
- [Zero-OS](tech/zero_os.md)
|
||||
- [Zero-Chance](tech/zero_chance.md)
|
||||
- [Zero-Deploy](tech/zero_deploy.md)
|
||||
- [Zero-Install](tech/zero_install.md)
|
||||
- [Zero-Boot](tech/zero_boot.md)
|
||||
- [Zero-Kube](tech/zkube.md)
|
||||
- [Storage](tech/qsss_home.md)
|
||||
- [Quantum Safe Storage Algo](tech/qss_algorithm.md)
|
||||
- [Zero Knowledge proof](tech/qss_zero_knowledge_proof.md)
|
||||
- [NFT Storage](tech/nft_storage.md)
|
||||
- [S3 Storage](tech/s3_interface)
|
||||
- [S3 Storage](tech/s3_interface)
|
||||
- [File System](tech/qss_filesystem.md)
|
||||
- [Network](tech/networking.md)
|
||||
- [Mycelium](tech/mycelium.md)
|
||||
@ -43,7 +50,6 @@
|
||||
- [TZG](partners_utilization/tanzania.md)
|
||||
- [Tier-S DC](partners_utilization/tier_s_datacenter.md)
|
||||
- [OW Freezone](partners_utilization/freezone.md)
|
||||
- [Earth Wallet](partners_utilization/earth_wallet.md)
|
||||
- [Helium](partners_utilization/helium.md)
|
||||
|
||||
<!-- - [Elestio](partners_utilization/elestio.md) -->
|
||||
|
||||
@ -34,11 +34,11 @@
|
||||
- [Mycelium](tech/mycelium.md)
|
||||
- [Web Gateway](tech/webgw.md)
|
||||
- [Key Innovations](tech/key_innovations_overview.md)
|
||||
- [Mycelium Network](tech/mycelium_innovation.md)
|
||||
- [Mycelium Network](tech/mycelium_inno.md)
|
||||
- [Zero-OS](tech/zos_innovation.md)
|
||||
- [Quantum Safe Storage](tech/zstor_innovation.md)
|
||||
- [Quantum Safe Filesystem](tech/qsfs_innovation.md)
|
||||
- [FList: better OS Images](tech/flist_innovation.md)
|
||||
- [FList: better OS Images](tech/zero_image.md)
|
||||
- [FungiStor](tech/fungistor_innovation.md)
|
||||
- [Network Wall](tech/network_wall_innovation.md)
|
||||
- [Architecture](tech/architecture.md)
|
||||
|
||||
@ -138,7 +138,7 @@ Following list is incomplete but gives some issues to think about.
|
||||
|
||||
|
||||
## ZOS
|
||||
- zmachine support
|
||||
- zero_vm support
|
||||
- Integration with latest subtsrate client event types
|
||||
- public ipv6 support in VMs
|
||||
- planetary support in VMs
|
||||
@ -154,7 +154,7 @@ Following list is incomplete but gives some issues to think about.
|
||||
https://github.com/threefoldtech/zos/releases
|
||||
|
||||
## Terraform
|
||||
- Support ZMachine
|
||||
- Support Zero VM
|
||||
- Support Kubernetes
|
||||
- Support QSFS
|
||||
- Support Capacity Planning
|
||||
@ -164,7 +164,7 @@ https://github.com/threefoldtech/tf-terraform-provider/releases
|
||||
|
||||
|
||||
## grid3_client_ts
|
||||
- Support ZMachine
|
||||
- Support Zero VM
|
||||
- Support Kubernetes
|
||||
- Support QSFS
|
||||
- Support Capacity Planning
|
||||
|
||||
@ -26,9 +26,9 @@ If node was restarted, `provisiond` tries to bring all active workloads back to
|
||||
|
||||
0-OS currently support 8 type of workloads:
|
||||
- network
|
||||
- `zmachine` (virtual machine)
|
||||
- `zmount` (disk): usable only by a `zmachine`
|
||||
- `public-ip` (v4 and/or v6): usable only by a `zmachine`
|
||||
- `zero_vm` (virtual machine)
|
||||
- `zmount` (disk): usable only by a `zero_vm`
|
||||
- `public-ip` (v4 and/or v6): usable only by a `zero_vm`
|
||||
- [`zdb`](https://github.com/threefoldtech/0-DB) `namespace`
|
||||
- [`qsfs`](https://github.com/threefoldtech/quantum-storage)
|
||||
- `zlogs`
|
||||
|
||||
@ -77,7 +77,7 @@ test: mountpoint /var/cache
|
||||
// this should allow you to work with the following types of storage medium
|
||||
// - full disks (device) (these are used by zdb)
|
||||
// - subvolumes these are used as a read-write layers for 0-fs mounts
|
||||
// - vdisks are used by zmachines
|
||||
// - vdisks are used by zero_vms
|
||||
// this works as following:
|
||||
// a storage module maintains a list of ALL disks on the system
|
||||
// separated in 2 sets of pools (SSDs, and HDDs)
|
||||
|
||||
@ -79,7 +79,7 @@ dl := gridtypes.Deployment{
|
||||
network(), // network workload definition
|
||||
zmount(), // zmount workload definition
|
||||
publicip(), // public ip definition
|
||||
zmachine(), // zmachine definition
|
||||
zero_vm(), // zero_vm definition
|
||||
},
|
||||
SignatureRequirement: gridtypes.SignatureRequirement{
|
||||
WeightRequired: 1,
|
||||
@ -168,7 +168,7 @@ type Workload struct {
|
||||
- [`network`](./workload_types.md#network-type)
|
||||
- [`ip`](./workload_types.md#ip-type)
|
||||
- [`zmount`](./workload_types.md#zmount-type)
|
||||
- [`zmachine`](./workload_types.md#zmachine-type)
|
||||
- [`zero_vm`](./workload_types.md#zero_vm-type)
|
||||
- [`zlogs`](./workload_types.md#zlogs-type)
|
||||
- Storage related
|
||||
- [`zdb`](./workload_types.md#zdb-type)
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
- [`network` type](#network-type)
|
||||
- [`ip` type](#ip-type)
|
||||
- [`zmount` type](#zmount-type)
|
||||
- [`zmachine` type](#zmachine-type)
|
||||
- [`zero_vm` type](#zero_vm-type)
|
||||
- [Building your `flist`](#building-your-flist)
|
||||
- [`zlogs` type](#zlogs-type)
|
||||
- [Storage](#storage)
|
||||
@ -51,30 +51,30 @@ In minimal form, `IP` workload does not require any data. But in reality it has
|
||||
Full `IP` workload definition can be found [here](https://github.com/threefoldtech/zos/blob/main/pkg/gridtypes/zos/ipv4.go)
|
||||
|
||||
### `zmount` type
|
||||
A `zmount` is a local disk that can be attached directly to a container or a virtual machine. `zmount` only require `size` as input as defined [here](https://github.com/threefoldtech/zos/blob/main/pkg/gridtypes/zos/zmount.go) this workload type is only utilized via the `zmachine` workload.
|
||||
A `zmount` is a local disk that can be attached directly to a container or a virtual machine. `zmount` only require `size` as input as defined [here](https://github.com/threefoldtech/zos/blob/main/pkg/gridtypes/zos/zmount.go) this workload type is only utilized via the `zero_vm` workload.
|
||||
|
||||
### `zmachine` type
|
||||
### `zero_vm` type
|
||||
|
||||
`zmachine` is a unified container/virtual machine type. This can be used to start a virtual machine on a `zos` node give the following:
|
||||
`zero_vm` is a unified container/virtual machine type. This can be used to start a virtual machine on a `zos` node give the following:
|
||||
- `flist`, this what provide the base `vm` image or container image.
|
||||
- the `flist` content is what changes the `zmachine` mode. An `flist` built from a docker image or has files, or executable binaries will run in a container mode. `ZOS` will inject it's own `kernel+initramfs` to run the workload and kick start the defined `flist` `entrypoint`
|
||||
- the `flist` content is what changes the `zero_vm` mode. An `flist` built from a docker image or has files, or executable binaries will run in a container mode. `ZOS` will inject it's own `kernel+initramfs` to run the workload and kick start the defined `flist` `entrypoint`
|
||||
- private network to join (with assigned IP)
|
||||
- optional public `ipv4` or `ipv6`
|
||||
- optional disks. But at least one disk is required in case running `zmachine` in `vm` mode, which is used to hold the `vm` root image.
|
||||
- optional disks. But at least one disk is required in case running `zero_vm` in `vm` mode, which is used to hold the `vm` root image.
|
||||
|
||||
For more details on all parameters needed to run a `zmachine` please refer to [`zmachine` data](https://github.com/threefoldtech/zos/blob/main/pkg/gridtypes/zos/zmachine.go)
|
||||
For more details on all parameters needed to run a `zero_vm` please refer to [`zero_vm` data](https://github.com/threefoldtech/zos/blob/main/pkg/gridtypes/zos/zero_vm.go)
|
||||
|
||||
#### Building your `flist`
|
||||
|
||||
Please refer to [this document](manual.md) here about how to build an compatible `zmachine flist`
|
||||
Please refer to [this document](manual.md) here about how to build an compatible `zero_vm flist`
|
||||
|
||||
### `zlogs` type
|
||||
|
||||
Zlogs is a utility workload that allows you to stream `zmachine` logs to a remote location.
|
||||
Zlogs is a utility workload that allows you to stream `zero_vm` logs to a remote location.
|
||||
|
||||
The `zlogs` workload needs to know what `zmachine` to stream logs of and also the `target` location to stream the logs to. `zlogs` uses internally the [`tailstream`](https://github.com/threefoldtech/tailstream) so it supports any streaming url that is supported by this utility.
|
||||
The `zlogs` workload needs to know what `zero_vm` to stream logs of and also the `target` location to stream the logs to. `zlogs` uses internally the [`tailstream`](https://github.com/threefoldtech/tailstream) so it supports any streaming url that is supported by this utility.
|
||||
|
||||
`zlogs` workload runs inside the same private network as the `zmachine` instance. Which means zlogs can stream logs to other `zmachines` that is running inside the same private network (possibly on different nodes).
|
||||
`zlogs` workload runs inside the same private network as the `zero_vm` instance. Which means zlogs can stream logs to other `zero_vms` that is running inside the same private network (possibly on different nodes).
|
||||
|
||||
For example, you can run [`logagg`](https://github.com/threefoldtech/logagg) which is a web-socket server that can work with `tailstream` web-socket protocol.
|
||||
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
# `zlogs` type
|
||||
|
||||
Zlogs is a utility workload that allows you to stream `zmachine` logs to a remote location.
|
||||
Zlogs is a utility workload that allows you to stream `zero_vm` logs to a remote location.
|
||||
|
||||
The `zlogs` workload needs to know what `zmachine` to stream logs of and also the `target` location to stream the logs to. `zlogs` uses internally the [`tailstream`](https://github.com/threefoldtech/tailstream) so it supports any streaming url that is supported by this utility.
|
||||
The `zlogs` workload needs to know what `zero_vm` to stream logs of and also the `target` location to stream the logs to. `zlogs` uses internally the [`tailstream`](https://github.com/threefoldtech/tailstream) so it supports any streaming url that is supported by this utility.
|
||||
|
||||
`zlogs` workload runs inside the same private network as the `zmachine` instance. Which means zlogs can stream logs to other `zmachines` that is running inside the same private network (possibly on different nodes).
|
||||
`zlogs` workload runs inside the same private network as the `zero_vm` instance. Which means zlogs can stream logs to other `zero_vms` that is running inside the same private network (possibly on different nodes).
|
||||
|
||||
For example, you can run [`logagg`](https://github.com/threefoldtech/logagg) which is a web-socket server that can work with `tailstream` web-socket protocol.
|
||||
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
# `zmachine` type
|
||||
# `zero_vm` type
|
||||
|
||||
`zmachine` is a unified container/virtual machine type. This can be used to start a virtual machine on a `zos` node give the following:
|
||||
`zero_vm` is a unified container/virtual machine type. This can be used to start a virtual machine on a `zos` node give the following:
|
||||
- `flist`, this what provide the base `vm` image or container image.
|
||||
- the `flist` content is what changes the `zmachine` mode. An `flist` built from a docker image or has files, or executable binaries will run in a container mode. `ZOS` will inject it's own `kernel+initramfs` to run the workload and kick start the defined `flist` `entrypoint`
|
||||
- the `flist` content is what changes the `zero_vm` mode. An `flist` built from a docker image or has files, or executable binaries will run in a container mode. `ZOS` will inject it's own `kernel+initramfs` to run the workload and kick start the defined `flist` `entrypoint`
|
||||
- private network to join (with assigned IP)
|
||||
- optional public `ipv4` or `ipv6`
|
||||
- optional disks. But at least one disk is required in case running `zmachine` in `vm` mode, which is used to hold the `vm` root image.
|
||||
- optional disks. But at least one disk is required in case running `zero_vm` in `vm` mode, which is used to hold the `vm` root image.
|
||||
|
||||
For more details on all parameters needed to run a `zmachine` please refer to [`zmachine` data](https://github.com/threefoldtech/zos/blob/main/pkg/gridtypes/zos/zmachine.go)
|
||||
For more details on all parameters needed to run a `zero_vm` please refer to [`zero_vm` data](https://github.com/threefoldtech/zos/blob/main/pkg/gridtypes/zos/zero_vm.go)
|
||||
|
||||
# Building your `flist`.
|
||||
Please refer to [this document](manual.md) here about how to build an compatible `zmachine flist`
|
||||
Please refer to [this document](manual.md) here about how to build an compatible `zero_vm flist`
|
||||
|
||||
@ -1,2 +1,2 @@
|
||||
# `zmount` type
|
||||
A `zmount` is a local disk that can be attached directly to a container or a virtual machine. `zmount` only require `size` as input as defined [here](https://github.com/threefoldtech/zos/blob/main/pkg/gridtypes/zos/zmount.go) this workload type is only utilized via the `zmachine` workload.
|
||||
A `zmount` is a local disk that can be attached directly to a container or a virtual machine. `zmount` only require `size` as input as defined [here](https://github.com/threefoldtech/zos/blob/main/pkg/gridtypes/zos/zmount.go) this workload type is only utilized via the `zero_vm` workload.
|
||||
|
||||
@ -136,7 +136,7 @@ vm.env = {
|
||||
};
|
||||
```
|
||||
|
||||
Now we go to the VM model, that will be used to build our `zmachine` object
|
||||
Now we go to the VM model, that will be used to build our `zero_vm` object
|
||||
|
||||
We need to specify its
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ As a user, you have two options
|
||||
|
||||
## Compute
|
||||
|
||||
VM workload is the only workload that you will need to run a full blown VM or an [flist-based](flist_hub.md) container
|
||||
VM workload is the only workload that you will need to run a full blown VM or an [flist-based](zero_hub.md) container
|
||||
|
||||
### How can I create an flist?
|
||||
|
||||
|
||||
@ -230,10 +230,10 @@ resource "grid_deployment" "d2" {
|
||||
output "wg_config" {
|
||||
value = grid_network.net1.access_wg_config
|
||||
}
|
||||
output "node1_zmachine1_ip" {
|
||||
output "node1_zero_vm1_ip" {
|
||||
value = grid_deployment.d1.vms[0].ip
|
||||
}
|
||||
output "node1_zmachine2_ip" {
|
||||
output "node1_zero_vm2_ip" {
|
||||
value = grid_deployment.d2.vms[0].ip
|
||||
}
|
||||
|
||||
|
||||
@ -70,10 +70,10 @@ resource "grid_deployment" "d1" {
|
||||
output "wg_config" {
|
||||
value = grid_network.net1.access_wg_config
|
||||
}
|
||||
output "node1_zmachine1_ip" {
|
||||
output "node1_zero_vm1_ip" {
|
||||
value = grid_deployment.d1.vms[0].ip
|
||||
}
|
||||
output "node1_zmachine2_ip" {
|
||||
output "node1_zero_vm2_ip" {
|
||||
value = grid_deployment.d1.vms[1].ip
|
||||
}
|
||||
output "public_ip" {
|
||||
|
||||
@ -254,10 +254,10 @@ resource "grid_deployment" "d2" {
|
||||
output "wg_config" {
|
||||
value = grid_network.net1.access_wg_config
|
||||
}
|
||||
output "node1_zmachine1_ip" {
|
||||
output "node1_zero_vm1_ip" {
|
||||
value = grid_deployment.d1.vms[0].ip
|
||||
}
|
||||
output "node1_zmachine2_ip" {
|
||||
output "node1_zero_vm2_ip" {
|
||||
value = grid_deployment.d2.vms[0].ip
|
||||
}
|
||||
|
||||
@ -801,10 +801,10 @@ To avoid errors, set HTTPS with the master VM and power off the worker VM.
|
||||
```
|
||||
* Put `#` in front of the appropriated lines, as shown below:
|
||||
```
|
||||
output "node1_zmachine1_ip" {
|
||||
output "node1_zero_vm1_ip" {
|
||||
value = grid_deployment.d1.vms[0].ip
|
||||
}
|
||||
#output "node1_zmachine2_ip" {
|
||||
#output "node1_zero_vm2_ip" {
|
||||
# value = grid_deployment.d2.vms[0].ip
|
||||
#}
|
||||
|
||||
|
||||
@ -209,7 +209,7 @@ resource "grid_deployment" "d1" {
|
||||
output "wg_config" {
|
||||
value = grid_network.net1.access_wg_config
|
||||
}
|
||||
output "node1_zmachine1_ip" {
|
||||
output "node1_zero_vm1_ip" {
|
||||
value = grid_deployment.d1.vms[0].ip
|
||||
}
|
||||
|
||||
|
||||
@ -165,7 +165,7 @@ resource "grid_deployment" "d1" {
|
||||
output "wg_config" {
|
||||
value = grid_network.net1.access_wg_config
|
||||
}
|
||||
output "node1_zmachine1_ip" {
|
||||
output "node1_zero_vm1_ip" {
|
||||
value = grid_deployment.d1.vms[0].ip
|
||||
}
|
||||
|
||||
@ -244,7 +244,7 @@ As a test, you can [ping](../../computer_it_basics/cli_scripts_basics.md#test-th
|
||||
* ```
|
||||
ping vm_wg_ip
|
||||
```
|
||||
* Note that, with this Terraform deployment, the Wireguard IP address of the micro VM is named `node1_zmachine1_ip`
|
||||
* Note that, with this Terraform deployment, the Wireguard IP address of the micro VM is named `node1_zero_vm1_ip`
|
||||
|
||||
|
||||
## SSH into the 3Node with Wireguard
|
||||
|
||||
@ -202,10 +202,10 @@ resource "grid_deployment" "d2" {
|
||||
output "wg_config" {
|
||||
value = grid_network.net1.access_wg_config
|
||||
}
|
||||
output "node1_zmachine1_ip" {
|
||||
output "node1_zero_vm1_ip" {
|
||||
value = grid_deployment.d1.vms[0].ip
|
||||
}
|
||||
output "node1_zmachine2_ip" {
|
||||
output "node1_zero_vm2_ip" {
|
||||
value = grid_deployment.d2.vms[0].ip
|
||||
}
|
||||
|
||||
|
||||
@ -266,10 +266,10 @@ resource "grid_deployment" "d1" {
|
||||
output "wg_config" {
|
||||
value = grid_network.net1.access_wg_config
|
||||
}
|
||||
output "node1_zmachine1_ip" {
|
||||
output "node1_zero_vm1_ip" {
|
||||
value = grid_deployment.d1.vms[0].ip
|
||||
}
|
||||
output "node1_zmachine2_ip" {
|
||||
output "node1_zero_vm2_ip" {
|
||||
value = grid_deployment.d1.vms[1].ip
|
||||
}
|
||||
output "public_ip" {
|
||||
|
||||
@ -70,7 +70,7 @@ resource "grid_name_proxy" "p1" {
|
||||
output "fqdn" {
|
||||
value = data.grid_gateway_domain.domain.fqdn
|
||||
}
|
||||
output "node1_zmachine1_ip" {
|
||||
output "node1_zero_vm1_ip" {
|
||||
value = grid_deployment.d1.vms[0].ip
|
||||
}
|
||||
output "public_ip" {
|
||||
|
||||
@ -192,7 +192,7 @@ resource "grid_deployment" "d1" {
|
||||
output "wg_config" {
|
||||
value = grid_network.net1.access_wg_config
|
||||
}
|
||||
output "node1_zmachine1_ip" {
|
||||
output "node1_zero_vm1_ip" {
|
||||
value = grid_deployment.d1.vms[0].ip
|
||||
}
|
||||
|
||||
|
||||
@ -1 +1,18 @@
|
||||
# Concepts
|
||||
|
||||
|
||||
## Compute
|
||||
|
||||
- [Zero VM](zero_vm.md) : full virtual machine with own kernel
|
||||
- [Zero VM Light](zero_vm_light.md) : virtual machine which uses the kernel of the host operating system.
|
||||
- [Zero Install](zero_install.md) : no need to install OS files on local storage system e.g. SSD
|
||||
|
||||
|
||||
## Storage
|
||||
|
||||
- [Zero Image](zero_image.md) : image which is actually a deduped, cached, stateless filesystem can be used by [Zero VM](zero_vm.md)
|
||||
|
||||
|
||||
## Network
|
||||
|
||||
- [Mycelium Whitelist](mycelium_whiltelist.md)
|
||||
@ -1,12 +0,0 @@
|
||||
Compute
|
||||
- [Zero-OS: a minimalistic and more efficient server operating system](zos_innovation)
|
||||
- [Zero-Image: a new way to deal with OS Images](flist_innovation.md)
|
||||
|
||||
Network
|
||||
- [Mycelium: a new network layer for the Internet](mycelium_innovation.md)
|
||||
- [Network Wall: a secure way to connect your apps to Internet](network_wall_innovation.md)
|
||||
|
||||
Storage
|
||||
- [Quantum Safe Storage: storage which cannot get lost nor corrupted](zstor_innovation.md)
|
||||
- [Quantum Safe Filesystem: host any storage interface e.g. IPFS](qsfs_innovation.md)
|
||||
- [FungiStor: Content Delivery everwhere in the world](fungistor_innovation.md)
|
||||
@ -1,5 +0,0 @@
|
||||
|
||||
## Zero-Images: A New Way Of Dealing With OS Images
|
||||
|
||||
!!wiki.include page:flist_innovation_short
|
||||
|
||||
4
collections/tech/innovations/compute/zero_deploy_inno.md
Normal file
4
collections/tech/innovations/compute/zero_deploy_inno.md
Normal file
@ -0,0 +1,4 @@
|
||||
|
||||
|
||||
|
||||
!!wiki.include page:'zero_deploy.md'
|
||||
@ -1,11 +1,20 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### The Problem
|
||||
|
||||
The current method of deploying workloads in the cloud using Docker containers and virtual machine images has inherent issues. These images consume significant storage space, result in slow and bandwidth-intensive transfers to the internet's edge, drive up costs, introduce complexity, and pose security risks due to difficulties in tracking their contents over time.
|
||||
|
||||
For instance, a complete Ubuntu image can easily be 2 GB in size, comprising millions of files. In contrast, the Flist for a full Ubuntu image is less than 2 MB (1000 times smaller), containing only the necessary files required to launch an application.
|
||||
For instance, a complete Ubuntu image can easily be 2 GB in size, comprising millions of files. In contrast, the Flist (metadata for Zero-Image) for a full Ubuntu image is less than 2 MB (1000 times smaller). Based on this flist only the required files will be dowbloaded which can easily be 10x less compared to the original image size. These downloaded files (or subparts of files) are identified by a fingerprint (hash) and will only boot once authenticity can be verified.
|
||||
|
||||
|
||||
### Process
|
||||
|
||||
- Zero-OS or the Zero-Image Command Line (works on linux) gets informed to provision a virtual filesystem based on a Zero-Image URL.
|
||||
- The Zero-Image Metadata is stored on e.g. an S3 Server or our [Zero-Hub](zero_hub.md)
|
||||
|
||||
|
||||
### Introducing Flist
|
||||
|
||||
@ -0,0 +1 @@
|
||||
!!wiki.include page:zero_install.md
|
||||
@ -4,4 +4,4 @@ Zero-OS is our innovative operating system built from the Linux kernel.
|
||||
|
||||
|
||||
|
||||
!!wiki.include page:zos_innovation_short
|
||||
!!wiki.include page:zos_inno0
|
||||
@ -1,7 +1,11 @@
|
||||
|
||||
### The Problem
|
||||
|
||||
It is challenging to use current Linux-based operating systems safely and efficiently on the edges of the Internet. They require central management, involve excessive complexity, and prove difficult to update and maintain, resulting in numerous security vulnerabilities. To revolutionize the internet, we must rethink how we host our applications, essentially reinventing the concept of a cloud-based operating system.
|
||||
It is challenging to use current Linux-based operating systems safely and efficiently on the edges of the Internet.
|
||||
|
||||
They require central management, involve excessive complexity, and prove difficult to update and maintain, resulting in numerous security vulnerabilities.
|
||||
|
||||
To revolutionize cloud and the internet, we must rethink how we host our applications, essentially reinventing the concept of a cloud-based operating system.
|
||||
|
||||
### Introducing Zero-OS
|
||||
|
||||
@ -4,15 +4,15 @@
|
||||
|
||||
## Mycelium: a new network layer for the internet
|
||||
|
||||
!!wiki.include page:mycelium_innovation_short.md
|
||||
!!wiki.include page:mycellium_short_ino.md
|
||||
|
||||
## Zero-OS: a minimalistic more efficient server operating system
|
||||
|
||||
!!wiki.include page:zos_innovation_short
|
||||
!!wiki.include page:zos_inno
|
||||
|
||||
## FList: a new way how to deal with OS Images
|
||||
|
||||
!!wiki.include page:flist_innovation_short
|
||||
!!wiki.include page:zero_image_inno
|
||||
|
||||
|
||||
## Zero-Stor : a quantum safe backend storage system.
|
||||
|
||||
24
collections/tech/innovations/key_innovations_list.md
Normal file
24
collections/tech/innovations/key_innovations_list.md
Normal file
@ -0,0 +1,24 @@
|
||||
|
||||
[Compute](compute_inno.md)
|
||||
|
||||
- [Zero-OS: a minimalistic and more efficient server operating system](zos_innovation)
|
||||
- [Zero-Image: a new way to deal with OS Images](zero_image.md)
|
||||
- [Deterministic Deploy: a predictable way how to install.](tech/zero_deploy_inno.md)
|
||||
- [Zero-Install: easier maintainable to install base layer](tech/zero_install_inno.md)
|
||||
|
||||
[Network](network_inno.md)
|
||||
|
||||
- [Mycelium: a new network layer for the Internet](mycelium_inno.md)
|
||||
- [Network Wall: a secure way to connect your apps to Internet](network_wall_innovation.md)
|
||||
- [Shortest Path Routing](tech/mycelium_shortest_path_routing_inno.md)
|
||||
- [Whitelists, better security](tech/mycelium_whiltelist.md)
|
||||
- [Virtual Browser, no unprotected access to webapps](tech/virtual_browser.md)
|
||||
|
||||
[Storage](storage_inno.md)
|
||||
|
||||
- [Quantum Safe Storage: storage which cannot get lost nor corrupted](zstor_innovation.md)
|
||||
- [Quantum Safe Filesystem: host any storage interface e.g. IPFS](qsfs_innovation.md)
|
||||
- [FungiStor: Content Delivery everwhere in the world](fungistor_innovation.md)
|
||||
|
||||
Others
|
||||
- [Energy Efficient](tech/energy_efficient.md)
|
||||
@ -3,5 +3,5 @@
|
||||
|
||||
# Key Innovations
|
||||
|
||||
!!wiki.include page:components_links.md
|
||||
!!wiki.include page:key_innovations_list.md
|
||||
|
||||
|
||||
0
collections/tech/innovations/network/benefits.md
Normal file
0
collections/tech/innovations/network/benefits.md
Normal file
BIN
collections/tech/innovations/network/img/peer2peer_network.jpg
Normal file
BIN
collections/tech/innovations/network/img/peer2peer_network.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 162 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 130 KiB |
BIN
collections/tech/innovations/network/img/whitelists.jpg
Normal file
BIN
collections/tech/innovations/network/img/whitelists.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 124 KiB |
@ -1,7 +1,9 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Mycelium: A New Network Layer for the Internet
|
||||
|
||||
!!wiki.include page:mycelium_innovation_short.md
|
||||
|
||||
|
||||
!!wiki.include page:mycelium_inno0.md
|
||||
@ -11,6 +11,7 @@ Mycelium is an overlay network layer designed to enhance the existing internet i
|
||||
|
||||
### The Benefits
|
||||
|
||||
|
||||
- **Continuous connectivity:** Mycelium ensures uninterrupted connectivity by dynamically rerouting traffic through available connections (friends, satellites, 4/5G, fiber).
|
||||
- **End-to-end encryption:** robust encryption stops man-in-the-middle attacks, guaranteeing secure communication.
|
||||
- **Proof of authenticity ([POA](p2p:poa.md))**: ensures that we know who we are communicating with
|
||||
@ -0,0 +1,59 @@
|
||||
|
||||
|
||||
# Shortest Path Routing
|
||||
|
||||
## Empowering Connectivity with an End-to-End Encrypted Overlay Network
|
||||
|
||||
### The Concept of End-to-End Encryption
|
||||
|
||||
End-to-end encryption (E2EE) ensures that data is encrypted on the sender's device and only decrypted on the recipient's device. This means that no intermediaries, including service providers, can access or alter the data while it is in transit.
|
||||
|
||||
### Shortest Path Routing in Overlay Networks
|
||||
|
||||
An overlay network is a virtual network built on top of an existing physical network.
|
||||
|
||||
Each enduser mycelium agent will execute custom routing logic and protocols to improve connectivity.
|
||||
|
||||
- In the context of a Mycelium peer-to-peer (P2P) overlay network, nodes (participants) can dynamically discover and connect to each other, forming a mesh-like structure.
|
||||
- Shortest Path Routing: The network can use algorithms to find the shortest or most efficient path between nodes. This ensures that data packets travel the minimum distance required to reach their destination, reducing latency and improving performance.
|
||||
|
||||
### Multi-Hop Communication
|
||||
|
||||
In a P2P overlay network, data can hop through multiple nodes to reach its destination. This means that if a direct connection is not available, the data can be relayed through intermediary nodes. For example:
|
||||
|
||||
1. **Node A** wants to send data to **Node D**.
|
||||
2. There is no direct connection, but **Node A** can reach **Node B**, which can reach **Node C**, which finally reaches **Node D**.
|
||||
3. The data is encrypted end-to-end, so it remains secure throughout its journey.
|
||||
|
||||
Network usage tracking and billing can be used to make sure all participants are rewarded.
|
||||
|
||||
### Leveraging Existing Networks
|
||||
|
||||
This overlay network operates on top of existing internet infrastructure.
|
||||
|
||||
This leads to:
|
||||
|
||||
1. **Cost Efficiency**: By leveraging existing infrastructure, there is no need for extensive new investments in physical hardware.
|
||||
2. **Flexibility**: The network can dynamically adapt to changing conditions, such as network congestion or outages.
|
||||
|
||||
### Improving Connectivity for Underserved Populations
|
||||
|
||||
Currently, around 4 billion people lack decent internet access.
|
||||
|
||||
Mycelium can significantly improve their connectivity:
|
||||
|
||||
1. **Decentralized Access**: People in remote or underserved areas can connect to the network through nearby nodes, which may belong to friends, community members, or even commercial providers offering bandwidth.
|
||||
2. **Community-Driven Networks**: Local communities can set up nodes that connect to the broader overlay network, creating a resilient and scalable web of connectivity.
|
||||
3. **Increased Bandwidth**: By aggregating available bandwidth from multiple sources, the overlay network can provide higher data rates and more reliable connections.
|
||||
|
||||
### Example Scenario
|
||||
|
||||
Imagine a remote village with limited internet access. The villagers set up several nodes that connect to each other and to nearby towns with better connectivity, also some of the nodes can be connected to Internet over satelite, mobile 4g or other mechanisms.
|
||||
|
||||
Here’s how it works:
|
||||
|
||||
1. **Local Node Setup**: Villagers install nodes on their devices, which form a local mesh network.
|
||||
2. **Connecting to Broader Network**: Some nodes have access to satellite internet or long-range Wi-Fi that connects to nearby towns.
|
||||
3. **Dynamic Routing**: When a villager wants to access online resources, their data is encrypted end-to-end and routed through the shortest path available, which may include local nodes, satellite links, and commercial internet providers.
|
||||
4. **Enhanced Access**: This setup leverages all available bandwidth sources, providing more reliable and faster internet access to the village.
|
||||
|
||||
@ -0,0 +1,54 @@
|
||||
|
||||
|
||||
# Mycelium Whitelists
|
||||
|
||||
> Rethinking Network Security: Beyond Traditional Firewalls
|
||||
|
||||
### The Limitations of Traditional Firewalls
|
||||
|
||||
Firewalls have long been the cornerstone of network security, operating as gatekeepers to keep malicious actors out.
|
||||
|
||||
They work by monitoring incoming and outgoing network traffic and applying security rules to block or allow data packets based on predefined criteria. However, while firewalls are effective at creating a barrier, they have inherent limitations:
|
||||
|
||||
1. **Perimeter Focus**: Firewalls are designed to protect the perimeter of the network. This approach assumes that threats come from outside the network, but it does not adequately address threats from within.
|
||||
2. **Static Rules**: Firewalls rely on static rules that can be bypassed by sophisticated attacks. They do not adapt dynamically to changing threat landscapes.
|
||||
3. **Single Point of Failure**: As a centralized barrier, firewalls represent a single point of failure. If a firewall is compromised, the entire network can be exposed.
|
||||
|
||||
### The Need for Strong Authentication and Peer-to-Peer Communication
|
||||
|
||||
To address these limitations, a more modern approach to network security involves strong authentication and decentralized communication. By ensuring that all participants on the network are strongly authenticated, we can establish trust at the individual level rather than relying solely on perimeter defenses.
|
||||
|
||||
#### Strong Authentication
|
||||
|
||||
Strong authentication involves verifying the identity of network participants using robust methods such as:
|
||||
|
||||
- **Multi-Factor Authentication (MFA)**: Requires multiple forms of verification, such as passwords, biometrics, and hardware tokens.
|
||||
- **Public Key Infrastructure (PKI)**: Uses cryptographic keys to authenticate users and devices.
|
||||
|
||||
By implementing strong authentication, we can ensure that only legitimate users and devices can access the network, significantly reducing the risk of unauthorized access.
|
||||
|
||||
#### Peer-to-Peer Communication Over an Overlay Network
|
||||
|
||||
Instead of routing all traffic through a central firewall, participants can communicate directly with each other and applications using a peer-to-peer (P2P) overlay network. An overlay network, called Mycelium, can facilitate this decentralized communication.
|
||||
|
||||
- **Mycelium Overlay Network**: This overlay network functions like a mesh, allowing nodes (participants) to connect directly with each other and applications. It provides a resilient and scalable architecture where each node can dynamically find the best path for communication.
|
||||
|
||||
### Whitelists and Group-Based Access Control
|
||||
|
||||
To further enhance security, applications can use whitelists and group-based access control. This approach involves:
|
||||
|
||||
1. **Whitelisting Users**: Only allowing access to users who are explicitly permitted. This can be based on strong authentication credentials.
|
||||
2. **Group-Based Access Control**: Organizing users into groups with specific permissions. Each application can define which groups have access based on their source IP addresses and other criteria.
|
||||
|
||||
#### Example Scenario
|
||||
|
||||
Consider an application hosted on the network. Instead of relying on a firewall to block unauthorized access, the application uses Mycelium to communicate with authenticated peers. It employs a whitelist to specify which users or groups can access the application. For instance:
|
||||
|
||||
- **Group A**: Developers with access to development resources.
|
||||
- **Group B**: Administrators with access to administrative tools.
|
||||
- **Group C**: End-users with access to specific application features.
|
||||
|
||||
Each group’s access is controlled by specifying the allowed source IP addresses and other authentication factors. This ensures that only authorized users can access the application, regardless of their location.
|
||||
|
||||
> only available in the enterprise edition.
|
||||
|
||||
@ -7,4 +7,7 @@
|
||||
The Network Wall offers 100% separation between where compute workloads are and where services are exposed, proving an extremely high level of security.
|
||||
|
||||
|
||||
!!wiki.include page:network_wall_innovation_short
|
||||
!!wiki.include page:network_wall_inno0
|
||||
|
||||
> Available in Enterprise and OEM editions ony.
|
||||
|
||||
71
collections/tech/innovations/network/virtual_browser.md
Normal file
71
collections/tech/innovations/network/virtual_browser.md
Normal file
@ -0,0 +1,71 @@
|
||||
|
||||
|
||||
## Secure Remote Browser Concept
|
||||
|
||||
### Overview
|
||||
|
||||
In this concept, users interact with a secure web application through their web browsers without running JavaScript locally.
|
||||
|
||||
Instead, the actual browser logic and JavaScript execution occur in a secure, remote virtual browser hosted in a secure part of a private cloud. This setup provides enhanced security and control, ensuring that users are protected from malicious scripts and other threats.
|
||||
|
||||
### Key Components
|
||||
|
||||
1. **Client-Side Browser (Local Browser)**
|
||||
- **Rendering Only**: The user's local browser is responsible only for rendering content. It draws the user interface using technologies like HTML5 Canvas.
|
||||
- **No Local JavaScript Execution**: No JavaScript code runs on the local browser, eliminating the risk of client-side script attacks.
|
||||
|
||||
2. **Remote Browser (Virtual Browser)**
|
||||
- **Secure Execution Environment**: The remote browser runs within a secure container in the cloud. For example, this could be within the secure network of a bank.
|
||||
- **JavaScript Execution**: All JavaScript execution happens in the remote browser. This environment is tightly controlled and monitored.
|
||||
- **Context Validation**: Each JavaScript file executed is checked to ensure it originates from the original, built application. This prevents unauthorized or malicious scripts from running.
|
||||
|
||||
3. **Session Management**
|
||||
- **Ephemeral Sessions**: Each user session is temporary. After a session ends, the context is destroyed and rebuilt for the next session, ensuring a clean state each time.
|
||||
- **Session Recording**: Sessions can be recorded, similar to screen CCTV, for auditing and security purposes. This allows for detailed monitoring and review if needed.
|
||||
|
||||
4. **Network Service Lists and Mycelium Integration**
|
||||
- **Secure Communication**: The connection between the local browser and the remote browser uses end-to-end encryption. The Mycelium overlay network ensures the shortest path and secure, peer-to-peer communication.
|
||||
- **Access Control**: Network service lists and group-based access control manage which users can access specific applications, enhancing security and control.
|
||||
|
||||
### Example Workflow
|
||||
|
||||
1. **User Initiates Connection**
|
||||
- The user opens their local browser and navigates to the bank's application URL.
|
||||
- The local browser connects to the remote browser hosted in the bank's secure cloud environment.
|
||||
|
||||
2. **Remote Browser Setup**
|
||||
- A new, secure container is instantiated for the user's session.
|
||||
- The remote browser loads the bank's application and validates all JavaScript files.
|
||||
|
||||
3. **Rendering in Local Browser**
|
||||
- The remote browser executes the JavaScript and sends the rendered output to the local browser.
|
||||
- The local browser draws this output on the canvas, providing a seamless user experience.
|
||||
|
||||
4. **Session Management**
|
||||
- Throughout the session, all interactions are processed by the remote browser.
|
||||
- User interactions (e.g., clicks, form submissions) are sent to the remote browser, which processes them and updates the rendered output accordingly.
|
||||
|
||||
5. **Session Termination**
|
||||
- When the user finishes their session, the remote browser context is destroyed.
|
||||
- Any recorded session data is stored securely for auditing purposes.
|
||||
|
||||
### Benefits
|
||||
|
||||
1. **Enhanced Security**
|
||||
- By not running JavaScript locally, the risk of client-side attacks such as cross-site scripting (XSS) is eliminated.
|
||||
- The remote browser's secure environment ensures that only validated scripts execute.
|
||||
|
||||
2. **Controlled Environment**
|
||||
- The bank has full control over the execution environment, allowing for stringent security policies and monitoring.
|
||||
- Ephemeral sessions ensure that each user starts with a clean slate, reducing the risk of persistent threats.
|
||||
|
||||
3. **Auditing and Compliance**
|
||||
- Session recording provides a detailed audit trail, which is valuable for security reviews and compliance with regulatory requirements.
|
||||
|
||||
4. **Improved User Experience**
|
||||
- Users benefit from a secure browsing experience without performance degradation, as rendering is offloaded to the client's local browser.
|
||||
|
||||
### Integration with Mycelium and Network Service Lists
|
||||
By combining this remote browser concept with Mycelium and network service lists, we can ensure secure and efficient communication:
|
||||
- **Mycelium Overlay Network**: Ensures that the connection between the local and remote browser is routed through the most efficient path, leveraging peer-to-peer connections where possible.
|
||||
- **Network Service Lists**: Manage which users and groups can access the remote browser and specific applications, providing fine-grained access control.
|
||||
29
collections/tech/internet/cloud_today.md
Normal file
29
collections/tech/internet/cloud_today.md
Normal file
@ -0,0 +1,29 @@
|
||||
|
||||
|
||||
### Cloud Stacks: The Onion Analogy
|
||||
|
||||
Most cloud stacks can be compared to an onion, where each layer represents an additional component or service added to address a problem in the system. However, like peeling an onion, as you dig deeper, you often find that these layers are not solving the core issues but merely masking symptoms, leading to a complex and often fragile structure.
|
||||
|
||||
#### 1. **The Outer Layers: Quick Fixes and Additions**
|
||||
- **Problem:** When an issue arises, such as performance bottlenecks or security vulnerabilities, organizations often add another tool, service, or layer to the cloud stack to mitigate the issue.
|
||||
- **Analogy:** This is akin to applying a bandage or taking a painkiller when you feel pain. The immediate discomfort might be alleviated, but the underlying problem remains untouched.
|
||||
|
||||
#### 2. **The Middle Layers: Compounded Complexity**
|
||||
- **Problem:** As more layers are added to solve different issues, the cloud stack becomes increasingly complicated. Each new layer interacts with the existing ones, often in unpredictable ways, leading to a system that is difficult to manage and troubleshoot.
|
||||
- **Analogy:** Just like adding more painkillers to treat worsening symptoms, the system becomes dependent on these layers to function. However, this doesn’t address the root cause of the issues; instead, it creates a reliance on temporary fixes that complicate the system further.
|
||||
- **Example:** Security patches or monitoring tools are added after incidents of data breaches or unauthorized access. While these layers enhance security, they do not address the underlying issue of poor security practices in the original architecture, leading to a cloud stack that is more difficult to maintain and secure.
|
||||
|
||||
#### 3. **The Core: Root Causes Ignored**
|
||||
- **Problem:** At the core of the onion, the fundamental issues often remain unaddressed. These could be poor initial design choices, lack of planning, or failure to align the cloud architecture with the business’s long-term needs.
|
||||
- **Analogy:** Similar to how treating only the symptoms of an illness without addressing its cause can lead to recurring issues, adding layers to a cloud stack without fixing the root problems results in a cycle of ongoing maintenance, inefficiency, and potential failure.
|
||||
- **Example:** If a cloud environment was initially set up without considering future scalability, each layer added to address scaling problems doesn’t solve the underlying issue of an inflexible architecture. As the system grows, the layers pile up, making the system more cumbersome and fragile.
|
||||
|
||||
### Painkiller Approach: Treating Symptoms, Not Causes
|
||||
|
||||
This onion-like structure represents a "painkiller approach" to cloud management, where immediate issues are addressed with quick fixes rather than tackling the underlying problems. Over time, this approach leads to several challenges:
|
||||
|
||||
- **Cyber Pandemic** The Cyber Pandemic is real, added these layers leads to weak security.
|
||||
- **Increased Complexity:** Each new layer adds complexity, making the system harder to understand and maintain.
|
||||
- **Higher Costs:** More layers often mean more resources, licenses, and management overhead, increasing operational costs.
|
||||
- **Reduced Agility:** The more complex the stack, the harder it is to make changes or adapt to new requirements, reducing the system’s overall agility.
|
||||
- **Fragility:** A stack built on temporary fixes is more prone to failures because the core issues are not resolved, making the system brittle.
|
||||
BIN
collections/tech/internet/img/onion.jpg
Normal file
BIN
collections/tech/internet/img/onion.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 116 KiB |
@ -35,9 +35,7 @@ Our current internet model compromises autonomy and sovereignty. Most data is st
|
||||
|
||||
Moreover, the internet is replicated many times across various applications, each requiring its own full infrastructure. This approach is unsustainable and inefficient.
|
||||
|
||||
## ThreeFold wants to create a new base layer
|
||||
|
||||
A Base layer who doesn't have these issues.
|
||||
## The ThreeFold Cloud Engine resolves quite a lot of those issues
|
||||
|
||||
ThreeFold resolves
|
||||
|
||||
|
||||
2
collections/tech/internet/status_today.md
Normal file
2
collections/tech/internet/status_today.md
Normal file
@ -0,0 +1,2 @@
|
||||
# Status Today
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 341 KiB |
@ -1,5 +1,7 @@
|
||||
|
||||
|
||||
We need a new cloud engine which supports the evolution of the Internet
|
||||
|
||||
# The Internet’s Natural Progression
|
||||
|
||||
The Internet was always meant to be a peer-to-peer infrastructure.
|
||||
@ -38,7 +40,7 @@ The technical backbone enabling the Hero is a component known as the 3Bot. This
|
||||
|
||||
Communication between 3Bots is optimized to use the shortest possible paths, ensuring that all interactions are end-to-end encrypted for maximum security and privacy.
|
||||
|
||||
## 3Bot Architecture in relation to TFGrid
|
||||
## 3Bot Architecture
|
||||
|
||||
|
||||
|
||||
|
||||
@ -3,9 +3,9 @@
|
||||
|
||||
|
||||
|
||||
This tool allows you to manage your ZMachine over web remotely.
|
||||
This tool allows you to manage your Zero VM over web remotely.
|
||||
|
||||
ZMachine process manager:
|
||||
Zero VM process manager:
|
||||
|
||||
- Provides a web interface and a REST API to control your processes
|
||||
- Allows you to watch the logs of your processes
|
||||
|
||||
BIN
collections/tech/primitives/compute/img/zos_images.jpg
Normal file
BIN
collections/tech/primitives/compute/img/zos_images.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 133 KiB |
7
collections/tech/primitives/compute/zero_image.md
Normal file
7
collections/tech/primitives/compute/zero_image.md
Normal file
@ -0,0 +1,7 @@
|
||||
|
||||
## Zero-Images
|
||||
|
||||
> A New Way Of Dealing With OS Images
|
||||
|
||||
!!wiki.include page:zero_image_inno.md
|
||||
|
||||
@ -4,22 +4,20 @@ TFGrid is compatible with Kubernetes Technology.
|
||||
|
||||
|
||||
|
||||
Each eVDC as shown above is a full blown Kubernetes deployment.
|
||||
|
||||
### Unique for our Kubernetes implementation
|
||||
|
||||
- The Kubernetes networks are on top of our [ZNet](znet) technology which means all traffic between containers and kubernetes hosts is end2end encrypted independent of where your Kubernetes nodes are deployed.
|
||||
- You can mount a QSFS underneath a Kubernetes Node (VM), which means that you can deploy containers on top of QSFS to host unlimited amounts of storage in a super safe way.
|
||||
- The Kubernetes networks are on top of our [Mycelium](mycelium.md) technology which means all traffic between containers and kubernetes hosts is end2end encrypted independent of where your Kubernetes nodes are deployed.
|
||||
- You can mount a Quantum Safe Storage System underneath a Kubernetes Node (VM), which means that you can deploy containers on top of QSFS to host unlimited amounts of storage in a super safe way.
|
||||
- You Kubernetes environment is for sure 100% decentralized, you define where you want to deploy your Kubernetes nodes and only you have access to the deployed workloads on the TFGrid.
|
||||
|
||||
### Features
|
||||
|
||||
* integration with znet (efficient, secure encrypted network between the zmachines)
|
||||
* integration with znet (efficient, secure encrypted network between the zero_vms)
|
||||
* can be easily deployed at the edge
|
||||
* single-tenant!
|
||||
|
||||
<!--
|
||||
### ZMachine Benefits
|
||||
### Zero VM Benefits
|
||||
|
||||
* [ZOS Protect](zos_protect): no hacking surface to the Zero-Nodes, integrate silicon route of trust
|
||||
* [ZNet](znet) and [Planetary Net](planetary_network): a true global single backplane network connecting us all -->
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# ZMachine
|
||||
# Zero VM
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Features
|
||||
@ -12,5 +12,5 @@
|
||||
* minimal hacking surface to the Zero-Nodes, integrate silicon route of trust
|
||||
* ZOS Filesystem: dedupe, zero-install, hacker-proof
|
||||
* Webgateway: intelligent connection between web (internet) and container services
|
||||
* integration with Mycelium (efficient, secure encrypted network between the zmachines)
|
||||
* integration with Mycelium (efficient, secure encrypted network between the zero_vms)
|
||||
|
||||
|
||||
BIN
collections/tech/primitives/network/img/virtual_browser.jpg
Normal file
BIN
collections/tech/primitives/network/img/virtual_browser.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 84 KiB |
@ -6,4 +6,6 @@ The planetary network called Mycelium is an overlay network which lives on top o
|
||||
|
||||
In the Mycelium network, everyone is connected to everyone. End-to-end encryption between users of an app and the app runs behind the network wall.
|
||||
|
||||
!!wiki.include page:'tech:mycelium_incl.md'
|
||||
!!wiki.include page:'tech:mycelium0.md'
|
||||
|
||||
> [read more about the shortest path routing](tf9_products:shortest_path_routing.md)
|
||||
54
collections/tech/primitives/network/mycelium_whiltelist.md
Normal file
54
collections/tech/primitives/network/mycelium_whiltelist.md
Normal file
@ -0,0 +1,54 @@
|
||||
|
||||
|
||||
# Mycelium Whitelists
|
||||
|
||||
> Rethinking Network Security: Beyond Traditional Firewalls
|
||||
|
||||
### The Limitations of Traditional Firewalls
|
||||
|
||||
Firewalls have long been the cornerstone of network security, operating as gatekeepers to keep malicious actors out.
|
||||
|
||||
They work by monitoring incoming and outgoing network traffic and applying security rules to block or allow data packets based on predefined criteria. However, while firewalls are effective at creating a barrier, they have inherent limitations:
|
||||
|
||||
1. **Perimeter Focus**: Firewalls are designed to protect the perimeter of the network. This approach assumes that threats come from outside the network, but it does not adequately address threats from within.
|
||||
2. **Static Rules**: Firewalls rely on static rules that can be bypassed by sophisticated attacks. They do not adapt dynamically to changing threat landscapes.
|
||||
3. **Single Point of Failure**: As a centralized barrier, firewalls represent a single point of failure. If a firewall is compromised, the entire network can be exposed.
|
||||
|
||||
### The Need for Strong Authentication and Peer-to-Peer Communication
|
||||
|
||||
To address these limitations, a more modern approach to network security involves strong authentication and decentralized communication. By ensuring that all participants on the network are strongly authenticated, we can establish trust at the individual level rather than relying solely on perimeter defenses.
|
||||
|
||||
#### Strong Authentication
|
||||
|
||||
Strong authentication involves verifying the identity of network participants using robust methods such as:
|
||||
|
||||
- **Multi-Factor Authentication (MFA)**: Requires multiple forms of verification, such as passwords, biometrics, and hardware tokens.
|
||||
- **Public Key Infrastructure (PKI)**: Uses cryptographic keys to authenticate users and devices.
|
||||
|
||||
By implementing strong authentication, we can ensure that only legitimate users and devices can access the network, significantly reducing the risk of unauthorized access.
|
||||
|
||||
#### Peer-to-Peer Communication Over an Overlay Network
|
||||
|
||||
Instead of routing all traffic through a central firewall, participants can communicate directly with each other and applications using a peer-to-peer (P2P) overlay network. An overlay network, called Mycelium, can facilitate this decentralized communication.
|
||||
|
||||
- **Mycelium Overlay Network**: This overlay network functions like a mesh, allowing nodes (participants) to connect directly with each other and applications. It provides a resilient and scalable architecture where each node can dynamically find the best path for communication.
|
||||
|
||||
### Whitelists and Group-Based Access Control
|
||||
|
||||
To further enhance security, applications can use whitelists and group-based access control. This approach involves:
|
||||
|
||||
1. **Whitelisting Users**: Only allowing access to users who are explicitly permitted. This can be based on strong authentication credentials.
|
||||
2. **Group-Based Access Control**: Organizing users into groups with specific permissions. Each application can define which groups have access based on their source IP addresses and other criteria.
|
||||
|
||||
#### Example Scenario
|
||||
|
||||
Consider an application hosted on the network. Instead of relying on a firewall to block unauthorized access, the application uses Mycelium to communicate with authenticated peers. It employs a whitelist to specify which users or groups can access the application. For instance:
|
||||
|
||||
- **Group A**: Developers with access to development resources.
|
||||
- **Group B**: Administrators with access to administrative tools.
|
||||
- **Group C**: End-users with access to specific application features.
|
||||
|
||||
Each group’s access is controlled by specifying the allowed source IP addresses and other authentication factors. This ensures that only authorized users can access the application, regardless of their location.
|
||||
|
||||
> only available in the enterprise edition.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Web Gateway
|
||||
|
||||
The Web Gateway is a mechanism to connect private networks to the open Internet in such a way that there is no direct connection between the Internet and the secure workloads running in the ZMachines.
|
||||
The Web Gateway is a mechanism to connect private networks to the open Internet in such a way that there is no direct connection between the Internet and the secure workloads running in the Zero VMs.
|
||||
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@ The Web Gateway is a mechanism to connect private networks to the open Internet
|
||||
|
||||
### Implementation
|
||||
|
||||
Some 3Nodes support gateway functionality (this is configured by the farmers). A 3Node with gateway configuration can then accept gateway workloads and forward traffic to ZMachines that only have Planetary Network or IPv6 addresses.
|
||||
Some 3Nodes support gateway functionality (this is configured by the farmers). A 3Node with gateway configuration can then accept gateway workloads and forward traffic to Zero VMs that only have Planetary Network or IPv6 addresses.
|
||||
|
||||
The gateway workloads consist of a name (prefix) that first needs to be reserved on the blockchain. Then, the list of backend IPs. There are other flags that can be set to control automatic TLS (please check Terraform documentation for the exact details of a reservation).
|
||||
|
||||
@ -21,9 +21,9 @@ Once the 3Node receives this workload, the network configures proxy for this nam
|
||||
|
||||
### Security
|
||||
|
||||
ZMachines have to have a Planetary Network IP or any other IPv6 (IPv4 is also accepted). This means that any person connected to the Planetary Network can also reach the ZMachine without the need for a proxy.
|
||||
Zero VMs have to have a Planetary Network IP or any other IPv6 (IPv4 is also accepted). This means that any person connected to the Planetary Network can also reach the Zero VM without the need for a proxy.
|
||||
|
||||
So it's up to the ZMachine owner/maintainer to make sure it is secured and that only the required ports are open.
|
||||
So it's up to the Zero VM owner/maintainer to make sure it is secured and that only the required ports are open.
|
||||
|
||||
### Redundant Network Connection
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# ZNIC
|
||||
|
||||
ZNIC is the network interface which is connected to ZMachine.
|
||||
ZNIC is the network interface which is connected to Zero VM.
|
||||
|
||||
Can be implemented as interface to
|
||||
|
||||
|
||||
@ -11,10 +11,10 @@ Any application which can run on linux can run on the TFGrid.
|
||||
|
||||
- [ZKube](zkube.md)
|
||||
- kubernetes deployment
|
||||
- [ZMachine](zmachine.md)
|
||||
- [Zero VM](zero_vm.md)
|
||||
- the container or virtual machine running inside ZOS
|
||||
- [CoreX](corex.md)
|
||||
- process manager (optional), can be used to get remote access to your zmachine
|
||||
- process manager (optional), can be used to get remote access to your zero_vm
|
||||
|
||||
A 3Node is a Zero-OS enabled computer which is hosted by any cloud operator.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
|
||||
|
||||
presents itself as a filesystem to the ZMachine.
|
||||
presents itself as a filesystem to the Zero VM.
|
||||
|
||||
### Benefits
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Storage Primitives
|
||||
|
||||
- [ZOS Filesystem](zos_fs.md) : deduped immutable filesystem
|
||||
- [ZOS Mount](zmount.md) : a part of a SSD (fast disk), mounted underneath your zmachine
|
||||
- [ZOS Mount](zmount.md) : a part of a SSD (fast disk), mounted underneath your zero_vm
|
||||
- [Quantum Safe Filesystem](qsfs.md) : unbreakable storage system (secondary storage only)
|
||||
- [Zero-DB](zdb.md) : the lowest level storage primitive, is a key value stor, used underneath other storage mechanisms typically
|
||||
- [Zero-Disk](zdisk.md) : OEM only, virtual disk format
|
||||
|
||||
@ -9,9 +9,9 @@ A deduped filesystem which is more efficient compared to images as used in other
|
||||
|
||||
## Uses FLIST Inside
|
||||
|
||||
In Zero-OS, `flist` is the format used to store zmachine images. This format is made to provide a complete mountable remote filesystem, but downloading only the files contents that you actually needs.
|
||||
In Zero-OS, `flist` is the format used to store zero_vm images. This format is made to provide a complete mountable remote filesystem, but downloading only the files contents that you actually needs.
|
||||
|
||||
In practice, Flist itself is a small database which contains metadata about files and directories, file payload are stored on a tfgrid hub. You only need to download payload when you need it, this dramatically reduce zmachine boot time, bandwidth and disk overhead.
|
||||
In practice, Flist itself is a small database which contains metadata about files and directories, file payload are stored on a tfgrid hub. You only need to download payload when you need it, this dramatically reduce zero_vm boot time, bandwidth and disk overhead.
|
||||
|
||||
### Why this ZFlist Concept
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
Imagine a storage system with the following benefits
|
||||
|
||||
!!!include:qss_benefits_
|
||||
!!wiki.include qss_benefits_
|
||||
|
||||
> This is not a dream but does exist and is the underpinning of the TFGrid.
|
||||
|
||||
@ -13,9 +13,5 @@ Our storage architecture follows the true peer-to-peer design of the TF grid. An
|
||||
Peer-to-peer provides the unique proposition of selecting storage providers that match your application and service of business criteria. For example, you might be looking to store data for your application in a certain geographic area (for governance and compliance) reasons. Also, you might want to use different "storage policies" for different types of data. Examples are live versus archived data. All of these uses cases are possible with this storage architecture and could be built by using the same building slice produced by farmers and consumed by developers or end-users.
|
||||
|
||||
|
||||
!!!include:qsss_toc
|
||||
|
||||
!!!def alias:qsss,quantum_safe_storage_system
|
||||
|
||||
|
||||
|
||||
|
||||
@ -7,14 +7,14 @@ This stack allows everyone to deploy scalable web 2/3/4 apps on top of the TFGri
|
||||
|
||||
| | Roadmap | Timing |
|
||||
| -------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ------ |
|
||||
| Hero Publisher | Publish websites, e-books, ... on top of TFGrid | Q2 24 |
|
||||
| Hero CI = Continuous Integration | Easier to use Continuous Integration / Development, very powerfull, with multi node support | Q3 24 |
|
||||
| Hero Play | Integrate declarative automation and configuration management as part of wiki approach in hero Publisher | Q3 24 |
|
||||
| Hero Git | Alternative to centralized Github (based on Gitea), fully integrated on top of TFGrid | Q3 24 |
|
||||
| Hero DB | Flexible ultra redundant database stor with indexing, queries, stored procesudes, super scalable replication | Q3 24 |
|
||||
| Hero OSIS | Object Storage and Index system integrates with hero Git, all data on git based backend | Q3 24 |
|
||||
| Hero WEB | Web framework (with co-routines) using Vlang, deployable globally on TFGrid, integrated with Mycelium Net and Names. | Q3 24 |
|
||||
| Hero Monitor | Monitor all your different components on redundant monitoring stack | Q3 24 |
|
||||
| Hero Publisher | Publish websites, e-books, ... on top of TFGrid | Q4 24 |
|
||||
| Hero CI = Continuous Integration | Easier to use Continuous Integration / Development, very powerfull, with multi node support | Q4 24 |
|
||||
| Hero Play | Integrate declarative automation and configuration management as part of wiki approach in hero Publisher | Q4 24 |
|
||||
| Hero Git | Alternative to centralized Github (based on Gitea), fully integrated on top of TFGrid | Q4 24 |
|
||||
| Hero DB | Flexible ultra redundant database stor with indexing, queries, stored procesudes, super scalable replication | Q4 24 |
|
||||
| Hero OSIS | Object Storage and Index system integrates with hero Git, all data on git based backend | Q4 24 |
|
||||
| Hero WEB | Web framework (with co-routines) using Vlang, deployable globally on TFGrid, integrated with Mycelium Net and Names. | Q4 24 |
|
||||
| Hero Monitor | Monitor all your different components on redundant monitoring stack | Q4 24 |
|
||||
| Hero Happs | Hero natively supports Holochain HAPPS | Q1 25 |
|
||||
| Hero Actors | Hero can serve actors which respond and act on OpenRPC calls ideal as backend for web or other apps. | Q1 25 |
|
||||
| Hero Web 3 Gateway | Hero aims to have native support for chosen Web3 partner solutions | Q1 25 |
|
||||
|
||||
@ -40,8 +40,8 @@ however, for this initiative to truly succeed on planetary level, we need many m
|
||||
| Zero-OS v4 (our next major release) | v4, no more TFChain, mutual credit, marketplace | Q1 25 |
|
||||
| FungiStor | A revolutionary different way how to deliver content | Q1 25 |
|
||||
| Zero-Images on FungiStor | Can be stored on FungiStor | Q1 25 |
|
||||
| Zero-Images from Docker | CI/CD integration (See below) | Q4 24 |
|
||||
| Zero-Images Hub | CI/CD integration (See below) <BR> no more need for separate Hub | Q4 24 |
|
||||
| Zero-Images from Docker | CI/CD integration (See Hero CI/CD) | Q4 24 |
|
||||
| Zero-Images Hub | CI/CD integration (See Hero CI/CD) <BR> no more need for separate Hub | Q4 24 |
|
||||
| Mycelium Core | Just more hardening and testing | Q4 24 |
|
||||
| Mycelium Message Bus | Replace our current RMB, all our own RPC over Mycelium | Q4 24 |
|
||||
| Quantum Safe Storage | Integration in UI, better documentation | Q4 24 |
|
||||
|
||||
@ -13,11 +13,11 @@ To build on the ThreeFold Grid, refer to the [Developers](developers@@developers
|
||||
- [The Internet Re-invented](how_does_it_work.md)
|
||||
- [World Records](world_records.md)
|
||||
- [Key Innovations](key_innovations_overview.md)
|
||||
- [Mycelium Network](mycelium_innovation.md)
|
||||
- [Mycelium Network](mycelium_inno.md)
|
||||
- [Zero-OS](zos_innovation.md)
|
||||
- [Quantum Safe Storage](zstor_innovation.md)
|
||||
- [Quantum Safe Filesystem](qsfs_innovation.md)
|
||||
- [FList: Better OS Images](flist_innovation.md)
|
||||
- [FList: Better OS Images](zero_image.md)
|
||||
- [FungiStor](fungistor_innovation.md)
|
||||
- [Network Wall](network_wall_innovation.md)
|
||||
- [Architecture](architecture.md)
|
||||
|
||||
@ -1,3 +1,3 @@
|
||||
qsss_1.png
|
||||
smartcontract_deploy.png
|
||||
zmachine_storage.png
|
||||
zero_vm_storage.png
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
|
||||
## Unbreakable Storage
|
||||
|
||||
|
||||
|
||||
|
||||
- unlimited history
|
||||
- survives network, datacenter or node breakdown
|
||||
|
||||
@ -1,26 +0,0 @@
|
||||
|
||||
## Zero-Chance = Deterministic Deployment
|
||||
|
||||
|
||||
|
||||
The Dedupe filesystem flist uses an interface which allows you to create the file system interface in user space, it is a virtual filesystem.
|
||||
|
||||
Metadata is exposed. The system sees the full tree of the image, but data itself is not there, data is downloaded whenever they are accessed and fully deduped (unique data).
|
||||
|
||||
>TODO: improve
|
||||
|
||||
### Benefits
|
||||
|
||||
- Smart contract for IT
|
||||
The smart contract for IT concept is applicable to any workload: containers, VMs, all gateways primitives, volumes, kubernetes and network.
|
||||
It is a static agreement between farmer and user about deployment of an IT workload
|
||||
- no dynamic behavior for deployment at runtime
|
||||
- no process can start unless the files are 100% described on flist level
|
||||
|
||||
### There are multiple ways to create an flist:
|
||||
|
||||
- Convert an existing docker image which is hosted on the docker hub
|
||||
- Push an archive like a tgz on the hub
|
||||
- A library and CLI tool exist to build the flist from scratch: doing it this way, the directory is locally populated, and the flist is then created from the CLI tool
|
||||
- A [GitHub action](https://github.com/threefoldtech/publish-flist) allows to build a flist directly from GitHub action, useful for developers on GitHub
|
||||
|
||||
36
collections/tech/zos/benefits/zero_deploy.md
Normal file
36
collections/tech/zos/benefits/zero_deploy.md
Normal file
@ -0,0 +1,36 @@
|
||||
|
||||
|
||||
|
||||
## Deterministic Deployment
|
||||
|
||||
|
||||
The concept of Zero-Deploy is a key component of the **Smart Contract for IT** framework, which can be applied to any type of workload—whether it's containers, virtual machines (VMs), network gateways, volumes, Kubernetes resources, or other network elements. This framework serves as a formal agreement between a farmer (provider) and a user regarding the deployment of an IT workload.
|
||||
|
||||
### Process
|
||||
|
||||
1. **Build Your Code**
|
||||
Develop and prepare your application code.
|
||||
|
||||
2. **Convert to Zero-Image**
|
||||
Use a CI/CD solution (e.g., Hero CI/CD) to convert your Docker build (or other format) into a Zero-Image format.
|
||||
|
||||
3. **Define the Workload**
|
||||
Specify all the details of your workload, including network bridges, web gateways, required machines, and more.
|
||||
|
||||
4. **Register and Sign**
|
||||
Register the workload and sign it with your private key.
|
||||
|
||||
5. **Automatic Detection**
|
||||
All necessary Zero-OS nodes (our infrastructure) will detect that a new workload needs to be deployed.
|
||||
|
||||
6. **Deployment Process**
|
||||
The nodes will pull down the formal workload descriptions and initiate the deployment process.
|
||||
|
||||
7. **Validation**
|
||||
Every step of the deployment is verified by Zero-OS (ZOS) to ensure that the intended result is accurately replicated. If any discrepancies are detected, ZOS will halt the deployment and provide an error message.
|
||||
|
||||
### Benefits
|
||||
|
||||
- **Deterministic Deployment**: There is no dynamic behavior during deployment at runtime, ensuring a consistent and predictable outcome.
|
||||
- **Strict Compliance**: No process can start unless all files and configurations are fully described at the flist level.
|
||||
|
||||
@ -4,22 +4,28 @@
|
||||
|
||||
The Zero-OS is delivered to the 3Nodes over the internet network (network boot) and does not need to be installed.
|
||||
|
||||
|
||||
### 3Node Install
|
||||
|
||||
1. Acquire a computer (server)
|
||||
1. Deploy a computer
|
||||
2. Configure a farm on the TFGrid explorer
|
||||
3. Download the bootloader and put on a USB stick or configure a network boot device
|
||||
4. Power on the computer and connect to the internet
|
||||
5. Boot! The computer will automatically download the components of the operating system (Zero-OS)
|
||||
|
||||
The actual bootloader is very small, it brings up the network interface of your computer and queries TFGeid for the remainder of the boot files needed.
|
||||
The actual bootloader is very small, it brings up the network interface of your computer and queries TFGrid for the remainder of the boot files needed.
|
||||
|
||||
The operating system is not installed on any local storage medium (hard disk, ssd), Zero-OS is stateless.
|
||||
|
||||
The mechanism to allow this to work in a safe and efficient manner is an innovation called our container virtual filesystem.
|
||||
|
||||
|
||||
This is explained in more detail [in our SDK manual](https://library.threefold.me/info/manual/#/booting_node).
|
||||
|
||||
### Process
|
||||
|
||||
|
||||
- optionally: configure booting from secure BIOS
|
||||
- optionally: install signing certificate in the BIOS, to make sure that only the right bootloader can be started
|
||||
- the bootloader (ISO, PXE, USB, ...) get's downloaded from Internet (TFGrid CDN or private deployment)
|
||||
- core-0 (the first boot process) starts, self verification happens
|
||||
- the metadata for the the required software modules is downloaded and checked against signature and hashes
|
||||
- the core-0 zero_image service
|
||||
|
||||
@ -1,10 +0,0 @@
|
||||
|
||||
## Flist Hub
|
||||
|
||||
We provide a public hub you could use to upload your own Flist or filesystem directly and take advantages of Flist out-of-box on Zero-OS.
|
||||
You can convert an existing docker image the same way.
|
||||
|
||||
Example TFGrid Public hub: [hub.grid.tf](https://hub.grid.tf)
|
||||
|
||||
|
||||
|
||||
28
collections/tech/zos/zero_hub.md
Normal file
28
collections/tech/zos/zero_hub.md
Normal file
@ -0,0 +1,28 @@
|
||||
|
||||
# Zero Hub
|
||||
|
||||
> TODO: screenshots
|
||||
|
||||
A server which can manage your [Zero-Images](zero_image.md) and make it available to all Zero-OS'es
|
||||
|
||||
Features
|
||||
|
||||
- docker to zero_image converter
|
||||
- each user has its own account to manage their [Zero-Images](zero_image.md)
|
||||
- explorer for zero-images, see the content of what is inside
|
||||
- upload/download images which get converted to zero-image format, image can be e.g. export of a docker
|
||||
- replication between zero-hubs (as commandline in scripts)
|
||||
|
||||
## Private Zero Hub
|
||||
|
||||
You can deploy your private Zero-Hub and use [Mycelium Whitelist](mycelium_whiltelist.md)
|
||||
|
||||
## Public Zero Hub
|
||||
|
||||
We provide a public hub you could use to upload your own Flist or filesystem directly and take advantages of Flist out-of-box on Zero-OS.
|
||||
You can convert an existing docker image the same way.
|
||||
|
||||
Example TFGrid Public hub: [hub.grid.tf](https://hub.grid.tf)
|
||||
|
||||
|
||||
|
||||
@ -4,10 +4,10 @@
|
||||
|
||||
- [ZKube](zkube.md)
|
||||
- kubernetes deployment
|
||||
- [ZMachine](zmachine.md)
|
||||
- [Zero VM](zero_vm.md)
|
||||
- the container or virtual machine running inside ZOS
|
||||
- [CoreX](corex.md)
|
||||
- process manager (optional), can be used to get remote access to your zmachine
|
||||
- process manager (optional), can be used to get remote access to your zero_vm
|
||||
|
||||
A 3Node is a Zero-OS enabled computer which is hosted with any of the Cloud Providers.
|
||||
|
||||
|
||||
2
heroscript/tech/devel.sh
Executable file
2
heroscript/tech/devel.sh
Executable file
@ -0,0 +1,2 @@
|
||||
#!/bin/bash
|
||||
hero mdbook -u https://git.ourworld.tf/tfgrid/info_tfgrid/src/branch/main/heroscript/tech -o
|
||||
3
heroscript/tech/sync_production.sh
Executable file
3
heroscript/tech/sync_production.sh
Executable file
@ -0,0 +1,3 @@
|
||||
#!/bin/bash
|
||||
hero mdbook -u https://git.ourworld.tf/tfgrid/info_tfgrid/src/branch/main/heroscript/tech
|
||||
rsync -rv ~/hero/www/info/tech/ root@info.ourworld.tf:/root/hero/www/info/tech/
|
||||
Loading…
Reference in New Issue
Block a user