^Up^
█║ S Y N C H R O K N O T ║█






Virtual System On Chip Software


Decentralized Cloud, IoT And Data Center [Data Decenter] In Minutes.

<<^>> Beyond Light Years.


█║▌║ vSoC supports Astra Linux Common Edition OREL with or without Fly graphical interface to be installed as its base operating system. █║▌║ vSoC supports Astra Linux Special Edition SMOLENSK For Confidential & Top Secret Information Protection. ■ Available at: astralinux.ru █║▌║ vSoC supports Debian 10. █ vSoC works transparently with the kernel[s] and packages that come with the supported operating systems.
▌ Note: Multiple distributions are not supported due to a large over-head in tracking different packages, versions, libraries and most importantly security features and updates. ▌ Other distributions may be supported depending on the demand and feasibility. █║▌║ vSoC also works with SynchroKnot-provided vSoC Kernels with built-in Satellite Tree Switch and kernel modules: ■ 5.10.8-synchroknot-vsoc-satellite-tree-switch with SLTS Civil Infrastructure Project [CIP] Kernel. ■ 4.9.0-synchroknot-vsoc-satellite-tree-switch Kernel. **This document is a work-in-progress and may contain errors. Content can be added/modified anytime.** *Basic knowledge of BTRFS [B-Tree Filesystem] and its diagnostics is required. *Please read and understand the SynchroKnot License under the "About" section of the SynchroKnot official website. *SynchroKnot vSoC License[s] are unavailable and invalid for use in the Blacklisted Regions. Please read the "Permanant Blacklist" under the "About" section of the SynchroKnot official website. *Take your time to understand for a fun learning curve. Good Luck! and ^Zip+++Up^ your Spacesuits!!*

║█║ Index of Shortcuts:

║█║ IMPORTANT REQUIREMENTS FOR PERFORMANCE AND SCALABILITY ║█║ SynchroKnot Certified SoCs From Authorized Manufacturer ║█║ vSoC IP Addressing ║█║ Operating System & Package Installation ║█║ Spatial Fabric Satellite - 1-Step Auto Setup & Deployment ║█║ Spatial Fabric Array ║█║ Spatial Cluster ║█║ Microcosm, Macrocosm, Intercosm ║█║ Network Transport Types, Reliable Response, D-Mask and Mask ║█║ Excerpts ║█║ Shoutout ║█║ Reachout : Power Module ║█║ Distance Vector ║█║ Inbound & Outbound Traffic Overview To & From Spatial Fabric Satellites to help set up & configure your own switch/router ║█║ Gateway for Customer / Tenant Inbound and Outbound Traffic to and from the Spatial Fabric Satellite(s) ║█║ Provider VPN : Layer 2 Peer-to-Peer VPN ║█║ Spatial Fabric Satellite Interconnection Across Multiple Sites By The Infrastructure Provider ║█║ Spaceway : Power Module ║█║ Spatial Fabric Traverser with Intersecter : Power Module
║█║ Infrastructure Engine ║█║ Authentication Calibration : Built-in Authentication Security Feature ║█║ Spacesuit ║█║ Spatial Virtual Machine ║█║ Disperser ║█║ Synchroknot [User] ║█║ Synchroknot Decentralized Access Control Identification - SDAC and VM-SDAC ║█║ Spatial Fabric Array Information, List and Realtime Log ║█║ Stagnant Virtual Machine ║█║ Zombie Virtual Machine ║█║ Relocate Virtual Machine ║█║║║ Modify Virtual Machine ║█║║║ Network Operations ║█║ SpaceBuoy ║█║ DHCPCAST ║█║ Flood Control ║║█║║║ Storage Operations ║█║ Storage Datapath Access ║█║║║ Spatial Fabric Satellite : Deployment Options ║█║║║ High Performance Switching with SATELLITE TREE PROTOCOL ║█║ [new] FASTR - Fast Asynchronous Triggered Replication, Recovery & Disaster Recovery : Power Module ║█║ [new] Reliable Realtime Cache : Power Module ║█║ [new] Realtime Cache : Power Module ║█║ [new] Synchrosync : Power Module ║█║ [new] Interstellar : Power Module ║█║ [new] ARPLESS Interstellar : Power Module ║█║ [new] Level 2 Security With LDAP, ACTIVE DIRECTORY AND SSH : Power Module ║█║ [new] AuthControl - Distributed Fault-Tolerant Authentication Management & Identification Control System : Power Module ║█║ [new] Blockchain SSH - Public Key Infrastructure [ PKI ] Management : Power Module ║█║║║ SynchroKnot Auto NAT Enablement
║█║ IMPORTANT REQUIREMENTS FOR PERFORMANCE AND SCALABILITY:
■ ONLY use LOCAL DRIVES. ***DO NOT*** import block devices via iSCSI, SAN, NAS, Distributed block/file storage or other methods. ■ DO NOT use USB drives. ■ DO NOT run SynchroKnot vSoC in virtual machines. ■ Confirm the workability and testing of the network, for example, checking if your Ethernet NICs [drivers and cabling] are set up and working individually and also when connected in ring or torus topology. Verify if VLANs [single, double and triple stacks] work when set up [ie 802.1ad+802.1q+802.1q]. This is a requirement every time an operating system is updated/upgraded. ■ Be sure to follow only the QEMU-KVM manual [not libvirt] for syntaxes/options regarding the virtual machine. Wrong options and/or syntaxes may not start/function the virtual machine as expected. When in doubt start a virtual machine using the QEMU-KVM syntax/option[s] from the commandline and then incorporate them into the Spacesuit of the virtual machine using the trigger vm-modify. Be aware that all QEMU-KVM options may not be supported/available in consideration for Tenant security, stability, scalability and complexity. ■ Assigning physical hardware like Ethernet NICs, GPUs, USB etc to the virtual machines is not supported due to complexity, security, driver instability and related issues. ■ As a security best practice, please *DO NOT* directly attach/connect the hardware SoC to wireless devices/chipsets [Eg. WiFi, Bluetooth, 4G, 5G etc]. ■ If USB Ethernet adapters are used for testing or for whatever reason, then Linksys 3.0 Gigabit Ethernet Adapter [Model No. USB3GIGV1] is known to work [Eg. It does not have to be unplugged and plugged back in while testing the bringing down and up ethernet interfaces].

║█║ SynchroKnot Certified SoCs From Authorized Manufacturer

SynchroKnot vSoC License[s] are authorized to work only on SynchroKnot Certified SoCs from a SynchroKnot Authorized Manufacturer. SynchroKnot Authorized Manufacturer: ASRock Industrial Computer Corp. 7F., No.9, Ln. 79, Ligong St., Beitou Dist., Taipei City 112, Taiwan (R.O.C) +886-2-5588-2688 +886-2-2858-1369 Info_ipc@asrockind.com www.asrockind.com SynchroKnot Certified SoCs based on AMD CPUs from ASRock Industrial Computer Corp.: 4000 Series - Up To 16 Threads V2000 Series - Up To 16 Threads V1000 Series - Up To 8 Threads R1000 Series - Up To 4 Threads

║█║ vSoC IP Addressing

█ Spatial Fabric Satellite Internal IP Address : 28.0.0.0/7
28.0.0.0/7 is only for use by Spatial Fabric Satellites.
█ Spatial Fabric Satellite External Access IP Address : 10.0.0.0/7
IP addresses in the 10.0.0.0/7 are used for access by the Tenant machines via a VPN [Tenant VPN] of the Provider or internally.
█ Spatial Fabric Satellite Auto-Generated IP Address Range : 29.x.x.x
29.x.x.x is used for Auto-Generated IP Addresses. Please *DO NOT* manually assign an IP address in the 29.x.x.x range to Spatial Fabric Satellites.
█ Spatial Fabric Satellite Provider-Assigned IP Address Range : 28.x.x.x
28.x.x.x is a Provider-Assigned IP Address Range where the Provider can assign an IP address to Spatial Fabric Satellites. After reserving a portion of the 28.x.x.x range for Tenant access [see below], the rest could be assigned while keeping in mind the region/location of the Spatial Fabric Satellites. This will prove helpful when using the multifarious search capability of the Infrastructure Engine along with Microcosm, Macrocosm and Intercosm.
█ Tenant Access IP Address Range : 10.x.x.x
The Provider *MUST* reserve a portion of the 28.x.x.x range for Tenant access via a VPN [Tenant VPN] or internally. The Provider may choose a suitable IP address range to be reserved for the Tenants. Example of IP address range reservation for Tenant access via a Tenant VPN of the Provider: If the Provider chooses to reserve 28.0.0.0 to 28.10.255.255 for the Tenants, its corresponding mapping translates to 10.0.0.0 to 10.10.255.255. Therefore 10.0.0.0 to 10.10.255.255 can be reserved for Tenants, and the 28.0.0.0 to 28.10.255.255 MUST NOT be assigned to the Spatial Fabric Satellites. 28.11.0.0 and above could be used for manual Provider-Assigned IP Addresses for Spatial Fabric Satellites. For example, Tenant A could be assigned the range 10.1.1.255, Tenant B could be assigned the range 10.2.255.255 and so on. Here, assigning the range 10.1.1.255 to Tenant A means that only the traffic from Tenant A's machine[s] with the usable host Source IP range 10.1.1.1 to 10.1.1.254 [and destination IP in 10.0.0.0/7 range] will be allowed. The Service Provider will block all other traffic. Simple as that! Tenant A's machine[s] can either be assigned static IP address OR can receive an IP address via DHCP from the Tenant VPN of the Provider when a connection is made to it. █ *** IMPORTANT *** : To be able to access all the Spatial Fabric Satellites, Tenant Machine IP Address ***MUST*** be in the 10.0.0.0/7 range, that is, they must have a broadcast 11.255.255.255 and netmask 254.0.0.0. From the above example, if Tenant A was assigned the range 10.1.1.255, then the Tenant A's machine could be given an IP address with the command "ifconfig eth0 10.1.1.10/7" which will give it an IP address 10.1.1.10 netmask 254.0.0.0 broadcast 11.255.255.255. Even though Tenant A's machine has a 10.1.1.10/7 IP address, the Tenant VPN of the Provider will only allow traffic from Tenant Access IP Address Range assigned to Tenant A! █ In addition to the simple and straight-forward method described above, the Tenants can be given IP addresses starting with 192.168, 172.16 etc., and then be routed or 1-to-1 NATed. However, this will increase the complexity of the setup, and therefore, should be avoided. █ General Details of the 28.0.0.0/7 network: IP Address: 28.0.0.0 Network Address: 28.0.0.0 CIDR Notation: /7 Usable Host IP Range: 28.0.0.1 - 29.255.255.254 Broadcast Address: 29.255.255.255 Total Number of Hosts: 33,554,432 Number of Usable Hosts: 33,554,430 Subnet Mask: 254.0.0.0

║█║ Operating System & Package Installation:

█║▌║ Astra Linux Common Edition OREL with or without Fly graphical interface. █║▌║ Astra Linux Special Edition SMOLENSK For Confidential & Top Secret Information Protection. ■ Available at: astralinux.ru █║▌║ Debian 10 █ BTRFS [B-Tree Filesystem].
█ STEP 1:Install the operating system with a unique hostname starting with spatial-fabric-satellite[number]. Eg. spatial-fabric-satellite1 and a username other than "sknt"Fully disable all firewalls. Modify and enable them later as need be. Please set a temporary IP address with "ifconfig" or "ip" command. Please do not hard-code a static IP address at the time of installation or in "/etc/network/interfaces". SynchroKnot vSoC will automatically assign a unique IP address, which can be later modified if needed. █ STEP 2: ■ As required, you can choose to lock the kernel so that it does not get updated/replaced by another version. Note: This step is *NOT* a requirement for vSoC Example with "dpkg --set-selections": for i in $(dpkg -l "*$(uname -r)*" | grep kernel | awk '{print $2}') ; do echo $i hold | dpkg --set-selections; done Example with "apt-mark": for i in $(dpkg -l "*$(uname -r)*" | grep kernel | awk '{print $2}') ; do apt-mark hold $i ; done In addition to the above, with the graphical desktop, when clicked on "software & updates", under the "Updates" section, select "Never" for "Automatically check for updates:" █ STEP 3: BTRFS ■ Do an "apt-get update" from commandline [avoid using update-manager in graphical desktop]. ■ Install BTRFS tools: [btrfs-progs btrfs-tools] apt-get install btrfs-tools modprobe btrfs ■ Create a BTRFS volume with the name "tier0": Example: mkdir /root/btrfs truncate -s {size} /root/btrfs/btrfs0 Eg. truncate -s 9000M /root/btrfs/btrfs0 mkfs.btrfs /root/btrfs/btrfs0 mount /root/btrfs/btrfs0 /tier0 OR mkfs.btrfs [path to your partition or disk eg. /dev/sdx etc] mount [path to your partition or disk eg. /dev/sdx etc] /tier0 To mount using lzo compression do: mount -o compress=lzo [path to your partition or disk eg. /dev/sdx etc] /tier0 Check BTRFS filesystem usage: btrfs filesystem usage /tier0 ***IMPORTANT: Add an entry in "/etc/fstab" for btrfs to mount "/tier0", or else, vSoC will not auto invoke on boot.*** Example of an entry in "/etc/fstab": ## file system mount point type options dump pass [path to your partition or disk eg. /dev/sdx etc] /tier0 btrfs defaults 0 0 /dev/sdX /tier0 btrfs defaults 0 0 OR UUID=18e676b8-a44d-ee4f-85e6-096545f4a7d2 /tier0 btrfs defaults 0 0 To get UUID do: lsblk --fs {path to your partition or disk} ***To further increase the performance substantially, mount BTRFS with the "noatime" option:*** /dev/sdX /tier0 btrfs rw,noatime,ssd,space_cache,subvolid=5,subvol=/ 0 0 To get the default mount options do: mount | grep btrfs Example output: /dev/sdX on /tier0 type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/) Replace "relatime" with "noatime". █ STEP 4: ■ Install the necessary packages required for vSoC: apt-get -y install numactl bridge-utils apache2 qemu-kvm ebtables ethtool iptables inotify-tools curl tcpdump dnsmasq lsof nodejs net-tools rsync openssh-server *** IMPORTANT: Only proceed to the next step if all packages have been successfully installed *** ■ Install the packages required to build your own kernel [no harm in downloading them]. build-essential bison flex gnupg libncurses-dev libelf-dev libssl-dev wget
║█║ Install Driver For RealTek RTL8125 2.5 Gigabit Ethernet Controller:
■ Please install the RealTek RTL8125 2.5 Gigabit Ethernet controllers available at the RealTek official website. ■ Confirm that the driver loads as shown in the README file. r8125.ko must be present in: /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/realtek/r8125.ko In some situations, if r8125.ko is not present at the location shown above, compile the driver for the current $(uname -r); then: 1] create a directory: /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/realtek 2] Copy r8125.ko into it. 3] After that, *Make Sure* you do a "depmod" and reboot the SoC to check if it has loaded the driver [eg. lsmod | grep r8125].

║█║ Spatial Fabric Satellite - 1-Step Deployment:

█ IMPORTANT ■ Always log in / log out as user "sknt" with SSH AND/OR Graphical Desktop Login, and then become a root user with command "sudo su" OR "sudo bash". ■ It is a requirement that "sudo" be used to perform all SynchroKnot commandline operations. ■ It is advised to change directory to SynchroKnot [i.e cd /home/sknt/SynchroKnot], and then use spatial-cluster-ctl.sknt and spatial-fabric-satellite-ctl.sknt as all clean up operations are automatically performed in /home/sknt/SynchroKnot ■ BTRFS tier0 volume *MUST* always be up [online] and mounted at /tier0 before proceeding with any SynchroKnot operation. tier0 must have enough free space and the quota of the spatial cluster[s] must be large enough to accomodate new and existing virtual machine disks. ■ All the Ethernet Ports must have their drivers loaded and *MUST* be up. Please confirm by checking "/sys/class/net/". If all the Ethernet Ports are not up, then when modifying the Spatial Fabric Satellite in the future, with the auto option[s], when a new Ethernet NIC is discovered and chosen by the built-in software algorithm, it will result in a changed IP address! It is best to avoid using a USB adapter for the setup phase.
█ Install SynchroKnot vSoC Base - One-Time Setup
█ First Step:
Make sure that all the above mentioned required packages are installed and tier0 is online Create a directory synchroknot-latest in /root mkdir /root/synchroknot-latest
█ Second Step:
▌ Place the "SynchroKnot-vSoC-1.0-Binary.tgz", "synchroKnot.license" and "synchroKnot.license.sign" [and other *.power-module.license | *.power-module.license.sign files if any] in "/root/synchroknot-latest" ▌ Decompress satellite-tree-switch-x86_64.tgz" using "tar xzf" & place it in "/root/synchroknot-latest" Note: "satellite-tree-switch-x86_64.tgz" can also be manually decompressed using "tar xzf" & placed it in "/tier0/satellite-tree-switch" after the completion of the "Third Step" below. *** IMPORTANT *** : The same "synchroknot.license" and "synchroknot.license.sign" *MUST NOT* be present on other Spatial Fabric Satellites.
█ Third Step:
Then, as the root user do : cd /root/synchroknot-latest && tar xzpf SynchroKnot-vSoC-1.0-Binary.tgz && chmod 755 SynchroKnot-vSoC-1.0-Base.sknt && ./SynchroKnot-vSoC-1.0-Base.sknt For the user convenience, in addition to setting up the SynchroKnot Base, the Spatial Fabric Satellite setup will also be automated. ■ The Spatial Fabric Satellite will be auto-set up with a unique IP address algorithmically-derived from the hardware MAC address of the network interface card. ■ A new user "sknt" with the password "sknt" will be created with sudo privileges. Use the username "sknt" with password "sknt" to log in via SSH and change the password upon login. Note: If the installation, for whatever reason, does not succeed; simply remove all the contents of tier0 with "btrfs subvolume delete"; fix the issue [eg. install missing package etc]; and again go through steps 1], 2], and 3] mentioned above! Example output: root@spatial-fabric-satellite0:~/synchroknot-latest# ls satellite-tree-switch-x86_64 synchroknot.license synchroknot.license.sign SynchroKnot-vSoC-1.0-Binary.tgz root@spatial-fabric-satellite0:~/synchroknot-latest# cd /root/synchroknot-latest && tar xzpf SynchroKnot-vSoC-1.0-Binary.tgz && chmod 755 SynchroKnot-vSoC-1.0-Base.sknt && ./SynchroKnot-vSoC-1.0-Base.sknt SynchroKnot : INFO : Installing SynchroKnot vSoC Base ... SynchroKnot : Success : SynchroKnot vSoC Base Is Set Up & Ready! SynchroKnot : INFO : Starting Spatial Fabric Satellite Auto Setup SynchroKnot : SUCCESS : Spatial Fabric Satellite Is Now Set Up & Ready To Be Invoked. Spatial Fabric Satellite Internal IP Address : 29.31.69.4 Spatial Fabric Satellite External Access IP Address : 11.31.69.4 Ethernet Ports : enp1s0 enp2s0f0 MAC Address To IP : a8:a1:59:4a:a3:ai SynchroKnot : 1] Please Make A Note Of The Auto-Generated IP Address Above. SynchroKnot : 2] Reboot This Spatial Fabric Satellite. SynchroKnot : 3] SSH To The "External Access IP Address" As User "sknt" With Password "sknt" And Change The Password Upon Login. SynchroKnot : 4] Use The Command "sudo su" OR "sudo bash" To Become A Root User. *This Is A Requirement For Operating vSoC* SynchroKnot : 5] Change Directory To SynchroKnot [cd SynchroKnot]. SynchroKnot : 6] Create A Spatial Cluster With "spatial-cluster-ctl.sknt"!
█ Auto-Create A Spatial Cluster [after rebooting the Spatial Fabric Satellite].
Contents of /home/sknt/SynchroKnot: │ ├── spatial-cluster-ctl.sknt ├── spatial-fabric-satellite-ctl.sknt
█ First Step:
Assign an IP address to the system from where you are going to SSH into the Spatial Fabric Satellite in the 10.0.0.0/7 network range. Eg: ifconfig eth0 10.9.0.10/7 SSH to the External Access IP Address : 11.31.69.4 with user "sknt" and password "sknt" ssh sknt@11.31.69.4 Change your password upon login.
█ Second Step:
sudo su OR sudo bash cd SynchroKnot
█ Third Step:
Check the Spatial Fabric Satellite status: ./spatial-fabric-satellite-ctl.sknt <<< "trigger:status" OR echo "trigger:status" | ./spatial-fabric-satellite-ctl.sknt Create a Spatial Cluster: ./spatial-cluster-ctl.sknt <<< "synchroknot:auto interstellar:1000 cpu:0,1,2,3 quota:6G trigger:spatial-cluster-create" Note: modify the values of the keys "interstellar:", "cpu:", "quota:" as needed. Quota must be numbers in gigabytes ending with "G" or "g". Example output of "trigger:spatial-cluster-create": root@spatial-fabric-satellite0:/home/sknt/SynchroKnot# ./spatial-cluster-ctl.sknt <<< "synchroknot:auto interstellar:1000 cpu:0,1,2,3 quota:6G trigger:spatial-cluster-create" SynchroKnot : INFO : Auto-Generated Spatial Cluster Blockchain ID : 1PmL67W6MfGA5fJVeBm2Qaz2umJ8FMFyF5 SynchroKnot : INFO : Auto-Generated Spatial Cluster Blockchain Private Key : KyQhiY324QrbMxu5gCjXzLXfkmJBq5NBR5g13u4Mw23tFdbnkrpZ SynchroKnot : INFO : Please Save The Above Details Or Else It Will Not Be Possible to Log In To the Spatial Cluster SynchroKnot : INFO : The Blockchain ID And Blockchain Private Key Are Available In The Directory: SynchroKnot : INFO : "/tier0/spatial-cluster/1PmL67W6MfGA5fJVeBm2Qaz2umJ8FMFyF5/blockchain-key". Please Don't Keep Them Lingering! SynchroKnot : INFO : Remember To Use The Same Interstellar: 1000 When Creating Spatial Cluster: 1PmL67W6MfGA5fJVeBm2Qaz2umJ8FMFyF5 On SynchroKnot : INFO : Another Spatial Fabric Satellite Or Network Connectivity Will Fail. SynchroKnot : INFO : Creating Spatial Cluster : 1PmL67W6MfGA5fJVeBm2Qaz2umJ8FMFyF5 SynchroKnot : SUCCESS : Spatial Cluster 1PmL67W6MfGA5fJVeBm2Qaz2umJ8FMFyF5 Created And Auto Start On Boot Enabled.
█ Start The Spatial Cluster
Start the Spatial Cluster 1PmL67W6MfGA5fJVeBm2Qaz2umJ8FMFyF5 that was just created. Example output of trigger:spatial-cluster-start: root@spatial-fabric-satellite0:/home/sknt/SynchroKnot# ./spatial-cluster-ctl.sknt <<< "synchroknot:1PmL67W6MfGA5fJVeBm2Qaz2umJ8FMFyF5 trigger:spatial-cluster-start" SynchroKnot : INFO : Starting Spatial Cluster : 1PmL67W6MfGA5fJVeBm2Qaz2umJ8FMFyF5 SynchroKnot : SUCCESS : Spatial Cluster 1PmL67W6MfGA5fJVeBm2Qaz2umJ8FMFyF5 Invoked.
█ Access And Operate The Spatial Cluster With SynchroKnot Infrastructure Engine.
The Infrastructure Engine can be accessed by all Tenants in the 10.0.0.0/7 range corresponding to the 28.0.0.0/7 range IP address given to the Spatial Fabric Satellite. Please read the Infrastructure Engine Section for more details. Access the Spatial Fabric Satellite "External Access IP Address : 11.31.69.4" in the web browser: https://11.31.69.4/SynchroKnot.sknt Since this is the first login, you will be taken to SynchroKnot Decentralized Blockchain Identity Management for authentication and authorization. To log into the SynchroKnot Infrastructure Engine with the above example auto-generated Spatial Cluster Blockchain ID and Spatial Cluster Blockchain Private Key : ■ Use the Bitcoin Address 1PmL67W6MfGA5fJVeBm2Qaz2umJ8FMFyF5 as SynchroKnot Identity. ■ Use the Bitcoin Address 1PmL67W6MfGA5fJVeBm2Qaz2umJ8FMFyF5 as Spatial Cluster Identity. ■ Use the Bitcoin Private Key KyQhiY324QrbMxu5gCjXzLXfkmJBq5NBR5g13u4Mw23tFdbnkrpZ as Blockchain Private Key. Note: If you see a message depicted below in Realtime Log [or in /tier0/spatial-cluster/[Spatial Cluster ID]/log/synchroknot/synchroknot.log], it is likely that the license is not placed appropriately or a copy of the license is detected across Spatial Fabric Satellites. All SynchroKnot management operations will be halted. The remedy is to have the license in place with the correct permissions [chown www-data:www-data *.license* && chmod 400 *.license*] : ..... 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z @ 28.9.0.1 : Illegal License Detected - Taking Precautionary Measures - All Timers Will Be Out Of Sync! : Remove All Illegal Licenses. [Please read more details under the Spatial Cluster section below.] Example of contents in /home/sknt/Synchroknot │ ├── spatial-cluster-ctl.sknt ├── spatial-fabric-satellite-ctl.sknt Example of contents in /tier0/synchroknot/www │ ├── css/ ├── js/ ├── SynchroKnot-Datadecenter-Fabric.sknt ├── SynchroKnot-Identify.sknt ├── synchroknot-modules/ ├── SynchroKnot.sknt ├── tightvnc-jviewer.jar ├── webview.sknt Example of contents in /tier0/synchroknot/www/synchroknot-modules │ ├── disperser-enable.sknt ├── space-debris.sknt ├── synchroknot.license ├── vm-create.sknt ├── vm-delete.sknt ├── vm-modify.sknt ├── vm-relocate.sknt ├── vm-start.sknt ├── synchroknot.license *** Note: The size of largest file is only about 400K! *** *** Simply replace the files to update to a newer version of SynchroKnot without disrupting/stopping any Spatial Cluster[s], Virtual Machines, Remote Consoles, Storage Data Transfers and other aspects! ***
█ Modify Spatial Fabric Satellite
■ To modify, do a reboot of the Spatial Fabric Satellite. ■ You can modify the IP address and network ports with "trigger:setup". ■ Remember to use the IP addresses in the 28.x.x.x network range when manually assigning Spatial Fabric Satellites with IP addresses. ■ Use the key "ip:" to modify the IP address and the key "ports:" to modify the Ethernet NIC ports. ■ The key "ip:" will have a value in the 28.x.x.x network OR auto. ■ The key "ports:" will need the network ports separated with a comma OR have the value "auto". ■ The SynchroKnot Infrastructure Engine Web Interface access will always be in the 10.0.0.0/7 network corresponding to the IP set in the 28.0.0.0/7 network. ■ Once the Spatial Fabric Satellite is modified, reboot the Spatial Fabric Satellite for the changes to activate. *** IMPORTANT *** : All the Ethernet Ports must have their drivers loaded and *MUST* be up. Before modifying the Spatial Fabric Satellite, please confirm by checking "/sys/class/net/" If new Ethernet NICs OR USB Ethernet adapters are added and "auto" is used as value[s] for the keys "ip:auto ports:auto", then the built-in software algorithm might discover and choose the new NIC, resulting in a changed IP address! If you would like to keep the previous IP address you have the following options: 1] Remove the USB OR Ethernet NIC and then use the keys "ip:auto ports:auto" 2] Manually set the previous IP address that was auto-assigned in the 29.x.x.x range with the key IP. 3] Give the Spatial Fabric Satellite a manual IP address in the 28.x.x.x range. Examples of modification with the "trigger:setup" of spatial-fabric-satellite-ctl.sknt: ./spatial-fabric-satellite-ctl.sknt <<< "trigger:setup ip:28.90.0.1 ports:enp1s0,enp2s0f0,enp2s0" OR ./spatial-fabric-satellite-ctl.sknt <<< "trigger:setup ip:28.90.0.1 ports:auto" OR ./spatial-fabric-satellite-ctl.sknt <<< "trigger:setup ip:auto ports:auto" Note: trigger:setup-rt will be released shortly which will allow the non-disruptive modification even if the spatial clusters are active!
█ Invoke Spatial Fabric Satellite - ONLY NEEDED IF AUTO INVOKE ON BOOT IS DISABLED
█ IMPORTANT : Manually invoking Spatial Fabric Satellite is not needed with vSoC 1.0 and above, as it is auto-invoked on boot. █ Invoke log is available at: "/tier0/spatial-fabric-satellite/log/invoke.log" which is overwritten everytime a Spatial Fabric Satellite is restarted. █ To disable auto invoke on boot, uncomment "### exit 0" under "####### DISABLE AUTO INVOKE ON BOOT HERE: #######" in "/etc/init.d/synchroknot-vSoC" █ Please ***DO NOT*** invoke the Spatial Fabric Satellite it if it is already invoked. Always check the status: ./spatial-fabric-satellite-ctl.sknt <<< "trigger:status" echo "trigger:invoke" | /home/sknt/SynchroKnot/spatial-fabric-satellite-ctl.sknt Example output: echo "trigger:invoke" | /home/sknt/SynchroKnot/spatial-fabric-satellite-ctl.sknt SynchroKnot : Invoking ... Inserting Satellite Tree Protocol Module : Success Enabling Satellite Tree Protocol : Success Starting Blockchain Gateway : Success Starting Webserver : Success Starting Storage Datapath Access Root : Success Starting SynchroKnot Gateway : Success Starting SynchroKnot Secure Gateway : Success Starting Transmigrate for Spatial Fabric Array : Success Starting Transmigrate for Spatial Fabric Satellite : Success SynchroKnot : Success : Done and Invoked.
║█║ Spatial Fabric Satellite : Help And Other Advanced Options
1] trigger:help echo "trigger:help" | /home/sknt/SynchroKnot/spatial-fabric-satellite-ctl.sknt Example output: █║▌║▌║ <<^>> SynchroKnot License ID : 19vy4inWdEfavwtPWb68GPp7WDihEwJ1Fr │ ├──█║▌ Organization ID : 1Gqb8EPWVCmyKqMJKeso6kFRn1ptsmU2LZ │ ├──█║▌ Organization : example-corp │ ├──█║▌ Country : example-country │ ├──█║▌ Authorized CPUs : 16 │ ├──█║▌ Expiration Date : Sat-Nov-28-17:05:47-CET-2021 │ ├──█║▌ Version : 1.0 │ ├──█║▌ Power Module[s] : arpless-interstellar, authcontrol, blockchain-ssh, fastr, interstellar, level2-security, reachout, realtime-cache, reliable-realtime-cache, synchrosync │ └──█║▌ trigger:help|invoke|performance|status|service-restart|enable-network-ports|setup|complete-service-stop ▌ trigger:[enable|disable]-reimage|[disable|enable]-satellite-tree-switch 2] trigger:status Show the current Spatial Fabric Satellite status. ./spatial-fabric-satellite-ctl.sknt <<< "trigger:status" OR /etc/init.d/synchroknot-vSoC status Example output: Spatial Fabric Satellite IP : 29.11.82.15 SynchroKnot vSoC Auto Start : Enabled Auto MAC Address To IP : a8a159318dde SynchroKnot Secure Gateway : ACTIVE + FailSafe on 127.0.0.1:443 SynchroKnot Gateway : ACTIVE + FailSafe on 127.0.0.1:80 SFA Transmigrate : ACTIVE + FailSafe SFS Transmigrate : ACTIVE + FailSafe SFS Storage Data Path : ACTIVE Blockchain Gateway : ACTIVE + FailSafe Active Ethernet Ports : eth0 eth1 Setup Ethernet Ports : eth0 eth1 Satellite Tree Switch : Enabled Satellite Tree Switch Status : ACTIVE Satellite Tree Switch Reimage : Disabled Tier0 Usage: Overall: Device size: 50.00GiB Device allocated: 4.24GiB Device unallocated: xxx.xxMiB Device missing: 0.00B Used: xxx.xxMiB Free (estimated): xxx.xxMiB (min: xxx.xxMiB) Data ratio: 1.00 Metadata ratio: 2.00 Global reserve: x.xxMiB (used: 0.00B) 3] trigger:enable-network-ports Enables and reinstates all the physical network ports [starting with eth and en] that are assigned to the Spatial Fabric Satellite. [With certain USB Ethernet adapters the network port[s] could go offline when the machine goes into or wakes up from sleep/hibernate mode or when the network interface is manually brought down.] 4] trigger:service-restart Restarts any service that is found inactive. Eg. the Blockchain Gateway is sometimes known to go offline after a system wakes up from hibernate/sleep. 5] trigger:performance Automatically optimizes the Spatial Fabric Satellite for high-performance. 6] trigger:complete-service-stop Completely stops Synchroknot vSoC services and other components running on the Spatial Fabric Satellite. It is automatically invoked from /etc/init.d/synchroknot-auto-start-stop when a system is in the process of being shutdown or rebooted. Only use this manually if you are going to shutdown or reboot the Spatial Fabric Satellite. 7] trigger:[enable|disable]-reimage This trigger enables and disables the reimaging of Satellite Tree Switch. Reimaging is needed when the Satellite Tree Switch is either updated with software and updates or its older image is replaced with complete new image. The Satellite Tree Switch image that can be replaced with a newer image or the existing updated is present in "/tier0/satellite-tree-switch" When the "trigger:enable-reimage" is used then the Satellite Tree Switch will be automatically reimaged on the next boot of the Spatial Fabric Satellite. The "Reimage-Status" will show as "ACTIVE". To disable reimaging of Satellite Tree Switch, use "trigger:disable-reimage". The "Reimage Status" should then show as "INACTIVE". Note: The Satellite Tree Switch will only be "ACTIVE" if a vSoC-enabled kernel with built-in Satellite Tree Switch is not detected. Satellite Tree Switch will fail to activate if the image is corrupted or there is not enough memory [1 GB required]. 8] trigger:[disable|enable]-satellite-tree-switch To disable Satellite Tree Switch on the next boot use "trigger:disable-satellite-tree-switch". To enable Satellite Tree Switch on the next boot use if it is disabled, use trigger:enable-satellite-tree-switch"
║█║ Spatial Fabric Array :
Bifurcated CPU and Memory resources given to a Customer / Tenant on a particular Spatial Fabric Satellite. The Spatial Fabric Array inherits the IP address of the underlying Spatial Fabric Satellite, and a unique port number is automatically computed from the Blockchain ID of the Tenant. The same port number is automatically computed for the Tenant with the same Blockchain ID across all Spatial Fabric Satellites [locally or globally]. This distinct feature allows the internal control and management traffic [unicast/broadcast/multicast] of the Tenant to be bifurcated and directed to only the Spatial Fabric Satellite(s) where the Tenant Spatial Cluster exists, and *NOT* to all Spatial Fabric Satellite(s) as one large unicast/broadcast/multicast domain for all the Tenants. *Important: When the key and value sfa:[IP address] is used together with any trigger, then ONLY the Spatial Fabric Array with that IP address hears the trigger.*

║█║ Spatial Cluster :

Customer / Tenant setup, modification, network bifurcation and interconnection of Spatial Fabric Arrays across different Spatial Fabric Satellites.
█ Spatial Cluster Create :
Create a Spatial Cluster for the Tenant on single or multiple Spatial Fabric Satellites locally or globally dispersed. The Tenant can access the SynchroKnot Infrastructure Engine Web Interface on any Spatial Fabric Satellite where the Spatial Cluster was created and manage any Spatial Fabric Array with the right credentials. ■ The Tenant gives the Infrastructure Provider their Blockchain ID [i.e Bitcoin Address] and a message signed with their Private Key. The Infrastructure Provider can request the Tenant to sign a specific message to validate authenticity. ■ The Infrastructure Provider verifies the signed message. Successful verification proves the Tenant is the owner of the Private Key and the Infrastructure Provider can go ahead and create the Spatial Cluster. ■ For example, the Tenant can sign a message using bitcoin-cli or bitcoin-qt [GUI] with the command "signmessagewithprivkey", and the Infrastructure Provider can verify it with the command "verifymessage" █ IMPORTANT: ■ Only Bitcoin Address Type Legacy [i.e an address starting with 1] is supported. ■ It is recommended that a Bitcoin Address is generated/verified using the official Bitcoin Core software [available at https://bitcoincore.org]. ■ If the option synchroknot:auto is used then the Spatial Cluster Blockchain ID and Private Key will be auto generated, displayed and placed in: /tier0/spatial-cluster/[Spatial Cluster ID]/blockchain-key/[Spatial Cluster ID]-blockchain-keys The synchroknot:auto option is useful if you need to create a new Spatial Cluster Blockchain ID and Private Key for a Spatial Cluster, and then reuse it to create Spatial Cluster[s] on other Spatial Fabric Satellites as needed. Example of creating a Spatial Cluster with trigger spatial-cluster-create: echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z interstellar:1000 cpu:0,1,2,3 quota:2G trigger:spatial-cluster-create" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt OR with "auto" option: echo "synchroknot:auto interstellar:1000 cpu:0,1,2,3 quota:2G trigger:spatial-cluster-create" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt ■ synchroknot:[Legacy Bitcoin Address of the Customer / Tenant] OR auto ■ interstellar:[single OR double OR triple stacked VLAN. Example : 1000 | 1000.1000 | 1000.1000.1000] ■ cpu:[comma separated value of the CPU cores you would like the Customer / Tenant to have] ■ quota:[size in GB. Example : 500G] █ IMPORTANT: ■ It is a requirement that each Spatial Cluster created on Spatial Fabric Satellite[s] with a Bitcoin Address of the Tenant be given a unique interstellar [i.e single OR double OR triple stacked VLAN] per Infrastructure Provider site. In other words, each Tenant *MUST* have a unique VLAN. For example, at the Infrastructure Provider site A, there is a physical cluster of 16 Spatial Fabric Satellites. A Spatial Cluster with the Bitcoin Address 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z is requested to be created on 6 Spatial Fabric Satellites by the Tenant. Then, the Infrastructure Provider first assigns and associates a free interstellar [i.e VLAN 1000 from the example above] to the Tenant Spatial Cluster 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z on site A, and then creates the spatial cluster 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z using "trigger:spatial-cluster-create" across any of the 6 Spatial Fabric Satellites with the requested resources with the *SAME* interstellar 1000. For more information, please read Spatial Fabric Satellite Interconnection Across Multiple Sites By The Infrastructure Provider. █ It is *NOT* necessary to create the same Spatial Cluster on all Spatial Fabric Satellites. All the virtual machines in the spatial cluster will have transparent layer 2 connectivity! Example: If you have 10 Spatial Fabric Satellites, then you can create Spatial Cluster 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z as needed on all 1 to 10 OR 3 and 8 OR 2,3,6,8,9 etc. █ You have the flexibility to transparently expand and contract the spatial cluster as and when you need *WITHOUT* disrupting/interrupting the existing Spatial Clusters, virtual machines and services already present & running across all Spatial Fabric Satellites.
█ Spatial Cluster Start :
The BTRFS "tier0" volume must be up [online] and mounted at "/tier0" ***Important : As mentioned above, always login in as non-root user with SSH [remotely/locally], and then become root and perform the operations below.*** echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:spatial-cluster-start" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt Example output: echo "synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE trigger:spatial-cluster-start" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt SynchroKnot : Starting Spatial Cluster : 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE SynchroKnot : Success : Spatial Cluster 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE Invoked.
█ Spatial Cluster Modify :
trigger:spatial-cluster-modify piped to /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt with the options below : add-cpu:[physical cpu has to exist and within the allowed limit mentioned in the license] remove-cpu:[cpu number] quota:[must be numbers in gigabytes ending with "G" or "g". Eg: quota:128G ] *Important: spatial cluster has to be modified before being started to reflect the changes.*
█ Spatial Cluster Force Stop :
echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:spatial-cluster-force-stop" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt A complex attempt will be made to stop all aspects of the specific Spatial Cluster! Note: You will need the key and value am-i-sure:yes for trigger spatial-cluster-force-stop to work.
█ Spatial Cluster Blockchain Identification :
Find out how many spatial clusters exist on the Spatial Fabric Satellite echo "trigger:scid" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt Example output: echo "trigger:scid" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt Spatial Cluster Blockchain Identification ----------------------------------------- 18aMrKwYjRc9T6gMoiPgQS4ggSRZqtV3Au 19cTPsdaoYu8w47yC1hqYJrcBWSvF5eZVB 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z 1JsMy66EGn1Yzw9FS5ky2EnhyUHUVuNrDe 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE
█ Spatial Cluster Status :
Displays Realtime Active/Inactive Status Information [processes/daemons/ports]. echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:spatial-cluster-status" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt Example output: echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:spatial-cluster-status" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt Spatial Cluster : 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z Spatial Cluster Auto Start : Enabled Spatial Cluster ID : 12470 Available Storage Quota : 25G Storage Total Used : 285.74MB Spatial Cluster Network : ACTIVE Spatial Cluster Listener : ACTIVE + FailSafe on Port : 12470 Storage Data Path : ACTIVE on Port : 13339 Realtime Log : ACTIVE on Port : 21953 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: SynchroKnot Secure Gateway : ACTIVE + FailSafe on 127.0.0.1:443 SynchroKnot Gateway : ACTIVE + FailSafe on 127.0.0.1:80 SFA Transmigrate : ACTIVE + FailSafe SFS Transmigrate : ACTIVE + FailSafe SFS Storage Data Path : ACTIVE Blockchain Gateway : ACTIVE + FailSafe Tier0 Usage: Overall: Device size: 50.00GiB Device allocated: 4.24GiB Device unallocated: xxx.xxMiB Device missing: 0.00B Used: xxx.xxMiB Free (estimated): xxx.xxMiB (min: xxx.xxMiB) Data ratio: 1.00 Metadata ratio: 2.00 Global reserve: x.xxMiB (used: 0.00B)
█ Spatial Cluster Service Restart :
echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:spatial-cluster-service-restart" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt This will only restart SynchroKnot processes/services/daemons related to the specific Spatial Cluster without affecting virtual machines, disperser, power modules and other aspects. The SynchroKnot listening processes/services/daemons of the Spatial Cluster whose service is being restarted may be impaired [usually under a second] from hearing during the restart process. If a push/pull-based data transfer was initiated with Storage Datapath, then it might have to be reinitiated.
█ Spatial Cluster Remove :
echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:spatial-cluster-remove" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt Note: You will need the key and value am-i-sure:yes for trigger spatial-cluster-force-remove to work.
█ Spatial Cluster Auto Start Enable
Starts Spatial Cluster On Boot. echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:auto-start-enable" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt
█ Spatial Cluster Auto Start Disable
Disables Spatial Cluster Start On Boot. echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:auto-start-disable" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt
█ Spatial Cluster CPU Map : Displays CPU to Spatial Cluster Mapping
Displays the mapping betwwen the CPU cores on the system to the Spatial Cluster. echo "trigger:cpu-map" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt You will notice in the example below that only one or two cpu cores are dedicated to a Spatial Cluster. This was done only for testing purposes to check and push the limits. It should not be done in actual use case scenarios. You should dedicate 4 or more cores per Spatial Cluster depending on the number of virtual machines and their type of workload. Example output: echo "trigger:cpu-map" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt Total CPUs : 0 - 3 CPUs : Spatial Cluster ---- : --------------- CPU 0 : 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE CPU 1 : 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE CPU 2 : 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z CPU 3 : -
█ Spatial Cluster Interstellar Map : Displays Single/Double/Triple Stacked VLANS to Spatial Cluster Mapping
echo "trigger:interstellar-map" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt Example output: echo "trigger:interstellar-map" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt Spatial Cluster : Single/Double/Triple Stacked VLANs --------------- : ---------------------------------- 18aMrKwYjRc9T6gMoiPgQS4ggSRZqtV3Au : 1000 19cTPsdaoYu8w47yC1hqYJrcBWSvF5eZVB : 1000.1000 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z : 10.100.1000 1JsMy66EGn1Yzw9FS5ky2EnhyUHUVuNrDe : 1000.1000.1000 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE : 9
█ Spatial Cluster Test For Echo
/home/sknt/SynchroKnot/spatial-cluster-ctl.sknt <<< "trigger:spatial-cluster-test-for-echo d-vector: mask: synchroknot:[Spatial Cluster ID]" The output in the form of: {Hostname} : {IP address} : {number of CPUs} : {CPU Load Average} Example output: /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt <<< "trigger:spatial-cluster-test-for-echo d-vector: mask: synchroknot:1BuCrGhtLUn5BKaDi8FkgNuMN5nWXNYLdF" spatial-fabric-satellite3 : 29.13.17.14 : 0.00 0.00 0.00 1/284 31696 spatial-fabric-satellite2 : 29.18.83.11 : 0.00 0.00 0.00 1/365 2813 spatial-fabric-satellite4 : 29.15.10.111 : 0.00 0.00 0.00 1/286 30026 spatial-fabric-satellite1 : 29.21.48.9 : 0.00 0.01 0.00 1/396 7242 Note: "trigger:spatial-cluster-test-for-echo" currently does not support "d-mask:"
█ Spatial Cluster Help : Displays Information about License and Triggers
echo "trigger:help" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt Example output: echo "trigger:help" | /home/sknt/SynchroKnot/spatial-cluster-ctl.sknt █║▌║▌║ <<^>> SynchroKnot License ID : 19vy4inWdEfavwtPWb68GPp7WDihEwJ1Fr │ ├──█║▌ Organization ID : 1Gqb8EPWVCmyKqMJKeso6kFRn1ptsmU2LZ │ ├──█║▌ Organization : example-corp │ ├──█║▌ Country : example-country │ ├──█║▌ Authorized CPUs : 16 │ ├──█║▌ Expiration Date : Sat-Nov-28-17:05:47-CET-2021 │ ├──█║▌ Version : 1.0 │ ├──█║▌ Power Module[s] : arpless-interstellar, authcontrol, blockchain-ssh, fastr, interstellar, level2-security, reachout, realtime-cache, reliable-realtime-cache, synchrosync │ └──█║▌ trigger:[help|cpu-map|interstellar-map|scid|cpu-lock-map] ▌ trigger:[cpu-unlock|cpu-lock] synchroknot:[Spatial Cluster ID] ▌ trigger:spatial-cluster-[status | modify | start | service-restart | force-stop | remove | auto-start-enable | auto-start-disable] synchroknot:[Spatial Cluster ID] ▌ trigger:spatial-cluster-test-for-echo d-vector: mask: synchroknot:[Spatial Cluster ID] ▌ trigger:spatial-cluster-create interstellar: cpu: quota: synchroknot:[Spatial Cluster ID OR auto] ▌ trigger:enable-reliable-realtime-cache timer: ip: synchroknot:[Spatial Cluster ID] ▌ trigger:disable-reliable-realtime-cache synchroknot:[Spatial Cluster ID] ▌ trigger:enable-authentication-calibration calibration-code:[SHA512 Checksum] synchroknot:[Spatial Cluster ID] ▌ trigger:disable-authentication-calibration synchroknot:[Spatial Cluster ID] ▌ trigger:enable-authentication-calibration-session synchroknot:[Spatial Cluster ID] ▌ trigger:disable-authentication-calibration-session synchroknot:[Spatial Cluster ID] ▌ trigger:authentication-calibration-override synchroknot:[Spatial Cluster ID] add:[User CSV] remove:[User CSV] delete: ▌ trigger:authentication-calibration-override-info synchroknot:[Spatial Cluster ID] ▌ trigger:authentication-calibration-info synchroknot:[Spatial Cluster ID]

║█║ Microcosm, Macrocosm, Intercosm :

■ Microcosm, Macrocosm and Intercosm can be set and updated by the Tenant after the Spatial Fabric Array is created by the Infrastructure Provider. ■ Every Tenant on the SoC can set up their own Microcosm, Macrocosm and Intercosm. trigger:spatial-fabric-array-modify sfa:[ip address] intercosm:[tag(s) up to 15 csv] macrocosm:[tag(s) up to 15 csv] microcosm:[tag(s) up to 15 csv] ■ The keys "microcosm:", "macrocosm:" and "intercosm:" can be modified all together or individually [eg. if the values for the keys "microcosm:", "macrocosm:" and "intercosm:" have already been assigned, and only the key "intercosm:" needs an updated value then the following can be done: trigger:spatial-fabric-array-modify sfa:[ip address] intercosm:[tag(s) up to 15 csv] ■ The values for the keys "microcosm:", "macrocosm:" and "intercosm:" can be used with full-regex consisting of up to two "AND" operators along with multiple "OR", "Range" and "Expansion" operators across all triggers that support Microcosm, Macrocosm and Intercosm including the Power Modules Realiable Realtime Cache and Realtime Cache! Microcosm : tag(s) [up to 15 csv] related to where the Spatial Fabric Array is located [eg. city/town, zip code, street etc]. Macrocosm : tag(s) [up to 15 csv] related to region where the Spatial Fabric Array is located [continent, country, state etc]. Intercosm : tag(s) [up to 15 csv] related to row, stack/rack/shelf, CPU type, network type, topology, group/team/provider identification or Blockchain ID for correspondence, support and management For example, a group of Spatial Fabric Arrays with Intercosm tag "management0" would mean that triggers pertaining to management of users, authentication etc having the the Intercosm tag "management0" will only be answered by them]. [See usage examples under Excerpts.]

║█║ Network Transport Types, Reliable Response, D-Mask and Mask :

SynchroKnot uses various transport types [reliable type TCP and unreliable type UDP] and their combinations automatically. Brief Overview of Network Transport Types and their Combinations: TYPE A : with Unicast, Broadcast and Multicast: Sender Receiver[s] | UDP --------> UDP | | UDP <-------- UDP | TYPE B : Sender Receiver[s] | TCP -------> TCP | | TCP <------- TCP | TYPE C : with Unicast, Broadcast and Multicast: Sender Receiver[s] | UDP -------> UDP | | TCP <------- TCP | TYPE D : with Unicast, Broadcast and Multicast: Sender[s] Receiver[s] | TCP -------> TCP | | UDP <------- UDP | Some of these internal transport types and their built-in combinations can be invoked and controlled by utilizing certain options on specific triggers.
█ Reliable Response : rr
Reliable Response "rr:{on|off}" is a unique and powerful option designed to bring about reliable responses to requests sent over unreliable transport. ■ When rr is off the requests and responses of triggers traverse over unreliable transport [UDP]. ■ When rr is on the requests of the triggers are sent over UDP and their responses are received over reliable transport [TCP]. ■ All the triggers where the option "rr:" can be used come automatically preset with them. ■ By default, the option rr is off for most triggers.
█ D-Mask : Destination Network Mask
The option "d-mask:" adds the destination network mask to the trigger. With this unique option only the Spatial Fabric Arrays that constitute the given mask answer to the request[s], all other requests are terminated at the destination itself, thus substantially reducing the management network traffic [since the results are not terminated at the receiving end, as done with the option "mask:", see Mask below]. ■ The key "d-mask:" can have a value of any valid netmask starting with either 254 or 255 [for the IP address Network 28.0.0.0]. ■ The key "d-mask:" works with all transport types and their combinations and should be used instead of "mask:". ■ The key "d-mask:" is automatically disabled internally when the key "sfa:" has a valid IP address. As the destination is already known, "d-mask:" is not required. ■ The value of key "d-mask:" takes precedence over "intercosm: macrocosm: microcosm:". The "intercosm: macrocosm: microcosm:" checks are only invoked when the Spatial Fabric Array automatically ascertains that it is within/part of the given "d-mask:" ■ The key "d-mask:" works with both the reliable response options "rr:on" and "rr:off". For example, setting a destination mask 254.240.0.0 to the key "d-mask:" like this "d-mask:254.240.0.0" will bring about the results from Spatial Fabric Arrays with the IP Addresses starting from 28.0.0.1 and ending with 29.15.255.254 : Network: 28.0.0.0 Broadcast: 29.15.255.255 Starting IP: 28.0.0.1 Ending IP: 29.15.255.254 Similarly, setting a destination mask 255.240.0.0 to the key "d-mask:" like this "d-mask:255.240.0.0" will bring about the results from Spatial Fabric Arrays with the IP Addresses starting from 28.0.0.1 and ending with 28.15.255.254 : Network: 28.0.0.0 Broadcast: 28.15.255.255 Starting IP: 28.0.0.1 Ending IP: 28.15.255.254
█ Mask : Network Mask
Any valid network mask of the IP network 28.0.0.0 with a prefix can be given as a value to the key "mask:". Eg. "mask:28.0.0.0/7", "mask:28.100.80.0/24" etc. ■ The key "mask:" *DOES NOT* work with the option "rr:on". It only works with the option "rr:off". ■ All non-matching results pertaining to the network mask are terminated while receiving the response, which means that more management traffic traverses over the network.

║█║ Excerpts : [New and Enhanced]

Excerpts are various informational & identification tags given to virtual machines for their decentralized search and management. ■ Excerpts can be set and modified with the trigger:vm-modify with up to 15 comma-separated values having the legal characters: 0-9 a-z , - ■ The most powerful, fine-grained search specificity and functionality is invoked with the built-in Parallel Regex Logic & Engine when excerpts are further used in combination with Microcosm, Macrocosm and Intercosm. ■ Even more powerful, regional search specificity can be achieved by using a destination network mask "d-mask:" *** Assign IP addresses to Spatial Fabric Satellites intelligently so as to take full advantage of the "d-mask:" functionality across regions with or without the use of Microcosm, Macrocosm and Intercosm for near-endless, fine-grained search & management possibilities! *** ■ The values for the keys "microcosm:", "macrocosm:" and "intercosm:" can be used with full-regex consisting of up to two "AND" operators along with multiple "OR", "Range" and "Expansion" operators across all triggers that support Microcosm, Macrocosm and Intercosm including the Power Modules Realiable Realtime Cache and Realtime Cache!.
Setting Excerpts to a Virtual Machine:
trigger:vm-modify sfa:[ip address] synchroknot:[vm name] excerpts:[up to 15 separated by commas] Excerpts may encompass [operating system name eg. linux|freebsd|solaris etc],[application type eg. webserver|database etc],[application name eg. apache|mysql etc],[department/group type/id eg. devteam101,applications etc],[mac address[es] of the virtual machine without the colon (:)],[IP addresses replacing the . with -] Examples of setting Excerpts [all must be in lower case]: linux,webserver,apache,devteam101,dac000143799,192-168-1-21,kernel-5-4-88 freebsd,database,mysql,dbateam1,dac000143885,10-10-11-110,kernel-4-19 * MAC address[es] can be very helpful in finding out the virtual machine name, location etc. As some network application log files may only have MAC address[es], you might want to ascertain which virtual machine is associated with that particular MAC address[es]. This functionality is quite unique, as finding a virtual machine from its MAC address is not possible/not as simple with most modern virtualization systems in centralized or distributed/decentralized setups. * ■ Excerpts are inherited by the virtual machines when created from a parent Spacesuit or a virtual machine. So, if a MAC address and/or IP address has been added to the excerpts, the excerpts will need to be updated with new MAC/IP address[es] or removed as needed. ■ The Spacesuits must not have MAC addresses or IP Addresses added to their Excerpts. The different SynchroKnot Excerpts triggers utilizing different transports automatically give exceptional control, reach and responsiveness over decentralized virtual infrastructure. ***IMPORTANT*** Only "Excerpts" and "Excerpts Regex" work with the options "rr:off" and "rr:on". For ease in usability, the triggers "Excerpts" and "Excerpts Regex" come preset with the options "rr:off" and "rr:on". There are many variants of Excerpts: 1] Excerpts - are specialized for EXACT matches and are invoked with "trigger:excerpts" - works with d-mask: Example of preset trigger: trigger:excerpts rr:on sfa: intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot: trigger:excerpts rr:off sfa: intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot: 2] Excerpts Regex - are specialized for multi-function REGEX with multiple OR, AND and NOT matches, and are invoked with "trigger:excerpts-regex". This is the default. Works with d-mask: Example of preset trigger: trigger:excerpts-regex rr:on intercosm: macrocosm: microcosm: sfa: d-vector: d-mask: synchroknot: trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: sfa: d-vector: d-mask: synchroknot: 3] Excerpts Reliable Realtime Cache Regex - are part of Reliable Realtime Cache Power Module that are specialized for multi-function REGEX with multiple OR, AND and NOT matches with instantaneous real-time response, and are invoked with: "trigger:excerpts-rrtc-regex" Example of preset trigger: trigger:excerpts-rrtc-regex intercosm: macrocosm: microcosm: synchroknot: Note: "trigger:excerpts-rrtc-regex" does not need "d-mask:" or "sfa:" as it already is aware of the destination. 4] Excerpts Realtime Cache Regex - are part of Realtime Cache Power Module that are specialized for multi-function REGEX with multiple OR, AND and NOT matches with instantaneous real-time response, and are invoked with: "trigger:excerpts-rtc-regex" Example of preset trigger: trigger:excerpts-rtc-regex intercosm: macrocosm: microcosm: synchroknot: Note: "trigger:excerpts-rtc-regex" does not need "d-mask:" or "sfa:" as it already is aware of the destination. 5] Excerpts Regex are also fully integrated with the Reachout Power Module utilizing reliable transport [ TCP ] to perform Decentralized Realtime Precision Parallel Search. trigger:excerpts-regex sfa:{IP addresses csv} pm:reachout intercosm: macrocosm: microcosm: d-vector: synchroknot: Note: "trigger:excerpts-regex" with "pm:reachout" does not need "d-mask:" as the destination is known by the IP addresses [csv] given as a value for the key "sfa:" by the user, or preset using Reachouts [i.e Shoutouts with IP addresses [csv]]. *** All frequently used or long/complex Excerpts Regex & Excerpts Realtime Cache searches can be converted into presets called Shoutouts so that the results can be realized with just a click of a button - see the next Shoutout section *** ■ Up to 15 tags [csv] can be searched for exact match with trigger:excerpts. ■ With "trigger:excerpts" and "trigger:excerpts-rtc", when a comma is used as a separator SynchroKnot understands it as looking for multiple exact matches. ■ With "trigger:excerpts-regex" and "trigger:excerpts-rtc-regex", when a comma is used as a separator SynchroKnot understands it as an AND operator. There can be only one AND operator [i.e ,]. ■ Clicking on "SYNCHROKNOT" on the Infrastructure Engine or leaving a blank value for the key "synchroknot:" matches all authorized virtual machines and returns their real-time status and metadata [visible via mouse-over]. ■ Refer to video demonstration for an outdated yet basic example.
Operators for "trigger:excerpts-regex", "trigger:excerpts-rrtc-regex:" and "trigger:excerpts-rtc-regex:"
Pipe : | is an OR operator.
Multiple "OR", "Expansion" and "Range" operators are supported. Example: tag1|tag2 tag1|tag2|t.*3|tag[5-9]
Dot Star : .* is an Expansion operator.
Example: l.*ux - Multiple Dot Star Operators are supported on search terms.
Minus within square brackets : [-] is a Range operator.
Multiple Minus Operators are supported. Example: tag[0-9a-z] tag[0-3|6-9|a-h|p-z]
Exclamation with parenthesis : !() is a NOT [Other Than] operator.
█ NOT operator is only used in specific cases and only recommended for those who are experienced with its logic. Everything within !() will be excluded from matching. Single or multiple OR operator[s] are needed when a NOT operator is used. Nesting of !() is supported. Example: Here tag1 is ignored and tag2 is matched if present. !(tag1)|tag2 Here tag1 and tag2 are ignored and tag3 is matched if present. !(tag1|tag2)|tag3 Here tags between tag0 to tag3 and tag6 to tag9 are ignored along with tag11 and tag12, while tag13 and tag14 are matched if present. !(tag[0-3|6-9]|tag11|tag12)|tag13|tag14 Here the search starts with "tag" and ends with "-dev": (tag33|tag44|!(tag[0-3|6-9]|tag11|tag12)|tag13|tag14)-dev
Comma : , is an AND operator.
█ There can up to two "AND" operators [in the near future up to 5 AND Operators will be supported]. █ AND Operator usage supports multiple Expansion, OR, Range and Not Operators. █ Up to two "AND" operators are also supported for use with Microcosm, Macrocosm and Intercosm, along with the support for multiple Expansion, OR, Range and Not Operators. █ Single/Multiple OR operator[s] with AND operator[s] is usually only used in specific cases and only recommended for those who are experienced with its logic. █ Single/Multiple NOT operator[s] individually or with other operators is usually only used in specific cases and only recommended for those who are experienced with its logic. Examples: tag1,tag2 tag1,tag2,tag3 tag1,tag2|tag20,t.*3|t.*40 █ Below are simple examples to get started with excerpts-regex. █ Replace "trigger:excerpts-regex" with "trigger:excerpts-rrtc-regex" or "trigger:excerpts-rtc-regex" if the Reliable Realtime Cache Power Module or the Realtime Cache Power Module is enabled. trigger:excerpts-regex intercosm: macrocosm: microcosm: d-vector: synchroknot:webserver - returns: webserver
Examples with Range and OR operators:
trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:webserver|linux - returns: webserver and other virtual machines that have linux in their excerpts. trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:apache|nginx - returns: all virtual machines that have apache and ngnix in their excerpts. trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:[a-z].*server - returns: all virtual machines that have characters a to z and end with server. Eg. webserver, appserver, databaseserver etc. trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:webserver[0-9] - returns: webserver0 to webserver9 trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:webserver1[0-9]|webserver2[0-5] - returns: webserver10 to webserver25 trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:(app|web)server1[0-9]|(app|web)server2[0-5] OR trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:(app|web)server(1[0-9]|2[0-5]) - returns: webserver10 to webserver25 and appserver10 to appserver25 trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:(da.*e|m.*a|app|web)server1[0-9]|(da.*e|m.*a|app|web)server2[0-5] OR trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:(da.*e|m.*a|app|web)server(1[0-9]|2[0-5]) - returns: webserver10 to webserver25, appserver10 to appserver25, mediaserver10 to mediaserver25 and databaseserver10 to databaseserver25. Here m.*a & da.*e expands to media and database.
Examples with AND, Range and OR operators:
*** The above examples can be used with an AND operator with a comma [,]. This means multiple OR operators can be matched but the result will only be produced if it also matches an AND operator. *** trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:(da.*e|m.*a|app|web)server(1[0-9]|2[0-5]),linux - will only return virtual machines between webserver10 to webserver25, appserver10 to appserver25, mediaserver10 to mediaserver25 and databaseserver10 to databaseserver25 that also have "linux" in their excerpts. All the rest will be ignored. trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:(da.*e|m.*a|app|web)server(1[0-9]|2[0-5]),linux,containers - same as above, but also looks for "containers". Here the result will only be produced if virtual machines between webserver10 to webserver25, appserver10 to appserver25, mediaserver10 to mediaserver25 and databaseserver10 to databaseserver25 that also have "linux" and "containers" in their excerpts. All the rest will be ignored.
Adding OR operator[s] to an AND operator[s]:
█ Single/Multiple OR operator[s] with AND operator[s] are only used in specific cases and only recommended for those who are experienced with its logic. trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:(da.*e|m.*a|app|web)server(1[0-9]|2[0-5]),linux|freebsd Here the results will only be returned if linux OR freebsd are also present in their excerpts. trigger:excerpts-regex rr:off intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:(da.*e|m.*a|app|web)server(1[0-9]|2[0-5]),linux|freebsd|unix,containers-(dev|prod)[0-5]|docker|lxc Here the results will only be returned if linux OR freebsd OR unix AND containers-dev0 to containers-dev5 OR containers-prod0 to containers-prod5 OR docker OR lxc are also present in their excerpts.
Examples with Microcosm, Macrocosm and Intercosm:
Microcosm : tag(s) [up to 15 csv] related to where the Spatial Fabric Array is located [eg. city/town, zip code, street etc]. Macrocosm : tag(s) [up to 15 csv] related to region where the Spatial Fabric Array is located [continent, country, state etc]. Intercosm : tag(s) [up to 15 csv] related to row, stack/rack/shelf, CPU type, network type, topology, group/team/provider identification or Blockchain ID for correspondence, management and support. For example, if the Microcosm, Macrocosm and Intercosm was set on Spatial Fabric Arrays like shown in the example below: trigger:spatial-fabric-array-modify sfa:[ip address] intercosm:rack10,id55555 macrocosm:asia,china microcosm:shenzen,zip010101 trigger:spatial-fabric-array-modify sfa:[ip address] intercosm:rack23,id88888 macrocosm:asia,japan microcosm:tokyo,zip24268 trigger:spatial-fabric-array-modify sfa:[ip address] intercosm:rack33,id88888 macrocosm:asia,korea microcosm:seoul,zip33368 trigger:spatial-fabric-array-modify sfa:[ip address] intercosm:rack13,id88888 macrocosm:asia,india microcosm:delhi,zip54668 Then, the searches should yield the appropriate results from the following regions & racks/ids: trigger:excerpts-regex intercosm:rack[0-2][0-9]|stack[0-9]|id55555|id88888|id1000[0-9] macrocosm:japan|china|korea|india microcosm:delhi|tokyo|okinawa|beijing|shenzen|seoul|zip010101|zip24268 d-vector: mask: synchroknot:webserver[0-9][0-9] trigger:excerpts-regex intercosm:rack[0-2][0-9]|stack[0-9]|id55555|id88888|id1000[0-9] macrocosm:japan|china|korea|india microcosm:delhi|tokyo|okinawa|beijing|shenzen|seoul|zip010101|zip24268 d-vector: mask: synchroknot:(da.*e|m.*a|app|web)server(1[0-9]|2[0-5]),linux,containers *** Note: you can also set the distance vector and/or d-mask as needed. ***
Examples with Destination Network Mask "d-mask" and "mask:" :
Examples with "d-mask:" : trigger:excerpts-regex intercosm:rack[0-2][0-9]|stack[0-9]|id55555|id88888|id1000[0-9] macrocosm:japan|china|korea|india microcosm:delhi|tokyo|okinawa|beijing|shenzen|seoul|zip010101|zip24268 d-vector: d-mask:254.240.0.0 synchroknot:(da.*e|m.*a|app|web)server(1[0-9]|2[0-5]),linux trigger:excerpts-regex intercosm:rack[0-2][0-9]|stack[0-9]|id55555|id88888|id1000[0-9] macrocosm:japan|china|korea|india microcosm:delhi|tokyo|okinawa|beijing|shenzen|seoul|zip010101|zip24268 d-vector: d-mask:255.240.0.0 synchroknot:(da.*e|m.*a|app|web)server(1[0-9]|2[0-5]),linux Examples with "mask:" : trigger:excerpts-regex intercosm:rack[0-2][0-9]|stack[0-9]|id55555|id88888|id1000[0-9] macrocosm:japan|china|korea|india microcosm:delhi|tokyo|okinawa|beijing|shenzen|seoul|zip010101|zip24268 d-vector: mask:28.9.0.0/16 synchroknot:(da.*e|m.*a|app|web)server(1[0-9]|2[0-5]),linux trigger:excerpts-regex intercosm:rack[0-2][0-9]|stack[0-9]|id55555|id88888|id1000[0-9] macrocosm:japan|china|korea|india microcosm:delhi|tokyo|okinawa|beijing|shenzen|seoul|zip010101|zip24268 d-vector: mask:28.0.0.0/7 synchroknot:(da.*e|m.*a|app|web)server(1[0-9]|2[0-5]),linux Note: "rr:off" can also be changed to "rr:on" for a reliable response.
║█║ Shoutout :
Shoutouts are presets for "excerpts-regex". There are similar separate presets for excerpts with Realtime Cache and Reachout. Up to 50 Shoutouts can be created with the trigger:shoutout-modify. All the Shoutouts are displayed by clicking the "^" symbol above the SynchroKnot Infrastructure Engine input box, or with the trigger:shoutout trigger:shoutout-info gives the information about all the existing Shoutouts. trigger:shoutout-remove removes a Shoutout. The presets created with Shoutout can be also used with Realtime-Cache and Reachout Power Modules saving time and extra effort. ■ Reliable Realtime Cache equivalent of Shoutouts can be accessed via the ">>" symbol or via "trigger:shoutout-rrtc". ■ Realtime Cache equivalent of Shoutouts can be accessed via "trigger:shoutout-rtc". ■ Reachout equivalent of Shoutouts can be accessed via the "<<" symbol, or via "trigger:reachout". █ ***IMPORTANT*** : Each Shoutout key and value cannot be modified separately. All the needed value[s] for the keys are required to be present in the same line for Shoutout to produce the required result. All the keys are displayed when the "trigger:shoutout-modify" is selected from the Infrastructure Engine. Examples: "trigger:shoutout-modify" with preset options: trigger:shoutout-modify excerpts: sfa: intercosm: macrocosm: microcosm: d-vector: d-mask: rr:off synchroknot: The value of the key "rr:" can be "on" or "off" Fill in values for the needed keys. Shoutouts "shoutout-0" to "shoutout-50" are valid. Refer to the examples above under the Excerpts section. trigger:shoutout-modify excerpts: sfa: intercosm: macrocosm: microcosm: d-vector: d-mask: synchroknot:shoutout-0 █ To remove a Shoutout: trigger:shoutout-remove synchroknot:shoutout-0 █ To get information about Shoutouts: trigger:shoutout-info
║█║ Reachout : Power Module
Reachout is a Power Module that uses reliable transport [ TCP ] to perform Decentralized Realtime Precision Parallel Search with all its features [excerpts, intercosm, microcosm and macrocosm] to be performed in parallel against specific Spatial Fabric Arrays [up to 100]. Reachout is mapped to Shoutout where all the metadata is already preset, but in turn uses a list of IP addresses of Spatial Fabric Arrays to interact with them using reliable transport in parallel. █ Note: You must be directly logged into the Spatial Fabric Array on which Reachout is to be configured and modified. █ Create a Reachout [reachout-0 to reachout-50] trigger:reachout-modify pm:reachout reachout-0:28.9.0.1,28.9.0.2,28.9.0.3 In the above example, reachout-0 must have a shoutout-0 with the required preset metadata. Upon successful creation of reachout-0 it will be displayed when clicked on "<<" symbol or using "trigger:reachout-info pm:reachout". Reachout can also be called with the "excerpts-regex" and "excerpts" triggers where the key and value "pm:reachout" is present. In this case, the key "sfa:" will accept up to 100 comma-separated [csv] IP addresses. Example: trigger:excerpts-regex sfa:28.9.0.1,28.9.0.2,28.9.0.3 pm:reachout intercosm: macrocosm: microcosm: d-vector: synchroknot: trigger:excerpts-regex sfa:28.9.0.1,28.9.0.2,28.9.0.3 pm:reachout intercosm: macrocosm: microcosm: d-vector: synchroknot: █ Reachout Information trigger:reachout-info pm:reachout Shows information of Reachouts that are created and their status of whether they are insync with their respective Shoutouts. █ Delete a Reachout trigger:reachout-modify pm:reachout reachout-2: Only the key "reachout-2:" with a blank value removes reachout-2 █ Note: Multiple Reachouts can be added or removed!
║█║ Distance Vector :
The distance vector comes preset with an optimal value of 0.7 [i.e 700 milliseconds/ms]. You can increase or decrease it as required. The Spatial Fabric Array listens and waits for 700 ms before it processes the response[s] to the request[s] sent out. trigger:spatial-fabric-array-modify sfa:[ip address] d-vector:[0.25 to 3.5] Different Spatial Fabric Arrays can have different distance vectors. For example, logging into Spatial Fabric Array with d-vector:0.3 would result in a faster response from local or near-local network(s). Logging into Spatial Fabric Array with d:vector:0.7 [or more] may accommodate a distributed global network. It is not a simple task determining local/global network responsiveness. The response to a trigger from local/global Spatial Fabric Arrays depends on a lot of factors. The distance and the load [the CPU cycles available at the destination to process the trigger quickly] can be considered the main factors. For fun, using the trigger:excerpts after setting NETEM delay of 300ms [Eg. tc qdisc add dev eth0 root netem delay 300ms] with the preset distance vector [700 milliseconds/ms] there is still a proper response, even if a single core is dedicated to a spatial cluster on a 2 core [~2GHz] 2GB RAM hardware at the destination! This is just an example of our stretching the distance with UDP in difficult real-world situations on low performance hardware for the purposes of testing. With the Power Module Reachout and Realtime Cache, the distance can be stretched by 5x to 10x.

║█║ Inbound & Outbound Traffic Overview To & From Spatial Fabric Satellites To Help Set Up & Configure Your Own Switch/Router

This section depicts the simplicity of setting up a standard switch/router or a Linux box acting as a switch/router to traverse inbound and outbound traffic to/from the Spatial Fabric Satellite cluster[s]. ■ Block all traffic forwarding on your switch/router and disable and block Spanning Tree Protocol entering and exiting all ports/interfaces. ■ Connect any free Ethernet ports on Spatial Fabric Satellites not part of their internal interconnect topology to your switch/router. For example, if you have 16 Spatial Fabric Satellites, then you can connect 2 - 4 [or more] ports from the Spatial Fabric Satellite cluster to your switch/router. Eg. 1 port from Spatial Fabric Satellite1, 1 port from Spatial Fabric Satellite16 and Spatial Fabric Satellite8 and so on as desired for the purposes of redundancy and traffic load distribution. The Spatial Fabric Satellite traffic is classified into two types: ■ Outbound ■ Inbound
█ Outbound Traffic From Spatial Fabric Satellites
The Outbound traffic from Spatial Fabric Satellites is of 2 types: █ VLAN Tagged: *** All VLAN tagged traffic is Tenant traffic *** Single Stack: 802.1ad [Ethertype 0x88a8] Double Stack: 802.1q [Ethertype 0x8100] - 802.1ad + 802.1q Triple Stack: 802.1q [Ethertype 0x8100] - 802.1ad + 802.1q + 802.1q a] Connect the Ethernet port[s] to your IPv4/IPv6 Router/Gateway. b] Untag the VLAN that was given to the Tenant when creating the Spatial Cluster [i.e interstellar], and block all traffic going in and out of the VLAN. c] Only allow the public IPv4/IPv6 subnet [including ARP for IPv4] given to the Tenant to traverse and flow on to your IPv4/IPv6 Router/Gateway ports. That's it! Example of setting up a Single Stack VLAN [55] with 802.1ad and a Double Stack VLAN [802.1ad + 802.1q] 55.100 using the ip link command on Linux: ip link add link eth0 eth0.55 type vlan proto 802.1ad id 55 ip link add link eth0.55 eth0.55.100 type vlan proto 802.1Q id 100 █ Untagged *** All untagged traffic is SynchroKnot Spatial Fabric Satellite internal traffic. *** a] Connect an Ethernet port to your layer 2 Provider VPN [Eg. TINC peer-to-peer VPN] that connects all the sites with Spatial Fabric Satellites. Read Layer 2 Peer-to-Peer VPN and Spatial Fabric Satellite Interconnection Across Multiple Sites By The Infrastructure Provider b] Block all traffic, and only allow the 28.0.0.0/7 and 10.0.0.0/7 subnets along with their unicast/broadcast/ARP traffic to traverse and flow on to your Provider VPN [TINC] port. That's it!
█ Inbound Traffic Towards Spatial Fabric Satellites From Tenant VPN
█ IMPORTANT : Please read the section "vSoC IP Addressing" first.
█ IMPORTANT : It is best to reserve & directly assign a portion of the 10.x.x.x range for the Tenants to access via a VPN instead of Routing/NATing
█ The Provider can choose any layer3/2 VPN to act as a Tenant VPN for the Tenants to remotely connect. ***
a] Connect the Ethernet port from your Tenant VPN. b] First, block all traffic from/to the Tenant VPN port. Then, only allow traffic with the source IP address range assigned to the Tenant and having the destination IP in the 10.0.0.0/7 range [along with ARP traffic] to traverse and flow on to the ports connected to the Spatial Fabric Satellites. That's it. c] As a standard practice, the Tenant traffic must be separated and must not communicate with each other. The destination IP [and ARP] subnet allowed of the Tenant traffic must only be 10.0.0.0/7. *IMPORTANT*: If the Tenant traffic is NATed, then it has to be a 1:1 NAT [see example below]. To achieve this, a public IP address range [Eg. 240.0.0.0 public IP range that is unused & reserved for future use] can be used as a private address and a 1:1 NAT can be set up. The Tenants can be given the IP subnets from 240.0.x.x to 240.8.x.x. In this 1:1 NAT example [240.0.0.0/7 mapped to 10.0.0.0/7], the Spatial Fabric Satellites must be given IP addresses other than those reserved for the Tenants. For example, Spatial Fabric Satellites can be given IP addresses in the 28.9.x.x range and above [which will also have their corresponding IP addresses in the 10.9.x.x range and above]. That's it! The Tenants will be able to access the local and distributed Infrastructure Engine, Storage Datapath Access, etc. on any authorized Spatial Fabric Satellite where they have a Spatial Cluster. Examples of NAT 1:1 mapping with Netfilter [IPTables Netmap]: iptables -t nat -A PREROUTING -d 240.0.0.0/7 -i eth0 -j NETMAP --to 10.0.0.0/7 iptables -t nat -A POSTROUTING -s 10.0.0.0/7 -o eth0 -j NETMAP --to 240.0.0.0/7 Replace eth0 with the interface connected to your Tenant VPN on your switch/router OR with the interface on your Tenant VPN itself that is connected to your switch/router. Make sure that the Tenant subnets do not communicate with each other, and the packets coming in from the Tenant VPN have a destination IP subnet other than 240.0.x.x to 240.8.0.0 range [as this range is given to the Tenants in this example]. You can customize this example to suit the needs of your setup. SynchroKnot automatically takes care of and handles redirects with combination of partly server-side + partly server-side-embedded-client-side functionality so that the traffic behind the NAT can still reach its destination when a redirect is requested from the Infrastructure Engine on the Spatial Fabric Satellite [which is on the other side of the NAT]. Read SynchroKnot Auto NAT Enablement
║█║ Provider VPN : Layer 2 Peer-to-Peer VPN :
The infrastructure provider(s) can use any layer 2 VPN [preferably it should be peer-to-peer] acting as a Provider VPN to interconnect sites with Spatial Fabric Satellites. ***Satellte Tree Protocol *MUST* be blocked from getting in and out of the VPN. In other words, neither site should let the Satellite Tree Protocol reach the other site[s]. There is no harm if it does, but it might reduce the scalability and increase the optimal path selection time in certain situations, as metadata of the local site will be propagated across all the other sites.*** The Tenants can also use layer 2 peer-to-peer VPN inside their virtual machine[s] to simply connect their local/global site(s) separate and independent of the infrastructure provider(s) and not have to do anything related to Satellte Tree Protocol or any other aspect. TINC is a peer-to-peer VPN which is widely used. It is known to have good performance, plus it is mature and stable. This makes it an ideal VPN solution to use with SynchroKnot. If you choose TINC then keep the following in mind : ■ Read : "Example: bridging Ethernet segments using tinc under Linux" [using the switch mode] on the official TINC website. ■ If the total sites connected are 50 - 100 or more, then set up 5 - 15 nodes [or more depending upon your setup] as the "connect to" peers or C2-Peer. Here every TINC node will only connect to the C2-Peers with the "connect-to=" option, allowing you to scale. Without the C2-Peers, every node might connect to eachother and notify eachother every time a new node joins and leaves, generating a lot of metadata, among other things. This can cause a load on the network, as some nodes might experience spiked cpu, memory and bandwidth usage. ■ Adjust the MTU if needed when allowing single/double/triple stacked VLANs to traverse [see scenario 1 below]. ■ Use hardware with enough fast CPUs and memory, and needless to say, enough bandwidth. ■ Set up a virtual machine for TINC pre-configured as a Spacesuit for the Tenants with instructions on how to use it as a gateway to quickly interconnect their sites. ■ If different infrastructure providers share sites, then make sure that there is an understanding such that the IP addresses of the Spatial Fabric Satellites don't clash. ■ That's it!
║█║ Spatial Fabric Satellite Interconnection Across Multiple Sites By The Infrastructure Provider :
Communication between Spatial Fabric Satellites is untagged [no VLAN tags used] with IP addresses assigned in the 28.0.0.0/7 range. The Infrastructure Provider can use layer 2 loop-free VPN [see above] to connect dispersed sites/locations. ■ IP addresses of all Spatial Fabric Satellites must be unique and in the 28.0.0.0/7 range. ■ Layer 2 traffic [mainly, IPv4 UDP unicast, UDP broadcast, ARP and TCP from and to the 28.0.0.0/7 range and 10.0.0.0/7 range] needs to be transparently reachable across the VPN like the local network. ■ Spanning Tree Protocol [STP] *MUST* be blocked and *MUST NOT* be allowed to traverse across the sites connected via a VPN. ■ ***Scenario 2 and 3 seem more optimal from managing, scaling and flexibility points of view without having the infrastructure provider manage Tenant network [i.e VPN, co-ordination of VLANs across sites, maintenance of Tenant inter-site connectivity etc].*** ■ As mentioned before, It is *NOT* necessary to create the same Spatial Cluster on all Spatial Fabric Satellites. General details of the 28.0.0.0/7 network: IP Address: 28.0.0.0 Network Address: 28.0.0.0 CIDR Notation: /7 Usable Host IP Range: 28.0.0.1 - 29.255.255.254 Broadcast Address: 29.255.255.255 Total Number of Hosts: 33,554,432 Number of Usable Hosts: 33,554,430 Subnet Mask: 254.0.0.0
█ Example : Scenario 1 : * Not Recommended *
*** Just One Simple Step - Connect all needed sites with a Layer 2 VPN *** [Please read "Layer 2 Peer-to-Peer VPN" above.] ■ *All traffic* except Spanning Tree Protocol [STP] is allowed to traverse the VPN. ■ Each spatial cluster must be created with the same VLAN ID across all sites. ■ The MTU of the VPN may need to be adjusted to allow single, double or triple stacked Vlans to traverse. Plus, since most VPNs may not be able to look into the source/destination fields of the packets/frames with VLAN tags there are chances that those packets/frames might be broadcasted. Please ascertain your use case scenario carefully. 6 dispersed sites with 10 Spatial Fabric Satellites each -- All sites interconnected via a layer 2 VPN by the same infrastructure provider OR separate infrastructure providers with an understanding of the IP address [28.0.0.0/7] range they can use. Spatial Cluster for Tenant ABC is created on all 60 Spatial Fabric Satellites with the *SAME* VLAN ID. Then, Tenant ABC can log into any [or all] Spatial Fabric Satellite[s] and manage virtual infrastructure across all 60 Spatial Fabric Satellites across all the sites seamlessly. The virtual infrastructure [ie virtual machines of Tenant ABC] across all the 6 sites *WILL* also be connected.
█ Example : Scenario 2 : *** Highly Recommended ***
*** Just One Simple Step - Connect all needed sites with a Layer 2 VPN *** [Please read "Layer 2 Peer-to-Peer VPN" above.] *** DO NOT allow single, double or triple stacked VLANS and Spanning Tree Protocol [STP] to traverse the VPN. That's all there is to it! *** Spatial Cluster for Tenant ABC is created on any/all Spatial Fabric Satellites as needed across the 6 dispersed sites. *** Each site can assign the *SAME* OR *DIFFERENT* VLAN ID to the spatial cluster. There is no need for the infrastructure providers at different sites to co-ordinate regarding VLAN IDs or other aspects!!! *** The Tenant will be able to transparently and seamlessly manage their virtual machines and other aspects of their virtual infrastructure from any Spatial Fabric Satellite. SynchroKnot provides the unique ability to perform ANY-to-ANY management. The virtual machines can communicate with each other within their respective sites. The virtual machines across the sites *WILL NOT* be connected and cannot communicate unless the Tenant specifically chooses to do so, in which case, the Tenants can use layer 2 peer-to-peer VPN [eg. TINC] inside a virtual machine acting as a VPN Gateway on one site to simply connect their local/global dispersed sites or for that matter any site running on public/private cloud or physical infrastructure! This gives Tenants full interconnection specificity and flexibility. The Infrastructure Provider[s] do not have to manage the Tenant networks [i.e Tenant VPNs, VLANs across sites and much more]. Since the network of the Tenant [i.e the spatial cluster] is based on Ethernet Layer 2, the Tenant[s] are free to use any IP addressing or non-IP addressing schemes in their virtual machines, and all software applications that run on network Layer 2 and above should work transparently! Example: Infrastructure Provider at site 1 creates a spatial cluster 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE with VLAN 100 on the needed spatial fabric satellites, and the same/other Infrastructure Provider at site 2 creates spatial cluster 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE with VLAN 200.200, and so on. Then, Tenant ABC can log into any one [or all] Spatial Fabric Satellite[s] on any site[s] and manage all virtual machines and related aspects dispersed across all 6 sites seamlessly and transparently as if they were local. As mentioned above, the virtual machines of the Tenant across all the 6 sites *WILL NOT* be connected unless the Tenant specifically chooses to. Read Gateway for Customer / Tenant Inbound and Outbound traffic below for more information.
█ Example : Scenario 3 :
2 dispersed sites with 10 Spatial Fabric Satellites each -- The Spatial Fabric Satellites at these 2 sites are *NOT* interconnected [eg. separate infrastructure providers]. Spatial Cluster for Tenant ABC is created on all 10 Spatial Fabric Satellites on site 1 and all 10 Spatial Fabric Satellites on site 2. The Tenant ABC *CANNOT* seamlessly manage the virtual infrastructure on site 1 and site 2, but can separately manage it by logging in separately [eg. 2 browser tabs] into any [or all] Spatial Fabric Satellite(s) on site 1 and site 2. The Tenant can choose to connect virtual infrastructure on site 1, site 2 or any other site with a VPN.

║█║ Spatial Fabric Traverser with Intersecter : Power Module

█ Spatial Fabric Traverser is a SynchroKnot Software that:
■ Connects the Spatial Fabric Satellites to the Public Internet Gateway Router[s]/Switch[es], Provider VPN [i.e VPN that connects the sites of the provider] and Tenant VPN [i.e VPN where the Tenants remotely connect] with a quick and minimal set up. ■ Transparently traverses traffic from both Public IPv4 and IPv6 addresses to/from single/multiple Internet service providers to/from spatial clusters on Spatial Fabric Satelltes. ■ Takes care of all single/double/triple stacked VLAN traffic traversing from spatial clusters on Spatial Fabric Satellites to single/multiple Public Internet Gateways [IPv4/IPv6] from single/multiple Internet service providers. ■ Serves as a simple, fault-tolerant alternative to using standard routers/switches. ■ Installs on any AMD64 hardware with multiple Ethernet network ports [has same operating system requirements as Spatial Fabric Satellites]. ■ All modifications to the IPv4 and IPv6 blocks can be made at the same time and without disrupting the traffic flow of all existing IPv4/IPv6 blocks to/from spatial clusters. Each Spatial Fabric Traverser can be connected to multiple Public Internet Gateways, which means, Tenants [spatial clusters] that have been given specific public IPv4/IPv6 address blocks can reach their public Internet Gateways across different Internet service providers. With Spatial Fabric Traverser, each spatial cluster can be given IPv4/IPv6 address blocks from different Internet service providers if needed! Multiple Spatial Fabric Traversers can be set up for fault-tolerance and load balancing with Satellite Tree Protocol [built-in]. Note: Depending on the use case scenario, the Power Module Spaceway may not be needed if the Spatial Fabric Traverser is used.
█ Intersecter:
■ Is a part of the Spatial Fabric Traverser. It interconnects separate physical clusters of Spatial Fabric Satellites transparently while keeping their Satellite Tree Protocol Domains separated. ■ Does not allow one large Satellite Tree Protocol domain to form across different physical clusters of Spatial Fabric Satellites when they are interconnected, allowing for the ease of maintenance, expansion, contraction and troubleshooting.
█ Triggers to Control and Manage Spatial Fabric Traverser and Intersecter:
█ Set Up Traverser
Sets up Traverser. echo "trigger:setup-traverser ports:[port[s] facing Spatial Fabric Satellites] traverser-ports:[port[s] facing Internet Gateway[s]]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl The key traverser-ports: are Internet Gateway facing, and the key ports: holds the Spatial Fabric Satellite facing ports. Connect any free Ethernet port[s] from the Spatial Fabric Satellte cluster that are not a part of their internal interconnect topology to the Traverser [i.e Spatial Fabric Satellite facing ports]. Eg. If there are 16 Spatial Fabric Satelltes interconnected to eachother in a Ring/Torus/custom mixed topology, use any free Ethernet port[s] from 1 to 4 [or more] Spatial Fabric Satelltes of choice and connect them to any available Spatial Fabric Satellite facing ports on the Traverser. No manual configuration needed! To modify Traverser, use trigger:setup-traverser. The operating system will need to be rebooted to use the trigger:invoke-traverser as realtime modification is currently not supported for Traverser.
█ Set Up Outbound and Inbound Ports
After the Spatial Fabric Traverser is set up as shown above, the Outbound and Inbound ports can be set up if needed. The Outbound port is connected to the Provider VPN [Eg. TINC] which connects the sites of the provider. The Inbound port is connected to the Tenant VPN. The Tenant VPN allows Tenants to remotely connect. Choose any free port assigned to the Spatial Fabric Satellites [i.e the key "ports:" when using the "trigger:setup-traverser"] to be enabled as an Inbound and Outbound port. Example: echo "trigger:modify-outbound outbound:[any free port facing Spatial Fabric Satellites]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl echo "trigger:modify-inbound inbound:[any free port facing Spatial Fabric Satellites]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl To modify the inbound or outbound port follow the steps shown above.
█ Invoke Traverser
Invokes the traverser into operational mode. echo "trigger:invoke-traverser" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Info Traverser
Shows the Ethernet ports assigned to the Traverser and Intersecter. echo "trigger:info-traverser" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Add Interstellar
Adds single or multiple [CSV] Interstellars. echo "trigger:add-interstellar interstellar:[single/double/triple stacked VLANS CSV]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl Example: echo "trigger:add-interstellar interstellar:100,222.222,555.555.555,1000" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Remove Interstellar
Removes single or multiple [CSV] Interstellars. echo "trigger:remove-interstellar interstellar:[single/double/triple stacked VLANS CSV]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Info Interstellar
Shows information of a single Interstellar. echo "trigger:info-interstellar interstellar:[one single/double/triple stacked VLAN]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ List Interstellar
Lists all available Interstellars. echo "trigger:list-interstellar" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Start Interstellar
Starts a single Interstellar. echo "trigger:start-interstellar interstellar:[one single/double/triple stacked VLAN]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Stop Interstellar
Stops a single Interstellar. echo "trigger:stop-interstellar interstellar:[one single/double/triple stacked VLAN]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Modify Interstellar
Modifies a single Interstellar. echo "trigger:modify-interstellar interstellar:[one single/double/triple stacked VLAN] ipv4:[ipv4 blocks CSV] ipv6:[ipv6 blocks CSV] ipv6-icmp-type:[ICMP Types CSV]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl Setting a blank value to the keys ipv4, ipv6 and ipv6-icmp-type removes their assigned value. Example of IPv4 & IPv6: ipv4:111.111.111.0/24,222.222.222.0/24 ipv6:2001.0db8.100.1.2.3.4.5/48 The following ICMP Types are supported: destination-unreachable no-route communication-prohibited address-unreachable port-unreachable packet-too-big time-exceeded ttl-zero-during-transit ttl-zero-during-reassembly parameter-problem bad-header unknown-header-type unknown-option echo-request echo-reply router-solicitation router-advertisement neighbour-solicitation neighbour-advertisement redirect Note: If the value for the key ipv6-icmp-type: is blank, then the following ICMP Types are automatically assigned if valid IPv6 block[s] are found for that interstellar: destination-unreachable no-route address-unreachable port-unreachable echo-request echo-reply router-solicitation router-advertisement neighbour-solicitation neighbour-advertisement
█ Modify Interstellar Realtime
Modifies a single Interstellar in realtime without affecting or disturbing its traffic flow, and also without affecting or disturbing the traffic flow of other Interstellars. For example, if the IPv4 blocks assigned to Interstellar 1000 are 111.111.111.0/24,222.222.222.0/24 and you add another block 99.99.99.0/24, then the traffic from virtual machines using the blocks 111.111.111.0/24 and 222.222.222.0/24 will not be affected/disrupted. Likewise, if block 99.99.99.0/24 was added and the block 111.111.111.0/24 was removed, then the traffic from the virtual machines that use the block 222.222.222.0/24 will not be affected/disrupted. echo "trigger:modify-interstellar-rt ipv4:[ipv4 blocks CSV] ipv6:[ipv6 blocks CSV] ipv6-icmp-type:[ICMP Types CSV]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Setup Intersecter
Sets up the Intersecter. echo "trigger:setup-intersecter intersecter-ports:[unused free ports]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl Note: Please make sure that the ports are not assigned to Traverser [though an internal check is performed for already assigned Ethernet ports]. To modify Intersecter do the same as above, but the operating system will need to be rebooted to use the trigger:invoke-intersecter as realtime modification is currently not supported for the Intersecter and Traverser.
█ Invoke Interstellar
Invokes the Intersecter into operational mode. echo "trigger:invoke-intersecter" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl

║█║ Spaceway : Power Module

The Synchroknot Spaceway is a power module that is designed for the Spatial Fabric Satellites. It allows the Spatial Fabric Satellites to allow specific public IPv4 and/or IPv6 address block[s] to traverse and reach their Spatial Clusters. With Spaceway, the outbound traffic from the virtual machines can reach their gateway[s] with public IP addresses, and the inbound traffic can reach the virtual machines from their public IP gateway[s]. The Spaceway removes the need for setting up a router/switch that can tag/untag single/double/triple stacked VLANs and the performing of other complex configurations and their maintenance. To use Spaceway you need: ■ Public IPv4 and/or IPv6 addresses, and have them associated with a spatial cluster on the Spatial Fabric Satellite. ■ The Spaceway port must be connected to the router that has or points to the gateway with public IP address[es]. Then, the virtual machines of that spatial cluster will have inbound and outbound access to and from the Internet. Spaceway can be invoked on multiple Spatial Fabric Satellites. Different Spaceways can be invoked for different spatial clusters on single or multiple Spatial Fabric Satellites. If a Spaceway for a specific spatial cluster is created on two or more Spatial Fabric Satellites, then the virtual machines from that spatial cluster will have multiple fault-tolerant paths to reach their gateways. Important: A Spaceway port on a single or multiple Spatial Fabric Satellites can be conected to a standard router [Layer 3]. If using a switch [layer 2], it is important that the traffic does not loop back and STP is turned off. If you would like to have your own powerful solution in the simplest possible steps please take a look at SynchroKnot Spatial Fabric Traverser. Note: Depending on use the case scenario, the Power Module Spaceway may not be need if the Spatial Fabric Traverser is used.
█ Spaceway Setup
To set up a Spaceway, assign a network port that is not assigned to the Spatial Fabric Satellite to be a part of its internal interconnect topology. Though more than one free port [csv] can be assigned to the Spaceway, it is recommended to assign to it only one free port. This is a one-time operation, unless the network port is desired to be modified. echo "trigger:setup ports:eth4" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
█ Spaceway Invoke
The Spaceway needs to be invoked before it can be used. This operation is required every time the Spaceway is first started [Eg. after the Spatial Fabric Satellite boots up]. echo "trigger:invoke" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
█ Spaceway Construct
Spaceway "construct" creates a Spaceway for a particular spatial cluster. IPv4 and/or IPv6 blocks [csv] can be assigned to a specific spatial cluster. echo "trigger:construct spatial-cluster:[spatial cluster Blockchain Id] ipv4:[csv IPv4 blocks] ipv6:[csv IPv6 blocks" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt Important: When using IPv6 blocks, remember to change the : to a . Example: echo "trigger:construct spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE ipv4:111.111.111.0/24,222.222.222.0/24 ipv6:2001.0db8.100.1.2.3.4.5/48" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
█ Spaceway Start
Spaceway "start" starts the Spaceway for the specific spatial cluster for which it was created, and only allows the public IPv4 and/or IPv6 blocks assigned to that spatial cluster to traverse. echo "trigger:start spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
█ Spaceway Modify
Spaceway "modify" transparently modifies the IPv4 and/or IPv6 address blocks. All operations are performed without disrupting the existing blocks that are not modified. For example, if the IPv4 blocks assigned to the spatial cluster 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE are 111.111.111.0/24,222.222.222.0/24 and you add another block 99.99.99.0/24, then the traffic from virtual machines using the blocks 111.111.111.0/24 and 222.222.222.0/24 will not be affected/disrupted. Likewise, if block 99.99.99.0/24 was added and the block 111.111.111.0/24 was removed, then the traffic from the virtual machines that use the block 222.222.222.0/24 will not be affected/disrupted. To completely remove the IPv4 and/or IPv6 blocks let the value for the keys ipv4 and ipv6 be blank. Eg ipv4: ipv6: Important: When using IPv6 blocks, remember to change the : to a . Examples: Adding 99.99.99.0/24 to the existing blocks 111.111.111.0/24 and 222.222.222.0/24. The csv can be in any order. echo "trigger:modify spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE ipv4:111.111.111.0/24,222.222.222.0/24,99.99.99.0/24" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt In the above example, the ipv4 block 99.99.99.0/24 is added to the existing blocks 111.111.111.0/24 and 222.222.222.0/24 without disruption. echo "trigger:modify spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE ipv4:99.99.99.0/24,111.111.111.0/24" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt In the above example, the ipv4 block 222.222.222.0/24 is removed without disrupting the blocks 99.99.99.0/24 and 111.111.111.0/24 Note: All non-disrupting changes can be made to IPv4 and IPv6 blocks at the same time.
█ Spaceway Stop
Spaceway "stop" stops the Spaceway for the specific spatial cluster for which it was created. All traversing traffic will be dropped instantly. echo "trigger:stop spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
█ Spaceway Deconstruct
Spaceway "deconstruct" completely removes the Spaceway after automatically stopping it if it was started. echo "trigger:deconstruct spatial-cluster:[spatial cluster Blockchain Id]" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt Example: echo "trigger:deconstruct spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
█ Spaceway Info
Spaceway "info" returns the IPv4 and IPv6 blocks associated with the spatial cluster. echo "trigger:info spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
║█║ Gateway for Customer / Tenant Inbound and Outbound Traffic to and from the Spatial Fabric Satellite(s) :
One can use SynchroKnot Spatial Fabric Traverser OR Spaceway, OR a standard switch/router, or a Linux box to act as a router/gateway that adds and removes VLAN tags coming in from the Spatial Cluster(s) on the Spatial Fabric Satellite(s). █ Level 1 tag [i.e base tag] is always 802.1ad [Ethertype 0x88a8]. █ Level 2 and level 3 tags are 802.1q [Ethertype 0x8100].
Step 1:
Block all traffic going in and coming out of the interface with the VLAN tag that is assigned to a Customer/Tenant.
Step 2:
*ONLY THEN* allow the public IP address [IPv4/IPv6] range/subnet that was alloted to the Tenant to traverse. That's all there is to it! *** This means ZERO management of the Tenant networks by the Infrastructure Provider. *** * The Tenants set up and manage their own VPN. * Multiple Ethernet ports from the Spatial Fabric Satellites that are not used as a part of the their interconnect topology can be connected to the gateway(s). Spanning Tree Protocol, Rapid Spanning Tree Protocol or similar other protocol traffic *MUST NOT* reach the Spatial Fabric Satellites from the gateway(s). The gateway(s) *MUST NOT* loop traffic back to Spatial Fabric Satellites. Example Scenario : On site A, the Infrastructure Provider creates 4 spatial clusters [on 4 Spatial Fabric Satellites] for Tenant abc with the blockchain id 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z and interstellar 1000.1000.1000 [triple stacked VLAN], and then allots for example, public IP addresses in the range 111.111.111.0/24. The provider, before giving out this IP range to the Tenant, blocks all traffic at the gateway that tags/untags VLAN 1000.1000.1000, and only allows the IP range 111.111.111.0/24 to go in and out of the interface with the VLAN tag 1000.1000.1000. That's it! The Tenant can then set up their own VPN in a virtual machine and get global direct connection to any number of sites regardless of the underlying provider. Let's say here the client connects to site B and C where the same Spatial Cluster 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z is running on VLANs 999.999 and 234 on sites B and C respectively. There is no need to coordinate between the infrastructure providers regarding VLANs or any other aspect regarding Spatial Fabric Satellites. Also, there is no need for BGP peering and other complexities. With the SynchroKnot product, 802.1ad [Ethertype 0x88a8] *IS NOT* used the same way it is used with Metro Ethernet [i.e service and customer VLAN IDs] across various connection brokers/providers providing interconnection and BGP peering between various customer and cloud provider sites. With the SynchroKnot product, up to triple-stacked VLANs are used in just one site! The Infrastructure Provider for example, can charge the Tenant(s) for the infrastructure and bandwidth, and now gets the flexible option to choose the least expensive Internet bandwidth available, and also load balance inbound and outbound traffic across multiple bandwidth links/connections.

║█║ Infrastructure Engine :

The Infrastructure Engine can be accessed by all Tenants in the 10.0.0.0/7 range corresponding to the 28.0.0.0/7 range IP address given to the Spatial Fabric Satellite. Eg. https://10.9.0.1/SynchroKnot.sknt If the user is logging in for the first time or has cleared the browser cookies, he/she will be automatically taken to the SynchroKnot-Identify.sknt page to log in and then brought back to the Infrastructure Engine landing page on success. *** There MUST NOT be a space between the key and value pair separated by a : [Eg. key:value]. *** *** There MUST ALWAYS be a "space" between the "sets" of key and value pairs [Eg. key1:value1 key2:value2 key3:value3 etc]. *** ■ To log in use your Bitcoin Address as username, your private key and the Bitcoin Address of the spatial cluster. If you do not exist or your ID is disabled you will not be able to log in. ■ To log out use trigger:eject and to get license information use trigger:license. ■ To clear/undo the trigger use ctrl+z. ■ To set appropriate browser/screen font size use ctrl- to reduce and ctrl+ to increase the font size. Some browsers have a default large font size, which may not be efficient, and/or some screen/monitor size/dimensions might be small. For a pleasant visual experience, it is important to have a small font size to appropriately display results. ■ To move the cursor quickly across the input box use ctrl+left/right arrow key. ■ To move the cursor to the start and end of the input box use Fn+left/right arrow key. ■ The trigger input box automatically expands and contracts adjusting to the length of the triggers. ■ When only using the keyboard, use ctrl + enter key to successfully trigger. This feature greatly reduces the chances of mishaps caused by accidental triggering. ■ Tested on Firefox [52.2.0 and above on Linux 64-bit], should work on modern Webkit-based web browsers with Javascript enabled. ■ The virtual machine console access using Java applet will only work in the browser[s] with version[s] that support Java applets.
█ Basic Usage:
■ Click "SYNCHROKNOT" to get all the virtual machines present in your spatial cluster across all the Spatial Fabric Satellites. ■ Click directly below "SYNCHROKNOT" [invisible area seen with mouseover] to instantly get all the virtual machines present in your spatial cluster across all the Spatial Fabric Satellites using Reliable Realtime Cache [Power Module]. ■ Under the input box there are shortcuts with the "■" symbol which upon clicking will append their preset triggers to the input box. ■ Click "^" symbol [or use trigger:shoutout] to instantly access Shoutouts. ■ Click ">>" symbol [or use trigger:shoutout-rrtc] to instantly access Shoutouts with Reliable Realtime Cache [Power Module]. ■ Click "<<" symbol [or use trigger:reachout] to instantly access Shoutouts with Reachout [Power Module]. Note: Shoutouts will only be displayed if they were previously created with trigger:shoutout-modify. Please read the Shoutout section. ■ Click "█" on the right side of "SYNCHROKNOT" to view all the details of the Synchroknot User that is logged in. ■ Click "█" on the left side of "SYNCHROKNOT" to view all the SynchroKnot License and Power Module details.
█ Dual Purpose On-Page Sift:
Dual Purpose On-Page Sift is a unique feature of the SynchroKnot Infrastructure Engine that speeds-up on-page search operations by reducing the time and effort required. Dual Purpose On-Page Sift does two things in parallel when typed in the Input Box: 1] Automatically searches for "SynchroKnot Triggers" after the minimum count of 5 characters. To show various matching triggers before the minimum count of 5 characters, tap the "Space Bar" one or more times!. 2] Automatically searches for virtual machine names that have appeared on the page as a result of the excerpts trigger [eg. regex|rtc|reachout etc] by immediately fading away the unmatched results in real-time as the search string is being typed. The virtual machine names reappear when the search string is reduced or removed [Eg. using "Back Space"]. 3] Regular expressions are supported with searches using On-Page Sift. Note: Simply hit the "Escape Key" [or continue to type through] to temporarily deactivate the "SynchroKnot Trigger Search" after 5 characters if by some chance the virtual machine search string might contain characters that also belong to the "SynchroKnot Triggers"!
█ Basic Usage of "Shortcuts" with Virtual Machine Information [i.e "trigger:vm-info"] and Other Triggers:
Shortcuts are convenient. They save space on the input box and greatly reduce time and effort when initiating triggers! ■ Short name for the key "spatial-fabric-array:" is "sfa:" [defaults to "sfa:"] ■ Short name for the key "destination-spatial-fabric-array:" is "d-sfa:" [defaults to "d-sfa:"] ■ Short name for the key "power-module:" is "pm:" [defaults to "pm:"] ■ Mouse-over on the IP address of the Spatial Fabric Array says "Append to sfa:"; on clicking, the IP address gets added to the key sfa: without disturbing all the other keys and values. ■ Mouse-over on the Blockchain ID [ Bitcoin Address] of the virtual machine says "Append + as a shortcut for virtual machine name to synchroknot:" ; on clicking the Blockchain ID a "+" gets added to the key synchroknot: without disturbing all the other keys and values. Here SynchroKnot will automatically translate "+" to the virtual machine's full name internally. ■ Mouse-over on the first name of the virtual machine says "Append virtual machine name to synchroknot:" ; on clicking the virtual machine name, the full name of the virtual machine [first + last] gets added to the key synchroknot: without disturbing all the other keys and values. ■ Mouse-over on "█║▌║▌║" says "Append to spacesuit:" ; on clicking the symbol, the full name of the virtual machine [first + last] gets added to the key spacesuit: without disturbing all the other keys and values. Here a "+" can also be added to the key spacesuit: as a shortcut to the full name of the virtual machine. Note: If there happens to be a value already given to a key, then that value will be non-disruptively replaced by the new value. █ IMPORTANT: ■ SynchroKnot *DOES NOT* connect/use the Bitcoin network or other external network(s) to perform any task. Power Module(s) in the future may use it, in which case it will be explicitly mentioned. ■ Your Bitcoin Private Key is *NOT* sent to the server. It is *ONLY* used in the browser to sign a Spatial Nonce Fingerprint [ invisible to the user ]. ■ Your Bitcoin Private Key *MUST NOT* be shared with anyone and you *MUST ONLY* be logging in to a trusted Infrastructure Provider.

║█║ Authentication Calibration : Built-in Authentication Security Feature

Authentication Calibration is a built-in authentication feature that works in addition to successful authentication via Decentralized Heterogeneous Blockchain Identity Management. ■ 1] The organization/group creates a calibration code [Eg. pin, sentence etc.] and shares the SHA512 checksum of that calibration code internally with their members which can be updated daily, weekly, bi-weekly, monthly etc. as required. ■ 2] If Authentication Calibration is enabled for a spatial cluster, then the users logging into that particular Spatial Fabric Array will be required to submit their calibration code. ■ Authentication Calibration can be managed via the Infrastructure Engine with the capability of enabling, disabling and modifying all the aspects individually on a particular Spatial Fabric Array or across multiple Spatial Fabric Arrays using Microcosm, Macrocosm and Intercosm. ■ Authentication Calibration can also be managed with "spatial-cluster-ctl.sknt" from the commandline on each Spatial Fabric Array individually without Microcosm, Macrocosm and Intercosm capabilities. ■ Authentication Calibration has an additional capability of managing the session of the users with the built-in Authentication Calibration Session Management. If this feature is enabled, and the calibration code is changed/updated, the users will have to authenticate again with the new calibration code. ■ Authentication Calibration Session Management has an override feature that disables Authentication Calibration and Authentication Calibration Session Management for the users in override list. ■ Authentication Calibration works with Level 2 Security Power Module if it is enabled. Successful authentication of the calibration code is required before authentication via Level 2 Security is invoked. ***IMPORTANT*** : Only characters allowed for the pin, phrase, sentence, etc. without space/tab are "a-z" "A-Z" "0-9" and "-". Example: echo -en "This-is-an-example-12345" | /usr/bin/sha512sum echo -en "eXampLe12345" | /usr/bin/sha512sum
█ Authentication Calibration use from the Infrastructure Engine
trigger:authentication-calibration-info sfa: microcosm: macrocosm: intercosm: trigger:disable-authentication-calibration sfa: microcosm: macrocosm: intercosm: trigger:enable-authentication-calibration calibration-code:[SHA512 Checksum] sfa: microcosm: macrocosm: intercosm: trigger:enable-authentication-calibration-session sfa: microcosm: macrocosm: intercosm: trigger:disable-authentication-calibration-session sfa: microcosm: macrocosm: intercosm: trigger:authentication-calibration-override sfa: add:[Blockchain ID[s] csv] remove:[Blockchain ID[s] csv] delete:[the value "delete" will completely remove the override list] trigger:authentication-calibration-override-info sfa: ***IMPORTANT*** : Please be aware that when using the triggers enable-authentication-calibration, enable-authentication-calibration-session, disable-authentication-calibration and disable-authentication-calibration-session if the key "sfa:" does not have a value, then all the Spatial Fabric Arrays OR the Spatial Fabric Arrays that constitute the value[s] of the key[s] "microcosm: macrocosm: intercosm:" will be modified. ***IMPORTANT*** : It is essential that one or more SynchroKnot root [synchroknot0] users are added to the "override list" -first- with the "trigger:authentication-calibration-override" to prevent a possible lock-out if a wrong sha512 checksum is added. If by any chance, you might be locked out, use "spatial-cluster-ctl.sknt" from the commandline to disable Authentication Calibration [with "trigger:disable-authentication-calibration] to gain back access.
█ Authentication Calibration use from commandline with "spatial-cluster-ctl.sknt"
./spatial-cluster-ctl.sknt <<< "trigger:enable-authentication-calibration calibration-code:[SHA512 Checksum] synchroknot:[Spatial Cluster ID]" ./spatial-cluster-ctl.sknt <<< "trigger:disable-authentication-calibration synchroknot:[Spatial Cluster ID]" ./spatial-cluster-ctl.sknt <<< "trigger:enable-authentication-calibration-session synchroknot:[Spatial Cluster ID]" ./spatial-cluster-ctl.sknt <<< "trigger:disable-authentication-calibration-session synchroknot:[Spatial Cluster ID]" ./spatial-cluster-ctl.sknt <<< "trigger:authentication-calibration-override synchroknot:[Spatial Cluster ID] add:[User CSV] remove:[User CSV] delete:[the value "delete" will completely remove the override list]" ./spatial-cluster-ctl.sknt <<< "trigger:authentication-calibration-override-info synchroknot:[Spatial Cluster ID]" ./spatial-cluster-ctl.sknt <<< "trigger:authentication-calibration-info synchroknot:[Spatial Cluster ID]" Note: The Authentication Calibration use from commandline is designed and built as an additional fail-safe capability for the Infrastructure Provider to pursue as and when needed. Authentication Calibration could be disabled from the commandline if you are "locked-out" due not being on the "override list" and a wrong sha512 checksum being assigned.
║█║ Spacesuit :
Virtual Machine Spacesuit : This is a template of the virtual machine from which new virtual machines can be created. One can create a spacesuit from an existing spacesuit or a virtual machine, and configure its encrypted configuration vault [also called the spacesuit]. The virtual machine spacesuit is identified by its yellow icon and by its naming scheme. Eg. {name}-ss0, {name}-spacesuit0 etc. Each virtual machine and a user [ie. synchroknot with a Bitcoin ID] has an encrypted vault also called spacesuit which stores the configuration and metadata. These configurations can be modified with trigger:vm-modify for the virtual machine and trigger:synchroknot-modify for the user [see below].
║█║ Spatial Virtual Machine :
QEMU virtual machines [with default KVM enabled] are known by their fullname [firstname-lastname]. The firstname is the name given to it and the lastname is a Blockchain ID that is automatically generated along with its private key. Make sure you use the correct QEMU options where required, and that the virtual machine's operating system supports those options [eg. drivers, crtl-alt-del, power down etc] for successful boot and operations. When in doubt or experiencing potential issues, it is recommended that the virtual machines be tested with the QEMU commandline and assessed for its appropriate workability, and only then incorporate the necessary QEMU options with trigger:vm-modify It is important that you give the virtual machines a unique first name [though multiple virtual machines with the same first name will work, but will cause serious management and operational issues]. Tenants are advised to maintain a list or database of virtual machines and user names that are used. This may be used for auditing against the virtual infrastructure. Eg. {vmname},{spatial fabric array},{nicx-ip},{nicx-gateway-ip},{excerpts},{interstellar and interstellar resonance ids},{location} | {user blockchain id},{privilege},{name},{contact},{spatial fabric array},{location} For real-time monitoring, stats, and alerts Netdata will have to be installed directly in the virtual machines. The Tenant will need a path/route [direct/VPN] from his/her machine to access the Netdata port on the virtual machine. Please refer to the Netdata manual. Refer to video demonstration.
█ Create
█ A new virtual machine can be created in the following ways:From a spacesuit. This spacesuit may be in a stopped, paused or running state and the new virtual machine created from it will be created without any interruption or disruption to the existing spacesuit. Just the first name of the Spacesuit is required. ■ From an existing virtual machine using it as a spacesuit. The existing virtual machine can be in a stopped, paused or running state and the new virtual machine created from it will be created without any interruption or disruption to the existing virtual machine. ■ A virtual machine is automatically created on a Spatial Fabric Array with the best resources if the key sfa: is blank. The spacesuit needs to be present on Spatial Fabric Array[s] for the virtual machine to be auto-created. Fine-grained specifics such as Intercosm, Microcosm, Macrocosm, Destination Mask ["d-mask:"] and Performance are supported! ■ The values for the keys "microcosm:", "macrocosm:" and "intercosm:" can be used with full-regex consisting of up to two "AND" operators along with multiple "OR", "Range" and "Expansion" operators across all triggers that support Microcosm, Macrocosm and Intercosm. Plus, apart from automatically creating the virtual machine in a decentralized manner, the location of newly created virtual machine will also be automatically determined and you will be take to its operations page. trigger:vm-create spacesuit:[first name of spacesuit] intercosm: macrocosm: microcosm: d-mask: performance:[blank refers to high|high|low] synchroknot:[name of the new virtual machine] ■ If a virtual machine needs to be created on a specific Spatial Fabric Array, then the key "sfa:" needs value of an IP address. The spacesuit [template with the yellow icon] or the virtual machine acting as a spacesuit needs to be present there. If not, you can create a virtual machine on a Spatial Fabric Array that has that spacesuit or virtual machine [chosen to be used as a spacesuit], and then [auto/manual] relocate it. For example, you have 5 Spatial Fabric Arrays and all of them have a spacesuit called debian as the firstname and different lastnames. You can create [auto/manual] virtual machines across all 5 Spatial Fabric Arrays. Now, if you only had spacesuit debian on Spatial Fabric Arrays 1 and 2, then virtual machines can only be created [auto/manual] on Spatial Fabric Arrays 1 and 2, and then relocated [auto/manual] if necessary. trigger:vm-create origin: spacesuit: sfa: synchroknot: ■ Name must be 30 characters or below and can only have these legal characters [numbers, a to z and -] without spaces: - 0-9 a-z ■ The name of the spacesuit from which the virtual machine is to be created can just be its first name if it is an actual virtual machine spacesuit. [It does not matter if the same spacesuit exists on different Spatial Fabric Arrays with different lastnames, SynchroKnot automatically takes care of that complexity.] ■ If the virtual machine with a first name exists on a particular Spatial Fabric Array, then that Spatial Fabric Array will not respond to the decentralized resource radar. This is a built-in feature to prevent virtual machine creation with the same first name, since this would cause complexity in management. However, if you still choose to go ahead, then create the virtual machine by giving it the IP address of the Spatial Fabric Array "sfa:" where you would like it to be manually created. Note: All virtual machine names have a unique Blockchain ID as their last name, so creating virtual machines with the same first name is possible but as stated above, will cause management complexities. █ A Spacesuit can be created in the following ways:From an existing spacesuit which may be in a stopped, paused or running state without any interruption or disruption to the existing spacesuit. Fullname of the Spacesuit and the IP address of the Spatial Fabric Array where the Spacesuit is present are required. trigger:vm-create type:spacesuit origin:spacesuit spacesuit:[fullname of the existing spacesuit] sfa: synchroknot:[name of the new spacesuit] ■ From a virtual machine which may be in a stopped, paused or running state without any interruption or disruption to the existing virtual machine. Fullname of the virtual machine and the IP address of the Spatial Fabric Array where the virtual machine is present are required. trigger:vm-create type:spacesuit origin:spatial-vm spacesuit:[fullname of the existing virtual machine] sfa: synchroknot:[name of the new spacesuit] █ Creating a new virtual machine from an existing virtual machine: ■ If a new virtual machine is to be created from an existing virtual machine, then the fullname of that existing virtual machine needs to be given as a spacesuit along with "origin:spatial-vm", and the key "sfa:" needs a value of an IP address where the existing virtual machine is present. The key "type:" could be blank or can be type:spatial-vm trigger:vm-create type:[blank or spatial-vm] origin:spatial-vm spacesuit:[fullname of the existing virtual machine] sfa: synchroknot:[name of the new virtual machine] █ Creating a Spacesuit from an existing virtual machine: ■ If a Spacesuit is created from an existing virtual machine, then the fullname of that existing virtual machine needs to be given as a Spacesuit along with "origin:spatial-vm type:spacesuit", and the key "sfa:" needs a value of an IP address where the existing virtual machine is present. trigger:vm-create type:spacesuit origin:spatial-vm spacesuit: sfa: synchroknot:
█ Delete
Virtual machine can be deleted using the delete button from the infrastructure engine. You will be prompted for a confirmation while doing so. If the trigger:vm-delete is used from the keyboard, then the fullname of the virtual machine and the IP address of the Spatial Fabric Array where it is located is needed, and the virtual machine will be removed without prompting for confirmation. As a unique feature, the virtual machine can also be deleted if it is in a running or paused state without having to stop it [or processes attached to it or closing all the open consoles], or unconfigure the SpaceBuoy/DHCPCAST/FASTR/Interstellar/Arpless etc or any other Power Module. All the actual complexity associated with virtual machine deletion including its intertwined inter-dependencies with snapshots and other virtual machines is automatically taken care of by SynchroKnot. Refer to video demonstration
█ Operations
start, stop, pause, unpause, unplug, reset -- these triggers work from the keyboard with the virtual machine's fullname, or with the click of a button. Refer to video demonstration. ■ The HTML5-based Web View can be restarted with 'trigger:vm-webview-restart' in cases where the virtual machine's web console is not accessible.
█ Spatial Virtual Machine Replica - Writable Snapshot :
A Replica can be created from an existing virtual machine or a spacesuit which may be in a stopped, paused or running state without any interruption or disruption to the existing spacesuit/virtual machine. trigger:create type:replica origin:spatial-vm spacesuit:debian-webserver-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dkMm9 synchroknot:debian-webserver-replica1 *Important : You cannot use the replica if the original virtual machine exists, as it is an identical copy. Fullname of the spacesuit is required. End the virtual machine's replica name with -replica+number Eg. webserver-replica1, webserver-replica8 etc. The virtual machine's replica is identified with a light blue icon. You can create a new virtual machine from a replica [with the replica acting as a spacesuit for the new virtual machine].
█ Time Travel with Spatial Virtual Machine :
Move back and forth in time with specific granularity to the preferred state of the virtual machine at the point in time when the replica was created. First, delete the original virtual machine OR make a replica of the original virtual machine and then delete it. After that, create a virtual machine with its original name from the replica acting as its spacesuit! Multiple simple and complex scenarios are possible.

║█║ Disperser

█ Disperser Create trigger:disperser-create sfa: synchroknot: disperse: internal-ip: Example: trigger:disperser-create sfa:28.9.0.1 synchroknot:192.168.20.25 disperse:10.33.33.33,10.33.33.34 internal-ip:10.33.33.23 █ Extra Options: mask:[valid netmask for the key "internal-ip:". Eg. /24, /16, /8 etc without the "/"] - this an option for "trigger:disperser-create" internal-mask:[valid netmask for the key "synchroknot:". Eg. /24, /16, /8 etc without the "/"] - this an option for "trigger:disperser-create" When using the power module ARPless Interstellar/Interstellar, the disperser "internal-ip" will always be in Interstellar dab0002. The virtual machines to whom the traffic is being dispersed would need to have their interstellar or interstellar resonance as dab0002. Note: The values for "mask:" and "internal-mask:" are not requirements for "trigger:disperser-create" trigger:disperser-create sfa: synchroknot: mask: disperse: internal-ip: interstellar: internal-mask: Example: trigger:disperser-create sfa:28.9.0.1 synchroknot:192.168.20.25 mask:24 disperse:10.33.33.33,10.33.33.34 internal-ip:10.33.33.23 internal-mask:16 █ Disperser Enable trigger:disperser-enable sfa:28.9.0.1 synchroknot:10.33.33.40 █ Disperser Disable trigger:disperser-disable sfa:28.9.0.1 synchroknot:192.168.20.25 █ Disperser Info trigger:disperser-info sfa:28.9.0.1 synchroknot: trigger:disperser-info sfa:28.9.0.1 synchroknot:192.168.10.25 █ Disperser Remove trigger:disperser-remove sfa:28.9.0.1 synchroknot:28.13.20.25
█ Disperser Inter-Weaving
If an IP address of the virtual machine being dispersed to is on a hardware with faster or more cpu cycles, then you could choose to inter-weave that IP address so that it gets more traffic. Eg. disperse:10.33.33.33,10.33.33.34,10.33.33.33,10.33.33.35,10.33.33.33,10.33.33.36,10.33.33.37 ---- here 10.33.33.33 has faster/more cpu cycles. The disperser will not be able to run on specific cpus given to the Tenant [due to its kernel functionality]. Refer to video demonstration.

║█║ Synchroknot [User]

SynchroKnot is the user identified by his/her Blockchain ID [Bitcoin Address]. Each Synchroknot has a Synchroknot Decentralized Access Control Identification known as SDAC with root and non-root privileges. Synchroknot root user is synchroknot0 [sdac-root] and has all the privileges to control and manage all aspects across all Spatial Fabric Arrays. When a spatial cluster is created on the Spatial Fabric Satellite, the first user with the Blockchain ID [Bitcoin Address] of the spatial cluster is automatically created. The Tenant can log in to the Spatial Fabric Satellite with the spatial cluster's Blockchain ID [Bitcoin Address] the User ID [ i.e same Bitcoin Address] and the Private Key, and then create new users. █ IMPORTANT: ■ Only Bitcoin Address Type Legacy [i.e an address starting with 1] is supported. ■ It is recommended that a Bitcoin Address is generated using the official Bitcoin Core software [available at https://bitcoincore.org]. ■ If using bitcoin-cli or bitcoin-qt [GUI] use the command "getnewaddress" to generate a new Bitcoin Address and the command "dumpprivkey" to get the Private Key associated with your Bitcoin Address. ■ As a security best practice, please *DO NOT* generate and dump Bitcoin Address[es] on a machine with wireless connectivity [Eg. WiFi, Bluetooth, 4G, 5G etc], and avoid direct connection to the Internet. Example: bitcoin-cli getnewaddress "label" legacy bitcoin-cli getnewaddress synchroknot legacy bitcoin-cli getnewaddress "" legacy bitcoin-cli dumpprivkey {Your Bitcoin Address}

║█║ Synchroknot [User] With Decentralized Access Control Identification - SDAC and VM-SDAC

Automatic decentralized real-time ad-hoc calibration of credentials of the Synchroknots [SDAC] with those of the virtual machines [VM-SDAC] and vice-versa for fine-grained decentralized access, control and management of the virtual infrastructure. SDAC IDs and VM-SDAC IDs start with the name synchroknot and end with numbers [eg. synchroknot101]. A Synchroknot with SDAC-Root has the privilege to access, manage and control all the virtual machines and the spacesuits of the other Synchroknots. For the non-root Synchroknots to access, manage and control all the virtual machines, their SDAC-ID must pass successful calibration with the VM-SDAC ID of the virtual machine. Each synchroknot and virtual machine can have up to 15 [csv] SDAC and VM-SDAC IDs respectively. For example, if any one of the 15 SDAC IDs of the Synchroknot calibrates successfully with any one of the 15 VM-SDAC IDs of the virtual machine, then that Synchroknot can access, manage and control that virtual machine, and also have the ability to create new virtual machines and replicas from it. Examples: Synchroknot with sdac-id:synchroknot112 will be able to access, manage and control all virtual machines that have vm-sdac-id:synchroknot112 OR vm-sdac-id:synchroknot25,synchroknot112,synchroknot19 and so on. Synchroknot with multiple sdac-ids Eg. sdac-id:synchroknot112,synchroknot25,synchroknot19 will be able to manage and control all virtual machines that have vm-sdac-id:synchroknot112,synchroknot101,synchroknot25,synchroknot19 all together OR separately vm-sdac-id:synchroknot112 | vm-sdac-id:synchroknot25,synchroknot22222 | vm-sdac-id:synchroknot4555,19 OR in any other combination!! *Only SynchroKnot-Root user can modify the SDAC and VM-SDAC IDs.*
█ synchroknot-create
trigger:synchroknot-create sfa:[SFA IP] synchroknot:[Bitcoin ID] trigger:synchroknot-create sfa:28.9.0.1 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z ***You need to have the sdac-root:synchroknot0 privilege to use the trigger:synchroknot-create. The user created must possess the private key associated with the Bitcoin ID, if not he/she will not be able to log in.*** *value for the key sfa: is needed*
█ synchroknot-info
trigger:synchroknot-info sfa: synchroknot: trigger:synchroknot-info sfa:28.9.0.1 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z *value for the key sfa: is needed* *Full details will only be viewable by the synchroknot [user] to whom the Spacesuit belongs and to the users who have the sdac-root:synchroknot0 privilege. All other synchroknots [users] will see minimal details.*
█ synchroknot-list
Lists all synchroknots [users] or those that are specifically filtered using microcosm/macrocosm/intercosm. trigger:synchroknot-list rr:on intercosm: macrocosm: microcosm: sfa: d-vector: synchroknot: trigger:synchroknot-list rr:off intercosm: macrocosm: microcosm: sfa: d-vector: synchroknot: If an IP address of a specific spatial fabric array is given and the value for "synchroknot:" is "blank" then all the synchroknots on that particular spatial fabric array are listed. Clicking on any one of the results gives detailed information. ■ Regex matches are also supported [like seen with virtual machines]! ■ The values for the keys "microcosm:", "macrocosm:" and "intercosm:" can be used with full-regex consisting of up to two "AND" operators along with multiple "OR", "Range" and "Expansion" operators across all triggers that support Microcosm, Macrocosm and Intercosm. Eg. synchroknot:1M.* | synchroknot:1Me8d.*tz | synchroknot:1[M|r|A|2]e8d.*tz | synchroknot:1[M|r|A|2]e8d.*[p-v|P-V]z
█ synchroknot-remove
trigger:synchroknot-remove sfa:28.9.0.1 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z ***You need to have the sdac-root:synchroknot0 privilege to use the trigger:synchroknot-remove. User with sdac-root:synchroknot0 privilege cannot remove himself, but can remove others as needed.*** *value for the key sfa: is needed*
█ synchroknot-modify
trigger:synchroknot-modify sfa:28.9.0.1 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z sdac-id:synchroknot19 ▌ You need to have the sdac-root:synchroknot0 privilege to: ■ remove or add the sdac-root:synchroknot0 privilege ■ assign/modify multiple sdac-ids ■ enable/disable status [ie. status:enabled]. * value for the key sfa: is needed. * *** To assign a non-root privilege to a user, *Make Sure* the key sdac-root: has no value given to it. *** *** Those without sdac-root:synchroknot0 privilege *WILL NOT* be able to modify themselves to become sdac-root OR modify their sdac-id. *** ■ The synchroknot-modify trigger below enables user 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z with sdac-id:synchroknot112,synchroknot25,synchroknot19, while removing synchroknot0 privilege by leaving the value of key sdac-root blank. ■ The trigger below will only be successful if it is initiated by someone with sdac-root:synchroknot0 privilege. trigger:synchroknot-modify sfa:28.9.0.2 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z sdac-id:synchroknot112,synchroknot25,synchroknot19 sdac-root: status:enabled ■ To disable a synchroknot you must be synchroknot0 : trigger:synchroknot-modify sfa:28.9.0.2 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z status:disabled *The options status:disabled and status:enabled are not permitted to be used on one's own spacesuit.* ■ enable/disable login timeout If login timeout is enabled, then the user will be logged out automatically after 24 hours since the last login and will have to re-authenticate. trigger:synchroknot-modify sfa:28.9.0.2 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z login-timeout:enabled trigger:synchroknot-modify sfa:28.9.0.2 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z login-timeout:disabled ■ Force a user to re-authenticate Using the key "nonce-fingerprint:" with a blank value will force the user to re-authenticate. trigger:synchroknot-modify sfa:28.9.0.2 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z nonce-fingerprint: Note: This is an additional fine-grained feature separate from those seen with Authentication Calibration. ■ Other keys that can be modified with trigger:synchroknot-modify are: firstname, lastname, email, info and phone Note: Please use # or %20 in place of space. Note: "trigger:synchroknot-modify" has a built-in capability of accepting multiple keys and values all together.

║█║ Spatial Fabric Array Information, List and Realtime Log

█ spatial-fabric-array-info
trigger:spatial-fabric-array-info sfa:28.9.0.1 synchroknot: *value for the key sfa: is needed* Returns information about the Spatial Fabric Array.
█ Realtime Log View:
Click on the displayed IP:Port of Realtime Log in the returned information about the Spatial Fabric Array to open it in a new tab. Use the username and password provided in the information when logging in the first time.
█ spatial-fabric-array-list
trigger:spatial-fabric-array-list rr:off sfa: d-vector:1 d-mask: microcosm: macrocosm: intercosm: trigger:spatial-fabric-array-list rr:on sfa: d-vector:1 d-mask: microcosm: macrocosm: intercosm: Shows a list of Spatial Fabric Arrays along with their information. Works with rr:{off|on}. ■ The values for the keys "microcosm:", "macrocosm:" and "intercosm:" can be used with full-regex consisting of up to two "AND" operators along with multiple "OR", "Range" and "Expansion" operators across all triggers that support Microcosm, Macrocosm and Intercosm.
║█║ Stagnant Virtual Machine
A virtual machine becomes stagnant [zombie] when its metadata is disabled. The stagnant virtual machine will not show up when using "trigger:excerpts" or other triggers. The metadata of the virtual machine can be enabled/disabled. When virtual machines are relocated, their metadata is automatically disabled at the destination when a relocation fails. This stagnant copy must be removed for the success of future relocation of the same virtual machine to the same destination. In rare situations of the virtual machine relocation process, if two virtual machines with the same fullname are present on two separate Spatial Fabric Arrays, and the relocation has failed, then the relocation copy at the destination can be made stagnant, and then safely deleted. trigger:stagnant-vm intercosm: macrocosm: microcosm: sfa: d-vector: d-mask: synchroknot: ■ "trigger:stagnant-vm" without the value for the key "sfa:" shows stagnant zombie virtual machines across all Spatial Fabric Arrays. Distance Vector works in this case. ■ "trigger:stagnant-vm" with a value of an IP address only shows stagnant zombie virtual machines from that specific Spatial Fabric Array. ■ Clicking on the result automatically inserts into the infrastructure engine the full information "trigger:zombie-vm-delete sfa:{ip address} synchroknot:{virtual machine name}". ■ The values for the keys "microcosm:", "macrocosm:" and "intercosm:" can be used with full-regex consisting of up to two "AND" operators along with multiple "OR", "Range" and "Expansion" operators across all triggers that support Microcosm, Macrocosm and Intercosm. ■ "trigger:stagnant-vm" *DOES NOT* support rr:{on|off} █ "trigger:zombie-vm-delete" is used for removing stagnant zombie virtual machines. █ Enable Metadata: trigger:enable-metadata sfa:[SFA IP] synchroknot:[vm firstname or firstname-lastname] trigger:enable-metadata sfa:28.9.0.1 synchroknot:debian-webserver-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dkMm9 █ Disable Metadata: trigger:disable-metadata sfa:28.9.0.1 synchroknot:debian-webserver-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dkMm9
║█║ Zombie Virtual Machine
SynchroKnot finds zombie virtual machines on deeper inspection of the BTRFS volume. When the "trigger:stagnant-vm" is used, then clicking on the result automatically inserts into the infrastructure engine the full information "trigger:zombie-vm-delete sfa:{ip address} synchroknot:{virtual machine name}". The stagnant zombie virtual machine can also be removed manually with "trigger:zombie-vm-delete": trigger:zombie-vm-delete sfa:28.9.0.1 synchroknot:testvm-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dknN1 *value for the key "sfa:" is needed* ***Make sure you are removing a stagnant zombie virtual machine with trigger:zombie-vm-delete and not any other virtual machine.***

║█║ Relocate Virtual Machine

The QEMU-KVM cpu type "kvm64" [which is the default in virtual machine spacesuits] along with the machine "type=pc" is known to be best suited for successful virtual machine relocation across the same and sometimes across different CPU architectures. The QEMU option -machine type=pc is an alias of pc-i440fx-3.1 in version 3.1.0. It is important to have the same version of "qemu-system-x86_64" on all the SoCs or the full -machine type={name} should be used. Eg. -machine type=pc-i440fx-3.1. The success of the virtual machine relocation depends primarily on the cpu type, QEMU version and the machine type among other related aspects. The virtual machine may fail to migrate across different versions of QEMU as some options and features may not be available/supported across different QEMU versions.
█ Manual Relocation
trigger:vm-relocate data: sfa: d-sfa: synchroknot: Example: Relocate the virtual machine webserver-32w5Nws7S5SPAd9Uz5oHckuu1eqfPsUC6N from 28.9.0.4 to destination 28.9.0.1 trigger:vm-relocate data: sfa:28.9.0.4 d-sfa:28.9.0.1 synchroknot:webserver-32w5Nws7S5SPAd9Uz5oHckuu1eqfPsUC6N Note: The IP address where the the virtual machine is located is required ["sfa:"] along with the IP address of the destination ["d-sfa:"].
█ Auto Relocation
Works automatically with the single click of the "AUTO-RELOCATE" button on the Infrastructure Engine. For custom relocation options see below: trigger:vm-relocate intercosm: macrocosm: microcosm: d-vector: d-mask: data: performance: sfa: synchroknot: ■ The values for the keys "microcosm:", "macrocosm:" and "intercosm:" can be used with full-regex consisting of up to two "AND" operators along with multiple "OR", "Range" and "Expansion" operators across all triggers that support Microcosm, Macrocosm and Intercosm. Examples: trigger:vm-relocate d-vector: data: performance: sfa:28.9.0.1 synchroknot:webserver-13ttthWjYmTMKtHxx5f7DJ23PpMDri1PHi trigger:vm-relocate intercosm: macrocosm: microcosm: d-vector: d-mask: data: performance: sfa:28.9.0.1 synchroknot:webserver-13ttthWjYmTMKtHxx5f7DJ23PpMDri1PHi Note: The IP address where the the virtual machine is located is required [sfa:]. ■ To auto select an optimal Spatial Fabric Array at the destination with high performance use key and value "performance:high" OR keeping the key "performance:" blank is the same as high. ■ To auto select an optimal Spatial Fabric Array at the destination with low performance use key and value "performance:low" ■ Use the key "d-mask:" for a valid network destination mask [as shown in the Excerpts section]. ■ *** Works with all combinations of Microcosm, Macrocosm and Intercosm for precision auto-relocation. Please read the "Microcosm, Macrocosm, Intercosm" section. *** ■ Auto Relocation only works when Spatial Fabric Arrays up to 800ms away. Use manual relocation if the distance exceeds 800ms. ■ In some cases, if the relocation was not successful, and the virtual machine still shows that it is migrating, then use "trigger:vm-modify" with the option "migration-tag:remove". ■ To stop the in-progress relocation use the "trigger:vm-relocate-stop" trigger:vm-relocate-stop sfa: synchroknot: Note: QEMU may not be able to always stop the in-progress virtual machine relocation. *Important: Fullvmname [i.e firstname-lastname] is needed when using the keyboard to trigger:relocate. The "+" sign is the short for virtual machine's fullname, it can be auto added by clicking on the lastname of the virtual machine.* For fully automatic relocation hit the "AUTO-RELOCATE" button on the Infrastructure Engine. *Important: Only the disks attached to the virtual machines will be relocated with the virtual machine. This unique feature prevents build-up of non-relevant storage which costs the industry exabytes of wasted storage, as not everything is de-duplicated mainly for the reasons of performance and portability. After successful relocation the virtual machine on the source Spatial Fabric Array *WILL NOT* exist [as it will exist on the destination, so don't be surprised to see a message "trigger vm-delete successful" after the "trigger vm-relocate successful" message in realtime log]. █ Option - "data:preserve" To keep all the storage after successful relocation on the source for whatever reason, use the key and value data:preserve with the trigger:relocate. SynchroKnot automatically makes the source virtual machine stagnant when data:preserve is used. The option data:preserve works with both manual and automatic virtual machine relocation. Example: trigger:vm-relocate data:preserve sfa:28.9.0.4 d-sfa:28.9.0.1 synchroknot:webserver-32w5Nws7S5SPAd9Uz5oHckuu1eqfPsUC6N trigger:vm-relocate d-vector: data:preserve performance: sfa:28.9.0.1 synchroknot:webserver-13ttthWjYmTMKtHxx5f7DJ23PpMDri1PHi trigger:vm-relocate intercosm: macrocosm: microcosm: d-vector: d-mask: data:preserve performance: sfa:28.9.0.1 synchroknot:webserver-13ttthWjYmTMKtHxx5f7DJ23PpMDri1PHi *** Important: To prevent failure in virtual machine relocation please make sure the following conditions are adhered to: *** a] Before relocating, the virtual machine's cdrom value must be made blank. If the cdrom is attached, then it must be detached. b] Though vSoC takes care of it, it would help if open console[s] [java applet, html5, vnc/spice client etc] used to access the virtual machine is closed. c] The destination *MUST NOT* have a stagnant copy of the virtual machine. d] Please do not perform any operations [pause, unpause etc] while it is relocating. e] Please do not symlink the virtual machine's disk[s] outside the BTRFS volume where it was automatically placed at the time of creation. Virtual machines with symlinked disk[s] will not relocate. *** Important: virtual machines with Interstellar and Interstellar Resonance IDs enabled *MUST ONLY* be relocated to Spatial Fabric Arrays that have the Interstellar/ARPless Interstellar Power Module present and active on the Spatial Fabric Satellite. ***

║█║║║ Modify Virtual Machine

█ Legal characters when using trigger:vm-modify: + ; = % , . _ 0-9 a-z A-Z - █ To insert a space use %20 or # Eg. information:This%20is%20SynchroKnot OR information:This#is#SynchroKnot As a built-in security feature aimed at protecting and keeping spatial clusters of Tenants securely bifurcated, certain QEMU options may not work or are not supported. Please refer to the updated QEMU manual for additional details wherever you see [QEMU option(s)]. *** IMPORTANT: Using certain QEMU options requires specific drivers to be present in the virtual machine before you can use those options. It is recommended that those drivers are installed in the virtual machine[s] beforehand, and tested on the QEMU commandline to ensure that they work as expected before you modify the virtual machine Spacesuit. *** █ Multi-order edits are possible with the help of the built-in Intelligent Modification Logic and Engine. You should be able to edit in any order or combination all at once, and all the respective configuration(s) and service(s) will automatically be updated by SynchroKnot! █ Multi-order edits are not possible when used with sub-triggers like Create, Remove, Grow and Shrink virtual disks as explained under the Storage Operations section. █ To unset a value of a key[s] set a blank value to unset it. Eg. key:
█ Virtual Machine Modify Options [trigger:vm-modify] :
■ vm-sdac-id vm-sdac-id:[csv synchroknot[0-9]*] -- and up to 15 comma separated values [csv]. Please keep synchroknot[numbers] to a reasonable size for ease of management. vm-sdac-id:synchroknot100 vm-sdac-id:synchroknot100,synchroknot4000,synchroknot33,synchroknot2000 ■ Priority The virtual machine starts with the normal priority 0. Priority can be set from 0 to 19 OR 0 to -20. The priority set to a virtual machine takes effect when the virtual machine is started from a stopped state. To set a priority other than normal, the following can be done: priority:{any number between 0 to 19 OR 0 to -20} Normal Priority : 0 Low Priority : 3 to 6 Very Low Priority : 7 to 19 High Priority : -3 to -7 Very High Priority : -8 to -20 Example: priority:15 priority:-4 ■ Enable Replica replica:enable ■ Disable Replica replica:disable ■ Memory memory:2G ■ CPU cpu:[QEMU option(s)] ■ USB0 USB0 is an automatic USB slot that supports qemu-xhci, ich9-usb-ehci1, pci-ohci. Add usb-tablet or usb-kbd or usb-mouse or all together separated by commas eg. usb-tablet,usb-kbd,usb-mouse Examples: usb0:qemu-xhci,usb-tablet,usb-kbd,usb-mouse -OR- usb0:ich9-usb-ehci1,usb-tablet,usb-kbd,usb-mouse -OR- usb0:pci-ohci,usb-tablet,usb-kbd,usb-mouse ■ USB1 USB1 is an automatic USB slot that supports qemu-xhci, ich9-usb-ehci1, pci-ohci. Add usb-tablet or usb-kbd or usb-mouse or all together separated by commas eg. usb-tablet,usb-kbd,usb-mouse Examples: usb1:qemu-xhci,usb-tablet,usb-kbd,usb-mouse -OR- usb1:ich9-usb-ehci1,usb-tablet,usb-kbd,usb-mouse -OR- usb1:pci-ohci,usb-tablet,usb-kbd,usb-mouse ■ PCI0 PCI0 is an automatic PCI slot that supports i82801b11-bridge|ioh3420|pci-bridge|pci-bridge-seat|pxb|pxb-pcie|x3130-upstream|xio3130-downstream. Examples: pci0:ioh3420 pci0:i82801b11-bridge pci0:ioh3420,[option[s] separated with comma[s]] ■ VIRTIO0 VIRTIO0 is an automatic VIRTIO slot that supports virtio-keyboard|virtio-mouse|virtio-tablet|virtio-gpu Add virtio-keyboard or virtio-mouse or virtio-tablet or virtio-gpu with options separated with commas or all together separated by commas eg. virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu Examples: virtio0:virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu virtio0:virtio-gpu,{option[s] separated with comma[s]} virtio0:virtio-tablet virtio0:virtio-keyboard virtio0:virtio-mouse ■ VIRTIO1 VIRTIO1 is an automatic VIRTIO slot that supports virtio-keyboard|virtio-mouse|virtio-tablet|virtio-gpu Add virtio-keyboard or virtio-mouse or virtio-tablet or virtio-gpu with options separated with commas or all together separated by commas eg. virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu Examples: virtio1:virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu virtio1:virtio-gpu,{option[s] separated with comma[s]} virtio1:virtio-tablet ■ VIRTIO2 VIRTIO2 is an automatic VIRTIO slot that supports virtio-keyboard|virtio-mouse|virtio-tablet|virtio-gpu Add virtio-keyboard or virtio-mouse or virtio-tablet or virtio-gpu with options separated with commas or all together separated by commas eg. virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu Examples: virtio2:virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu virtio2:virtio-gpu,{option[s] separated with comma[s]} ■ VIRTIO3 VIRTIO3 is an automatic VIRTIO slot that supports virtio-keyboard|virtio-mouse|virtio-tablet|virtio-gpu Add virtio-keyboard or virtio-mouse or virtio-tablet or virtio-gpu with options separated with commas or all together separated by commas eg. virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu Examples: virtio3:virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu virtio3:virtio-gpu,{option[s] separated with comma[s]} ■ BIOS Set the filename for the BIOS. The file must be present in the storage volume of the virtual machine. bios:[filename] ■ RTC Set the realtime clock rtc:[QEMU option(s)] ■ Watchdog The following hardware watchdog models are supported: ib700|i6300esb|diag288 The following watchdog actions are supported: pause|shutdown|poweroff|debug|none|reset. If the key "watchdog-action:" is not set, it will default to the watchdog action reset. Please refer to the QEMU manual for more details. Example: watchdog:[ib700|i6300esb|diag288] watchdog-action:pause watchdog:ib700 ■ Virtualization By default, virtualization is set to "kvm". For pure emulation, set the value to "qemu". virtualization:qemu ■ Keyboard keyboard:[QEMU option(s)] ■ SMP smp:[QEMU option(s)] ■ Location eg. location:example-location location:example%20location location:example#location Legal characters: % - _ 0-9 a-z A-Z ■ Excerpts Up to 15 comma separated values. Legal characters: 0-9 a-z , - eg. excerpts:linux,webserver,production ■ Spice Console Password spice-password:[less than 15 characters: a-zA-Z0-9] ■ VNC Console Password vnc-password:[less than 25 characters: a-zA-Z0-9] ■ Boot Order boot:[cdrom0 | cdrom1 | disk0 - disk24] The virtual machine can boot from either cdrom0 or cdrom1 or any one of the disks from 0 to 24 i.e disk0 to disk24. ■ CDROM The iso must already be present in the virtual machine's storage volume to be attached. cdrom0:[name of the iso] -- will attach the cdrom when the virtual machine is started from the stopped state. cdrom1:[name of the iso] -- will attach the cdrom when the virtual machine is started from the stopped state. cdrom0-attach:[name of the iso] -- will attach the cdrom to a running virtual machine. The cdrom0:[name of the iso] must be set before that. cdrom1-attach:[name of the iso] -- will attach the cdrom to a running virtual machine. The cdrom1:[name of the iso] must be set before that. cdrom0-detach: -- detaches the attached cdrom from a running virtual machine. cdrom1-detach: -- detaches the attached cdrom1 from a running virtual machine. *** Important: Before relocating, the virtual machine's cdrom0/cdrom1 value must be made blank by modifying the key without assigning it a value [eg. cdrom0: and cdrom1: ]. If the cdrom is attached then it must be detached. *** ■ Machine machine:[QEMU option(s)] ■ Soundhw soundhw:[QEMU option(s)] ■ VGA vga:[QEMU option(s) eg. std|cirrus|none] ■ Remove Migration Tag In some failed virtual machine relocations the virtual machine might show that it is still migrating, but it might not have migrated due to an underlying failure. So, to remove this tag do: migration-tag:remove

║█║║║ Network Operations

■ Add NIC add-nic:[single or csv from 0 to 49] Eg. add-nic:1 OR add-nic:1,2,3,4,5,6,7,8,9 Note: change the NIC status to plugged after adding it for it to show up in the virtual machine. Read more about NIC Status below. ■ Delete NIC Eg. delete-nic:1 OR delete-nic:1,2,3,4,5,6,7,8,9 ■ NIC Status - Plugged and Unplugged Once the NIC has been added with add-nic it will not be plugged into the virtual machine unless one plugs it in. The results of plugging and unplugging NIC(s) take effect at the starting of the virtual machine from the stopped state. Operating systems may benefit from recognizing the NIC that was plugged back after being previously unplugged, and might keep the same ordering, name and other details, reducing the chances of misconfiguration. nic1-status:plugged nic1-status:unplugged add-nic:1 nic1-status:plugged It is also possbile to add an NIC, plug it in and assign it an IP address, Netmask and all the SpaceBuoy options [see below] all together in one shot! add-nic:1 nic1-status:plugged nic1-ip:10.33.33.33 nic1-gateway-ip:10.33.33.1 ■ NIC Model nic[0-49]-model:[QEMU option(s)] Eg. nic0-model:e1000 ■ NIC MAC Address nic[0-49]-mac:[Last 5 hexadecimal characters of a mac address] Eg. nic0-mac:12345 Note: a unique algorithmically-generated MAC address specific to virtual machine and its network interface is assigned when a new virtual machine is created or when a new NIC is added. To change that use nic[0-49]-mac: and/or nic[0-49]-interstellar-mac: ■ NIC Interstellar MAC Address nic[0-49]-interstellar-mac:[First 7 hexadecimal characters of the MAC address with dac as a prefix] Eg. nic0-interstellar-mac:dac0001 ■ NIC Interstellar Resonance - This works only with the Interstellar/Arpless Interstellar Power Module nic[0-49]-interstellar-resonance:[First 7 hexadecimal characters of the MAC address with dac as a prefix and up to 10 Interstellar Resonance IDs csv] nic0-interstellar-resonance:dac0002 nic0-interstellar-resonance:dac0002,dac0004 *** Interstellar Resonance IDs can be anything other than nic[0-49]-interstellar-mac. *** ■ INTERSTELLAR OUI - This works only with the Interstellar/Arpless Interstellar Power Module interstellar-oui:[6 hexadecimal characters of the MAC address of the target physical hardware or virtual machine which could be a switch, router, dhcp server etc. Up to 10 OUI IDs csv]
║█║ SpaceBuoy
■ NIC IP Address - add public or private IP address to NIC using SpaceBuoy automatically. nic0-ip:[ip address in the 10|172|192 range] -- Eg. nic[0-49]-ip Eg : trigger:modify synchroknot:debian-webserver-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dkMm9 nic0-ip:10.33.33.33 nic0-gateway-ip:10.33.33.1 Note: Assigning a public IP address may work for you. Assigning public IP addresses starting with 101 to 110 are known to not work [i.e the virtual machine does not receive these IP addresses]. There may be other public addresses that may not work, but for the most part it seems to be working fine. Please take a look at one of the demo videos to get a better understanding. █ Important: ■ To reinstate all the additional options below into the SpaceBuoy, it is required to add or re-add the NIC IP Address [eg. nic[0-49]-ip:] ■ Per standard networking norms, if multiple NICs are added and IP addresses are assigned to them, then necessary routes and default gateways may need to be added to them for traffic to traverse via their respective interfaces. Likewise, assigning multiple default gateways to multiple interfaces may not be possible via standard DHCP server in all the case scenarios, and might need to be added manually or via a script. ■ The operating systems and their DHCP client must support the standard DHCP features for all the DHCP options below to work. Eg. some operating systems may not accept the hostname sent to them by the DHCP server, some may not add a classless static route, DNS server and so on. As required, the operating system and its DHCP client configuration may need to be tweaked to get all the options working. It could then be made a part of the "Virtual Machine Spacesuit" so that the new virtual machines created from it work as configured and expected. ■ The IP address assigned to a network interface [eg. nic0] corresponds to its relevant MAC address [eg. nic0-mac] as seen under the "Network" -> "NIC0" tab. If multiple NICs are assigned to the virtual machine, the IP address will be assigned to the relevant MAC address [eg. nic0-mac] providing a DHCP client is listening for the MAC address. If a bridge is used with multiple interfaces, then the bridge may choose a MAC address on its own from the relevant NICs assigned to it. Therefore, in the case of a bridge, if a single IP address needs to be assigned to it while it has multiple NICs, your operating system's bridge configuration must be given a static "hardcoded" MAC address on which the DHCP client will listen and accept the assigned IP address via the SpaceBuoy. Depending on your operating system, a service restart or reboot may be required for its DHCP client to function as needed. Below are the modifications: ■ NIC IP Gateway Address - add public or private IP gateway address using SpaceBuoy automatically. nic0-gateway-ip:[gateway ip address in the 10|172|192 range] -- Eg. add-nic[0-49]-gateway-ip ■ NIC Netmask - add netmask for the NIC IP Address. nic0-netmask:[valid legal netmask] -- Eg. nic0-netmask:255.255.255.0 ■ NIC Broadcast - add broadcast for the NIC IP Address. nic0-broadcast:[valid legal broadcast] -- Eg. 192.168.1.255 ■ NIC DNS Server -- add up to five DNS Server IP addresses separated by a comma nic0-dns-server: ■ NIC Domain Name - add a domain name nic0-domain-name:[domain name] -- Eg. nic0-domain-name:synchroknot.everywhere ■ NIC Domain Search nic0-domain-search:[domain name] ■ NIC NTP Server nic0-ntp-server: ■ NIC MTU - add a MTU nic0-mtu:[legal MTU size] ■ NIC Classless Static Route - Set a classless static route for the network interface. nic0-classless-static-route: Example: nic0-classless-static-route:192.168.55.0/16,192.168.55.56,10.0.0.0/8,172.16.1.1 ■ NIC IP Forward Enable - Enable IP forwarding for the interface. nic0-ip-forward-enable: ■ NIC Log Server nic0-log-server: ■ NIC Netbios NS nic0-netbios-ns: ■ NIC Netbios DD nic0-netbios-dd: ■ NIC Netbios Node nic0-netbios-nodetype: ■ NIC SMTP Server nic0-smtp-server: ■ NIC Pop3 Server nic0-pop3-server: ■ NIC TCP Keepalive nic0-tcp-keepalive:
║█║ DHCPCAST
■ To enable DHCPCAST for a network interface: nic[0-49]-dhcpcast:[mac address of the destination dhcp server without the : separator] Eg. trigger:vm-modify synchroknot:debian-webserver-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dkMm9 nic0-dhcpcast:dac000143797 ■ To disable dhcpcast, simply set a blank nic[0-49]-dhcpcast: OR nic[0-49]-ip: Eg. trigger:vm-modify synchroknot:debian-webserver-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dkMm9 nic0-dhcpcast: * Important: If you use the Interstellar Power Module, the destination dhcp server should have the same Interstellar ID or Interstellar Resonance ID. In the case where you happen to use the Interstellar Power Module and the dhcp server cannot have the same Interstellar ID or Interstellar Resonance ID, then one can set the interstellar-oui. *
║█║ Flood Control
Flood Control is a built-in mechanism for protection from various types of flooding within and across the Spatial Cluster. It is designed to reduce the number of specific types of packets exiting the virtual machine. It can be enabled on a virtual machine. If enabled on a Spacesuit, then all the virtual machines created from that Spacesuit will inherit the Flood Control properties. Flood Control works with ARP, Multicast, DHCP4 [IPv4], DHCP6 [IPv6], DNS and IPv6 related Router Solicitation, Router Advertisement, Neighbour Solicitation and Neighbour Advertisement. No agent / software needs to be installed in the virtual machine. Flood Control automatically takes care of all the complexities when used along with SpaceBuoy, DHCPCAST, ARPLESS Interstellar, Interstellar and other Built-ins and Power Modules. Flood Control can be modified with the trigger vm-modify. The options below can be modified as a single modification or multiple modifications [i.e all in a line along with modifications other than those of Flood Control!] as preferred. All the underlying complexities will be taken care of by Synchroknot by allowing all the modifications to be performed automatically and the results reflected in realtime. There are two components: 1] Limit - maximum average packets to limit/reduce per second, minute, hour or day. packets/[second|minute|hour|day] - Eg: 2/minute 2] Burst - maximum initial packets allowed until Limit takes effect. Value for the key *-burst is not a requirement. *IMPORTANT*: ■ Only Synchroknot root user [synchroknot0] can make these modifications. ■ Setting a very low Limit and/or Burst may adversely affect the virtual machine communication. ■ Setting a high Limit and/or Burst may not reduce the excessive traffic. ■ Determine the appropriate Limit and/or Burst for the virtual machine by testing the functionality end-to-end. Eg. If DHCP4 Limit/Burst is set, then see if the virtual machine gets an IP address from SpaceBuoy, DHCPCAST or DHCP server. If ARP Limit/Burst is set then test if the virtual machine can ping other virtual machines present in the Spatial Cluster [i.e able to send and receive ARP packets] and so on. ■ Key[s] without any value automatically unset those respective key[s]. The following options are supported: ■ ARP arp-limit: arp-limit-burst: Eg: arp-limit:6/minute arp-limit-burst:18 ■ DHCP4 dhcp4-limit: dhcp4-limit-burst: Eg: dhcp4-limit:6/minute dhcp4-limit-burst:18 ■ DHCP6 dhcp6-limit: dhcp6-limit-burst: ■ DNS dns-limit: dns-limit-burst: ■ Multicast multicast-limit: multicast-limit-burst: ■ IPv6 Router Solicitation router-solicitation-limit: router-solicitation-limit-burst: ■ IPv6 Router Advertisement router-advertisement-limit: router-advertisement-limit-burst: ■ IPv6 Neighbour Solicitation neighbour-solicitation-limit: neighbour-solicitation-limit-burst: ■ IPv6 Neighbour Advertisement neighbour-advertisement-limit: neighbour-advertisement-limit-burst:

║█║║║ Storage Operations

■ Disk Attach Slot disk[0-24]-attach-slot:[name of the virtual disk. This virtual disk must be present in the virtual machine's storage volume. The attached disk will be seen by the operating system when it is started from a stopped state. It would be logical to keep the disk name as same as the disk[0-24]-attach-slot name if possible.] Eg. disk1-attach-slot:disk1 █ IMPORTANT: *** When a disk is attached it is automatically given the QEMU option of type as virtio-blk-pci, format as raw and cache as writeback. These options can be changed. The raw format [with type virtio] is known for its performance. It is advised to keep the QEMU cache writeback option. It is recommended that these options are not tweaked. *** *** Please make sure the necessary virtio drivers are pre-installed in the operating system running in the virtual machine if you would like it to boot or use the virtual disks with the type virtio-blk-pci. *** Below are the options to modify the type and cache: ■ Disk Type disk[0-24]-type:[virtio-blk-pci|virtio-scsi-pci|nvme|ide-drive] Eg. disk0-type:virtio-blk-pci ■ Disk Cache disk[0-24]-cache:[writeback refer QEMU option(s)] Eg. disk1-cache:writeback ■ Disk Format disk0-format:[raw or qcow2 refer QEMU option(s)] ---- disk[0-24]-format -- up to 25 virtual disks supported. Eg. disk0-format:raw ■ Disk Detach Slot disk[0-24]-detach:[name of the virtual disk. This virtual disk must be present in the virtual machine's storage volume. The detached disk will not be seen by the operating system when it is started from a stopped state.] Eg. disk1-detach-slot:disk1
■ Create Virtual Disk
To trigger:vm-modify add the following options to create a disk: disk:create name:[name of the disk] type:[raw|qcow2] size:[eg. 50K or 50M or 50G or 50T - capital K/M/G/T is required for kilobytes, megabytes, gigabytes and terabytes] Example: trigger:vm-modify sfa:[ip address] synchroknot:[virtual machine name] disk:create name:[diskname.raw] type:raw size:50M trigger:vm-modify sfa:[ip address] synchroknot:[virtual machine name] disk:create name:[diskname.qcow2] type:qcow2 size:50M *** IMPORTANT : trigger:vm-modify cannot have any other edits when used with sub-trigger disk:create. ***
■ Create Virtual Disk with a specific Block Size
Create a virtual disk with a specific block size to match the block size requirements of the applications [eg. databases etc] in the virtual machine. * Only works for the disk format qcow2. * To trigger:vm-modify add the following options to create a qcow2 disk with a specific block size: disk:create name:[diskname.qcow2] block-size:8K type:qcow2 size:50M *** block-size must be a power of two between 512 and 2048K [i.e 512 and 2048K/2M] *** Example: trigger:vm-modify sfa:[ip address] synchroknot:[virtual machine fullname] disk:create name:diskname.qcow2 block-size:8K type:qcow2 size:50M The virtual disks should be created quickly and will be shown under the storage volume of the virtual machine. In some cases, when a large virtual disk is created and the system resources are engaged in other tasks, the progress of the disk creation can be seen under the Storage Volume by comparing the "virtual size" to "disk size" of the disk being created [and clicking on information to refresh the data].
■ Remove Virtual Disk
To trigger:vm-modify add the following options to remove a disk: disk:remove name:[diskname.qcow2] *** Caution: the virtual disk will be permanently removed. *** *** IMPORTANT : trigger:vm-modify cannot have multiple edits when used with sub-trigger disk:remove. *** Example: trigger:vm-modify sfa:[ip address] synchroknot:[virtual machine name] disk:remove name:[diskname.qcow2]
■ Grow Virtual Disk
To trigger:vm-modify add the following options to grow a disk: disk:grow name:[diskname.raw] type:raw size:50M *** IMPORTANT : trigger:vm-modify cannot have multiple edits when used with sub-trigger disk:grow. *** Example: trigger:vm-modify sfa:[ip address] synchroknot:[virtual machine name] disk:grow name:[diskname.raw] type:raw size:50M trigger:vm-modify sfa:[ip address] synchroknot:[virtual machine name] disk:grow name:[diskname.qcow2] type:qcow2 size:100M
■ Shrink Virtual Disk
To trigger:vm-modify add the following options to shrink a disk: disk:shrink name:[diskname.raw] type:raw size:50M *** IMPORTANT : trigger:vm-modify cannot have multiple edits when used with sub-trigger disk:shrink. *** *** Caution: Before attempting to shrink a virtual disk, you *MUST* use file system and partitioning tools inside the virtual machine to reduce the allocated file system[s] and partition size[s]. Failure to do so will result in data loss *** * Caution: QCOW2 does not seem to support shrinking the virtual disk images. * Example: trigger:vm-modify sfa:[ip address] synchroknot:[virtual machine name] disk:shrink name:[diskname.raw] type:raw size:50M

║█║ Storage Datapath Access

Storage Datapath Access allows you to push and pull data [virtual machine disks, ISOs, spacesuits] to and from any Spatial Fabric Array. This can also be used as a pull-based back-up and/or archiving system. Another great use of Storage Datapath Access is the ease with which one can perform secure, controlled updating and versioning of spacesuits. For example, you can keep the main/original copy of the virtual machine spacesuit(s) at your location [head office, lab, control center, etc.], update the image with security, package and operating system updates/upgrades, test the functionality end-to-end, and then push it [only changed blocks] to as many Spatial Fabric Arrays that have those spacesuit(s)!!
█ To Access Data:
trigger:spatial-fabric-array-info sfa:[IP address] and look for port next to Storage Data Path OR trigger:spatial-fabric-array-list and look for S-PATH:[number] which is the port number of the Spatial Fabric Satellite *IMPORTANT* : Please make sure a password has been set before you can attempt to access the data. Use "trigger:datapath-secrets-info" to get information. rsync -a rsync://sknt0@10.9.0.1:22837 --password-file=[path to the file in the Linux user's home directory that contains the password. For ease of use, the file name can correspond to the rsync username sknt0|sknt1|sknt2.] Example: rsync -a --password-file=/root/sknt0 rsync://sknt0@10.9.0.1:22837 *IMPORTANT*: Make sure the password file is in the Linux user's home directory and only that Linux user has the reading rights to it, eg. chmod 400 and chown root:root /root/[your-password-file] Example output: spatial-fabric-array-log SYNCHROKNOT SPATIAL FABRIC ARRAY LOG ACCESS: Logs for 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE @ 28.9.0.1 spacesuit SYNCHROKNOT STORAGE DATAPATH ACCESS: virtual machine spacesuit for 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE @ 28.9.0.1 spatial-vm SYNCHROKNOT STORAGE DATAPATH ACCESS: virtual machines for 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE @ 28.9.0.1 resource-volume SYNCHROKNOT STORAGE DATAPATH ACCESS: resource volume for 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE @ 28.9.0.1 Note: You can then access all the volumes displayed and push/pull data.
To Update An Existing OR Newly Created Spacesuit/Virtual Machine:
1] ***MAKE SURE*** that the virtual machine disk that is intended to be pushed and used works with the supported QEMU-KVM syntax before-hand. [All QEMU-KVM options may not be supported, please read "IMPORTANT REQUIREMENTS FOR PERFORMANCE AND SCALABILITY"]. 2] Rsync directly to the "storage" directory of the Spacesuit or Virtual Machine 3] ***MAKE SURE*** that the virtual machine is in a stopped state [i.e turned off] before going ahead with the push. In the example below the disk named "tested-disk" with operating system Debian is pushed to spacesuit0-3HtqRozHuYpBukpWwf66stBceEXX7ZB2jA rsync -a --inplace --password-file=/root/sknt0 tested-disk rsync://sknt0@11.12.85.14:16201/tier0-spacesuit/spacesuit0-3HtqRozHuYpBukpWwf66stBceEXX7ZB2jA/storage/disk0 IMPORTANT: Use the "--inplace" option with Rsync. With this option, destination file[s] are updated in-place instead of creating a new copy of the file and then moving into place.
█ To Set/Modify Password[s]:
To set/modify the password of datapath secrets use the trigger:datapath-secrets-modify. ■ Up to four users [with usernames sknt0, sknt1, sknt2, sknt3] are allowed for multiple access to Storage Datapath. ■ Only Synchroknot root user [synchroknot0] can modify the passwords of sknt0, sknt1, sknt2 and sknt3. Eg. trigger:datapath-secrets-modify sknt0:yourpassword Eg. trigger:datapath-secrets-modify sknt0:yourpassword sknt1:sknt1password sknt2:sknt2password sknt3:sknt3password *IMPORTANT* : Please make sure a password has been set before you can attempt to access the data. Use "trigger:datapath-secrets-info" to get information.
█ To Get Datapath Secrets:
To get the datapath secrets usernames and passwords use the trigger: trigger:datapath-secrets-info ■ Only Synchroknot root user [synchroknot0] can view the usernames and passwords.
║█║║║ Spatial Fabric Satellite : Deployment Options
Cubicles, offices, shops, apartments, basements, wireless base stations, fibre optic hubs/stations etc. instead/alongside centralized data centers. Keep Spatial Fabric Satellites with virtual machines that communicate with each other with frequent/high network I/O in proximity to each other [Eg. within the same location i.e shelf/rack or close enough location[s]]. The network speed, capacity and bandwidth requirements mainly depend on the type of applications running in the virtual machines and the rate at which the infrastructure is scaled horizontally and/or vertically.

║█║║║ High Performance Switching with SATELLITE TREE PROTOCOL :

SynchroKnot vSoC software comes built-in with an *ACTUAL* automatic high-performance switch with Satellite Tree Protocol. It allows Spatial Fabric Satellites to be directly connected to eachother utilizing proven network topologies and without having to configure anything! SynchroKnot software enables and transforms SynchroKnot certified SoCs into an *ACTUAL* switch [eg. as seen in products from Cisco, Juniper and others], and not virtual switches like Open Virtual Switch [OVS] and related software. With this unique built-in automatic functionality, if you prefer, you *DO NOT* need physical or virtual switches anymore. Don't forget to see and learn from the demonstration videos and the explanations under the demo section of the website. To disable it for whatever reason, simply turn off STP with the brctl utility on all Spatial Fabric Satellites that see eachother on layer 2 : brctl stp synchroknot0 off Note: after disabling Satellite Tree Protocol you can use standard Ethernet switches and enable STP/RSTP, etc. on them as needed to connect Spatial Fabric Satellites. Channel Bonding is not supported on Spatial Fabric Satellites. The source code of the bridge kernel module should as usual be available at kernel.org or other locations. Feel free to not use it for whatever reason that deems fit. █ If you would like to use and benefit from the built-in Satellite Tree Protocol then: ■ Make sure your Ethernet ports [NIC/USB] are functional with their drivers loaded. The relevant interfaces must be visible in "ls /sys/class/net" ■ *** Important : *MAKE SURE* the Spanning Tree Protocol / Rapid Spanning Tree Protocol *DO NOT* reach Spatial Fabric Satellites. *** *** You should not need more than 4 Ethernet ports per Spatial Fabric Satellite unless you intend to use custom topologies. Only 2 Ethernet ports are needed for Ring topology and 4 Ethernet ports for Torus topology. *** Apart from Ethernet ports utilized in the direct connection of Spatial Fabric Satellites, an extra Ethernet port will be needed on those Spatial Fabric Satellite[s] that will be used to connect to your gateway[s] *** ■ To reduce uncertainties in the network, please do not connect Gigabit Ethernet port[s] to a 10 Gigabit Ethernet port[s]. ■ Choose the topology that suits your requirement below. An advanced topology guide may be available upon request! █ Satellite Tree Protocol has been available for free for quite sometime along with an article on how to learn and use it. URL: https://synchroknot.cloud/media/sstp-bridge.ko ARTICLE: https://vk.com/@synchroknot.cloud-learn-and-try-satellite-tree-protocol-hands-on-with-mininet
2 Port NIC for 1-D Ring Topology [X Axis] and 4 port NIC for 2-D Torus Topology [X and Y Axis].








Seamless Incremental Network Expansion of 1-D Ring Topology [using both one long cable and single length cable].








2-D Torus Topology.







Seamless Incremental Network Expansion of X and Y Axis.







Multipath Optimized Routes and Links for Mission Critical Operation.




║█║ FASTR - Fast Asynchronous Triggered Replication, Recovery & Disaster Recovery : Power Module

To use FASTR, create a virtual machine on the destination Spatial Fabric Array ["d-sfa:"] with the same first name of the source virtual machine which intends to be replicated. Make sure the name ends with "-fastr" For example, if virtual machine "webserver" needs to be replicated using FASTR, you will need to create a virtual machine on a different Spatial Fabric Array and name it "webserver-fastr". █ Place the "fastr-power-module.license", "fastr-power-module.license.sign" and "fastr-power-module.sknt" in "/var/www/synchroknot-modules" and do: chmod 400 fastr-power-module.license* chmod 700 fastr-power-module.sknt chown www-data:www-data fastr-power-module* █ Enable FASTR trigger:fastr-enable sfa:[IP where the virtual machine is located] d-sfa:[IP of the destination] fastr-vm:[fullname of the destination vm] block-size: bw: priority: interval: pm:fastr synchroknot:[fullname of the virtual machine] trigger:fastr-enable sfa:29.20.20.20 d-sfa:29.40.40.40 fastr-vm:webserver-fastr-14sZs5Vrgu4EuJJFiEVksCiaeT2GttWgYS block-size: bw: priority: interval: pm:fastr synchroknot:webserver-17ZjT7qGq4rDmxM96kGKLayEFodWzNa5th The default and the maximum block size is fixed at: 131072. If the value of "block-size:" is blank then the default value is 131072 priority:[any number between 0 to 19 OR 0 to -20] Normal Priority : 0 Low Priority : 3 to 6 Very Low Priority : 7 to 19 High Priority : -3 to -7 Very High Priority : -8 to -20 The key "bw:" is better left blank and not used. It refers to maximum transfer rate for the data sent. It is specified in units per second [Eg. 1m]. █ Start FASTR after enabling it trigger:fastr-start sfa: pm:fastr synchroknot: █ Disable FASTR trigger:fastr-disable sfa: pm:fastr synchroknot: █ Sync FASTR to Remote Site trigger:fastr-sync sfa: pm:fastr synchroknot: Note: FASTR must not be running to do a sync. █ Stop FASTR Stops FASTR after the current or next replication cycle: trigger:fastr-stop sfa: pm:fastr synchroknot: Immediately force stop FASTR: trigger:fastr-force-stop sfa: pm:fastr synchroknot: █ Recover FASTR trigger:fastr-recover sfa: pm:fastr synchroknot: █ Stop FASTR Recovery trigger:fastr-recover-stop sfa: pm:fastr synchroknot: trigger:fastr-unlock sfa: pm:fastr synchroknot: To remove recovery lock if FASTR complains that the recovery is in progress because there is a stale fastr recovery lock do: trigger:fastr-unlock sfa: pm:fastr synchroknot: All details regarding the FASTR replication status can be seen by clicking "FASTR" on the virtual machine's information page. FASTR will not automatically start when the Spatial Fabric Satellite [SoC] is started or rebooted.

║█║ Reliable Realtime Cache : Power Module

Realtime Cache delivers instantaneous, sub-millisecond search results from cached metadata. It works transparently with Decentralized Realtime Precision Parallel Search with all its features [excerpts, intercosm, microcosm and macrocosm]. ■ Updates [ metadata ] are received over reliable transport without making requests, and updates are only received if there is a change in metadata at the destination. ■ Updates from the destination can be soft or hard refreshed individually or with a combination of Destination Mask [ d-mask ], Microcosm, Macrocosm and Intercosm. ■ Reliable Realtime Cache brings about speed and reliability in managing a large number of decentralized systems with minimal overhead. ■ Reliable Realtime Cache can scale substantially and receive updates from a large number of SoCs [locally or globally]. ■ Reliable Realtime Cache works with its own trigger excerpts-rrtc-regex [similar in functionality to trigger excerpts-regex]. ■ Reliable Realtime Cache is further integrated with Shoutout, which means quick accessibility to specific custom sets/groups of virtual machines without having to know any other detail about their geographic location, tags, hardware, rack etc. ■ Reliable Realtime Cache substantially reduces network traffic [broadcast/unicast] while delivering instantaneous results. The only time taken [usually milliseconds] is when clicking on one of the results to retrieve the virtual machine's information in real-time from its actual location. █ Place the "reliable-realtime-cache-power-module.license" and "reliable-realtime-cache-power-module.license.sign" in "/var/www/synchroknot-modules" and do: chmod 400 reliable-realtime-cache-power-module.license* chown www-data:www-data reliable-realtime-cache-power-module.license* [There is no reliable-realtime-cache-power-module.sknt as it is fully built into the Data Decenter Fabric.] Only the "reliable-realtime-cache-power-module.license", "reliable-realtime-cache-power-module.license.sign" files need to be placed on the receiver denoted with the key "ip:" which can have up to 50 IP addresses separated with commas [CSV]. Reliable Realtime Cache Power Module automatically detects if it is the sender or receiver or both. No configuration necessary. That's it. Simple and easy enablement of a complex distributed realtime updation system! IMPORTANT: If the key "sfa:" has a blank value, then all the Spatial Fabric Arrays will be enabled. █ Enable Reliable Realtime Cache trigger:enable-reliable-realtime-cache intercosm: macrocosm: microcosm: sfa: d-vector: d-mask: timer: ip: trigger:enable-reliable-realtime-cache intercosm: macrocosm: microcosm: sfa:29.31.15.2 d-vector: d-mask: timer:1 ip:29.20.18.12,29.31.15.2 The key "timer:" can have a numeric value which refers to minutes. With "timer:1", Reliable Realtime Cache will check every one minute for change in the virtual machine status and metadata and will only send an update to the value of the key "ip:" if it intelligently ascertains there is a change worth updating. Even as the timer checks for changes after a defined time interval, certain important triggers intelligently ascertain the result of a change and invoke Reliable Realtime Cache into sending realtime updates. Example: If you give 25 IP addresses to the key "ip:" and have a total of 5000 SoCs, then you need to keep the above mentioned license files on the SoCs that have those 25 IP addresses that will act as receivers of updates. Then, upon using the "trigger:enable-reliable-realtime-cache" without giving the key "sfa:" a value, all the 5000 SoCs will get updated, out of which 4975 will automatically act as clients and 25 will be the SoCs that will be updated! Also, the SoCs acting as receivers will also act as senders and update themselves. █ Disable Reliable Realtime Cache trigger:disable-reliable-realtime-cache intercosm: macrocosm: microcosm: sfa: d-vector: d-mask: █ Refresh Reliable Realtime Cache To soft refresh on the next timer cycle do: trigger:reliable-realtime-cache-refresh intercosm: macrocosm: microcosm: sfa: d-vector: d-mask: Soft refresh prevents flooding if there are thousands of SoCs, as it will refresh and send updates on its next timer cycle. To hard refresh and receive updates immediately do: trigger:reliable-realtime-cache-hard-refresh intercosm: macrocosm: microcosm: sfa: d-vector: d-mask: ■ Refer to the "Excerpts" section to learn more about using "trigger:excerpts-rrtc-regex" ■ Refer to the "Shoutout" section to learn more about Reliable Realtime Cache equivalent of Shoutouts that can be accessed via the ">>" symbol or via "trigger:shoutout-rrtc".

║█║ Realtime Cache : Power Module

■ Realtime Cache delivers instantaneous, sub-millisecond search results from cached metadata. It works transparently with Decentralized Realtime Precision Parallel Search with all its features [excerpts, intercosm, microcosm and macrocosm]. ■ Realtime Cache works with its own trigger excerpts-rtc-regex [similar in functionality to trigger excerpts-regex]. ■ Realtime Cache is further integrated with Shoutout, which means quick accessibility to specific custom sets/groups of virtual machines without having to know any other detail about their geographic location, tags, hardware, rack etc. ■ Realtime Cache substantially reduces network traffic [broadcast/unicast] while delivering instantaneous results. The only time taken [usually milliseconds] is when clicking on one of the results to retrieve the virtual machine's information in real-time from its actual location. █ Place the "realtime-cache-power-module.license" and "realtime-cache-power-module.license.sign" in "/var/www/synchroknot-modules" and do: chmod 400 realtime-cache-power-module.license* chown www-data:www-data realtime-cache-power-module.license* [There is no realtime-cache-power-module.sknt as it is fully built into the Data Decenter Fabric.] █ Enable Realtime Cache Log into the Spatial Fabric Array as Synchroknot root [synchroknot0] and do: trigger:realtime-cache-modify timer:1 The key "timer:" can have a numeric value which refers to minutes. With "timer:1", Realtime Cache will update its cache every one minute by making a request over unreliable transport. The receiver is automatic, as it is built into the Data Decenter Fabric. █ Disable Realtime Cache trigger:realtime-cache-modify timer: The key "timer:" with a blank value stops and disables Realtime Cache. █ Refresh Realtime Cache "trigger:realtime-cache-refresh" refreshes Realtime Cache. █ Flush Realtime Cache "trigger:realtime-cache-flush" flushes the realtime cache. Realtime Cache populates again at the next time interval as set with the key "timer:".

║█║ Synchrosync : Power Module

Synchrosync transparently syncs Storage Volume(s) across Spatial Fabric Arrays [local/global]. Each tenant can synchronize their virtual machine's storage volume [full/delta-transfer] across Spatial Fabric Arrays locally or globally independent of the infrastructure provider, and without any special access [eg. ssh, rsync, sftp, ftp etc]. You may only do it on a per-file basis. You can repeat the triggers separately for multiple files. █ Place the "synchrosync-power-module.license", "synchrosync-power-module.license.sign" and "synchrosync-power-module.sknt" in "/var/www/synchroknot-modules" and do: chmod 400 synchrosync-power-module.license* chmod 700 synchrosync-power-module.sknt chown www-data:www-data synchrosync-power-module.license* trigger:synchrosync block-size: bw: priority: sfa: dest-ip: destination: pm:synchrosync synchroknot: The key "synchroknot:" is the source. The destination is the key "destination:" The key "sfa:" is the source Spatial Fabric Array and "dest-ip:" is the destination Spatial Fabric Array. Note: To sync data locally within the source Spatial Fabric Array, give the key "dest-ip:" the IP address of the same source Spatial Fabric Array. The default and the maximum block size is fixed at: 131072. If the value of "block-size:" is blank then the default value is 131072 priority:[any number between 0 to 19 OR 0 to -20] Normal Priority : 0 Low Priority : 3 to 6 Very Low Priority : 7 to 19 High Priority : -3 to -7 Very High Priority : -8 to -20 The key "bw:" refers to maximum transfer rate for the data sent. It is specified in units per second [Eg. 1m]. In example output below, the text colored yellow shows what can be used as values for the Synchrosync keys "destination:" and "synchroknot:" : rsync -a --password-file=/root/sknt0 rsync://sknt0@10.9.0.1:22837 spatial-fabric-array-log SYNCHROKNOT SPATIAL FABRIC ARRAY LOG ACCESS: Logs for 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE @ 28.9.0.1 spacesuit SYNCHROKNOT STORAGE DATAPATH ACCESS: virtual machine spacesuit for 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE @ 28.9.0.1 spatial-vm SYNCHROKNOT STORAGE DATAPATH ACCESS: virtual machines for 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE @ 28.9.0.1 resource-volume SYNCHROKNOT STORAGE DATAPATH ACCESS: resource volume for 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE @ 28.9.0.1 spatial-vm/{vm fullname}/storage/{disk name} -- storage volume of the virtual machine. Can be synced to : the destination spatial-vm/{vm fullname}/storage/{disk name | renamed disk name} the destination resource-volume/{disk name | renamed disk name} spatial-vm/{vm fullname}/spacesuit/spacesuit -- spacesuit volume of the virtual machine. Can only be synced to the destination virtual machine's spacesuit volume: the destination spatial-vm/{vm fullname}/spacesuit/spacesuit resource-volume/{disk name} -- generic volume to temporarily store virtual machine disks and ISOs. Can be synced to : the destination spatial-vm/{vm fullname}/storage/{disk name | renamed disk name} the destination resource-volume/{disk name | renamed disk name} Examples: trigger:synchrosync block-size: bw: priority: sfa:{IP} dest-ip:{IP} destination:[spatial-vm/{vm fullname}/storage/] synchroknot:[spatial-vm/{vm fullname}/storage/{disk name}] trigger:synchrosync block-size: bw: priority: sfa:{IP} dest-ip:{IP} destination:[spatial-vm/{vm fullname}/storage/{disk name | renamed disk name}] synchroknot:[spatial-vm/{vm fullname}/storage/{disk name}] trigger:synchrosync block-size: bw: priority: sfa:{IP} dest-ip:{IP} destination:[spatial-vm/{vm fullname}/storage/] synchroknot:[resource-volume/{disk name}] trigger:synchrosync block-size: bw: priority: sfa:{IP} dest-ip:{IP} destination:[spatial-vm/{vm fullname}/storage/{disk-name | renamed disk name}] synchroknot:[resource-volume/{disk name}] trigger:synchrosync block-size: bw: priority: sfa:{IP} dest-ip:{IP} destination:[resource-volume/] synchroknot:[resource-volume/{disk name}] trigger:synchrosync block-size: bw: priority: sfa:{IP} dest-ip:{IP} destination:[resource-volume/{disk-name | renamed disk name}] synchroknot:[resource-volume/{disk name}] trigger:synchrosync block-size: bw: priority: sfa:{IP} dest-ip:{IP} destination:[spatial-vm/{vm fullname}/spacesuit/spacesuit] synchroknot:spatial-vm/{vm fullname}/spacesuit/spacesuit trigger:synchrosync block-size: bw: priority: sfa:28.9.0.1 dest-ip:28.9.0.1 destination:resource-volume synchroknot:spacesuit/spacesuit0-1NKCDZhypfWxv1zQJEQYUtsGf4yZHrPnBE/spacesuit/spacesuit power-module:synchrosync trigger:synchrosync block-size: bw: priority: sfa:28.9.0.1 dest-ip:29.19.10.11 destination:spacesuit/spacesuit0-1NKCDZhypfWxv1zQJEQYUtsGf4yZHrPnBE/storage/disk0-res-vol synchroknot:resource-volume/disk0-copy power-module:synchrosync █ Create a virtual disk trigger:synchrosync-create sfa: size: pm:synchrosync synchroknot: The key "options:" supports different values [see example below]. Examples: trigger:synchrosync-create sfa:28.9.0.1 size:1G power-module:synchrosync synchroknot:spatial-vm/webserver-3FaqfVxJperG5WrVwzVV5vZF4S3eza6vMR/storage/testdisk.raw trigger:synchrosync-create sfa:28.9.0.1 size:1G power-module:synchrosync synchroknot:spatial-vm/webserver-3FaqfVxJperG5WrVwzVV5vZF4S3eza6vMR/storage/testdisk0 type:raw options:preallocation=falloc trigger:synchrosync-create sfa:28.9.0.1 size:1G power-module:synchrosync synchroknot:spatial-vm/webserver-3FaqfVxJperG5WrVwzVV5vZF4S3eza6vMR/storage/testdisk1.qcow2 type:qcow2 options:cluster_size=8K trigger:synchrosync-create sfa:28.9.0.1 size:1G power-module:synchrosync synchroknot:spatial-vm/webserver-3FaqfVxJperG5WrVwzVV5vZF4S3eza6vMR/storage/testdisk1.qcow2 type:qcow2 options:cluster_size=8K,preallocation=falloc trigger:synchrosync-create sfa:28.9.0.1 size:1G power-module:synchrosync synchroknot:spatial-vm/webserver-3FaqfVxJperG5WrVwzVV5vZF4S3eza6vMR/storage/testdisk1.qcow2 type:qcow2 options:cluster_size=8K,preallocation=metadata █ Remove a virtual disk trigger:synchrosync-remove sfa: pm:synchrosync synchroknot: █ List the Replications - See their progress - Stop replications with a click of a button trigger:synchrosync-list sfa: pm:synchrosync synchroknot:

║█║ Interstellar : Power Module

Interstellars are decentralized access control for virtual machines. Only the virtual machines with the same interstellar ID and interstellar resonance IDs can communicate with eachother irrespective of their location across Spatial Fabric Arrays [locally/globally]. All other communication [traffic] is blocked and sealed at layer 2, and not allowed to enter or leave the virtual machine's network interface[s]. If the Interstellar Power Module is present and active on the Spatial Fabric Satellite, then any tenant can make use of the interstellars for their virtual machine. Interstellars are configured, enabled and disabled on virtual machines. They can be controlled and managed by "trigger:vm-modify". Information regarding Interstellar status and other metadata is available under the "NETWORK" section of the virtual machine information page. Virtual machines with interstellar and interstellar resonance IDs enabled must only be relocated to Spatial Fabric Arrays that have the Interstellar Power Module present and active. █ Place the "interstellar-power-module.license", "interstellar-power-module.license.sign" and "interstellar-power-module.sknt" in "/var/www/synchroknot-modules" and do: chmod 400 interstellar-power-module.license* chmod 700 interstellar-power-module.sknt chown www-data:www-data interstellar-power-module.license* IMPORTANT : "interstellar-status:enabled" is a requirement whenever an Interstellar is modified and the changes need to be reflected in realtime, or else, changes will only be reflected at the time the virtual machine is started. ■ NIC Interstellar MAC Address nic[0-49]-interstellar-mac:[First 7 hexadecimal characters of the mac address with dac as a prefix] nic0-interstellar-mac:dac0001 Blank value to the key "nic0-interstellar-mac:" removes its value[s]. trigger:vm-modify sfa:28.9.0.1 synchroknot:tier0-spacesuit0-1NKCDZhypfWxv1zQJEQYUtsGf4yZHrPnBE nic0-interstellar-mac:dac0999 interstellar-status:enabled trigger:vm-modify sfa:28.9.0.1 synchroknot:+ nic0-interstellar-mac:dac0999 interstellar-status:enabled ■ NIC Interstellar Resonance nic[0-49]-interstellar-resonance:[First 7 hexadecimal characters of the mac address with dac as a prefix and up to 10 resonance ids as comma separated values] nic0-interstellar-resonance:dac0002 nic0-interstellar-resonance:dac0002,dac0004 Blank value to the key "nic0-interstellar-resonance:" removes its value[s]. trigger:vm-modify sfa:28.9.0.1 synchroknot:webserver-1LrBsisM28Dc4MdZ32XP1ZfCE4atzrx6vH nic0-interstellar-resonance:dac0088,dac0001 interstellar-status:enabled trigger:vm-modify sfa:28.9.0.1 synchroknot:+ nic0-interstellar-resonance:dac0088,dac0001 interstellar-status:enabled trigger:vm-modify sfa:28.9.0.1 synchroknot:+ nic0-interstellar-resonance: interstellar-status:enabled ■ Interstellar Status interstellar-status:enabled interstellar-status:disabled trigger:vm-modify sfa:28.9.0.1 synchroknot:+ interstellar-status:disabled ■ INTERSTELLAR-OUI interstellar-oui:[6 hexadecimal characters of the mac address of the hardware - switch/router/dhcp server etc] interstellar-oui gives virtual machines that are interstellar-enabled the ability to communicate with other physical or virtual hardware that does not have an interstellar id or interstellar resonance IDs. Blank value to the key "nic0-interstellar-oui:" removes its value[s]. trigger:vm-modify sfa:28.9.0.1 synchroknot:+ interstellar-oui:aaaaaa,ffffff,cccccc,bbbbbb interstellar-status:enabled It is possible to modify them all together at once with all the other virtual machine modifications!: trigger:vm-modify sfa:28.9.0.1 synchroknot:+ nic0-interstellar-mac:dac0999 nic0-interstellar-resonance:dac0088,dac0001 interstellar-oui:aaaaaa,ffffff,cccccc,bbbbbb interstellar-status:enabled Example depiction: VM A has Interstellar dac0001 -- VM B has Interstellar dac0001 -----> Communication Works. VM A has Interstellar dac0001 -- VM B has Interstellar dac0088 -----> Communication Does Not Work By Design. To make it work see below. VM A has Interstellar dac0001 + VM A has interstellar resonance dac0088 -- VM B has Interstellar dac0088 and interstellar resonance dac0001 -----> Communication Works. VM A has Interstellar dac0001 + A has interstellar resonance dac0088 -- VM B Only has Interstellar dac0001 -----> Communication Will Not Work By Design. [the vice-versa also will not work] - Interstellar Resonance is needed at both places like shown above.

║█║ ARPLESS Interstellar : Power Module

ARPless creates a secure vacuum for trusted communication between virtual machines, and also with the existing physical infrastructure. It comes integrated with Interstellar Power Module. ■ ARPless does not allow forced traffic diversion from poisoned ARP caches of virtual machines to reach undesired destination(s). ■ ARPless ignores requests from virtual machines that impersonate the original and authentic IP and MAC address pairs in order to force-divert traffic or gain access. ■ ARPless securely and intelligently auto-responds to the virtual machines when they make an ARP request [ no agent / software needs to be installed inside the virtual machine(s) ]. It does not allow ARP requests from the virtual machines to get onto the network. ■ ARPless can further limit ARP traffic within the secure vacuum. ■ ARPless practically makes ARP spoofing, ARP cache poisoning, or ARP poison routing very difficult-to-impossible, which in turn substantially reduces the possibilities of other attacks stemming from it, such as denial of service, man-in-the-middle, or session hijacking. ■ ARPless intelligently handles and manages the following opcodes : 1 Request, 2 Reply, 3 Request_Reverse, 4 Reply_Reverse, 5 DRARP_Request, 6 DRARP_Reply, 7 DRARP_Error, 8 InARP_Request and 9 ARP_NAK █ Place the "arpless-interstellar-power-module.license", "arpless-interstellar-power-module.license.sign" and "arpless-interstellar-power-module.sknt" in "/var/www/synchroknot-modules" and do: chmod 400 arpless-interstellar-power-module.license* chmod 700 arpless-interstellar-power-module.sknt chown www-data:www-data arpless-interstellar-power-module.license* ARPLess can be invoked using "trigger:vm-modify". First, configure Interstellar like shown in the "Interstellar" section, and then, configure ARPless with valid keys "arpless0:" to "arpless100:". These keys require a value of an IP address and MAC address [without the colon separator] separated by a "-". Eg. arpless0:192.168.1.111-dac00011eeee Multiple ARPLess keys and values can be modified all at once along with all the other virtual machine modifications if needed! An Arpless key with a blank value disables that particular key. trigger:vm-modify sfa:28.9.0.1 synchroknot:+ arpless0:192.168.1.111-dac00011eeee interstellar-status:enabled trigger:vm-modify sfa:28.9.0.1 synchroknot:appserver-1ATvunMb2ao3WP7tsJqHj2GZjv12dou9CZ arpless0:192.168.1.111-dac00011eeee interstellar-status:enabled In the above example, the key "arpless0:" has a value "192.168.1.111-dac00011eeee" which denotes the IP address with its actual MAC address without the colon separators. That's it. The configuration is that simple. SynchroKnot vSoC takes care of all the underlying complexity automatically. Please watch the video on the official website for a visual depiction of a real-world case scenario.

║█║ Level 2 Security With LDAP, ACTIVE DIRECTORY AND SSH : Power Module

Level 2 Security provides multi-faceted fault-tolerant authentication capability with LDAP, Active Directory and SSH individually or all together at once. In addition to Blockchain Authentication, as required, users can be made to authenticate with their Calibration code and SSH password or private key and LDAP and/or Active Directory password all together with fast response times [even when some back-end SSH and LDAP/Active directory servers may be down or not responsive.]. The type and combination of authentication can be customized per user. There is no such authentication capability seen in the industry today that provides speed of authentication [even amidst possible failures of the back-end], security to the user and organization, the ease of setup and management, and the flexibility of choosing the type and combination of authentication per user! ■ SSH servers that users authenticate against with their password or private key can further be enabled with AuthControl for Distributed Fault-Tolerant Authentication Management & Identification Control. [Please read "AuthControl - Distributed Fault-Tolerant Authentication Management & Identification Control".] ■ User(s) can authenticate to a combination of individual or multiple SSH servers and LDAP and/or Active Directory server(s). ■ Each user can be assigned with a separate list of SSH, LDAP and AD server(s) with an existing or new user-id/username present on them. █ Place the "level2-security-power-module.license" and "level2-security-power-module.license.sign" in "/var/www/synchroknot-modules" and do: chmod 400 level2-security-power-module.license* chown www-data:www-data level2-security-power-module.license* [There is no separate "level2-security-power-module.sknt" file as it is built into SynchroKnot Decentralized Identity Management.] Level 2 Security can only be configured by SynchroKnot Root [synchroknot0]. Note: The SynchroKnot Users' status must be "enabled" in order to log in and also to use Level 2 Security.
█ Level 2 Security with LDAP and Active Directory
█║ To use Level 2 Security with LDAP and Active Directory, configure your LDAP or/and Active Directory with "cn" [user] and "ou" [group] as desired, and use "trigger:synchroknot-modify" to enable the SynchroKnot user's "l2sec-backend". █ Up to 5 backends [0-4] are supported. See the example below. Example: If the cn [user] is "hackers", ou [group] is "superheros", dc is "dc=example,dc=com", IP address is 172.16.0.2 then the value of the key "l2sec-backend-0:" would look like: hackers#superheros#dc=example,dc=com#172.16.0.2 l2sec-backend-0:hackers#superheros#dc=example,dc=com#172.16.0.2 If a port other than 636 is used then do the following: l2sec-backend-0:hackers#superheros#dc=example,dc=com#172.16.0.2#389 Note: Only secure communication [eg. ldaps] is supported. Authentication will fail on insecure back-ends. Authentication will also fail for the user logging in with the message "Password Rejected" if the back-end[s] are unreachable. Per the new Level 2 Security syntax for LDAP and Active Directory, the "cn", "ou", "dc=example,dc=com", "IP" and "port" are separated by a "#" trigger:synchroknot-modify sfa:28.9.0.1 synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE l2sec-backend-0:hackers#superheros#dc=example,dc=com#172.16.0.2 l2sec-status:enabled "l2sec-status:enabled" and "l2sec-status:disabled" enables and disables Level 2 Security with LDAP and Active Directory for the user. Setting a blank value for the key "l2sec-backend-x:" disables and clears its value. Level 2 Security with LDAP and Active Directory for the user can also be enabled and disabled separately: trigger:synchroknot-modify sfa:28.9.0.1 synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE l2sec-status:enabled If you have multiple back-ends: trigger:synchroknot-modify sfa:28.9.0.1 synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE l2sec-backend-0:hackers#superheros#dc=example,dc=com#172.16.0.2 l2sec-backend-1:hackers#superheros#dc=example,dc=com#172.16.10.12 trigger:synchroknot-modify sfa:28.9.0.1 synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE l2sec-backend-0:superhackers#supremeforce#dc=supremeexample,dc=com#172.16.0.2 l2sec-backend-1:hackers#superheros#dc=example,dc=com#10.10.9.11 IMPORTANT : Make sure that your LDAP or Active Directory is reachable and configured appropriately by testing it beforehand. For testing or general ease of use you might consider setting up Go-lang LDAP Authentication (GLAuth), which is a secure, easy-to-use, LDAP server w/ configurable backends [available at github.com/nmcclain/glauth]. The above are some of the user-submitted configurations from sample-*.cfg files used in their testing.
█ Level 2 Security with SSH [Secure Shell]
█║ To use Level 2 Security with SSH [Secure Shell], set the appropriate values for the keys "l2sec-ssh-user:" and "l2sec-ssh-ip:". The user must exist on the machine where the ssh server is running and the users must be able to log in with their SSH password or Private Key. Up to 3 IP addresses can be configured. The IP address[es] must start with 192, 172 and 10 corresponding to the IP address and subnet in which your SSH servers reside. If Level 2 Security with SSH [Secure Shell] is enabled, then either an SSH Password or an SSH Private Key can be used to log in. The Private Key must be base64 encoded. Example: cat {path/to/your/private/key} | base64 -w0 cat .ssh/id_rsa | base64 -w0 Example: trigger:synchroknot-modify sfa:28.9.0.1 synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE l2sec-ssh-ip:192.168.9.11 l2sec-ssh-user:exampleuser trigger:synchroknot-modify sfa:28.9.0.1 synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE l2sec-ssh-ip:192.168.9.11,172.16.9.11,10.10.9.11 l2sec-ssh-user:exampleuser "l2sec-ssh-status:enabled" and "l2sec-ssh-status:disabled" enables and disables Level 2 Security with SSH for the user. Setting a blank value to the keys "l2sec-ssh-user:" and "l2sec-ssh-ip:" disables and clears their values.
█ Requirement: Set Up Core Level 2 Security Power Module for SSH and/or LDAP/AD Functionality
█║ To be able to use Level 2 Security with LDAP, ACTIVE DIRECTORY and SSH the core L2SEC Power Module must be set up with the appropriate IP address[es] To set up and configure Level 2 Security, point the Infrastructure Engine by directly opening the IP address of the Spatial Fabric Array and using "trigger:l2sec-modify". ■ To Enable Level 2 Security do: trigger:l2sec-modify l2sec-status:enabled ■ To Disable Level 2 Security do: trigger:l2sec-modify l2sec-status:disabled ■ To Enable Level 2 Security with IP address[es] do: trigger:l2sec-modify l2sec-ip:192.168.9.11 power-module:level2-security trigger:l2sec-modify l2sec-ip:192.168.9.11,172.16.9.11,192.168.10.12,10.10.9.11 l2sec-interstellar:dac0001 power-module:level2-security ■ To Retrieve Level 2 Security information do: trigger:l2sec-info ■ To Modify Level 2 Security Timeout do: trigger:l2sec-modify l2sec-timeout:[.1 to .9] The standard timeout for LDAP and SSH defaults to .3 [i.e 300 milliseconds] The key "l2sec-timeout:" must be set separately with "trigger:l2sec-modify" and cannot be given along with other keys mentioned above. █ To re-configure Level 2 Security, disable it and enable it again.

║█║ AuthControl : Power Module

AuthControl is a Distributed Fault-Tolerant Authentication Management & Identification Control System that serves as a scalable, secure and simple alternative to LDAP, Active Directory and other authentication systems. In AuthControl, the user[s] are responsible for managing their password. The user's password SHA512/GOST checksum is kept in their encrypted Spacesuit. The user[s] can log in to their virtual machines or physical hardware [eg. computers, tablets, mobile phones etc] with their standard Linux username and password + 5 digit unique pin. This 5 digit pin is set on each Spatial Fabric Satellite by the SynchroKnot Root User [i.e tenant], and is the same for all the users logging in via that particular Spatial Fabric Satellite, therefore there is no complexity of managing a unique pin for each user. This pin can be changed regularly and communicated to the users using any standard secure method that might already be in place for communication within the organization. Depending on the nature of the circumstance, user access can be restricted/limited by either simply changing the PIN on the Spatial Fabric Satellite or resetting/disabling the user's password in their Spacesuit. Authcontrol also has a distinguished capability of creating a unique numerical value corresponding to the user's ID [uid] and group ID [gid]. For example, a unique numerical value can be generated with Authcontrol for an existing/new user, and then that user ID can be modified to have the new AuthControl-generated unique numerical value. With Authcontrol-generated unique numerical value there is no need to depend anymore on any centralized system and database to generate new user IDs with a unique numerical value or check for their authenticity, as AuthControl will always return the same numeric User ID / Group ID for the username anywhere [local or global Spatial Fabric Satellites]. With AuthControl, user IDs can be instantly checked for changes/manipulations and reinstated automatically if changed. It can also report/alert without having to poll, check and compare with central or distributed databases. ■ Users with AuthControl mapping to their Blockchain IDs can log in or access resources transparently with their standard Linux Username and Password + 5 Digit PIN using the following methods: │ ├─> Graphical Login ├─> Graphical Screen Saver Login [eg. screen lock] ├─> Non-Graphical Login ├─> SUDO ├─> SU ├─> SSH ├─> SCP ├─> SFTP ├─> SSHFS ├─> FTP ├─> VNC - Virtual Network Computing ├─> RDP - Remote Desktop Protocol ├─> CUPs ├─> CRON ├─> SAMBA ├─> File Manager - Create Network Place with SFTP, SAMBA and FTP ├─> All password requirements via Control Center ├─> Practically anything that uses Standard PAM for authentication! ■ Fault Tolerant - AuthControl algorithmically checks for failures of up to 5 Spatial Fabric Satellites [geographically dispersed if needed] before returning unreachable. ■ Load Balanced - Each user or groups of users can be assigned different Spatial Fabric Satellites for load balancing [with additional option of fault-tolerance]. ■ Scalable - Add more Spatial Fabric Satellites and point more users to them. ■ Simple - Very easy to set up and manage. Works transparently with Linux PAM without modifying standard PAM modules, and is end-to-end encrypted [uses standard HTTPS for communication]. █ AuthControl Power Module consists of 2 parts: ■ Part 1 : "authcontrol-power-module.sknt" and licenses that are placed in "/var/www/synchroknot-modules" on the Spatial Fabric Satellite. ■ Part 2 : "authcontrol-ctl.sknt", "authcontrol.sknt" and "common-auth" that are placed inside the virtual machines. Modify the contents of the original "/etc/pam.d/common-auth" with the provided "common-auth" or replace the original with it [chown root:root | chmod 644]. █ Part 1 : Place the "authcontrol-power-module.sknt", "authcontrol-power-module.license" and "authcontrol-power-module.license.sign" in "/var/www/synchroknot-modules" and do: chmod 400 authcontrol-power-module.license* chown www-data:www-data authcontrol-power-module* chmod 700 authcontrol-power-module.sknt AuthControl can be configured using the Infrastructure Engine by directly opening the IP address of the Spatial Fabric Array and using "trigger:authcontrol-modify". It is designed not to be configured from an IP of another Spatial Fabric Array [i.e giving an IP address as a value to the key "sfa:"]. █ Create AuthControl: trigger:authcontrol-modify authcontrol-ip:[Up to 25 IP addresses starting with 192/172/10] trigger:authcontrol-modify authcontrol-ip:192.168.1.201 The value of the key "authcontrol-ip:" must have IP address[es] reachable from the virtual machines. █ Modify AuthControl Pin: The AuthControl Pin is an SHA512 checksum of the 5 Digit pin assigned by the Synchroknot root users [tenants] with "trigger:authcontrol-modify-pin". This pin is added [appended] to the password when the user authenticates using various methods into and across virtual machines that are AuthControl-enabled. trigger:authcontrol-modify-pin calibration-pin:[SHA512 checksum of your 5 digit pin] trigger:authcontrol-modify-pin calibration-pin:3627909a29c31381a071ec27f7c9ca97726182aed29a7ddd2e54353322cfb30abb9e3a6df2ac2c20fe23436311d678564d0c8d305930575f60e2d3d048184d79 Example: The value of the above key "calibration-pin:" is sha512 checksum of "12345" : echo -en "12345" | sha512sum ; echo 3627909a29c31381a071ec27f7c9ca97726182aed29a7ddd2e54353322cfb30abb9e3a6df2ac2c20fe23436311d678564d0c8d305930575f60e2d3d048184d79 - █ Information of AuthControl: trigger:authcontrol-info █ Start AuthControl: trigger:authcontrol-start █ Stop AuthControl: trigger:authcontrol-stop █ Stop AuthControl: trigger:authcontrol-remove █ Part 2 : Place "authcontrol-ctl.sknt" and "authcontrol.sknt" in the virtual machine as follows: 1] Copy "authcontrol.sknt" to "/usr/sbin" [chown root:root | chmod 700 ]. 2] Create a directory: "/tier0/synchroknot/gear/" and place "authcontrol-ctl.sknt" in it [chown root:root | chmod 700 ]. 3] Set up AuthControl structure with "trigger:authcontrol-modify" using "authcontrol-ctl.sknt" as root in the virtual machine[s]. 4] Generate and assign the existing/new Linux users in the virtual machine with a unique Synchroknot Global User ID with "trigger:synchroknot-global-id" using "authcontrol-ctl.sknt". 5] Interlock Map Linux User's ID with his/her Blockchain ID on the Spatial Fabric Array with "trigger:authcontrol-modify" using "authcontrol-ctl.sknt" as root in the virtual machine. Example: ./authcontrol-ctl.sknt <<< "trigger:authcontrol-modify synchroknot-id:[Linux User ID in the virtual machine] blockchain-id:[Bitcoin ID of the Synchroknot User on the Spatial Fabric Array]" 6] Interlock Map the Synchroknot User's Blockchain ID on the Spatial Fabric Array with the Linux User's ID with "trigger:synchroknot-modify" as SynchroKnot Root User [synchroknot0]. Example: trigger:synchroknot-modify sfa:[IP] synchroknot:[Blockchain ID of the User on SFA] sdac-pki-id:[Linux User ID on the virtual machine] trigger:synchroknot-modify sfa:28.9.0.1 synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE sdac-pki-id:exampleuser That's it! After the double Interlock mapping is complete, the Synchroknot users can assign/modify their passwords with "trigger:synchroknot-modify" on their respective single or multiple Spatial Fabric Array[s]! Example: trigger:synchroknot-modify sfa:[IP] synchroknot:[Blockchain ID of the User on SFA] synchroknot-user-password:[SHA512 checksum of the users' password generated by the users themselves.] trigger:synchroknot-modify sfa:29.14.56.17 synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE synchroknot-user-password:9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca72323c3d99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043 Example: The value of the above key "synchroknot-user-password:" is sha512 checksum of "hello" : echo -en "hello" | sha512sum 9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca72323c3d99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043 - On completion of the above steps, the users can authenticate with the password that they have set for themselves along with the 5 digit pin set by Synchroknot root users [i.e tenant admins using "trigger:authcontrol-modify-pin". Refer to "█ Modify AuthControl Pin" ]. Users access the virtual machines with their Tenant VPN [or on-site/locally with VLAN-Tagged traffic] for authentication using the different methods described above. Once logged into the virtual machines, the users can further authenticate to other virtual machines using the different methods described above. A basic demonstration video is available at the official website: synchroknot.cloud The Synchroknot Users are responsible for managing and updating their own passwords. Below is an example output of "trigger:authcontrol-help" from inside the virtual machine: /tier0/synchroknot/gear/authcontrol-ctl.sknt <<< "trigger:authcontrol-help" █ AuthControl Help: trigger:authcontrol-help █ Retrieve Information on AuthControl and Interlock Mapped Users: trigger:authcontrol-info █ Generate a SynchroKnot Global User ID: trigger:synchroknot-global-id user:{Linux User ID} █ Set Up and/or Modify AuthControl: trigger:authcontrol-modify spatial-cluster:{Spatial Cluster Bitcoin ID} timeout:{0.2 or 0.27 etc} authcontrol-ip:{up to 5 comma-separated private IP addresses} █ Interlock Map or Modify a Linux User to Blockchain ID: trigger:authcontrol-modify synchroknot-id:{Linux User ID} blockchain-id:{Bitcoin ID} █ Remove AuthControl User Interlock Mapping: trigger:authcontrol-modify synchroknot-id-remove:{Linux User ID} *Refer to the SynchroKnot Manual for more information. Note: The value of the key "authcontrol-ip:" is the IP address[es] of up to 5 Spatial Fabric Arrays. These IP addresses are assigned to different Spatial Fabric Arrays when AuthControl is created individually on them. Refer to "█ Create AuthControl" above. For example, if "authcontrol-ip:" had 5 IP addresses assigned, it would mean that the AuthControl Power Module will automatically and intelligently load-balance and provide resilience to failure across the 5 IP addresses. ■ All Synchroknot User information is available in the following ways: Clicking "█" on the right side of "SYNCHROKNOT" shows all the details of the Synchroknot User that is logged in. trigger:synchroknot-list rr:off intercosm: macrocosm: microcosm: sfa: d-vector:1 d-mask: synchroknot: trigger:synchroknot-info sfa: synchroknot: [This section will be updated with more examples.]

║█║ Blockchain SSH - Public Key Infrastructure [ PKI ] Management : Power Module

■ Transparent fast login to virtual machines via SSH using standard username [ non-root ]. ■ In the target virtual machine simply modify the sshd_config & run the setup script [this is a one time operation], and then map the Linux [or other operating system] username [ID] to the Blockchain ID of the SynchroKnot. That's it. ■ For fully secure access, the user's Linux and Blockchain Identity must be interlock-mapped. The SynchroKnot root user must add the Linux user ID to the Spacesuit of the user that was given SSH access. Only the SynchroKnot root user can perform this operation. ■ Users manage their own public key(s) [ Base64 encoded & up to 10 keys ] in their Spacesuit on upto 5 different Spatial Fabric Arrays [which may be geographically dispersed to protect against network and infrastructure failures]. ■ Only the authorized SynchroKnot [user] can add or remove his/her public key(s). █ The Blockchain SSH Power Module is integrated with AuthControl Power Module. To use Blockchain SSH, the user needs to be interlock mapped as shown in the AuthControl Power Module section. Once the user has been mapped, then follow the steps below: 1] In the virtual machine, simply place the provided "blockchainssh.sknt" in "/tier0/synchroknot/gear/" [ chown root:root | chmod 700 ] and modify the contents of the existing "/etc/ssh/sshd_config" with the provided "sshd_config" or replace the original. Make sure the SSH service is restarted. That's it! █ The Synchroknot users can now add up to 10 Base64 encoded public SSH keys to their Spacesuit on single/multiple Spatial Fabric Array[s] individually or all at once. █ The IP address[es] of Spatial Fabric Array[s] where the Synchroknot user's public SSH key[s] are kept must correspond to the IP address[es] of the Spatial Fabric Array[s] assigned with Authcontrol [key "authcontrol-ip:" of "trigger:authcontrol-modify" using "authcontrol-ctl.sknt" in virtual machines -- Refer to the AuthControl section]. For example, if IP addresses of 5 Spatial Fabric Arrays are given to "authcontrol-ip:", then the Synchroknot users can keep their public SSH key[s] on any/all of those IP address[es] of the Spatial Fabric Array[s] where they exist as a user. Keeping public SSH key[s] on more than 1 Spatial Fabric Array will increase the resilience from failure. █ The Synchroknot users are responsible for managing and updating their public SSH keys. Examples: trigger:synchroknot-modify sfa:[IP] synchroknot:[user's Blockchain ID] pki-0:[Base64 encoded SSH public key] trigger:synchroknot-modify sfa:[IP] synchroknot:[user's Blockchain ID] pki-0: pki-1: pki-2: pki-3: pki-4: pki-5: pki-6: pki-7: pki-8: pki-9: To get an Base64 encoded SSH public key do: echo -en "your public SSH key" | base64 -w0 ; echo cat .ssh/id_rsa.pub | base64 -w0 ; echo; ■ Blank value given to the keys "pki-0:" to "pki-9:" disables them. ■ All Synchroknot User information is available in the following ways: Clicking "█" on the right side of "SYNCHROKNOT" shows all the details of the Synchroknot User that is logged in. trigger:synchroknot-list rr:off intercosm: macrocosm: microcosm: sfa: d-vector:1 d-mask: synchroknot: trigger:synchroknot-info sfa: synchroknot: █ Failure to log in with Blockchain SSH falls back on password authentication via AuthControl. If AuthControl is not configured, then it further falls back on the Linux system's local password authentication or LDAP etc if configured.

║█║║║ SynchroKnot Auto NAT Enablement

SynchroKnot Auto NAT Enablement allows for transparent access to Infrastructure Engine and Virtual Machine Consoles [HTML5/Java], Realtime Log and more from behind NAT [Network Address Translation]. This feature allows for secure and easy setup & access from behind standard NATs so that Tenants can have direct access, or access from their VPNs without accessing the actual provider network. This feature brings about flexibility and simplicity, while at the same time allows the service providers to securely keep the Tenants separated. Excerpt from the SynchroKnot Manual: The Infrastructure Engine can be accessed by all Tenants in the 10.xxx.xxx.xxx range corresponding to the 28.xxx.xxx.xxx range IP address given to the Spatial Fabric Satellite. Eg. https://10.9.0.1/SynchroKnot.sknt To access the SynchroKnot Infrastructure Engine on a Spatial Fabric Satellite from the above description, the IP address of the machine used to access the Infrastructure Engine from the web browser must be in the 10.x.x.x range for security reasons. If you have a Tenant behind a transparent NAT in the 172.x.x.x range for example, and it is pointed to the 10.x.x.x range to access the Infrastructure Engine, then the access is possible but with certain limitations. The Infrastructure Engine will not know about the 172.x.x.x range from where the request is coming in, as it is on the other side of NAT. Therefore, the response[s] given would still be pointing to the 10.x.x.x range. This would cause the http and other requests & redirects such as Cross Domain Ajax, the opening of new tabs for websocket based HTML5 console access, Java based console access, Realtime Log .... and much more to NOT work. Example scenarios without the use of SynchroKnot Auto NAT Enablement: ■ Scenario A Works: [ web browser in 10.x.x.x range ] ------------> [ Infrastructure Engine in 10.x.x.x range ] Different types of redirects sent from the Infrastructure Engine work transparently. ■ Scenario B Does Not Work: [ web browser in 172.x.x.x range ] -----> [ NAT ] ------> [ Infrastructure Engine in 10.x.x.x range ] [ web browser in 192.x.x.x range ] -----> [ NAT ] ------> [ NAT ] -----> [ Infrastructure Engine in 10.x.x.x range ] Different types of redirects sent from the Infrastructure Engine are pointing in the 10.x.x.x. The web browsers in 172 & 192 ranges behind single and double NATs will trigger the redirect in the 10.x.x.x range but will not be able reach the destination in the 10.x.x.x range. The SynchroKnot Auto NAT Enablement feature transparently addresses this issue and allows full access just as if you were accessing the Infrastructure Engine from the 10.x.x.x network. The above Scenario A and B would work with SynchroKnot Auto NAT Enablement. This should work with any transparent NAT [eg. with IPtables etc]. This unique solution was possible with the combination of partly server-side + partly server-side-embedded-client-side functionality [which is unique to SynchroKnot]. One does not have to touch the transparent firewall! Eg. If you were using IPtables to DNAT and SNAT/Masquerade on a transparent NAT box in between, then simply set the 172.x.x.x range to point to 10.x.x.x. range. That's it. No need for further reconfiguration, updating the rules for mapping/unmapping/remapping ports, IP addresses etc. [We will share the details of how to set up a transparent IPtables NAT in our manual shortly.]
Creative Commons License
SynchroKnot [ website - content ] by SynchroKnot is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Based on a work by its creator Mehul Sharma at SynchroKnot : synchroknot.[cloud|systems|com|org|in|ru].