Browse Source

format documentation (#363)

pull/364/head
Cian Butler 3 years ago
committed by GitHub
parent
commit
494ccc11f5
No known key found for this signature in database GPG Key ID: 4AEE18F83AFDEB23
  1. 20
      README.md
  2. 66
      docs/apache.md
  3. 2
      docs/assets/css/main.css
  4. 20
      docs/assets/img/site.webmanifest
  5. 238
      docs/atoz.md
  6. 161
      docs/index.html
  7. 5
      docs/nginx.md
  8. 4
      docs/service.md
  9. 3
      docs/sidebar.md
  10. 7
      src/assets/xterm_config/functionality.js
  11. 8
      src/assets/xterm_config/xterm_color_theme.js

20
README.md

@ -77,9 +77,8 @@ If instead you wish to connect to a remote host you can specify the `--ssh-host`
option, the SSH port using the `--ssh-port` option and the SSH user using the
`--ssh-user` option.
Check out the
[Flags docs](https://github.com/butlerx/wetty/blob/main/docs/flags.md) for a
full list of flags
Check out the [Flags docs](https://butlerx.github.io/wetty/flags) for a full
list of flags
### Docker container
@ -103,12 +102,12 @@ docker-compose file in the containers directory.
Check out the [docs](https://github.com/butlerx/wetty/tree/main/docs)
- [Running as daemon](https://github.com/butlerx/wetty/blob/main/docs/service.md)
- [HTTPS Support](https://github.com/butlerx/wetty/blob/main/docs/https.md)
- [Using NGINX](https://github.com/butlerx/wetty/blob/main/docs/nginx.md)
- [Using Apache](https://github.com/butlerx/wetty/blob/main/docs/apache.md)
- [Automatic Login](https://github.com/butlerx/wetty/blob/main/docs/auto-login.md)
- [Downloading Files](https://github.com/butlerx/wetty/blob/main/docs/downloading-files.md)
- [Running as daemon](https://butlerx.github.io/wetty/service)
- [HTTPS Support](https://butlerx.github.io/wetty/https)
- [Using NGINX](https://butlerx.github.io/wetty/nginx)
- [Using Apache](https://butlerx.github.io/wetty/apache)
- [Automatic Login](https://butlerx.github.io/wetty/auto-login)
- [Downloading Files](https://butlerx.github.io/wetty/downloading-files)
### What browsers are supported?
@ -127,8 +126,7 @@ WeTTy supports all browsers that
Contributions, issues and feature requests are welcome!<br />Feel free to check
[issues page](https://github.com/butlerx/wetty/issues).
Please read the
[development docs](https://github.com/butlerx/wetty/blob/main/docs/development.md)
Please read the [development docs](https://butlerx.github.io/wetty/development)
for installing from source and running is dev node
Thanks goes to these wonderful people

66
docs/apache.md

@ -29,38 +29,35 @@ RewriteRule /wetty/socket.io/(.*) ws://localhost:3000/wetty/socket.io/$1 [P,L]
## SAML2 integration to auth users
This conf is using apache2 (as for nginx, SAML2 integration is not
available on the community version, only pro).
This conf is using apache2 (as for nginx, SAML2 integration is not available on
the community version, only pro).
Main idea is to propagate the SAML2 validated user identity into the
`remote-user` HTTP header. You need to have the user id returned
within the SAML2 NameID matching the username defined on the platform
wetty is running.
`remote-user` HTTP header. You need to have the user id returned within the
SAML2 NameID matching the username defined on the platform wetty is running.
E.g: You can ask the Idp to return a sAMAccountName within the
SAML2Response NameID, and provision beforehand those allowed users on
the OS wetty is running on.
E.g: You can ask the Idp to return a sAMAccountName within the SAML2Response
NameID, and provision beforehand those allowed users on the OS wetty is running
on.
### SAML2 Metadata generation
SAML2 metadata needs to be generated for this new service on the
server and exchanged with the Idp. We will use the script provided at
SAML2 metadata needs to be generated for this new service on the server and
exchanged with the Idp. We will use the script provided at
https://raw.githubusercontent.com/bitsensor/saml-proxy/master/mellon_create_metadata.sh
```
$ mellon_create_metadata.sh urn:https://foo.bar.tlz https://foo.bar.tld/mellon
```
Then we move the generated files over
`/etc/apache2/saml2/foo.{xml,key,cert}`.
You need to put here additionaly the metadata from your SAML2
provider, named here `idp.xml` and exchange you foo.xml with it.
Then we move the generated files over `/etc/apache2/saml2/foo.{xml,key,cert}`.
You need to put here additionaly the metadata from your SAML2 provider, named
here `idp.xml` and exchange you foo.xml with it.
### Apache2 conf
``` apache
```apache
<VirtualHost *:443>
ServerName foo.bar.tld
ServerAdmin admin@bar.tld
@ -108,14 +105,12 @@ provider, named here `idp.xml` and exchange you foo.xml with it.
### Auto login
If you want to have a seamless login by trusting your IdP for
authentication, you can create password-less users on the wetty
platform and have them trust an SSH key used by the NodeJS, owned by
the dedicated wetty OS user.
If you want to have a seamless login by trusting your IdP for authentication,
you can create password-less users on the wetty platform and have them trust an
SSH key used by the NodeJS, owned by the dedicated wetty OS user.
Wetty instanciation with proper parameters, especially the SSH private
key is done via the following systemd service
`/etc/systemd/system/wetty.service`:
Wetty instanciation with proper parameters, especially the SSH private key is
done via the following systemd service `/etc/systemd/system/wetty.service`:
```
[Unit]
@ -136,24 +131,21 @@ RestartSec=2
WantedBy=multi-user.target
```
For your new users to be automically trusting this SSH key when
provisionning, you may add the pubkey to
`/etc/skel/.ssh/authorized_keys`.
For your new users to be automically trusting this SSH key when provisionning,
you may add the pubkey to `/etc/skel/.ssh/authorized_keys`.
### Security precautions
You probably don't want local users to impersonate each other, for that you need to make sure that:
You probably don't want local users to impersonate each other, for that you need
to make sure that:
1. NodeJS is listenning only to localhost: provided by `wetty.service`
2. **Only** the apache2 process can join the wetty port. Else local users
will be able to connect and forge a `remote-user` header: provided
by `iptables -A OUTPUT -o lo -p tcp --dport 3000 -m owner \!
--uid-owner www-data -j DROP`
3. Validate your wetty version does not allow access to `/wetty/ssh/`
else again you will be able to impersonnate anyone: provided by
either:
1. wetty version 2.0.3 and beyond implements this by disabling this feature in case of `remote-user`
presence
2. **Only** the apache2 process can join the wetty port. Else local users will
be able to connect and forge a `remote-user` header: provided by
`iptables -A OUTPUT -o lo -p tcp --dport 3000 -m owner \! --uid-owner www-data -j DROP`
3. Validate your wetty version does not allow access to `/wetty/ssh/` else again
you will be able to impersonnate anyone: provided by either:
1. wetty version 2.0.3 and beyond implements this by disabling this feature
in case of `remote-user` presence
2. apache2 conf as provided in previous section (containing the
`<Location /wetty/ssh/>`)

2
docs/assets/css/main.css

@ -1,3 +1,3 @@
:root {
--content-max-width : 100%;
--content-max-width: 100%;
}

20
docs/assets/img/site.webmanifest

@ -1 +1,19 @@
{"name":"","short_name":"","icons":[{"src":"/android-chrome-192x192.png","sizes":"192x192","type":"image/png"},{"src":"/android-chrome-512x512.png","sizes":"512x512","type":"image/png"}],"theme_color":"#ffffff","background_color":"#ffffff","display":"standalone"}
{
"name": "",
"short_name": "",
"icons": [
{
"src": "/android-chrome-192x192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "/android-chrome-512x512.png",
"sizes": "512x512",
"type": "image/png"
}
],
"theme_color": "#ffffff",
"background_color": "#ffffff",
"display": "standalone"
}

238
docs/atoz.md

@ -1,16 +1,27 @@
# Introduction
This is an A to Z guide that will help you get WeTTY up and running on a Debian based system. It covers the key configuration areas by using copy and paste commands. This will help you install this application and get it securely up and running with minimal system interference and reversible changes. It should also provide enough information to allow you to understand and extend that configuration for your personal requirements.
**Note:** Some of these configurations are optional, such as self signed SSL and public key authentication. The purpose of the guide is to show you how to correctly understand, configure, install and use these options should you wish to use them but they are not required to use WeTTY in general.
This is an A to Z guide that will help you get WeTTY up and running on a Debian
based system. It covers the key configuration areas by using copy and paste
commands. This will help you install this application and get it securely up and
running with minimal system interference and reversible changes. It should also
provide enough information to allow you to understand and extend that
configuration for your personal requirements.
**Note:** Some of these configurations are optional, such as self signed SSL and
public key authentication. The purpose of the guide is to show you how to
correctly understand, configure, install and use these options should you wish
to use them but they are not required to use WeTTY in general.
## Required dependencies
`Node` - WeTTY requires node v14 or greater. We will install this locally for a non root user later in the guide.
`Node` - WeTTY requires node v14 or greater. We will install this locally for a
non root user later in the guide.
`python` - This should be installed by default but we will include it in our `apt-get` command to be safe.
`python` - This should be installed by default but we will include it in our
`apt-get` command to be safe.
`build-essential` - We need this specifically for `node-gyp` to build packages when using `npm` or `yarn` to install packages.
`build-essential` - We need this specifically for `node-gyp` to build packages
when using `npm` or `yarn` to install packages.
As the `root` or `sudo` user run these commands:
@ -19,7 +30,8 @@ sudo apt update
sudo apt install -y build-essential curl python
```
If you have no root access and just want to check the dependencies are installed you can use these commands:
If you have no root access and just want to check the dependencies are installed
you can use these commands:
```bash
dpkg -s python | grep Status:
@ -34,23 +46,32 @@ Status: install ok installed
## Create a local user account
For this guide, unless specifically stated, you should not use a `root` account to install and run WeTTY. Please use an existing local account or create one now.
For this guide, unless specifically stated, you should not use a `root` account
to install and run WeTTY. Please use an existing local account or create one
now.
**Note:** Whichever user runs WeTTY should be the same user you wish to authenticate with via `ssh` to keep this guide simple.
**Note:** Whichever user runs WeTTY should be the same user you wish to
authenticate with via `ssh` to keep this guide simple.
If you need to create a local user account you can run this command:
**Important note:** replace `username` with a user name of your choosing and create a password when prompted
**Important note:** replace `username` with a user name of your choosing and
create a password when prompted
```bash
adduser --gecos "" username
```
Switch to your local user now and open an `ssh` session to continue with this guide.
Switch to your local user now and open an `ssh` session to continue with this
guide.
## Install node locally
To install and manage `node` as a local user we are going to use [Node Version Manager](https://github.com/nvm-sh/nvm). This is an established solution for installing and managing multiple versions of node without needing `root` access. This will allow you to install and use multiple versions of `node` at the same time.
To install and manage `node` as a local user we are going to use
[Node Version Manager](https://github.com/nvm-sh/nvm). This is an established
solution for installing and managing multiple versions of node without needing
`root` access. This will allow you to install and use multiple versions of
`node` at the same time.
This command will download and install `nvm` and reload our shell.
@ -58,7 +79,8 @@ This command will download and install `nvm` and reload our shell.
curl -sL https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh | bash && source ~/.profile
```
This command will install the latest version of the v14 branch, which is the minimum required version for WeTTY.
This command will install the latest version of the v14 branch, which is the
minimum required version for WeTTY.
```bash
nvm install 14
@ -76,17 +98,26 @@ Your result should look something like this.
v14.16.1
```
**Note:** There is an important consideration with the `nvm` method. `node` is only in the local user's path through sourcing of the `~/.nvm/nvm.sh` which is done when the user logs in and the shell sources the user's `.bashrc` file. So for some applications who are not aware of this local shell environment `node` will not be usable unless we provide a full path and `nvm` commands will also be unavailable. The way we over come this issue for the needs of this guide is by using this command substitution to provide the full path, where applicable:
**Note:** There is an important consideration with the `nvm` method. `node` is
only in the local user's path through sourcing of the `~/.nvm/nvm.sh` which is
done when the user logs in and the shell sources the user's `.bashrc` file. So
for some applications who are not aware of this local shell environment `node`
will not be usable unless we provide a full path and `nvm` commands will also be
unavailable. The way we over come this issue for the needs of this guide is by
using this command substitution to provide the full path, where applicable:
```bash
$(source ~/.nvm/nvm.sh && nvm which 14)
```
**Why?** This command will always provide us with the path to the most current version of `node 14` installed via `nvm` regardless of other versions of `node` installed with `nvm`.
**Why?** This command will always provide us with the path to the most current
version of `node 14` installed via `nvm` regardless of other versions of `node`
installed with `nvm`.
## Generate OpenSSL certificates
**Why?** So that later we can configure WeTTY to work with `https` and make sure we interact with WeTTY over a secure connection at all times.
**Why?** So that later we can configure WeTTY to work with `https` and make sure
we interact with WeTTY over a secure connection at all times.
Make the required directory using this command:
@ -94,9 +125,11 @@ Make the required directory using this command:
mkdir -p ~/.ssl
```
Generate the self signed `openssl` certificates we will use to encrypt our web traffic when using WeTTY using this command:
Generate the self signed `openssl` certificates we will use to encrypt our web
traffic when using WeTTY using this command:
**Note:** we are using `ecdsa` using the `secp384r1` curve. Tested to be compatible with Chrome and Firefox browsers.
**Note:** we are using `ecdsa` using the `secp384r1` curve. Tested to be
compatible with Chrome and Firefox browsers.
```bash
openssl req -x509 -nodes -days 1095 -newkey ec:<(openssl ecparam -name secp384r1) -subj "/C=GB/ST=None/L=None/O=None/OU=None/CN=None" -out ~/.ssl/wetty.crt -keyout ~/.ssl/wetty.key
@ -114,7 +147,8 @@ This is all we need to do for now in regards to https.
## Generate the ssh key file
**Why?** So that later we can set up automatic login via `ssh`. Our instance will authorise using this key file stored locally.
**Why?** So that later we can set up automatic login via `ssh`. Our instance
will authorise using this key file stored locally.
Make the required directory, if it does not exist, using this command:
@ -122,13 +156,16 @@ Make the required directory, if it does not exist, using this command:
mkdir -p ~/.ssh
```
Create the `ssh` private key using `ed25519` that we need to authorise our local connection, using this command:
Create the `ssh` private key using `ed25519` that we need to authorise our local
connection, using this command:
```bash
ssh-keygen -q -C "wetty-keyfile" -t ed25519 -N '' -f ~/.ssh/wetty 2>/dev/null <<< y >/dev/null
```
**Important Note:** You must add the public key to your `authorized_keys` file in order to be able to log in using your `ssh` key file when accessing WeTTY via a web browser.
**Important Note:** You must add the public key to your `authorized_keys` file
in order to be able to log in using your `ssh` key file when accessing WeTTY via
a web browser.
Copy the key to our `~/.ssh/authorized_keys` file, using this command:
@ -144,7 +181,9 @@ chmod 644 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/wetty
```
**Optional:** A housekeeping command. If you need to remove all entries of the WeTTY public key with the comment `wetty-keyfile` from the `~/.ssh/authorized_keys` file use this command. Otherwise ignore this.
**Optional:** A housekeeping command. If you need to remove all entries of the
WeTTY public key with the comment `wetty-keyfile` from the
`~/.ssh/authorized_keys` file use this command. Otherwise ignore this.
```bash
sed -r '/^ssh-ed25519(.*)wetty-keyfile$/d' -i ~/.ssh/authorized_keys
@ -152,11 +191,14 @@ sed -r '/^ssh-ed25519(.*)wetty-keyfile$/d' -i ~/.ssh/authorized_keys
## Install WeTTY
**Note:** we are using `-g` for `npm` or `global` for `yarn` along with `--prefix ~/` so that the application's symbolic link is installed to our `~/bin` directory and available in our local user's `PATH`.
**Note:** we are using `-g` for `npm` or `global` for `yarn` along with
`--prefix ~/` so that the application's symbolic link is installed to our
`~/bin` directory and available in our local user's `PATH`.
As your local user run these commands:
To make sure the local user's `~/bin` directory exists and is in the `PATH` please run the following command.
To make sure the local user's `~/bin` directory exists and is in the `PATH`
please run the following command.
```bash
mkdir -p ~/bin && source ~/.profile
@ -174,7 +216,8 @@ Then use `yarn` to install `wetty`.
yarn global add wetty --prefix ~/
```
Once successfully installed the application should be available in your local user's `PATH`. To test the installation was successful please use this command:
Once successfully installed the application should be available in your local
user's `PATH`. To test the installation was successful please use this command:
```bash
wetty -h
@ -182,9 +225,12 @@ wetty -h
## Accessing the web interface via our external IP
If you are using your external IP and not a domain to access WeTTY this step needs to be done here because it is not easy to do in the next steps if WeTTY is running in the terminal.
If you are using your external IP and not a domain to access WeTTY this step
needs to be done here because it is not easy to do in the next steps if WeTTY is
running in the terminal.
This command will generate the correct URL you need to visit after using the start up commands in the following section.
This command will generate the correct URL you need to visit after using the
start up commands in the following section.
```bash
echo https://$(curl -s4 icanhazip.com):3000
@ -194,17 +240,23 @@ _Please make make a note of this URL now._
## Running WeTTY
Now we have all the ground work done we can focus on our WeTTY server configuration settings.
Now we have all the ground work done we can focus on our WeTTY server
configuration settings.
For example, the below command would provide a `https` instance with automatic `ssh` authorisation using our `wetty` private key on port `3000` accessible at `https://IP:3000` .
For example, the below command would provide a `https` instance with automatic
`ssh` authorisation using our `wetty` private key on port `3000` accessible at
`https://IP:3000` .
**Important note:** This command will run in your current terminal session and not in the background. The key combination of `CTRL` + `c` will exit the application.
**Important note:** This command will run in your current terminal session and
not in the background. The key combination of `CTRL` + `c` will exit the
application.
```bash
wetty --host 0.0.0.0 --port 3000 --title wetty --base / --ssh-key ~/.ssh/wetty --ssh-host localhost --ssh-user $(whoami) --ssh-port 22 --ssh-auth publickey --ssl-key ~/.ssl/wetty.key --ssl-cert ~/.ssl/wetty.crt
```
Since you may not need all these settings we will look through what each one does below so that you can decide how to best configure your instance.
Since you may not need all these settings we will look through what each one
does below so that you can decide how to best configure your instance.
### Environment settings explained
@ -214,33 +266,51 @@ Let's break it down so that we can understand what's being done and why.
--host 0.0.0.0 --port 3000 --title wetty --base /
```
`--host 0.0.0.0` - defines the interface we want to bind to. Using `0.0.0.0` means that we bind to all available interfaces so using this setting just works. When we use nginx we can change this to `--host 127.0.0.1` in order to prevent generic port access to the application and force traffic through our nginx reverse proxy URL.
`--host 0.0.0.0` - defines the interface we want to bind to. Using `0.0.0.0`
means that we bind to all available interfaces so using this setting just works.
When we use nginx we can change this to `--host 127.0.0.1` in order to prevent
generic port access to the application and force traffic through our nginx
reverse proxy URL.
`--port 3000` - defines the local listening port. You will use this port to connect via the remotely accessible web server or when configuring a reverse proxy through nginx.
`--port 3000` - defines the local listening port. You will use this port to
connect via the remotely accessible web server or when configuring a reverse
proxy through nginx.
`--title wetty` - an optional setting to set the window title for this `wetty` session.
`--title wetty` - an optional setting to set the window title for this `wetty`
session.
`--base /` - changes the default base URL setting from `/wetty/` to define the remote URL. We use `--base /` to make `wetty` accessible on the URL format `https://IP:3000` instead of `https://IP:3000/wetty` but we would change this back if we use nginx to reverse proxy the application.
`--base /` - changes the default base URL setting from `/wetty/` to define the
remote URL. We use `--base /` to make `wetty` accessible on the URL format
`https://IP:3000` instead of `https://IP:3000/wetty` but we would change this
back if we use nginx to reverse proxy the application.
### SSH settings explained
These settings are all specific to `ssh` and will enable you to automatically log into you `ssh` session for the selected user.
These settings are all specific to `ssh` and will enable you to automatically
log into you `ssh` session for the selected user.
```bash
--ssh-key ~/.ssh/wetty --ssh-host localhost --ssh-user $(whoami) --ssh-port 22 --ssh-auth publickey
```
`--ssh-key ~/.ssh/wetty` - we are telling WeTTY to load our `ssh` key file that we generated earlier.
`--ssh-key ~/.ssh/wetty` - we are telling WeTTY to load our `ssh` key file that
we generated earlier.
`--ssh-host localhost` - optional setting telling WeTTY to connect the host `localhost`
`--ssh-host localhost` - optional setting telling WeTTY to connect the host
`localhost`
`--ssh-user $(whomai)` - defines our `ssh` username. In this case via the command substitution of `whoami` which will not require your input of a username.
`--ssh-user $(whomai)` - defines our `ssh` username. In this case via the
command substitution of `whoami` which will not require your input of a
username.
`--ssh-port 22` - optional setting to set the `ssh` port we need to connect to.
`--ssh-auth publickey` defines the accepted authentication types. You do not have to use the key file and you can instead require a password but setting this to `--sshauth password`. You can specify both `--sshauth publickey,password`
`--ssh-auth publickey` defines the accepted authentication types. You do not
have to use the key file and you can instead require a password but setting this
to `--sshauth password`. You can specify both `--sshauth publickey,password`
`--ssh-config configfile` - (not used for this guide) alternative ssh configuration file. From ssh(1):
`--ssh-config configfile` - (not used for this guide) alternative ssh
configuration file. From ssh(1):
> If a configuration file is given on the command line, the system-wide
> configuration file (/etc/ssh/ssh_config) will be ignored. The default for the
@ -248,19 +318,23 @@ These settings are all specific to `ssh` and will enable you to automatically lo
### SSL settings explained
These settings are specific to `openssl` to make WeTTY load https webserver so that all data is transmitted over a secure connection.
These settings are specific to `openssl` to make WeTTY load https webserver so
that all data is transmitted over a secure connection.
```bash
--ssl-key ~/.ssl/wetty.key --ssl-cert ~/.ssl/wetty.crt
```
`--ssl-key ~/.ssl/wetty.key` - tells WeTTY to load our `openssl` generated key file.
`--ssl-key ~/.ssl/wetty.key` - tells WeTTY to load our `openssl` generated key
file.
`--ssl-cert ~/.ssl/wetty.crt` - tells WeTTY to load our `openssl` generates certificate file.
`--ssl-cert ~/.ssl/wetty.crt` - tells WeTTY to load our `openssl` generates
certificate file.
### Optional - load settings via a configuration file
As of WeTTY v2 there is official support for a configuration file used with the flag `--conf` to specify the location of this file.
As of WeTTY v2 there is official support for a configuration file used with the
flag `--conf` to specify the location of this file.
Create the directory where we will store this configuration file.
@ -276,7 +350,12 @@ nano ~/.config/wetty/config.json
Here is the template `config.json` you need to use.
**Note:** To be [validated json](https://codebeautify.org/jsonvalidator) the below json example should have the `// ...` comments removed. With all comments removed the example is valid json. They are in the example to help explain the options and won't stop wetty from loading if you leave them in place. Lines you do not need can be commented out but should be removed if you want the json to pass validation.
**Note:** To be [validated json](https://codebeautify.org/jsonvalidator) the
below json example should have the `// ...` comments removed. With all comments
removed the example is valid json. They are in the example to help explain the
options and won't stop wetty from loading if you leave them in place. Lines you
do not need can be commented out but should be removed if you want the json to
pass validation.
```json
"ssh": {
@ -304,13 +383,16 @@ Here is the template `config.json` you need to use.
}
```
Press `ctrl` + `x` and then press `y` to save then press `enter` to confirm and exit `nano`.
Press `ctrl` + `x` and then press `y` to save then press `enter` to confirm and
exit `nano`.
## System Environment Variables
**Note:** We will not be using this section to configure WeTTY. We are simply documenting it.
**Note:** We will not be using this section to configure WeTTY. We are simply
documenting it.
There are some environment variables you can export that can be used by WeTTY to configure an instance.
There are some environment variables you can export that can be used by WeTTY to
configure an instance.
```bash
BASE
@ -347,7 +429,8 @@ mkdir -p ~/.config/systemd/user
### Systemd service
Here is an example template of how to use service file with hardcoded values you can set in the `wetty.service` file with all options enabled.
Here is an example template of how to use service file with hardcoded values you
can set in the `wetty.service` file with all options enabled.
Use `nano` to open a file for editing.
@ -357,7 +440,9 @@ nano ~/.config/systemd/user/wetty.service
The copy and paste this code.
**Note:** This is an example service file based on all the options documented and configured so far. You may not want all these option enabled so please remove or modify the `ExecStart` command based on your needs.
**Note:** This is an example service file based on all the options documented
and configured so far. You may not want all these option enabled so please
remove or modify the `ExecStart` command based on your needs.
```bash
[Unit]
@ -376,11 +461,14 @@ SyslogIdentifier=wetty
WantedBy=default.target
```
Press `ctrl` + `x` and then press `y` to save then press `enter` to confirm and exit `nano`.
Press `ctrl` + `x` and then press `y` to save then press `enter` to confirm and
exit `nano`.
### Optional - Systemd service with config file
Here is the example using our pseudo configuration file. All modifications to the start up of `wetty` will be done by editing the `~/.config/Wetty/config` file and then reloading the `wetty.service`.
Here is the example using our pseudo configuration file. All modifications to
the start up of `wetty` will be done by editing the `~/.config/Wetty/config`
file and then reloading the `wetty.service`.
Use `nano` to open the file for editing.
@ -390,7 +478,9 @@ nano ~/.config/systemd/user/wetty.service
The copy and paste this code.
**Note:** This `ExecStart` assumes the location of your `config.json` to be `~/.config/wetty/config.json`. Please make sure you use the correct location for this file.
**Note:** This `ExecStart` assumes the location of your `config.json` to be
`~/.config/wetty/config.json`. Please make sure you use the correct location for
this file.
```bash
[Unit]
@ -409,7 +499,8 @@ SyslogIdentifier=wetty
WantedBy=default.target
```
Press `ctrl` + `x` and then press `y` to save then press `enter` to confirm and exit `nano`.
Press `ctrl` + `x` and then press `y` to save then press `enter` to confirm and
exit `nano`.
### Activating your service
@ -435,17 +526,20 @@ systemctl --user enable --now wetty
## Nginx reverse proxy
If you want to use nginx as a reverse proxy here is the configuration file you can use.
If you want to use nginx as a reverse proxy here is the configuration file you
can use.
Please modify these specific environment settings:
**Why?** This will disable generic port access to the application and force traffic via the nginx reverse proxy.
**Why?** This will disable generic port access to the application and force
traffic via the nginx reverse proxy.
```bash
--host 127.0.0.1
```
**Why?** This change is so that our application does not attempt to load as the web root of `/` for nginx.
**Why?** This change is so that our application does not attempt to load as the
web root of `/` for nginx.
```bash
--base /wetty/
@ -453,9 +547,13 @@ Please modify these specific environment settings:
Now you can use this nginx configuration file.
**Note:** we are using `https` with `https://127.0.0.1:3000/wetty;` because we configured `wetty` to run via `https` using our self signed ssl certificates. If you chose not to run WeTTY with a self signed certificate you should changes this to `http://127.0.0.1:3000/wetty;`
**Note:** we are using `https` with `https://127.0.0.1:3000/wetty;` because we
configured `wetty` to run via `https` using our self signed ssl certificates. If
you chose not to run WeTTY with a self signed certificate you should changes
this to `http://127.0.0.1:3000/wetty;`
The copy and paste this into the `https` server block of your enable server configuration file.
The copy and paste this into the `https` server block of your enable server
configuration file.
```nginx
location /wetty {
@ -484,7 +582,8 @@ location /wetty {
}
```
Press `ctrl` + `x` and then press `y` to save then press `enter` to confirm and exit `nano`
Press `ctrl` + `x` and then press `y` to save then press `enter` to confirm and
exit `nano`
Now you would need to reload nginx service using this command:
@ -496,7 +595,8 @@ systemctl restart nginx
Visit the URL format `https://YourIPorDomain/wetty` and you can access WeTTY.
This command will generate the correct URL you need to visit it you are not using a domain.
This command will generate the correct URL you need to visit it you are not
using a domain.
```bash
echo https://$(curl -s4 icanhazip.com)/wetty
@ -504,15 +604,18 @@ echo https://$(curl -s4 icanhazip.com)/wetty
## Protecting your instance of WeTTY
**Disclaimer:** It is not recommended by this guide that you run an instance of WeTTY on your server with no access control in place.
**Disclaimer:** It is not recommended by this guide that you run an instance of
WeTTY on your server with no access control in place.
If you chose to not use a password to login in you should protect your instance behind either:
If you chose to not use a password to login in you should protect your instance
behind either:
1: [Nginx basic auth](https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/)
1:
[Nginx basic auth](https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/)
2: [Authelia](https://github.com/authelia/authelia)
## Configuration reference
## Configuration reference
`wetty -h` configuration options for reference.
@ -563,7 +666,8 @@ Now restart your `wetty` service.
The proper way to update NVM is to use git. The `.nvm` directory is a git repo.
These commands will update NVM to the latest version of the script and load it to your shell.
These commands will update NVM to the latest version of the script and load it
to your shell.
```bash
cd ~/.nvm

161
docs/index.html

@ -1,77 +1,96 @@
<!doctype html>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta
name="viewport"
content="width=device-width, initial-scale=1, minimum-scale=1.0, shrink-to-fit=no, viewport-fit=cover"
/>
<meta name="description" content="WeTTY" />
<title>WeTTY = Web + TTY</title>
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport"
content="width=device-width, initial-scale=1, minimum-scale=1.0, shrink-to-fit=no, viewport-fit=cover">
<meta name="description" content="WeTTY">
<title>WeTTY = Web + TTY</title>
<link
rel="apple-touch-icon"
sizes="180x180"
href="assets/img/apple-touch-icon.png"
/>
<link
rel="icon"
type="image/png"
sizes="32x32"
href="assets/img/favicon-32x32.png"
/>
<link
rel="icon"
type="image/png"
sizes="16x16"
href="assets/img/favicon-16x16.png"
/>
<link rel="manifest" href="assets/img/site.webmanifest" />
<link rel="apple-touch-icon" sizes="180x180" href="assets/img/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="assets/img/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="assets/img/favicon-16x16.png">
<link rel="manifest" href="assets/img/site.webmanifest">
<!-- Theme -->
<!-- <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/docsify-themeable/dist/css/theme-simple.css"> -->
<link
rel="stylesheet"
href="https://cdn.jsdelivr.net/npm/docsify-themeable/dist/css/theme-simple.css"
/>
<link rel="stylesheet" href="assets/css/main.css" />
<!-- Theme -->
<!-- <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/docsify-themeable/dist/css/theme-simple.css"> -->
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/docsify-themeable/dist/css/theme-simple.css">
<link rel="stylesheet" href="assets/css/main.css">
<script src="https://cdn.jsdelivr.net/npm/docsify-edit-on-github"></script>
</head>
<script src="https://cdn.jsdelivr.net/npm/docsify-edit-on-github"></script>
</head>
<body>
<div id="app">Please wait...</div>
<script>
window.$docsify = {
// GENERAL
// -----------------------------------------------------------------
name: 'WeTTY = Web + TTY',
repo: 'https://github.com/butlerx/wetty',
homepage: 'README.md',
loadSidebar: true,
loadSidebar: 'sidebar.md',
auto2top: true,
executeScript: true,
mergeNavbar: true,
maxLevel: 3,
subMaxLevel: 3,
// PLUGINS
// -----------------------------------------------------------------
plugins: [
EditOnGithubPlugin.create('https://github.com/butlerx/wetty/tree/master/docs/'),
],
search: {
noData: {
'/': 'No results!'
<body>
<div id="app">Please wait...</div>
<script>
window.$docsify = {
// GENERAL
// -----------------------------------------------------------------
name: 'WeTTY = Web + TTY',
repo: 'https://github.com/butlerx/wetty',
homepage: 'README.md',
loadSidebar: true,
loadSidebar: 'sidebar.md',
auto2top: true,
executeScript: true,
mergeNavbar: true,
maxLevel: 3,
subMaxLevel: 3,
// PLUGINS
// -----------------------------------------------------------------
plugins: [
EditOnGithubPlugin.create(
'https://github.com/butlerx/wetty/tree/master/docs/',
),
],
search: {
noData: {
'/': 'No results!',
},
paths: 'auto',
placeholder: {
'/': 'Search',
},
},
paths: 'auto',
placeholder: {
'/': 'Search'
}
},
tabs: {
persist: true, // default
sync: true, // default
theme: 'classic', // default
tabComments: true, // default
tabHeadings: true // default
},
themeable: {
readyTransition: true, // default
responsiveTables: true // default
}
};
</script>
<script src="https://cdn.jsdelivr.net/npm/docsify"></script>
<script src="https://cdn.jsdelivr.net/npm/docsify-tabs"></script>
<script src="https://cdn.jsdelivr.net/npm/docsify-copy-code"></script>
<script src="https://cdn.jsdelivr.net/npm/docsify-themeable"></script>
<script src="https://cdn.jsdelivr.net/npm/docsify/lib/plugins/search.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/docsify-prism"></script>
<script src="https://cdn.jsdelivr.net/npm/prismjs/plugins/autoloader/prism-autoloader.min.js"></script>
</body>
</html>
tabs: {
persist: true, // default
sync: true, // default
theme: 'classic', // default
tabComments: true, // default
tabHeadings: true, // default
},
themeable: {
readyTransition: true, // default
responsiveTables: true, // default
},
};
</script>
<script src="https://cdn.jsdelivr.net/npm/docsify"></script>
<script src="https://cdn.jsdelivr.net/npm/docsify-tabs"></script>
<script src="https://cdn.jsdelivr.net/npm/docsify-copy-code"></script>
<script src="https://cdn.jsdelivr.net/npm/docsify-themeable"></script>
<script src="https://cdn.jsdelivr.net/npm/docsify/lib/plugins/search.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/docsify-prism"></script>
<script src="https://cdn.jsdelivr.net/npm/prismjs/plugins/autoloader/prism-autoloader.min.js"></script>
</body>
</html>

5
docs/nginx.md

@ -12,8 +12,9 @@ The following confs assume you want to serve WeTTy on the url
`example.com/wetty` and are running WeTTy with the default base and serving it
on the same server
For a more detailed look see the [nginx.conf](../conf/nginx.template) used for
testing
For a more detailed look see the
[nginx.conf](https://github.com/butlerx/wetty/blob/main/conf/nginx.template)
used for testing
Put the following configuration in your nginx conf:

4
docs/service.md

@ -28,5 +28,5 @@ like this:
exec sudo -u root wetty -p 80 >> /var/log/wetty.log 2>&1
```
Systemd requires an absolute path for a unit's WorkingDirectory, consquently `$HOME`
will need updating to an absolute path in the `wetty.service` file.
Systemd requires an absolute path for a unit's WorkingDirectory, consquently
`$HOME` will need updating to an absolute path in the `wetty.service` file.

3
docs/sidebar.md

@ -1,4 +1,4 @@
- [README.md](README.md)
- [Home](README.md)
- [Apache](apache.md)
- [API](API.md)
- [AtoZ](atoz.md)
@ -9,4 +9,3 @@
- [https](https.md)
- [nginx](nginx.md)
- [service](service.md)

7
src/assets/xterm_config/functionality.js

@ -37,9 +37,8 @@ function inflateOptions(optionsSchema) {
const numberOption = document.querySelector('#number_option.templ');
const colorOption = document.querySelector('#color_option.templ');
function copyOver(element) {
while (element.children.length > 0)
document.body.append(element.children[0]);
function copyOver({ children }) {
while (children.length > 0) document.body.append(children[0]);
}
optionsSchema.forEach(option => {
@ -113,7 +112,7 @@ function setItem(json, path, item) {
}
}
window.loadOptions = function (config) {
window.loadOptions = config => {
allOptions.forEach(option => {
let value = getItem(config, option.path);
if (option.nullable === true && option.type === 'text' && value == null)

8
src/assets/xterm_config/xterm_color_theme.js

@ -148,9 +148,5 @@ selectionColorOption.set = function (value) {
selectionColorOpacityOption.el.querySelector('input').value =
Math.round((parseInt(value.substring(7), 16) / 255) * 100) / 100;
};
selectionColorOpacityOption.get = function () {
return 0;
};
selectionColorOpacityOption.set = function () {
return 0;
};
selectionColorOpacityOption.get = () => 0;
selectionColorOpacityOption.set = () => 0;

Loading…
Cancel
Save