szuru

Table of Contents

Installing hard dependencies
Setting up a database
Preparing environment
Preparing szurubooru for first run
Wiring szurubooru to the web server

Example

It is highly recommended that you deploy using Docker as it is easier install and maintain.

This guide may help the few users who do not wish to use Docker. Please note that this guide may be incomplete or out of date. Additionally, this guide assumes Arch Linux. Although exact instructions for other distributions are different, the steps stay roughly the same.

Installing hard dependencies

Szurubooru requires the following dependencies:

Python (3.8 or later)
Postgres
FFmpeg
node.js

user@host:~$ sudo pacman -S postgresql
user@host:~$ sudo pacman -S python
user@host:~$ sudo pacman -S python-pip
user@host:~$ sudo pacman -S ffmpeg
user@host:~$ sudo pacman -S npm
user@host:~$ sudo pip install virtualenv

The reason ffmpeg is used over, say, ImageMagick or even PIL is because of Flash and video posts.

Setting up a database

First, basic postgres configuration:

user@host:~$ sudo -i -u postgres initdb --locale en_US.UTF-8 -E UTF8 -D /var/lib/postgres/data
user@host:~$ sudo systemctl start postgresql
user@host:~$ sudo systemctl enable postgresql

Then creating a database:

user@host:~$ sudo -i -u postgres createuser --interactive
Enter name of role to add: szuru
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
user@host:~$ sudo -i -u postgres createdb szuru
user@host:~$ sudo -i -u postgres psql -c "ALTER USER szuru PASSWORD 'dog';"

Preparing environment

Getting szurubooru:

user@host:~$ git clone https://github.com/rr-/szurubooru.git szuru
user@host:~$ cd szuru

Installing frontend dependencies:

user@host:szuru$ cd client
user@host:szuru/client$ npm install

npm sandboxes dependencies by default, i.e. installs them to ./node_modules. This is good, because it avoids polluting the system with the project's dependencies. To make Python work the same way, we'll use virtualenv. Installing backend dependencies with virtualenv looks like this:

user@host:szuru/client$ cd ../server
user@host:szuru/server$ virtualenv python_modules # consistent with node_modules
user@host:szuru/server$ source python_modules/bin/activate # enters the sandbox
(python_modules) user@host:szuru/server$ pip install -r requirements.txt # installs the dependencies

Preparing `szurubooru` for first run

Compile the frontend:
```
user@host:szuru$ cd client
user@host:szuru/client$ node build.js
```
You can include the flags --no-transpile to disable the JavaScript transpiler, which provides compatibility with older browsers, and --debug to generate JS source mappings.

Configure things:

user@host:szuru/client$ cd ..
user@host:szuru$ mv server/config.yaml.dist .
user@host:szuru$ cp config.yaml.dist config.yaml
user@host:szuru$ vim config.yaml

Pay extra attention to these fields:

data directory,
data URL,
database,
the smtp section.

Upgrade the database:

user@host:szuru/client$ cd ../server
user@host:szuru/server$ source python_modules/bin/activate
(python_modules) user@host:szuru/server$ alembic upgrade head

alembic should have been installed during installation of szurubooru's dependencies.

Run the tests:

(python_modules) user@host:szuru/server$ pytest

It is recommended to rebuild the frontend after each change to configuration.

Wiring `szurubooru` to the web server

szurubooru is divided into two parts: public static files, and the API. It tries not to impose any networking configurations on the user, so it is the user's responsibility to wire these to their web server.

The static files are located in the client/public/data directory and are meant to be exposed directly to the end users.

The API should be exposed using WSGI server such as waitress, gunicorn or similar. Other configurations might be possible but I didn't pursue them.

API calls are made to the relative URL /api/. Your HTTP server should be configured to proxy this URL format to the WSGI server. Some users may prefer to use a dedicated reverse proxy for this, to incorporate additional features such as load balancing and SSL.

Note that the API URL in the virtual host configuration needs to be the same as the one in the config.yaml, so that client knows how to access the backend!

Example

In this example:

The booru is accessed from http://example.com/
The API is accessed from http://example.com/api
The API server listens locally on port 6666, and is proxied by nginx or apache
The static files are served from /srv/www/booru/client/public/data

You can use either nginx or apache to serve your static content and proxy the api server. Choose whichever you prefer, but don't use both.

nginx configuration:

server {
    listen 80;
    server_name example.com;

    location ~ ^/api$ {
        return 302 /api/;
    }
    location ~ ^/api/(.*)$ {
        if ($request_uri ~* "/api/(.*)") { # preserve PATH_INFO as-is
            proxy_pass http://127.0.0.1:6666/$1;
        }
    }
    location / {
        root /srv/www/booru/client/public;
        try_files $uri /index.htm;
    }
}

apache configuration:

<VirtualHost *:80>
    ServerName example.com

    Redirect 302 /api /api/

    ProxyPreserveHost On
    ProxyPass /api/ http://127.0.0.1:6666/
    ProxyPassReverse /api/ http://127.0.0.1:6666/

    DocumentRoot "/srv/www/booru/client/public"
    FallbackResource /index.htm
    AllowEncodedSlashes On
</VirtualHost>

config.yaml:

data_url: 'http://example.com/data/'
data_dir: '/srv/www/booru/client/public/data'

To run the server using waitress:

user@host:szuru/server$ source python_modules/bin/activate
(python_modules) user@host:szuru/server$ pip install waitress
(python_modules) user@host:szuru/server$ waitress-serve --port 6666 szurubooru.facade:app

or gunicorn:

user@host:szuru/server$ source python_modules/bin/activate
(python_modules) user@host:szuru/server$ pip install gunicorn
(python_modules) user@host:szuru/server$ gunicorn szurubooru.facade:app -b 127.0.0.1:6666