Issue after installation SecretKey
Closed this issue · 10 comments
Hi,
I`m getting the following message after executing the start script (sudo python3 -m FreeTAKServer.controllers.services.FTS)
AttributeError: type object 'MainConfig' has no attribute 'SecretKey'
I have upgraded to version 1.9.9
There is a secret key in the the main config file.
Help is appriciated.
Many thanks
Matt
what is the output of sudo python3 -m pip show FreeTAKServer and specify how you installed it?
same issue - installed acc. to https://freetakteam.github.io/FreeTAKServer-User-Docs/Installation/Linux/1_Install/
Configure and Run FTS (1.9+)
this works only for 1.9 or better, for see here for manual configuration start FTS
"sudo python3 -m FreeTAKServer.controllers.services.FTS"
Then see at "issue above".
can we confirm that this issue is present in the current version 1.9.6?
Well, I can tell you that this is still a problem in the 1.9.9.2 releases.
I spent a couple of hours fixing the IP address problems in the official Docker image. The FreeTAKServer-Docker repo is set to use old versions of FreeTAKServer and FreeTAKServer-UI. These older versions don't specify dependencies correctly and as a result get the following error continuously in the UI server logs.
Traceback (most recent call last):
File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/usr/local/lib/python3.8/dist-packages/FreeTAKServer/controllers/services/FTS.py", line 6, in <module>
from FreeTAKServer.controllers.services.TCPDataPackageService import TCPDataPackageService as TCPFlaskFunctions
File "/usr/local/lib/python3.8/dist-packages/FreeTAKServer/controllers/services/TCPDataPackageService.py", line 1, in <module>
from .DataPackageServer import FlaskFunctions, Path, dp_directory, os, app, eventlet, const
File "/usr/local/lib/python3.8/dist-packages/FreeTAKServer/controllers/services/DataPackageServer.py", line 13, in <module>
from FreeTAKServer.controllers.DatabaseControllers.DatabaseController import DatabaseController
File "/usr/local/lib/python3.8/dist-packages/FreeTAKServer/controllers/DatabaseControllers/DatabaseController.py", line 1, in <module>
import FreeTAKServer.controllers.DatabaseControllers.table_controllers
File "/usr/local/lib/python3.8/dist-packages/FreeTAKServer/controllers/DatabaseControllers/table_controllers.py", line 3, in <module>
from FreeTAKServer.model.SQLAlchemy.User import User
File "/usr/local/lib/python3.8/dist-packages/FreeTAKServer/model/SQLAlchemy/User.py", line 18, in <module>
from FreeTAKServer.model.SQLAlchemy.system_user import SystemUser
File "/usr/local/lib/python3.8/dist-packages/FreeTAKServer/model/SQLAlchemy/system_user.py", line 6, in <module>
from flask_login import UserMixin
File "/usr/local/lib/python3.8/dist-packages/flask_login/__init__.py", line 12, in <module>
from .login_manager import LoginManager
File "/usr/local/lib/python3.8/dist-packages/flask_login/login_manager.py", line 4, in <module>
from flask import abort
File "/usr/local/lib/python3.8/dist-packages/flask/__init__.py", line 14, in <module>
from jinja2 import escape
File "/usr/local/lib/python3.8/dist-packages/jinja2/__init__.py", line 12, in <module>
from .environment import Environment
File "/usr/local/lib/python3.8/dist-packages/jinja2/environment.py", line 25, in <module>
from .defaults import BLOCK_END_STRING
File "/usr/local/lib/python3.8/dist-packages/jinja2/defaults.py", line 3, in <module>
from .filters import FILTERS as DEFAULT_FILTERS # noqa: F401
File "/usr/local/lib/python3.8/dist-packages/jinja2/filters.py", line 13, in <module>
from markupsafe import soft_unicode
ImportError: cannot import name 'soft_unicode' from 'markupsafe' (/usr/local/lib/python3.8/dist-packages/markupsafe/__init__.py)
I have tried to rebuild the docker container using FreeTAKServer set to 1.9.6 and FreeTAKServer-UI set to 1.9.5, but these versions have the same ImportError. You guys really need to get a handle on your dependency tree and set proper version restrictions on the dependencies. I am suspecting that the problem is that MarkupSafe should have been restricted so that it would not pull in the 2.1.0 package.
I know the above is a bit outside the scope of this issue, but it is frustrating to try to get the software running and hitting issues like these that should have been caught in your CI testing. Which then is further aggravated by the problem that this issue is trying to address.
So digging into the current code branches for FreeTAKServer and FreeTAKServer-UI it is mounting to the frustration level that there are 2 different methods for configuration. The two projects are closely related--why are there different configuration methods?
In FreeTAKServer-UI the configuration mechanism is to import config.py and yes it does have SECRET_KEY defined. (https://github.com/FreeTAKTeam/UI/blob/093fc8ca84ba4481f478ca4476454727e838a486/FreeTAKServer-UI/config.py#L14).
In FreeTAKServer it is configured by reading in a YAML file (/opt/FTSConfig.yaml) and there is no entry that appears to be equivalent to SECRET_KEY. So yes, this still seems to be a problem with the current code bases. Which begs the question of how the software ever made it to the point of release without full integration testing which should have caught the problem of missing config values.
Now, I may be missing something. I have only been working trying to get working copies of the software for a couple of hours. Forgive me if I am missing something. Yet given what I have seen thus far and problems that should not have made it to a release and complexities of configuring the software, I am compelled to give up and just run the official TAK server.
I am just trying to give some honest feedback here and not denigrate the work done by the maintainers and contributors of both projects. I am hoping that the bigger issues will be recognized and start to be addressed.
@hickey all the points you make are certainly valid and constructive criticism is necessary for improvement, to make sure I understand the issue so that it can be escalated I'll to try summarize what I understand, please correct me if any of my interpretation is incorrect.
- We need improved/any CI
- We should either deprecate or fully support the YAML configuration format
- We should consolidate the user configuration experience for the server and the UI
- The dependency tree should be stabilized through version restriction (should be done in latest version)
Pretty much you are on target here. Since these items are not directly related to this issue, we should probably move the conversation over to another issue. I will go create that here in a minute and populate it with some of my comments above.
Back to the original issue, I was able to duplicate the original problem with the not having SecretKey defined in the default configuration. Now I do have to say that after digging through configuration documentation (by the way none of which is referenced by any of the Docker guides produced for FTS) there was a reference of executing a command to generate the configuration. I don't have the information in front of me now so I can not remember what command that was. I would assume that executing the configuration command would add SecretKey to the YAML file. It will take me a little bit of time to get the environment setup again to give this a try and confirm.
I suspect that the quick fix is to create an entry in the default YAML file for SecretKey so that an unconfigured server has enough information to become functional (albeit not optimized).
Just to clarify the SecretKey configuration variable does not have an equivalent parameter in FTS, it is used by Flask (the FTS-UI framework) to secure client-side login session tokens and thus should be generated and really should not be a configurable value. This in no way negates many of the points you brought up which should be and I hope will be, opened separately. This also illustrates an issue in the way we configure the secret key (as a configurable instead of a randomized variable) which I will be opening as a new issue promptly.
Agreed. Earlier this week I digging through the code and doing some research on SecretKey. I did find reference to it being used by the Flask framework (I have done almost no Flask work, so a lot of the particulars escape me).
What confuses me a bit is that it appears that SecretKey is being defined (
MainConfig class. Yet later on when the class is referenced, it does not seem to have the SecretKey attribute defined.
File "/usr/local/lib/python3.8/dist-packages/FreeTAKServer/controllers/services/DataPackageServer.py", line 45, in <module>
app.config["SECRET_KEY"] = MainConfig.SecretKey
AttributeError: type object 'MainConfig' has no attribute 'SecretKey'
Ah! OK, this now make sense to me.
The Docker container is being built with an old copy of FTSConfig.yaml. That file does not have a System: section so
does not ever get executed. Hence
SecretKey does not get defined along with several other variables.
I think I need to go create another PR against FreeTAKServer-Docker to get the file updated.
It would also be useful if the FreeTAKServer Python package included a copy of the file with sane defaults. That way when new sections or variables are added to the config file the build of the Docker container can copy the file to /opt and make any modifications necessary for the Docker environment. This way any builds of the Docker container would be guaranteed to have a config that is known to work for the installed version of FreeTAKServer.