Updated installation and README
This commit is contained in:
parent
520a9dff47
commit
1fdd00b833
86
README.md
86
README.md
|
@ -1,44 +1,88 @@
|
||||||
# Web File Storage
|
# Cista Web Storage
|
||||||
|
|
||||||
The Python package installs a `cista` executable. Use `hatch shell` to initiate and install in a virtual environment, or `pip install` it on your system. Alternatively `hatch run cista` may be used to skip the shell step but stay virtual. `pip install hatch` first if needed.
|
Cista takes its name from the ancient cistae, metal containers used by Greeks and Egyptians to safeguard valuable items. This modern application provides a browser interface for secure and accessible file storage, echoing the trust and reliability of its historical namesake.
|
||||||
|
|
||||||
Create your user account:
|
Cista Storage is a cutting-edge file and document server designed for speed, efficiency, and unparalleled ease of use. Experience lightning-fast browsing, thanks to the file list maintained directly in your browser and updated from server filesystem events, coupled with our highly optimized code.
|
||||||
|
|
||||||
|
Fully keyboard-navigable and with a responsive layout, Cista Storage flawlessly adapts to your devices, providing a seamless experience wherever you are.
|
||||||
|
|
||||||
|
Our powerful instant search means you're always just a few keystrokes away from finding exactly what you need. Press 1/2/3 to switch ordering, navigate with all four arrow keys, or by clicking on breadcrumbs that remember where you were.
|
||||||
|
|
||||||
|
The Cista project started as an inevitable remake of [Droppy](https://github.com/droppyjs/droppy) which we used and loved despite its numerous bugs. Cista Storage stands out in handling even the most unconventional filenames, ensuring a smooth experience where others falter.
|
||||||
|
|
||||||
|
All of this is wrapped in an intuitive interface, making Cista Storage the ideal choice for anyone seeking a reliable, versatile, and quick file storage solution. Join us at Cista Storage – where your files are just a click away, safe, and always accessible.
|
||||||
|
|
||||||
|
Experience Cista by visiting [Cista Demo](https://drop.zi.fi) for a test run and perhaps upload something...
|
||||||
|
|
||||||
|
|
||||||
|
## Getting Started
|
||||||
|
### Installation
|
||||||
|
|
||||||
|
To install the cista application, use:
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
cista --user admin --privileged
|
pip install cista
|
||||||
```
|
```
|
||||||
|
|
||||||
## Running the server
|
Note: Some Linux distributions might need `--break-system-packages` to install Python packages, which are safely installed in the user's home folder. As an alternative to avoid installation, run it with command `pipx run cista`
|
||||||
|
|
||||||
Serve your files on localhost:8000:
|
### Running the Server
|
||||||
|
|
||||||
|
Create an account:
|
||||||
|
```sh
|
||||||
|
cista --user yourname --privileged
|
||||||
|
```
|
||||||
|
|
||||||
|
Serve your files at http://localhost:8000:
|
||||||
```sh
|
```sh
|
||||||
cista -l :8000 /path/to/files
|
cista -l :8000 /path/to/files
|
||||||
```
|
```
|
||||||
|
|
||||||
The Git repository does not contain a frontend build, so you should first do that...
|
The server remembers its settings in the config folder (default `~/.local/share/cista/`), including the listen port and directory, for future runs without arguments.
|
||||||
|
|
||||||
## Build frontend
|
### Internet Access
|
||||||
|
|
||||||
Frontend needs to be built before using and after any frontend changes:
|
To use your own TLS certificates, place them in the config folder and run:
|
||||||
|
|
||||||
|
```sh
|
||||||
|
cista -l cista.example.com
|
||||||
|
```
|
||||||
|
|
||||||
|
Most admins instead find the Caddy web server convenient for its auto TLS certificates and all. A proxy also allows running multiple web services or Cista instances on the same IP address. Caddy configuration **/etc/caddy/Caddyfile** is dead simple:
|
||||||
|
|
||||||
|
```Caddyfile
|
||||||
|
cista.example.com {
|
||||||
|
reverse_proxy :8000
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Development setup
|
||||||
|
|
||||||
|
For rapid development, we use the Vite development server for the Vue frontend, while running the backend on port 8000 that Vite proxies backend requests to. Each server live reloads whenever its code or configuration are modified.
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
cd frontend
|
cd frontend
|
||||||
npm install
|
npm install
|
||||||
npm run build
|
npm run dev
|
||||||
```
|
```
|
||||||
|
|
||||||
This will place the front in `cista/wwwroot` from where the backend server delivers it, and that also gets included in the Python package built via `hatch build`.
|
Concurrently, start the backend on another terminal:
|
||||||
|
|
||||||
## Development setup
|
```sh
|
||||||
|
hatch shell
|
||||||
|
pip install -e '.[dev]'
|
||||||
|
cista --dev -l :8000 /path/to/files
|
||||||
|
```
|
||||||
|
|
||||||
For rapid turnaround during development, you should run `npm run dev` Vite development server on the Vue frontend. While that is running, start the backend on another terminal `hatch run cista --dev -l :8000` and connect to the frontend.
|
We use `hatch shell` for installing on a virtual environment, to not disturb the rest of the system with our hacking.
|
||||||
|
|
||||||
The backend and the frontend will each reload automatically at any code or config changes.
|
Vue is used to build files in `cista/wwwroot`, included prebuilt in the Python package. Running `hatch build` builds the frontend and creates a NodeJS-independent Python package.
|
||||||
|
|
||||||
## System deployment
|
## System Deployment
|
||||||
|
|
||||||
Clone the repository to `/srv/cista/cista-storage` or other suitable location accessible to the storage user account you plan to use. `sudo -u storage -s` and build the frontend if you hadn't already.
|
This setup allows easy addition of storages, each with its own domain, configuration, and files.
|
||||||
|
|
||||||
|
Assuming a restricted user account **storage** for serving files and that cista is installed system-wide or on this account (check with `sudo -u storage -s`). Alternatively, use `pipx run cista` or `hatch run cista` as the ExecStart command.
|
||||||
|
|
||||||
Create **/etc/systemd/system/cista@.service**:
|
Create **/etc/systemd/system/cista@.service**:
|
||||||
|
|
||||||
|
@ -48,16 +92,14 @@ Description=Cista storage %i
|
||||||
|
|
||||||
[Service]
|
[Service]
|
||||||
User=storage
|
User=storage
|
||||||
WorkingDirectory=/srv/cista/cista-storage
|
ExecStart=cista -c /srv/cista/%i -l /srv/cista/%i/socket /media/storage/@%i/
|
||||||
ExecStart=hatch run cista -c /srv/cista/%i -l /srv/cista/%i/socket /media/storage/@%i/
|
|
||||||
TimeoutStopSec=2
|
|
||||||
Restart=always
|
Restart=always
|
||||||
|
|
||||||
[Install]
|
[Install]
|
||||||
WantedBy=multi-user.target
|
WantedBy=multi-user.target
|
||||||
```
|
```
|
||||||
|
|
||||||
This assumes you may want to run multiple separate storages, each having their files under `/media/storage/<domain>` and configuration under `/srv/cista/<domain>/`. Instead of numeric ports, we use UNIX sockets for convenience.
|
This setup supports multiple storages, each under `/media/storage/<domain>` for files and `/srv/cista/<domain>/` for configuration. UNIX sockets are used instead of numeric ports for convenience.
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
systemctl daemon-reload
|
systemctl daemon-reload
|
||||||
|
@ -65,7 +107,7 @@ systemctl enable --now cista@foo.example.com
|
||||||
systemctl enable --now cista@bar.example.com
|
systemctl enable --now cista@bar.example.com
|
||||||
```
|
```
|
||||||
|
|
||||||
Exposing this publicly online is the most convenient using the [Caddy](https://caddyserver.com/) web server but you can of course use Nginx or others as well. Or even run the server with `-l domain.example.com` given TLS certificates in the config folder.
|
Public exposure is easiest using the Caddy web server, but Nginx or others also work. Run the server with -l domain.example.com if you have TLS certificates in the config folder.
|
||||||
|
|
||||||
**/etc/caddy/Caddyfile**:
|
**/etc/caddy/Caddyfile**:
|
||||||
|
|
||||||
|
@ -74,5 +116,3 @@ foo.example.com, bar.example.com {
|
||||||
reverse_proxy unix//srv/cista/{host}/socket
|
reverse_proxy unix//srv/cista/{host}/socket
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Using the `{host}` placeholder we can just put all the domains on the same block. That's the full server configuration you need. `systemctl enable --now caddy` or `systemctl restart caddy` for the config to take effect.
|
|
||||||
|
|
10
cista/app.py
10
cista/app.py
|
@ -11,7 +11,7 @@ import brotli
|
||||||
import sanic.helpers
|
import sanic.helpers
|
||||||
from blake3 import blake3
|
from blake3 import blake3
|
||||||
from sanic import Blueprint, Sanic, empty, raw
|
from sanic import Blueprint, Sanic, empty, raw
|
||||||
from sanic.exceptions import Forbidden, NotFound, ServerError
|
from sanic.exceptions import Forbidden, NotFound
|
||||||
from sanic.log import logging
|
from sanic.log import logging
|
||||||
from stream_zip import ZIP_AUTO, stream_zip
|
from stream_zip import ZIP_AUTO, stream_zip
|
||||||
|
|
||||||
|
@ -119,11 +119,9 @@ def _load_wwwroot(www):
|
||||||
if len(br) >= len(data):
|
if len(br) >= len(data):
|
||||||
br = False
|
br = False
|
||||||
wwwnew[name] = data, br, headers
|
wwwnew[name] = data, br, headers
|
||||||
if not wwwnew:
|
if not wwwnew and not app.debug:
|
||||||
raise ServerError(
|
logging.warning(
|
||||||
"Web frontend missing. Did you forget npm run build?",
|
f"Web frontend missing from {base}\n Did you forget: hatch build"
|
||||||
extra={"wwwroot": str(base)},
|
|
||||||
quiet=True,
|
|
||||||
)
|
)
|
||||||
return wwwnew
|
return wwwnew
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user