"ValueError: DJANGO_EMAIL_SECURITY, if set, must be either SSL or TSL"

[johann-petrak]

• Downloaded get-teamware.sh as of 2024-03-11
• (script does not show a version number nor contains on in its comments)
• run the script and leave all inputs related to SMTP empty, answer "n" to question if SMTP requires secure connection
• run docker compose up
• Get lots of exceptions on the log:

teamware02-backend-1    | Traceback (most recent call last):
teamware02-backend-1    |   File "/app/manage.py", line 22, in <module>
teamware02-backend-1    |     main()
teamware02-backend-1    |   File "/app/manage.py", line 18, in main
teamware02-backend-1    |     execute_from_command_line(sys.argv)
teamware02-backend-1    |   File "/app/.local/lib/python3.9/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
teamware02-backend-1    |     utility.execute()
teamware02-backend-1    |   File "/app/.local/lib/python3.9/site-packages/django/core/management/__init__.py", line 363, in execute
teamware02-backend-1    |     settings.INSTALLED_APPS
teamware02-backend-1    |   File "/app/.local/lib/python3.9/site-packages/django/conf/__init__.py", line 82, in __getattr__
teamware02-backend-1    |     self._setup(name)
teamware02-backend-1    |   File "/app/.local/lib/python3.9/site-packages/django/conf/__init__.py", line 69, in _setup
teamware02-backend-1    |     self._wrapped = Settings(settings_module)
teamware02-backend-1    |   File "/app/.local/lib/python3.9/site-packages/django/conf/__init__.py", line 170, in __init__
teamware02-backend-1    |     mod = importlib.import_module(self.SETTINGS_MODULE)
teamware02-backend-1    |   File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
teamware02-backend-1    |     return _bootstrap._gcd_import(name[level:], package, level)
teamware02-backend-1    |   File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
teamware02-backend-1    |   File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
teamware02-backend-1    |   File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
teamware02-backend-1    |   File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
teamware02-backend-1    |   File "<frozen importlib._bootstrap_external>", line 850, in exec_module
teamware02-backend-1    |   File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
teamware02-backend-1    |   File "/app/teamware/settings/deployment.py", line 4, in <module>
teamware02-backend-1    |     from .base import *
teamware02-backend-1    |   File "/app/teamware/settings/base.py", line 218, in <module>
teamware02-backend-1    |     raise ValueError("DJANGO_EMAIL_SECURITY, if set, must be either SSL or TLS")
teamware02-backend-1    | ValueError: DJANGO_EMAIL_SECURITY, if set, must be either SSL or TLS
teamware02-backend-1 exited with code 0

[johann-petrak]

Tried to change the DJANGO_EMAIL_BACKEND setting to django.core.mail.backends.console.EmailBackend and SECURITY to TLS and now getting exception

teamware02-backend-1    | /app/.local/lib/python3.9/site-packages/django/core/management/commands/makemigrations.py:105: RuntimeWarning: Got an error checking a consistent migration history performed for database connection 'default': FATAL:  password authentication failed for user "gate"
teamware02-backend-1    | 
teamware02-backend-1    |   warnings.warn(
teamware02-backend-1    | No changes detected
teamware02-db-1         | 2024-03-11 12:52:08.149 UTC [30] FATAL:  password authentication failed for user "gate"
teamware02-db-1         | 2024-03-11 12:52:08.149 UTC [30] DETAIL:  Connection matched pg_hba.conf line 100: "host all all all scram-sha-256"
teamware02-backend-1    | Traceback (most recent call last):
teamware02-backend-1    |   File "/app/.local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection
teamware02-backend-1    |     self.connect()
teamware02-backend-1    |   File "/app/.local/lib/python3.9/site-packages/django/utils/asyncio.py", line 33, in inner
teamware02-backend-1    |     return func(*args, **kwargs)
teamware02-backend-1    |   File "/app/.local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 200, in connect
teamware02-backend-1    |     self.connection = self.get_new_connection(conn_params)
teamware02-backend-1    |   File "/app/.local/lib/python3.9/site-packages/django/utils/asyncio.py", line 33, in inner
teamware02-backend-1    |     return func(*args, **kwargs)
teamware02-backend-1    |   File "/app/.local/lib/python3.9/site-packages/django/db/backends/postgresql/base.py", line 187, in get_new_connection
teamware02-backend-1    |     connection = Database.connect(**conn_params)
teamware02-backend-1    |   File "/app/.local/lib/python3.9/site-packages/psycopg2/__init__.py", line 122, in connect
teamware02-backend-1    |     conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
teamware02-backend-1    | psycopg2.OperationalError: FATAL:  password authentication failed for user "gate"
teamware02-backend-1    | 
teamware02-backend-1    | 

[johann-petrak]

Is there by now a simple/recommended way to set up teamware without any email usage, just let the admin user define the other users? Wanted to set up a new annotation project from scratch and cannot really remember the manual hacks I might have used in the previous project to achieve this ...

[ianroberts]

Is there by now a simple/recommended way to set up teamware without any email usage

No, there isn't. I think the way you've done it (by setting the console backend) is the best approach if you did need to run without any email sending but I'm not sure why you're then getting a postgresql authentication failure.

Unless this is one of those cases where you've started a fresh installation but in a directory whose name is the same as one you've used previously on the same machine - the docker compose container names are derived from the name of the folder that contains the compose file, so if you've previously had a different teamware installation in a directory named teamware02 and the postgresql persistent volume from that old stack still exists, then docker compose will re-use the existing volume (which has a database that's already been set up using a different DB password) rather than creating an empty one for the new install. If the old installation is entirely defunct then docker compose down -v should delete the persistent volumes, allowing the database to be set up again from scratch.

[ianroberts]

There is an actual bug here though, which is that the only way to specify "no security" for the email server is not to set the DJANGO_EMAIL_SECURITY variable at all in your .env, whereas in get-teamware.sh when you say no to the security question it sets the variable, but to an empty string. This is something I can fix.

[johann-petrak]

Thanks running docker compose down did help to fix this!
Would it be an option to automatically put the console backend into env if empty SMPT parms are entered? Or first ask if SMPT is wanted and then do this?

Also perhaps it would be good to better choose that container name and e.g. include the creationdate in the name? it is very easy to get a name clash with the current method and the error one gets does not make users like me think of such a name clash..

[ianroberts]

Also perhaps it would be good to better choose that container name and e.g. include the creationdate in the name?

This is tricky - the way docker compose works is that you can either hard-code a specific container name in the compose file, or you can let compose generate a name as <project-name>-<service-name>-<index> where the project name defaults to the folder containing the compose file (but can be changed with a command line option to docker compose). If we wanted to have unique container names per installation we'd have to generate the compose file rather than using a single fixed one, and then there's all the issues with re-generating it on upgrades etc.

Given this only affects the (unusual) case of someone wanting to run multiple independent installations of teamware on the same server, I don't think it's a particularly high priority.