Walkthrough, services complete. Misc edits
@@ -1,6 +1,7 @@
|
||||
# ToDo
|
||||
|
||||
- Transfer HTML or refactor: Roadmap
|
||||
- Document diagnostic UI
|
||||
- Update principles, privacy, about, etc
|
||||
- Footer links need update (or removal?)
|
||||
- Add screenshots and details
|
||||
@@ -9,34 +10,21 @@
|
||||
- There are many issues that should be closed by 0.3 docs release, check that this is the case (some issues await new processes in order to test)
|
||||
- Update all guides in services
|
||||
- Launch versioned site/docs to start9.com
|
||||
- Address build errors after versioning is live
|
||||
- Address build errors
|
||||
|
||||
<!-- Original Layout (deprecated)
|
||||
<!-- Checklist
|
||||
# User Manual
|
||||
- Getting Started
|
||||
- Introduction
|
||||
- Purchasing
|
||||
- Initial Setup
|
||||
- Device-specific Setup Guides <label links with connectivity, performance, reliability, or tuning> - **ASK LUCY ABOUT "BADGES?"**
|
||||
- Linux
|
||||
- Mac
|
||||
- Windows
|
||||
- Android
|
||||
- iOS
|
||||
- Change to topic or hero boxes
|
||||
- (after release) create badges
|
||||
- Walkthrough
|
||||
- EmbassyOS Overview
|
||||
- Updating EOS
|
||||
- Services
|
||||
- Service Marketplace <link to marketplace>
|
||||
- Managing Services
|
||||
- Install / Uninstall
|
||||
- Instructions
|
||||
- Interfaces
|
||||
- Config
|
||||
- Backups
|
||||
- Properties
|
||||
- Logs
|
||||
- Dependencies
|
||||
|
||||
- Configuration
|
||||
- Basic Config
|
||||
- Name Your Embassy
|
||||
@@ -95,29 +83,14 @@
|
||||
- Embassy
|
||||
- Hardware
|
||||
- Software
|
||||
- Services
|
||||
|
||||
# Knowledgebase
|
||||
# Learn
|
||||
- Concepts
|
||||
- Open Source
|
||||
- Self-Hosting
|
||||
- Start9
|
||||
- EmbassyOS
|
||||
- Bitcoin/Lightning
|
||||
- Networks
|
||||
- LAN
|
||||
- SSL
|
||||
- Tor
|
||||
- FAQ
|
||||
- General
|
||||
- Embassy
|
||||
- Device
|
||||
- OS
|
||||
- DIY
|
||||
- Basic Usage
|
||||
- Services
|
||||
- Bitcoin
|
||||
- aLightning Network
|
||||
|
||||
# Developer Documentation
|
||||
- Service Packaging Guide
|
||||
|
||||
BIN
site/source/_static/images/services/service-ints.svg
Normal file
|
After Width: | Height: | Size: 89 KiB |
BIN
site/source/_static/images/services/service-ints0.svg
Normal file
|
After Width: | Height: | Size: 92 KiB |
BIN
site/source/_static/images/walkthrough/embassytab.svg
Normal file
|
After Width: | Height: | Size: 99 KiB |
BIN
site/source/_static/images/walkthrough/markettab.svg
Normal file
|
After Width: | Height: | Size: 71 KiB |
BIN
site/source/_static/images/walkthrough/notiftab.svg
Normal file
|
After Width: | Height: | Size: 36 KiB |
|
Before Width: | Height: | Size: 95 KiB After Width: | Height: | Size: 95 KiB |
BIN
site/source/_static/images/walkthrough/servicestab.svg
Normal file
|
After Width: | Height: | Size: 152 KiB |
@@ -87,7 +87,7 @@
|
||||
|
||||
.. This is for the side navigation display
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:maxdepth: 2
|
||||
:hidden:
|
||||
|
||||
start9
|
||||
|
||||
@@ -38,7 +38,6 @@ The server-side software available on EmbassyOS are referred to as "Services."
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
Some services have dependencies on other services. A service may even require its dependency to be *configured* in a particular way.
|
||||
|
||||
Traditionally, managing dependencies was a massive headache and a huge barrier to running a personal server. But no more! The Embassy's revolutionary dependency management system makes the process transparent and simple.
|
||||
@@ -53,8 +52,21 @@ Web User Interface (UI)
|
||||
-----------------------
|
||||
A User Interface, or UI, is as the name suggests, the way in which the user interacts with some software, typically in our context it will be a graphical interface (GUI). A WebUI is basically a website that is served (often by your Embassy) specifically for a user to issue commands or view data. A great example of this is EmbassyOS itself, which serves a WebUI for the user to add/remove services, make configurations, etc. This is your main point of contact with EOS.
|
||||
|
||||
.. _interfaces:
|
||||
|
||||
Service Interfaces
|
||||
------------------
|
||||
In EmbassyOS versions 0.2.x, each installed service received its own Tor hidden service URL. For some services, such as File Browser, the URL represented a website that could be visited in the browser; for other services, such as Bitcoin, the URL had to be input into a native client wallet such as Fully Noded or Specter.
|
||||
|
||||
Certain services, such as Bitcoin, actually have multiple interfaces. Bitcoin has an RPC interface, a P2P interface, and could potentially even have a graphical interface, such as a dashboard displaying important node information. Using the same URL for these various interfaces is not only confusing, it could potentially pose a security vulnerability. For example, a user may want to share their P2P interface address with someone for peering but not want to give out their UI address, which is for private use only.
|
||||
|
||||
As such, EmbassyOS 0.3.0 permits services to have multiple interfaces, each receiving its own Tor address and/or LAN address. Users can then view and access all interfaces for a given service inside the new :ref:`Interfaces <service-interfaces>` section of the service dashboard.
|
||||
|
||||
|
||||
.. _health-checks:
|
||||
|
||||
Health Checks
|
||||
-------------
|
||||
One of the most critical duties of a sysadmin or devops engineer is to build systems to monitor health. For example, a simple health check that monitors the availability of an LND node could mean the difference between that node having a poor reputation or a great one. Sometimes, it is not obvious when a service is unhealthy, especially since “health” is a subjective term depending on the subject. For example, is your Bitcoin node “healthy” if it is not fully synced? Is it healthy if the user interface is unreachable but everything else is working ok?
|
||||
|
||||
In EmbassyOS 0.3.0, package developers define what constitutes health and implement health checks according to subjective criteria that are then displayed to the user in easily digestible messages, complete with icons and colors. Even better, health checks are completely arbitrary and turing complete, meaning they can include anything, including config options and internal or external dependencies! For example, a Lightning wallet package developer could say “this service is only healthy if (1) it is fully synced, (2) Bitcoin is fully synced, (3) LND is fully synced, and (4) if and only if the user has opted for real-time pricing from a third party website, that third party website must be reachable.” Enormous power.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
.. _service_config:
|
||||
.. _service-config:
|
||||
|
||||
============================
|
||||
Service Config Specification
|
||||
|
||||
@@ -38,7 +38,7 @@ Image
|
||||
|
||||
Each service boils down to a Docker image. We're not going to dive into Docker specifics in this guide, since there exists tons of `resources <https://docs.docker.com/>`_ for developing with this containerization tool.
|
||||
|
||||
Because the service ultimately runs on a Raspberry Pi, the created Docker image should be a snapshot of an arm based linux environment. The service image is then mounted to the EmbassyOS image during installation. This path is defined in the :ref:`manifest <manifest>` configuration file.
|
||||
Because the service ultimately runs on a Raspberry Pi, the created Docker image should be a snapshot of an arm based linux environment. The service image is then mounted to the EmbassyOS image during installation. This path is defined in the :ref:`manifest <service-manifest>` configuration file.
|
||||
|
||||
The image is immutable, meaning that when the service is updated, the image is replaced with a completely new image containing the updated features.
|
||||
|
||||
@@ -63,7 +63,7 @@ This may sound cool or neat, but it is more than that: *it’s novel*. This has
|
||||
|
||||
The key to making the system work is a new, domain-specific-language (DSL) and set of standards that are used by developers to define the rules and requirements of their services. Run in the context of EmbassyOS, these rules and requirements appear as simple UI elements, such as inputs, toggles, and drop downs, and they are enforced by validations and clear user instructions. Using this system, what previously required involved time and expertise, can now be done by anyone in a matter of seconds.
|
||||
|
||||
This DSL is utilized in the :ref:`config rules <config_rules>` and :ref:`dependencies <dependencies>` key in the service manifest.
|
||||
This DSL is utilized in the :ref:`config rules <config_rules>` and :ref:`dependencies <service-dependencies>` key in the service manifest.
|
||||
|
||||
Manifest
|
||||
........
|
||||
@@ -83,7 +83,7 @@ There is nothing you need to do as a developer to enable the service to run over
|
||||
Config
|
||||
......
|
||||
|
||||
Most self-hosted applications require the user to tell the app how to behave using a config file in a specific format, environment variables, command-line arguments, or some combination of these inputs. One of the coolest features of EmbassyOS is that, when packaged correctly, the app's :ref:`configuration <service_config>` will be available to the user as a slick GUI that always produces a valid configuration no matter how little experience or skill the user has.
|
||||
Most self-hosted applications require the user to tell the app how to behave using a config file in a specific format, environment variables, command-line arguments, or some combination of these inputs. One of the coolest features of EmbassyOS is that, when packaged correctly, the app's :ref:`configuration <service-config>` will be available to the user as a slick GUI that always produces a valid configuration no matter how little experience or skill the user has.
|
||||
|
||||
With EmbassyOS, this means a service wrappers' configuration requires a particular format and rule structure to ensure it integrates smoothly with the user interface. This format enables clean handling of improper values and configuration dependencies.
|
||||
|
||||
|
||||
@@ -24,7 +24,9 @@ One thing is for certain though: if you control your server, then you control yo
|
||||
|
||||
Why do I care?
|
||||
--------------
|
||||
As an example, let's talk about the password manager, Bitwarden. It may help convey the concept of a personal server. Currently, when you use Bitwarden, your passwords are stored on a physical device (aka server) owned and operated by the Bitwarden team. Your phone or laptop sends requests to their server when you want to do anything: create an account, create a new password, retrieve existing passwords, etc. Your passwords are stored on their device, encrypted with your Bitwarden password. They are the custodian of your passwords, similar to getting a safe deposit box at the bank. The bank keeps your valuables in their vault, presumably they don't know what's in the box, and any time you want access to your box, you ask the bank for permission. This is exactly how a hosted Bitwarden experience works, as well as just about everything on the internet. When you install Bitwarden on your Embassy, by contrast, it's like building your own safe deposit box in a private bunker whose location is only known to you and whose keys only you posses. You create an account with yourself, store your passwords with yourself, etc. You are your own custodian. This same concept can be applied to just about everything on the Internet, without losing the convenience of the custodial model, which is what we are out to accomplish. This may sound cool, or neat, but it is so much more than that. The custodial data model is amongst the greatest threats to human liberty the world has ever seen.
|
||||
As an example, let's talk about the password manager, Bitwarden. It may help convey the concept of a personal server. Currently, when you use Bitwarden, your passwords are stored on a physical device (aka server) owned and operated by the Bitwarden team. Your phone or laptop sends requests to their server when you want to do anything: create an account, create a new password, retrieve existing passwords, etc. Your passwords are stored on their device, encrypted with your Bitwarden password. They are the custodian of your passwords, similar to getting a safe deposit box at the bank. The bank keeps your valuables in their vault, presumably they don't know what's in the box, and any time you want access to your box, you ask the bank for permission. This is exactly how a hosted Bitwarden experience works, as well as just about everything on the internet.
|
||||
|
||||
When you install Bitwarden on your Embassy, by contrast, it's like building your own safe deposit box in a private bunker whose location is only known to you and whose keys only you posses. You create an account with yourself, store your passwords with yourself, etc. You are your own custodian. This same concept can be applied to just about everything on the Internet, without losing the convenience of the custodial model, which is what we are out to accomplish. This may sound cool, or neat, but it is so much more than that. The custodial data model is amongst the greatest threats to human liberty the world has ever seen.
|
||||
|
||||
This `podcast <https://www.youtube.com/watch?v=aylDowaSdzU&t=270s>`_ may help expound upon why this is important.
|
||||
|
||||
@@ -44,7 +46,7 @@ The list of services will grow rapidly over the coming months, such that many th
|
||||
|
||||
What is EmbassyOS?
|
||||
------------------
|
||||
EmbassyOS is a new kind of Operating System (OS). It is built from the ground up to allow anyone to easily run their own ‘cloud,’ become independent from Big Tech, and own their own data. EmbassyOS allows anyone to easily self-host their own software services.
|
||||
EmbassyOS is a new kind of Operating System (OS). It is built from the ground up to allow anyone to easily run their own "cloud," become independent from Big Tech, and own their own data. EmbassyOS allows anyone to easily self-host their own software services.
|
||||
|
||||
EmbassyOS is a custom-built Linux distribution, which is a stripped down and beefed up version of `Raspbian Buster Lite OS <https://www.raspberrypi.org/software/operating-systems/>`_, along with a suite of software tools which make it easy to:
|
||||
|
||||
@@ -62,7 +64,7 @@ The .s9pk extension is Start9's custom package format based on tar. It encompass
|
||||
|
||||
What are EmbassyOS Services?
|
||||
----------------------------
|
||||
A Service can be any piece of software added to the Marketplace. All services are "self-hosted," meaning that you are in complete control of your data. This means you can run your own "cloud!" Learn more about managing services :ref:`here <managing-services>` and see our currently :ref:`Available Services <available-services>`.
|
||||
A Service can be any piece of software added to the Marketplace. All services are "self-hosted," meaning that you are in complete control of your data. This means you can run your own "cloud!" Learn more about managing services :ref:`here <managing-services>` and see our currently :ref:`Available Services <service-marketplace>`.
|
||||
|
||||
Does the Embassy ship worldwide?
|
||||
--------------------------------
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
.. _config:
|
||||
|
||||
=============
|
||||
Configuration
|
||||
=============
|
||||
@@ -11,4 +13,5 @@ Configuration, setup guides, and known limitations are provided here by device.
|
||||
tor-setup/index
|
||||
lan-setup/index
|
||||
wifi
|
||||
sessions
|
||||
limitations/index
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
.. _sessions:
|
||||
|
||||
===============
|
||||
Active Sessions
|
||||
===============
|
||||
|
||||
@@ -13,6 +13,7 @@ An overview of Services and Marketplaces on EmbassyOS.
|
||||
service-install
|
||||
service-config
|
||||
service-instructions
|
||||
service-properties
|
||||
service-actions
|
||||
service-interfaces
|
||||
service-logs
|
||||
|
||||
@@ -9,8 +9,6 @@ Currently, this is a link provided by the service package developer so that you
|
||||
.. figure:: /_static/images/services/donate.svg
|
||||
:width: 60%
|
||||
|
||||
Donate
|
||||
|
||||
.. topic-box::
|
||||
:title: Looking Forward
|
||||
|
||||
|
||||
@@ -1,7 +1,15 @@
|
||||
.. _interfaces:
|
||||
.. _service-interfaces:
|
||||
|
||||
==========
|
||||
Interfaces
|
||||
==========
|
||||
|
||||
Interfaces are URLs that a :ref:`Service<services>` uses to communicate in various ways with other software. Many Services will only have one interface, perhaps with a Tor and LAN address, to denote where it is hosted / accessed. Other services, such as Bitcoin or Lightning Nodes, may have several interfaces for different use-cases.
|
||||
|
||||
.. figure:: /_static/images/services/service-ints.svg
|
||||
:width: 60%
|
||||
|
||||
To view the instructions for a particular service, navigate to the :ref:`Services tab <services-tab>` *> [Service Name] > Properties*. From there you can copy a URL to your clipboard for use with external software.
|
||||
|
||||
.. figure:: /_static/images/services/service-ints0.svg
|
||||
:width: 60%
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
.. _logs:
|
||||
.. _service-logs:
|
||||
|
||||
====
|
||||
Logs
|
||||
@@ -6,4 +6,7 @@ Logs
|
||||
|
||||
Naviage to *Services > [Service Name] > Logs*
|
||||
|
||||
Every service emits logs while it is in a *running* state. Logs give an *under-the-hood* glimpse of a service and can be extremely useful for debugging purposes. To a non-technical user, logs may look like gibberish, and sometimes there is nothing to see at all.
|
||||
Every service emits logs while it is in a *running* state. Logs give an *under-the-hood* glimpse of a service and can be extremely useful for debugging purposes. To a non-technical user, logs may look like gibberish, and sometimes there is nothing to see at all. You can check here if you have an issue with a service, and if you are talking to support, they may ask you to screenshot or copy these logs to help discover the root of the problem.
|
||||
|
||||
.. figure:: /_static/images/services/logs.svg
|
||||
:width: 60%
|
||||
|
||||
@@ -6,6 +6,7 @@ Services Overview
|
||||
|
||||
Services are very similar to Applications on a mobile device. The biggest differences are that they are often designed to run constantly, with 24/7 availability for when a user requires them. This is why they are called :ref:`Services<services>`, they are always ready to serve users!
|
||||
|
||||
.. _service-page:
|
||||
|
||||
The Service Page
|
||||
----------------
|
||||
|
||||
@@ -1,15 +0,0 @@
|
||||
.. _properties:
|
||||
|
||||
==========
|
||||
Properties
|
||||
==========
|
||||
|
||||
Navigate to *Services > [Service Name] > Properties*
|
||||
|
||||
Properties are both static and dynamic information about a service. They could be almost anything: a default username/password, an invite code, or a list of peers - anything the service developer thought might be useful.
|
||||
|
||||
Properties may be accompanied by one or more of the following:
|
||||
|
||||
* a *help* icon for further explanation.
|
||||
* a *copy* icon for copying the value to your clipboard.
|
||||
* a *QR* icon for viewing the value as a QR code.
|
||||
@@ -0,0 +1,20 @@
|
||||
.. _service-properties:
|
||||
|
||||
==========
|
||||
Properties
|
||||
==========
|
||||
|
||||
Properties can contain both static and dynamic information about a service. They could be almost anything: a default username/password, an invite code, or a list of peers - anything the service developer thought might be useful.
|
||||
|
||||
.. figure:: /_static/images/services/props.svg
|
||||
:width: 60%
|
||||
|
||||
To view the instructions for a particular service, navigate to the :ref:`Services tab <services-tab>` *> [Service Name] > Properties*.
|
||||
|
||||
Properties may be accompanied by one or more of the following:
|
||||
|
||||
* a *help* icon for further explanation.
|
||||
* a *copy* icon for copying the value to your clipboard.
|
||||
* a *QR* icon for viewing the value as a QR code.
|
||||
|
||||
.. note:: Some services do not have any information in the Properties section
|
||||
@@ -1,9 +1,9 @@
|
||||
.. _updates:
|
||||
.. _service-updates:
|
||||
|
||||
========
|
||||
Updating
|
||||
========
|
||||
|
||||
To see if an update is available for a service, you can visit the *updates* section of the Marketplace or by visiting its Marketplace listing.
|
||||
To see if an update is available for a service, you can visit the *Updates* section of the Marketplace or by visiting its Marketplace listing.
|
||||
|
||||
If an update is available, simply click "Update" and confirm the action.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
.. _overview:
|
||||
|
||||
=====================
|
||||
Overview of EmbassyOS - ***NEED SCREENSHOTS / DETAILS***
|
||||
Overview of EmbassyOS
|
||||
=====================
|
||||
|
||||
.. _services-tab:
|
||||
@@ -11,8 +11,13 @@ Services Tab
|
||||
|
||||
The Services Tab will show you all of your currently installed :ref:`Services<services>`, or in the case of a fresh install, no Services.
|
||||
|
||||
Services
|
||||
========
|
||||
.. figure:: /_static/images/walkthrough/servicestab.svg
|
||||
:width: 60%
|
||||
|
||||
Click on any service in order to see its :ref:`Service Page<service-page>`.
|
||||
|
||||
.. figure:: /_static/images/walkthrough/servicepage.svg
|
||||
:width: 60%
|
||||
|
||||
.. _embassy-tab:
|
||||
|
||||
@@ -21,22 +26,25 @@ Embassy Tab
|
||||
|
||||
The Embassy Tab is where you can perform :ref:`Backups<backups>`, get Insights into EOS, change some basic Settings, and Power cycle your device if necessary.
|
||||
|
||||
.. figure:: /_static/images/walkthrough/embassytab.svg
|
||||
:width: 60%
|
||||
|
||||
.. _backups:
|
||||
|
||||
Backups
|
||||
=======
|
||||
|
||||
Do the backups
|
||||
One of the most important actions you can do on your Embassy is to keep a regular backup of your data. See the following page on :ref:`Backups<backup>`, and select your device for more details.
|
||||
|
||||
Insights
|
||||
========
|
||||
|
||||
Get the insights
|
||||
The Insights section gives you basic information on your Embassy, monitoring of system resources / temperature, and logs for debugging.
|
||||
|
||||
Settings
|
||||
========
|
||||
|
||||
Set the things
|
||||
The Settings section lets you change preferences, and manage `Connectivity` and Active Sessions. See the documentation on :ref:`Configuration<config>` for more details.
|
||||
|
||||
Power
|
||||
=====
|
||||
@@ -51,7 +59,7 @@ Restart
|
||||
Shutdown
|
||||
........
|
||||
|
||||
#. Be patient while services shut down. A *tune* will play, indicating the shutdown is complete.
|
||||
#. Be patient while services shut down, it may take some minutes. A *tune* will play, indicating the shutdown is complete.
|
||||
#. It is now safe to unplug the Embassy from power and the ethernet cable, if connected.
|
||||
|
||||
.. note:: After a shutdown, the *only* way to turn your Embassy back on is to unplug it and plug it back in. As such, we do not recommend shutting down your Embassy when you are not physically near it. Instead, you should use the restart option.
|
||||
@@ -61,7 +69,10 @@ Shutdown
|
||||
Marketplace Tab
|
||||
---------------
|
||||
|
||||
The Marketplace Tab is obviously the home of the Marketplace, where you can install new Services, or manange existing ones.
|
||||
The Marketplace Tab is obviously the home of the Marketplace, where you can search out and install new Services, or manange existing ones. You can view our live Marketplace `here <marketplace.start9.com>`_.
|
||||
|
||||
.. figure:: /_static/images/walkthrough/markettab.svg
|
||||
:width: 60%
|
||||
|
||||
Marketplace
|
||||
===========
|
||||
@@ -71,12 +82,7 @@ Marketplace
|
||||
Notifications Tab
|
||||
-----------------
|
||||
|
||||
The Notifications Tab is where you can view and manage Notifications produced by EOS and your Services
|
||||
The Notifications Tab is where you can view and manage information produced by EOS and your Services that may need your attention. You can clear these individually, or all at once with ``Delete All`` in the top right.
|
||||
|
||||
Notifications
|
||||
=============
|
||||
|
||||
* successful or failed EmbassyOS updates
|
||||
* successful or failed service installations
|
||||
* successful or failed service backups
|
||||
* successful or failed service updates
|
||||
.. figure:: /_static/images/walkthrough/notiftab.svg
|
||||
:width: 60%
|
||||
|
||||