Initial commit - existing project files
This commit is contained in:
commit
c49798a9ea
82 changed files with 4304 additions and 0 deletions
81
docs/Commands.md
Normal file
81
docs/Commands.md
Normal file
|
@ -0,0 +1,81 @@
|
|||
# Commands
|
||||
|
||||
You run a command with
|
||||
|
||||
```
|
||||
./run.sh <command>
|
||||
```
|
||||
|
||||
## Available Commands
|
||||
|
||||
---
|
||||
|
||||
`server` - Start the server
|
||||
This starts a caddy instance, hypercorn with the django application and a scheduler that automatically removes expired session data.
|
||||
Log files will be written.
|
||||
|
||||
---
|
||||
|
||||
`setup` - Set up the application
|
||||
This sets up some database tables, views, and more, generates a secret key for the application and lets you create an admin user.
|
||||
|
||||
---
|
||||
|
||||
`create-admin` - Lets you create an admin user
|
||||
|
||||
---
|
||||
|
||||
`generate-tls-cert` - generate a new self-signed tls certificate for https
|
||||
This overwrites the original files, if present (see [Setup](Setup.md)).
|
||||
|
||||
---
|
||||
|
||||
`generate-secret-key` - generate a new random secret key for django
|
||||
This will overwrite the old one.
|
||||
Warning: After running this, current sessions will be invalid, and the users have to relogin. Don't run this command while the server is running.
|
||||
|
||||
---
|
||||
|
||||
`clear-sessions` - manually remove all expired sessions from the database
|
||||
|
||||
---
|
||||
|
||||
`force-db-upgrade` - force a database migration and -upgrade
|
||||
This is mainly used in development.
|
||||
|
||||
---
|
||||
|
||||
`archive-tables` - archive (copy & delete) all entries in app_order and app_registertransaction
|
||||
Use this to archive old orders or transactions (e.g. when the database gets too big).
|
||||
|
||||
---
|
||||
|
||||
`development-server` - Start the development server
|
||||
This starts a caddy instance, the django development server with DEBUGGING enabled and the session-clear-scheduler.
|
||||
Only the HTTP-Access-Log will be written to its logfile, other logs will be written to the console.
|
||||
|
||||
---
|
||||
|
||||
`run-script <path>` - Run a python script in the context of the django project (experimental)
|
||||
`<path>` is the path to the python script
|
||||
|
||||
Keep in mind that the current directory won't be changed automatically to the parent folder of the script file.
|
||||
|
||||
---
|
||||
|
||||
`help` - Show a help text
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
Run the production server:
|
||||
```
|
||||
./run.sh server
|
||||
```
|
||||
|
||||
Create a new admin:
|
||||
```
|
||||
./run.sh create-admin
|
||||
```
|
23
docs/Configuration.md
Normal file
23
docs/Configuration.md
Normal file
|
@ -0,0 +1,23 @@
|
|||
# Configuration
|
||||
|
||||
## Main Configuration
|
||||
|
||||
`./config/config.sh`
|
||||
|
||||
There is no default configuration available, only a sample configuration with explanations.
|
||||
|
||||
|
||||
## Configuration files for tls certificates
|
||||
|
||||
This is the configuration for self-signed local TLS certificate generation.
|
||||
|
||||
`./config/tls/cert-config.sh`
|
||||
|
||||
This is already configured, but you can modify this for your needs.
|
||||
|
||||
|
||||
## Caddy Server Configuration
|
||||
|
||||
`./config/Caddyfile`
|
||||
|
||||
The default configuration should work out of the box, don't edit this file unless you know what you're doing.
|
117
docs/Setup.md
Normal file
117
docs/Setup.md
Normal file
|
@ -0,0 +1,117 @@
|
|||
# Setup
|
||||
|
||||
## I. Dependencies
|
||||
|
||||
Before the actual setup, you have to satisfy the following dependencies:
|
||||
|
||||
|
||||
### System
|
||||
|
||||
- `pg_config`
|
||||
- Fedora/RHEL: `libpq-dev`
|
||||
- `Caddy` 2.4.3+ (HTTP Reverse Proxy & Static File Server)
|
||||
- `gcc`, `gettext`
|
||||
- `Python` 3.9 with pip
|
||||
- `Python` header files
|
||||
- Fedora/RHEL: `python3-devel`
|
||||
|
||||
|
||||
### Python Packages (pip)
|
||||
|
||||
- `django~=3.2.7`
|
||||
- `django-currentuser==0.5.3`
|
||||
- `django-csp==3.7`
|
||||
- `psycopg2~=2.9.1`
|
||||
- `hypercorn~=0.11.2`
|
||||
- `cryptography~=36.0.0` (for self-signed tls certificates)
|
||||
|
||||
You can install those pip-packages with the following command:
|
||||
```bash
|
||||
pip install -U -r pip-dependencies.txt
|
||||
```
|
||||
|
||||
## II.A Installation
|
||||
|
||||
You can get the latest version with git:
|
||||
|
||||
```
|
||||
git clone --branch release-x.x https://gitlab.com/W13R/drinks-manager.git
|
||||
```
|
||||
(replace x.x with the latest version)
|
||||
|
||||
Alternatively, you can download the [latest release](https://gitlab.com/W13R/drinks-manager/-/releases) and extract the files to your prefered destination.
|
||||
|
||||
<u>**Warning:**</u>
|
||||
|
||||
Make shure that you set the correct file permissions, especially for the config files !!
|
||||
|
||||
The following should be sufficient:
|
||||
|
||||
```bash
|
||||
chmod -R u+rw,g+r,g-w,o-rwx <drinks_manager_directory>
|
||||
```
|
||||
|
||||
|
||||
## II.B Update
|
||||
|
||||
If you installed the application with git, you can run the following in the drinks-manager directory to update to the new version:
|
||||
|
||||
```
|
||||
git fetch
|
||||
git checkout release-x.x
|
||||
```
|
||||
(replace x.x with the new version)
|
||||
|
||||
If you downloaded the application from the releases page, you can download the new release in the same manner, and overwrite the old files with the new ones.
|
||||
|
||||
You have to restart the application server to apply the changes.
|
||||
WARNING: The auto-upgrade mechanism may expect you to input information. Therefore, you should start the application from the command-line the first time after an update.
|
||||
|
||||
Further upgrading-instructions may be provided in the Release Notes on the Releases Page of this Project (Deployments -> Releases).
|
||||
|
||||
|
||||
## III. Database
|
||||
|
||||
This project is using PostgreSQL. You have to set up a database by yourself.
|
||||
The database must have the schema `public` (exists on a new database). Make shure that you create a database user with the necessary privileges to write to and read from the database (SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, CREATE, CONNECT):
|
||||
|
||||
```sql
|
||||
-- connected to target database
|
||||
grant SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES on all tables in schema public to <dbuser>;
|
||||
grant CREATE, CONNECT on database <dbname> to <dbuser>;
|
||||
```
|
||||
|
||||
You can configure your database connection in `config/config.sh`.
|
||||
|
||||
|
||||
## IV. HTTPS & TLS Certificates
|
||||
|
||||
TLS/SSL certificates are required.
|
||||
If you don't have a TLS/SSL certificate already, you can generate one
|
||||
with the command `./run.sh generate-tls-cert`. This will generate a
|
||||
new TLS certificate and key file at `config/tls/server.pem` (certificate)
|
||||
and `config/tls/server-key.pem` (key).
|
||||
WARNING: This will overwrite an existing certificate/key with the same filepath.
|
||||
By default those generated certificates are valid for one year. After that year,
|
||||
they have to be regenerated with the same command.
|
||||
|
||||
If you have a certificate and key file already, you can put them in the following places:
|
||||
|
||||
- `config/tls/server.pem` for the certificate
|
||||
- `config/tls/server-key.pem` for the key
|
||||
|
||||
You can set another filepath for those files in your caddy configuration at `config/Caddyfile`.
|
||||
|
||||
|
||||
## V. Configuration
|
||||
|
||||
see [Configuration](Configuration.md)
|
||||
|
||||
|
||||
## VI. Run Setup Command
|
||||
|
||||
run `./run.sh setup`
|
||||
|
||||
This will automatically set up database tables, views and entries, set up Django and let you create a admin user.
|
||||
|
||||
After this, start the server with `./run.sh server` and navigate to `https://your.ip.add.ress:port/admin/`.
|
Loading…
Add table
Add a link
Reference in a new issue