Skip to main content
Version: 4.x

Installation FAQ

python manage.py updatedb fails​

Usually one of the following:

  • The Python version is too old; Spug 4.0 requires Python 3.8 or later.
  • Dependency versions do not match. Install them with pip install -r requirements.txt as documented (Django 4.2, channels 4, ...) and do not up- or downgrade single packages.
  • When using SQLite, the system SQLite is too old; Django 4.2 needs SQLite 3.21.0 or later. Use MySQL / MariaDB in production.

Nginx reports permission denied for the front-end files​

Check whether selinux is enabled. Run setenforce 0 to disable it temporarily and try again.

Login fails with 504 Gateway Timeout​

Make sure the api service is running. In a manual deployment it listens on 127.0.0.1:9001 (see spug_api/tools/start-api.sh) and the /api/ location in Nginx must proxy to that address. In development the front-end proxies to http://127.0.0.1:8000 through spug_web/src/setupProxy.js, so python manage.py runserver must listen on that port.

Login fails with 502 Bad Gateway​

Make sure the api service is running and the nginx configuration is correct. If the nginx log shows 13: Permission denied, disable selinux and try again.

Login fails with Exception: Error 61 connecting to 127.0.0.1:6379. Connection refused.​

Redis (5.0 or later) must be installed. If it does not listen on 127.0.0.1, set its address in spug_api/spug/overrides.py; both CACHES and CHANNEL_LAYERS use Redis, see below.

The host console, deploy page or pipeline console shows no output​

Real-time output is pushed over WebSocket. Make sure the spug-ws service (daphne) is running and that Nginx forwards /api/ws/ as WebSocket, see WebSocket.

Adding a host fails with Exception: not a vaild RSA private key file​

The key pair generated by Spug could not be validated. Check that the private key uploaded under System / Settings / SSH Key Settings is valid (RSA, Ed25519, ECDSA and DSA are supported; Spug generates 2048-bit RSA keys), or clear it and let Spug generate a new pair.

How do I use a Redis server with a password?​

Assuming the password is foo123, add the following to spug_api/spug/overrides.py (recommended) or settings.py (harder to upgrade later) and restart the services.

Tip

Custom settings go into spug_api/spug/overrides.py, which overrides the defaults. With the Docker install the file is at /data/spug/service/spug_api/spug/overrides.py on the host. Settings in overrides.py replace the whole dictionary instead of being merged, so keep the remaining keys from settings.py (KEY_PREFIX of CACHES; prefix / capacity / expiry of CHANNEL_LAYERS) and only change the address and password.

vi spug_api/spug/overrides.py
CACHES = {
"default": {
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "redis://:foo123@127.0.0.1:6379/1",
"KEY_PREFIX": "spug",
"OPTIONS": {
"CLIENT_CLASS": "django_redis.client.DefaultClient",
}
}
}

CHANNEL_LAYERS = {
"default": {
"BACKEND": "channels_redis.core.RedisChannelLayer",
"CONFIG": {
"hosts": ["redis://:foo123@127.0.0.1:6379/0"],
"prefix": "spug:channel",
"capacity": 1000,
"expiry": 120,
},
},
}

Using an external MySQL with the Docker install​

The Docker install takes its database connection entirely from the environment variables of the spug service in docker-compose.yml. To use an external database:

  1. Create a database and user with the utf8mb4 charset on your MySQL / MariaDB server.
  2. Remove the db service and the depends_on entry of the spug service from docker-compose.yml.
  3. Set MYSQL_HOST, MYSQL_PORT, MYSQL_DATABASE, MYSQL_USER and MYSQL_PASSWORD of the spug service to the external database.
  4. Run docker compose up -d and then the initialization command.
Note

The container generates /data/spug/spug_api/spug/overrides.py from the environment variables on its very first start and does not overwrite it afterwards. If the container has already been initialized, edit the DATABASES section of /data/spug/service/spug_api/spug/overrides.py on the host and restart the container. When migrating data, read the upgrade notes first so that future upgrades keep working.

Using SQL Server​

Thanks to @xiongwu1 for the contribution, see #38.