Merge pull request #5 from gmemstr/refactoring

Huge refactoring, simplification and expansion.

.circleci/config.yml

@@ -0,0 +1,41 @@
+version: 2.1
+orbs:
+  upx: circleci/[email protected]
+jobs:
+  build:
+    docker:
+      - image: cimg/go:1.14
+    steps:
+      - checkout
+      - restore_cache:
+          keys:
+            - go-mod-{{ checksum "go.sum" }}-v2
+            - go-mod-{{ checksum "go.sum" }}
+            - go-mod
+      - upx/install
+      - run:
+          command: make dist
+      - store_artifacts:
+          path: build
+      - save_cache:
+          key: go-mod-{{ checksum "go.sum" }}-v2
+          paths:
+            - /home/circleci/go/pkg/mod
+  test:
+    docker:
+      - image: cimg/go:1.14
+    steps:
+      - checkout
+      - restore_cache:
+          keys:
+            - go-mod-{{ checksum "go.sum" }}-v2
+            - go-mod-{{ checksum "go.sum" }}
+            - go-mod
+      - run:
+          command: make test
+workflows:
+  version: 2
+  build-and-test:
+    jobs:
+      - build
+      - test

.gitignore

@@ -14,12 +14,13 @@
 # IntelliJ
 .idea/
 
-# Config file
-config.json
+# Config files
+providers.yml
+auth.yml
 
 # Binary
 nas
+build/
 
 *.db
 .lock
-assets/web/*

Makefile

@@ -0,0 +1,35 @@
+.DEFAULT_GOAL := build
+SLIPROAD_VERSION := 2.0.0
+# Workaround for CircleCI Docker image and mkdir.
+SHELL := /bin/bash
+
+make_build_dir:
+	mkdir -p build/{bin,assets,tars}
+
+build: make_build_dir
+	go build -o build/bin/sliproad
+
+pi: make_build_dir
+	env GOOS=linux GOARCH=arm GOARM=5 go build -o build/bin/sliproad-arm
+
+small: make_build_dir
+	go build -o build/bin/sliproad -ldflags="-s -w"
+	upx --brute build/bin/sliproad -9 --no-progress
+
+small_pi: make_build_dir
+	env GOOS=linux GOARCH=arm GOARM=5 go build -o build/bin/sliproad-arm -ldflags="-s -w"
+	upx --brute build/bin/sliproad-arm -9 --no-progress
+
+run:
+	go run webserver.go
+
+test:
+	go test ./... -cover
+
+dist: clean make_build_dir small small_pi
+	cp -r assets/* build/assets
+	tar -czf build/tars/sliproad-$(SLIPROAD_VERSION)-arm.tar.gz build/assets build/bin/sliproad-arm README.md LICENSE
+	tar -czf build/tars/sliproad-$(SLIPROAD_VERSION)-x86.tar.gz build/assets build/bin/sliproad README.md LICENSE
+
+clean:
+	rm -rf build

README.md

@@ -1,30 +1,76 @@
-# nas
-small go nas platform for my raspberry pi
+# sliproad
+merging filesystems together
 
-## usage
+## about
 
+this project aims to be an easy-to-user web API that allows the management of cloud storage, whether it be on
+the host machine or part of a remote api. this is intended mostly for my own use, but i am documenting it in a way that
+i hope allows others to pick it up and improve on it down the line.
+
+if something is unclear, feel free to open an issue :)
+
+## configuration
+
+unlike the initial version of this project, the current build uses _providers_ to determine how to handle various 
+functions related to files. currently, two are implemented, `disk` and `backblaze`, since they are the primary providers
+i use myself. the providers you would like to use can be added to `providers.yml` alongside the binary.
+
+for example, here is a sample configuration implementing both of them:
+
+```yaml
+disk:
+  provider: disk
+  path: /tmp/nas
+backblaze:
+  provider: backblaze
+  config:
+    appKeyId: APP_KEY_ID
+    appId: APP_ID
+    bucket: BUCKET_ID
 ```
-cp assets/config/config.example.json assets/config/config.json
- # edit config file with your hot/cold storage locations
-nano assets/config/config.json
-# run
-go run webserver.go
-# or build and run
-go build; ./nas
-```
 
-you can also optionally use the `build-pi.sh` to build it for a raspberry pi (tested with raspberry pi 3 model b+)
+(read more here: [#providers](#providers))
+
+## running
+
+after adding the providers you would like to use, the application can be run simply with `./nas`. it will attach to port
+`:3000`.
+
+## building
+
+this project uses go modules and a makefile, so building should be relatively straightforward. 
+
+ - `make` will build the project for your system's architecture.
+ - `make run` will run the project with `go run`
+ - `make pi` will build the project with the `GOOS=linux GOARCH=arm GOARM=5 go` flags set for raspberry pis.
+
+## providers
+
+"providers" provide a handful of functions to interact nicely with a filesystem, whether it be on local disk or on a 
+remote server via an api. best-effort is done to keep these performant, up to date and minimal.
+
+there are a few built-in providers, and more can be added by opening a pull request.
+
+|name|service|configuration example|
+|----|-------|---------------------|
+|disk|local filesystem|assets/config_examples/disk.yml|
+|backblaze|backblaze b2|assets/config_examples/backblaze.yml|
 
-then navigate to `localhost:3000`
+you can find a full configuration file under `assets/config_examples/providers.yml`
 
-## api
+### custom provider
 
-initially the heavy lifting was done by the server, but the need for a better frontend was clear.
+custom file providers can be implemented by adding a new go file to the `files` module. it should
+implement the `FileProviderInterface` interface.
 
-full documentation coming soon once actual functionality has been nailed down.
+## authentication
 
-## credits
+basic authentication support utilizing [keycloak](https://keycloak.org/) has been implemented, but work
+is being done to bring this more inline with the storage provider implementation. see `assets/config_examples/auth.yml`
+for an example configuration - having this file alongside the binary will activate authentication on all
+`/api/files` endpoints. note that this implementation is a work in progress, and a seperate branch will
+contain further improvements.
 
-svg icons via https://iconsvg.xyz
+## icons
 
-raspberry pi svg via https://www.vectorlogo.zone/logos/raspberrypi/index.html
+SVG Icons provided by Paweł Kuna: https://github.com/tabler/tabler-icons (see assets/web/icons/README.md)

assets/config_examples/auth.yml

@@ -0,0 +1,3 @@
+provider_url: "http://localhost:8080"
+realm: "nas"
+redirect_base_url: "http://localhost:3000"

assets/config_examples/backblaze.yml

@@ -0,0 +1,9 @@
+# The Backblaze provider requires an application key, application key ID, and bucket ID to use.
+# You can find steps for generating there here: https://www.backblaze.com/b2/docs/application_keys.html
+# Keys should have at least the listBuckets, readFiles, writeFiles and shareFiles permissions for a bucket.
+backblaze:
+  provider: backblaze
+  config: # Provider-specific files.
+    applicationKeyId: aaaaaaaaaaaa
+    applicationKey: aaaaaaaaaaaa
+    bucket: aaaaaaaaaaaa

assets/config_examples/disk.yml

@@ -0,0 +1,5 @@
+# The disk provider is the most basic of providers, requiring only a path on disk to write and retrieve files to and
+# from.
+disk:
+  provider: disk
+  path: /tmp/nas # This is only used for the `disk` provider right now, and indicates where to manage files.

assets/config_examples/providers.yml

@@ -0,0 +1,20 @@
+# A "provider" is a service that provides access to a filesystem.
+#
+# A full configuration for every provider implemented in the application.
+# You can find full breakdowns for each provider's configuration in it's respective file under
+# `assets/config_examples/`.
+#
+# Schema is as follows:
+# Provider Name: string - used to identify which filesystem to access.
+#   provider: string - should be one of the built-in providers.
+#   path: string - optional, just used for `disk` right now.
+#   config: mapping - used for provider-specific configuration values, such as authentication.
+disk:
+  provider: disk
+  path: /tmp/nas
+backblaze:
+  provider: backblaze
+  config:
+    applicationKeyId: aaaaaaaaaaaa
+    applicationKey: aaaaaaaaaaaa
+    bucket: aaaaaaaaaaaa