(v0.4.5) Automated packaging of release by Packagr

related #121

docker/entrypoint-collector.sh

@@ -1,9 +1,9 @@
 #!/bin/bash
+
 # Cron runs in its own isolated environment (usually using only /etc/environment )
 # So when the container starts up, we will do a dump of the runtime environment into a .env file that we
-# will then source into the crontab file (/etc/cron.d/scrutiny.sh)
+# will then source into the crontab file (/etc/cron.d/scrutiny)
-
+(set -o posix; export -p) > /env.sh
-printenv | sed 's/^\(.*\)$/export \1/g' > /env.sh
 
 # adding ability to customize the cron schedule.
 COLLECTOR_CRON_SCHEDULE=${COLLECTOR_CRON_SCHEDULE:-"0 0 * * *"}
@@ -11,6 +11,7 @@ COLLECTOR_CRON_SCHEDULE=${COLLECTOR_CRON_SCHEDULE:-"0 0 * * *"}
 # if the cron schedule has been overridden via env variable (eg docker-compose) we should make sure to strip quotes
 [[ "${COLLECTOR_CRON_SCHEDULE}" == \"*\" || "${COLLECTOR_CRON_SCHEDULE}" == \'*\' ]] && COLLECTOR_CRON_SCHEDULE="${COLLECTOR_CRON_SCHEDULE:1:-1}"
 
+# replace placeholder with correct value
 sed -i 's|{COLLECTOR_CRON_SCHEDULE}|'"${COLLECTOR_CRON_SCHEDULE}"'|g' /etc/cron.d/scrutiny
 
 # now that we have the env start cron in the foreground

docs/TROUBLESHOOTING_DEVICE_COLLECTOR.md

@@ -118,6 +118,19 @@ instead of the block device (`/dev/nvme0n1`). See [#209](https://github.com/Anal
 ### Volume Mount All Devices (`/dev`) - Privileged
 
 
+## Scrutiny detects Failure but SMART Passed?
+
+There's 2 different mechanisms that Scrutiny uses to detect failures.
+
+The first is simple SMART failures. If SMART thinks an attribute is in a failed state, Scrutiny will display it as failed as well.
+
+The second is using BackBlaze failure data: [https://backblaze.com/blog-smart-stats-2014-8.html](https://backblaze.com/blog-smart-stats-2014-8.html) 
+If Scrutiny detects that an attribute corresponds with a high rate of failure using BackBlaze's data, it will also mark that attribute (and disk) as failed (even though SMART may think the device is still healthy).
+
+This can cause some confusion when comparing Scrutiny's dashboard against other SMART analysis tools. 
+If you hover over the "failed" label beside an attribute, Scrutiny will tell you if the failure was due to SMART or Scrutiny/BackBlaze data. 
+
+
 ## Hub & Spoke model, with multiple Hosts.
 
 When deploying Scrutiny in a hub & spoke model, it can be difficult to determine exactly which node a set of devices are associated with.

docs/TROUBLESHOOTING_INFLUXDB.md

@@ -8,8 +8,9 @@ https://docs.influxdata.com/influxdb/v2.2/install/
 ## Persistence
 
 To ensure that all data is correctly stored, you must also persist the InfluxDB database directory
-    - `/opt/scrutiny/influxdb` (for Docker omnibus image)
+
-    - `/var/lib/influxdb2` (for vanilla Influxdb image `influxdb:2.2`)
+- If you're using the Official Scrutiny Omnibus image (`ghcr.io/analogj/scrutiny:master-omnibus`), the path is `/opt/scrutiny/influxdb`
+- If you're deploying in Hub/Spoke mode with the InfluxDB maintained image (`influxdb:2.2`), the path is `/var/lib/influxdb2`
 
 If you attempt to restart Scrutiny but you forgot to persist the InfluxDB directory, you will get an error message like follows:
 
@@ -40,4 +41,28 @@ scrutiny    | panic: conflict: onboarding has already been completed
 You can fix this issue by authenticating to the InfluxDB admin portal (the default credentials are username: `admin`, password: `password12345`),
 then retrieving the API token, and writing it to your `scrutiny.yaml` config file under the `web.influxdb.token` field:
 
-![influx db admin token](./influxdb-admin-token.png)
+![influx db admin token](./influxdb-admin-token.png)
+
+## Upgrading from v0.3.x to v0.4.x
+
+When upgrading from v0.3.x to v0.4.x, some users have noticed problems such as:
+
+```
+2022/05/13 14:38:05 Loading configuration file: /opt/scrutiny/config/scrutiny.yaml
+time="2022-05-13T14:38:05Z" level=info msg="Trying to connect to scrutiny sqlite db:"
+time="2022-05-13T14:38:05Z" level=info msg="Successfully connected to scrutiny sqlite db:"
+panic: a username and password is required for a setup
+```
+
+As discussed in [#248](https://github.com/AnalogJ/scrutiny/issues/248) and [#234](https://github.com/AnalogJ/scrutiny/issues/234),
+this usually related to either:
+
+- Upgrading from the LSIO Scrutiny image to the Official Scrutiny image, without removing LSIO specific environmental variables
+  - remove the `SCRUTINY_WEB=true` and `SCRUTINY_COLLECTOR=true` environmental variables. They were used by the LSIO image, but are unnecessary and cause issues with the official Scrutiny image.
+- Updated versions of the [LSIO Scrutiny images are broken](https://github.com/linuxserver/docker-scrutiny/issues/22), as they have not installed InfluxDB which is a required dependency of Scrutiny v0.4.x
+  - You can revert to an earlier version of the LSIO image (`lscr.io/linuxserver/scrutiny:060ac7b8-ls34`), or just change to the official Scrutiny image (`ghcr.io/analogj/scrutiny:master-omnibus`)
+
+Here's a couple of confirmed working docker-compose files that you may want to look at:
+
+- https://github.com/AnalogJ/scrutiny/blob/master/docker/example.hubspoke.docker-compose.yml
+- https://github.com/AnalogJ/scrutiny/blob/master/docker/example.omnibus.docker-compose.yml

rootfs/etc/cont-init.d/50-cron-config

@@ -1,5 +1,11 @@
 #!/usr/bin/with-contenv bash
 
+# Cron runs in its own isolated environment (usually using only /etc/environment )
+# So when the container starts up, we will do a dump of the runtime environment into a .env file that we
+# will then source into the crontab file (/etc/cron.d/scrutiny)
+(set -o posix; export -p) > /env.sh
+
+# adding ability to customize the cron schedule.
 COLLECTOR_CRON_SCHEDULE=${COLLECTOR_CRON_SCHEDULE:-"0 0 * * *"}
 
 # if the cron schedule has been overridden via env variable (eg docker-compose) we should make sure to strip quotes

rootfs/etc/services.d/cron/run

@@ -1,10 +1,4 @@
 #!/usr/bin/with-contenv bash
 
-# Cron runs in its own isolated environment (usually using only /etc/environment )
-# So when the container starts up, we will do a dump of the runtime environment into a .env file that we
-# will then source into the crontab file (/etc/cron.d/scrutiny.sh)
-
-(set -o posix; export -p) > /env.sh
-
 echo "starting cron"
 cron -f -L 15

webapp/backend/pkg/version/version.go

@@ -2,4 +2,4 @@ package version
 
 // VERSION is the app-global version string, which will be replaced with a
 // new value during packaging
-const VERSION = "0.4.4"
+const VERSION = "0.4.5"