Fix log provider regression on proxy servers

  - Use getter for releaseChannel property access
  - Add beta channel update check period specialisation (every 10 minutes instead of the default 6 hours)
parent 19d59ffd
......@@ -50,6 +50,8 @@ __Before you pipe any script into your computer, always view the source code ([L
wget -qO- https://sitejs.org/install | bash
```
(To use curl instead, see the macOS instructions, below.)
#### macOS
```shell
......@@ -68,19 +70,37 @@ iex(iwr -UseBasicParsing https://sitejs.org/install.txt).Content
npm i -g @small-tech/site.js
```
### Alpha and Beta channels
On Linux and macOS, addition to the release build channel, there is also an alpha build and beta build channel available. Pass either `alpha` or `beta` as an argument to the Bash pipe to install the latest build from the respective channel.
For example, to install the latest beta build on Linux:
```shell
wget -qO- https://sitejs.org/install | bash -s -- beta
```
All of our servers at Small Technology Foundation ([Laura’s web site](https://laurakalbag.com), [Aral’s web site](https://ar.al), the [Small Technology Foundation web site](https://small-tech.org), and the [Better Blocker web site](https://better.fyi)) run on the Beta channel of Site.js so we can hopefully catch any issues that may exist in updates before pushing them out to everyone else.
Alpha builds are strictly for local testing and should not, under any circumstances, be used in production. We do not test Alpha builds in production.
Servers deployed using release builds check for updates every six hours whereas beta builds check every 10 minutes.
## System Requirements
### Linux
Any recent Linux distribution should work. However, Site.js is most thoroughly tested on Ubuntu 19.04/Pop!_OS 19.04 (development and staging) and Ubuntu 18.04 LTS (production) at [Small Technology Foundation](https://small-tech.org).
Any recent Linux distribution should work. However, Site.js is most thoroughly tested at Small Technology Foundation on Ubuntu 19.04/Pop!_OS 19.04 (development and staging) and Ubuntu 18.04 LTS (production).
There are builds available for x64 and ARM.
There are builds available for x64 and ARM (tested and supported on armv6l and armv7l only. Tested on Rasperry Pi Zero W, 3B+, 4B).
ARM builds currently only tested and supported on Raspberry Pi Zero W, 3B+, and 4B (armv6l and armv7l). If you are successfully running Site.js on other ARM architectures, please [let us know by opening an issue with the details](https://github.com/small-tech/site.js/issues) and we’ll update the documentation accordingly.
For production use, systemd is required.
For production use, [systemd](https://en.wikipedia.org/wiki/Systemd) is required.
### macOS
macOS 10.14 Mojave and macOS 10.15 Catalina are supported (the latter as of Site.js 12.5.1).
macOS 10.14.x Mojave and macOS 10.15.x Catalina are supported (the latter as of Site.js 12.5.1).
_Production use is not possible under macOS._
......@@ -94,16 +114,16 @@ _Production use is not possible under Windows._
## Dependencies
Site.js tries to install the dependencies it needs seamlessly while running. That said, there are certain basic components it expects on a Linux-like system. These are:
Site.js tries to seamlessly install the dependencies it needs when run. That said, there are certain basic components it expects on a Linux-like system. These are:
- `sudo`
- `libcap2-bin` (we use `setcap` to escalate privileges on the binary as necessary)
For production use, passwordless sudo is required. On systems where the sudo configuration directory is set to `/etc/sudoers.d`, Site.js will automatically install this rule. On other systems, you might have to set it up yourself.
__For production use, passwordless sudo is required.__ On systems where the sudo configuration directory is set to `/etc/sudoers.d`, Site.js will automatically install this rule. On other systems, you might have to [set it up yourself](https://serverfault.com/questions/160581/how-to-setup-passwordless-sudo-on-linux).
If it turns out that any of these prerequisites are a widespread reason for first-run breakage, we can look into having them installed automatically in the future. Please open an issue if any of these is an issue in your deployments or everyday usage.
If it turns out that any of these prerequisites are a widespread cause of first-run woe, we can look into having them installed automatically in the future. Please [open an issue](https://github.com/small-tech/site.js/issues) if any of these affects you during your deployments or in everyday use.
Of course, you will need `wget` (or `curl`) installed to download the install script. You can install `wget` via your distribution’s package manager (e.g., `sudo apt install wget` on Ubuntu-like systems).
To install Site.js using the one-line installation command on Linux and macOS, you will need `wget` (or `curl`) installed to download the installation script. On Linux, you can install either via your distribution’s package manager (e.g., `sudo apt install wget` on Ubuntu-like systems). macOS comes with curl installed.
## Update (as of version 12.9.5; properly functioning as of version 12.9.6)
......@@ -119,7 +139,7 @@ __Note:__ There is a bug in the semantic version comparison in the original rele
## Automatic updates in production (as of version 12.10.0)
[Production servers](#production) started with the `enable` command will automatically check for updates on first launch and then again at a set interval (currently every 5 hours) and update themselves as and when necessary.
[Production servers](#production) started with the `enable` command will automatically check for updates on first launch and then again at a set interval (currently every 6 hours) and update themselves as and when necessary.
This is a primary security feature given that Site.js is meant for use by individuals, not startups or enterprises with operations teams that can (in theory, at least) maintain servers with the latest updates.
......@@ -165,7 +185,9 @@ $ site serve . @localhost:666
#### Proxy server
You can use Site.js as a development-time reverse proxy for HTTP and WebSocket connections. For example, if you use [Hugo](https://gohugo.io/) and you’re running `hugo server` on the default HTTP port 1313. You can run a HTTPS reverse proxy at https://localhost [with LiveReload support](https://source.small-tech.org/hypha/tools/web-server/blob/master/bin/web-server.js#L237) using:
You can use Site.js as a development-time reverse proxy for HTTP and WebSocket connections.
This is useful, for example, if you have a REST API written in some other language that you want to use in your Node.js app or a web app that only supports HTTP (not TLS) that you want to deploy securely.
```shell
$ site :1313
......@@ -375,21 +397,6 @@ After you install the source and run tests:
npm run install-locally
```
### Building for Linux on ARM (Raspberry Pi, etc.)
You cannot currently [cross-compile for ARM](https://github.com/nexe/nexe/issues/424) so you must build Site.js on an ARM device. The release build is built on a Raspberry Pi 3B+. Note that [Aral had issues compiling it on a Pi 4](https://github.com/nexe/nexe/issues/685). To build the Site.js binary (e.g., version 12.8.0) on an ARM device, do:
```shell
mkdir -p dist/linux-arm/12.8.0
node_modules/nexe/index.js bin/site.js --build --verbose -r package.json -r "bin/commands/*" -r "node_modules/le-store-certbot/renewal.conf.tpl" -r "node_modules/@small-tech/auto-encrypt-localhost/mkcert-bin/mkcert-v1.4.1-linux-arm" -o dist/linux-arm/12.8.0/site
```
You can then find the `site` binary in your `dist/linux-arm/12.8.0/` folder. To install it, do:
```shell
sudo cp dist/linux-arm/12.8.0/site /usr/local/bin
```
### Deployment
```shell
......
......@@ -96,10 +96,7 @@ class Site {
}
static get releaseChannelFormattedForConsole () {
if (this.#manifest === null) {
this.readAndCacheManifest()
}
switch(this.#manifest.releaseChannel) {
switch(this.releaseChannel) {
// Spells ALPHA in large red block letters.
case this.RELEASE_CHANNEL.alpha: return clr(`\n
█████  ██  ██████  ██  ██  █████ 
......@@ -491,9 +488,10 @@ class Site {
const proxyHttpUrl = `http://localhost:${this.proxyPort}`
const proxyWebSocketUrl = `ws://localhost:${this.proxyPort}`
function prettyLog (message) {
let prettyLog = function (message) {
this.log(` 🔁 ❨Site.js❩ ${message}`)
}
prettyLog = prettyLog.bind(this)
const logProvider = function(provider) {
return { log: prettyLog, debug: prettyLog, info: prettyLog, warn: prettyLog, error: prettyLog }
......@@ -756,7 +754,16 @@ class Site {
}
this.log(' ⏰ Setting up auto-update check interval.')
this.autoUpdateCheckInterval = setInterval(checkForUpdates, /* every */ 5 /* hours */ * 60 * 60 * 1000)
// Regular and alpha releases check for updates every 6 hours.
// (You should not be deploying servers using the alpha release channel.)
let hours = 6
let minutes = 60
if (Site.releaseChannel === Site.RELEASE_CHANNEL.beta) {
// Beta releases check for updates every 10 minutes.
hours = 1
minutes = 10
}
this.autoUpdateCheckInterval = setInterval(checkForUpdates, /* every */ hours * minutes * 60 * 1000)
// And perform an initial check a few seconds after startup.
setTimeout(checkForUpdates, 3000)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment