Hey, just some feedback we received after enabling email notifications - we got a bunch of complaints from people asking how to turn it off. Makes me think that maybe it should be an opt-in feature, i.e. disabled by default; or maybe give the user some way to disable all notifications on their account, instead of on a per-device basis. Just a thought
Hi @nickberry17, that's true, I also got the same type of feedback.
For the moment the only option is to disable them.
You can run this from the shell:
NotificationSettings.objects.update(email=False)
Hey, just some feedback we received after enabling email notifications - we got a bunch of complaints from people asking how to turn it off. Makes me think that maybe it should be an opt-in feature, i.e. disabled by default; or maybe give the user some way to disable all notifications on their account, instead of on a per-device basis. Just a thought
Hi @nickberry17, that's true, I also got the same type of feedback.
For the moment the only option is to disable them.You can run this from the shell:
NotificationSettings.objects.update(email=False)
What are these settings in the admin interface for then?
If you use the latest
devbranch of ansible-openwisp2, you should not see the error even after enabling the radius module now.I will also try this again later on.
@pandafy:matrix.org Told you I would test this. Finally went back and ran it. Right now it is not working. Here is the error on Migrate:
fatal: [owtest.trip-g.com]: FAILED! => {
"changed": false,
"cmd": [
"./manage.py",
"migrate",
"--noinput"
],
"invocation": {
"module_args": {
"app_path": "/opt/openwisp2",
"apps": null,
"cache_table": null,
"clear": false,
"command": "migrate",
"database": null,
"failfast": false,
"fixtures": null,
"link": null,
"merge": null,
"project_path": "/opt/openwisp2",
"pythonpath": null,
"settings": null,
"skip": null,
"testrunner": null,
"virtualenv": "/opt/openwisp2/env"
}
},
"msg": "\n:stderr: Traceback (most recent call last):\n File \"./manage.py\", line 10, in <module>\n execute_from_command_line(sys.argv)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/core/management/init.py\", line 401, in execute_from_command_line\n utility.execute()\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/core/management/init.py\", line 395, in execute\n self.fetch_command(subcommand).run_from_argv(self.argv)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/core/management/base.py\", line 330, in run_from_argv\n self.execute(args, **cmd_options)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/core/management/base.py\", line 371, in execute\n output = self.handle(args, options)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/core/management/base.py\", line 85, in wrapped\n res = handle_func(*args, kwargs)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/core/management/commands/migrate.py\", line 92, in handle\n executor = MigrationExecutor(connection, self.migration_progress_callback)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/db/migrations/executor.py\", line 18, in init\n self.loader = MigrationLoader(self.connection)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/db/migrations/loader.py\", line 53, in init\n self.build_graph()\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/db/migrations/loader.py\", line 210, in build_graph\n self.load_disk()\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/db/migrations/loader.py\", line 112, in load_disk\n migration_module = import_module(migration_path)\n File \"/opt/openwisp2/env/lib/python3.7/importlib/init.py\", line 127, in import_module\n return _bootstrap._gcd_import(name[level:], package, level)\n File \"<frozen importlib._bootstrap>\", line 1006, in _gcd_import\n File \"<frozen importlib._bootstrap>\", line 983, in _find_and_load\n File \"<frozen importlib._bootstrap>\", line 967, in _find_and_load_unlocked\n File \"<frozen importlib._bootstrap>\", line 677, in _load_unlocked\n File \"<frozen importlib._bootstrap_external>\", line 728, in exec_module\n File \"<frozen importlib._bootstrap>\", line 219, in _call_with_frames_removed\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/openwisp_network_topology/migrations/0001_initial.py\", line 20, in <module>\n class Migration(migrations.Migration):\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/openwisp_network_topology/migrations/0001_initial.py\", line 25, in Migration\n dependency(*split(settings.AUTH_USER_MODEL), version='0004_default_groups'),\nTypeError: dependency() got an unexpected keyword argument 'version'\n",
"path": "/opt/openwisp2/env/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"syspath": [
"/tmp/ansible_django_manage_payload_w9ty7mt2/ansible_django_manage_payload.zip",
"/u
Hi @nemesisdesign thank you. I want to note I am not actually trying to use this. Was just testing to see if it was working. But .... following your guidance yields an apparent conflict in swapper versioning between a couple packages?
openwisp-ipam 0.2 requires swapper~=1.1.0, but you'll have swapper 1.3.0 which is incompatible.
openwisp-controller 0.9a0 requires swapper~=1.1.0, but you'll have swapper 1.3.0 which is incompatible.
django-x509 0.9.4 requires openwisp-utils~=0.7.2, but you'll have openwisp-utils 0.8a0 which is incompatible.
django-x509 0.9.4 requires swapper~=1.1.0, but you'll have swapper 1.3.0 which is incompatible.
Successfully installed swapper-1.3.0
(env) root@owtest:~# pip install -U swapper==1.1.0
/usr/lib/python3/dist-packages/secretstorage/dhcrypto.py:15: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead
from cryptography.utils import int_from_bytes
/usr/lib/python3/dist-packages/secretstorage/util.py:19: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead
from cryptography.utils import int_from_bytes
Collecting swapper==1.1.0
Downloading swapper-1.1.0.tar.gz (8.0 kB)
Building wheels for collected packages: swapper
Building wheel for swapper (setup.py) ... done
Created wheel for swapper: filename=swapper-1.1.0-py3-none-any.whl size=2480 sha256=d6114cf262864079a9c8f712b9807e5f515abcc689ea694228ed3fb3800aae3a
Stored in directory: /root/.cache/pip/wheels/03/52/0d/4b56cd24c06804248d8562abe36e7b390eb31c6a21fe9bd72d
Successfully built swapper
Installing collected packages: swapper
Attempting uninstall: swapper
Found existing installation: swapper 1.3.0
Uninstalling swapper-1.3.0:
Successfully uninstalled swapper-1.3.0
ERROR: After October 2020 you may experience errors when installing or updating packages. This is because pip will change the way that it resolves dependency conflicts.
We recommend you use --use-feature=2020-resolver to test your packages with the new resolver before it becomes the default.
openwisp-utils 0.8a0 requires swapper~=1.3.0, but you'll have swapper 1.1.0 which is incompatible.
django-x509 0.9.4 requires openwisp-utils~=0.7.2, but you'll have openwisp-utils 0.8a0 which is incompatible.
Successfully installed swapper-1.1.0
WARNING: You are using pip version 20.2.4; however, version 21.3.1 is available.
You should consider upgrading via the '/opt/openwisp2/env/bin/python3 -m pip install --upgrade pip' command.
(env) root@owtest:~#
swapper==1.3.0
dev branch of ansible-openwisp2: https://github.com/openwisp/ansible-openwisp2/blob/dev/defaults/main.yml#L29
I add this package on the
devbranch of ansible-openwisp2: https://github.com/openwisp/ansible-openwisp2/blob/dev/defaults/main.yml#L29
Ok - I'll wipe everything and try it again with a fresh pull from ansible-openwisp2 dev branch.
Anytime. But it blew up again. So I forced galaxy to reload my dev version of ansibleopenwisp 2. Verified that the main.yml file had your changes and ran my playbook. Blew up again.
fatal: [owtest.trip-g.com]: FAILED! => {
"changed": false,
"cmd": [
"./manage.py",
"migrate",
"--noinput"
],
"invocation": {
"module_args": {
"app_path": "/opt/openwisp2",
"apps": null,
"cache_table": null,
"clear": false,
"command": "migrate",
"database": null,
"failfast": false,
"fixtures": null,
"link": null,
"merge": null,
"project_path": "/opt/openwisp2",
"pythonpath": null,
"settings": null,
"skip": null,
"testrunner": null,
"virtualenv": "/opt/openwisp2/env"
}
},
"msg": "\n:stderr: Traceback (most recent call last):\n File \"./manage.py\", line 10, in <module>\n execute_from_command_line(sys.argv)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/core/management/init.py\", line 401, in execute_from_command_line\n utility.execute()\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/core/management/init.py\", line 395, in execute\n self.fetch_command(subcommand).run_from_argv(self.argv)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/core/management/base.py\", line 330, in run_from_argv\n self.execute(args, **cmd_options)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/core/management/base.py\", line 371, in execute\n output = self.handle(args, options)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/core/management/base.py\", line 85, in wrapped\n res = handle_func(*args, kwargs)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/core/management/commands/migrate.py\", line 92, in handle\n executor = MigrationExecutor(connection, self.migration_progress_callback)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/db/migrations/executor.py\", line 18, in init\n self.loader = MigrationLoader(self.connection)\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/db/migrations/loader.py\", line 53, in init\n self.build_graph()\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/db/migrations/loader.py\", line 210, in build_graph\n self.load_disk()\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/django/db/migrations/loader.py\", line 112, in load_disk\n migration_module = import_module(migration_path)\n File \"/opt/openwisp2/env/lib/python3.7/importlib/init.py\", line 127, in import_module\n return _bootstrap._gcd_import(name[level:], package, level)\n File \"<frozen importlib._bootstrap>\", line 1006, in _gcd_import\n File \"<frozen importlib._bootstrap>\", line 983, in _find_and_load\n File \"<frozen importlib._bootstrap>\", line 967, in _find_and_load_unlocked\n File \"<frozen importlib._bootstrap>\", line 677, in _load_unlocked\n File \"<frozen importlib._bootstrap_external>\", line 728, in exec_module\n File \"<frozen importlib._bootstrap>\", line 219, in _call_with_frames_removed\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/openwisp_network_topology/migrations/0001_initial.py\", line 20, in <module>\n class Migration(migrations.Migration):\n File \"/opt/openwisp2/env/lib/python3.7/site-packages/openwisp_network_topology/migrations/0001_initial.py\", line 25, in Migration\n dependency(*split(settings.AUTH_USER_MODEL), version='0004_default_groups'),\nTypeError: dependency() got an unexpected keyword argument 'version'\n",
"path": "/opt/openwisp2/env/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"syspath": [
"/tmp/ansible_django_manage_payload_7k61220c/ansible_django_manage_payload.zip",
"/usr/lib/python37.zip",
"/usr/lib/python3.7",
"/usr/lib/python3.7/lib-dynload",
"/usr/local/lib/python3.7/dist-
if the
reload_configscript of OpenWrt doesn't figure out it should reload the network, there's not much we can do unfortunately, the max you could do is to execute the network restart in the post reload config hook of openwisp-config.I suggest checking whether
ubus call network reloadfixes it, it should be faster than restarting the whole network stack.using openwisp-config with the sledge hammer (/etc/init.d/network restart) works. I will continue to look for a scalpel for this but so far it is all I can find that works.
FYI for anyone else who may attempt something similar - /sbin/ifdown "interface" and /sbin/ifup "interface" in the reload hook is enough to update the routing table with changed information. It is less time consuming than the sledge hammer.
if the
reload_configscript of OpenWrt doesn't figure out it should reload the network, there's not much we can do unfortunately, the max you could do is to execute the network restart in the post reload config hook of openwisp-config.I suggest checking whether
ubus call network reloadfixes it, it should be faster than restarting the whole network stack.using openwisp-config with the sledge hammer (/etc/init.d/network restart) works. I will continue to look for a scalpel for this but so far it is all I can find that works.
FYI for anyone else who may attempt something similar - /sbin/ifdown "interface" and /sbin/ifup "interface" in the reload hook is enough to update the routing table with changed information. It is less time consuming than the sledge hammer.
Wow this is great, we should write it down!
Another fun question ... Things have been building up swimmingly since our last set of threads. I was testing with one device and now with that one happy I plugged in my next device type. This device is newer and so I am running a snapshot version of wrt on it.
I can only get daemon.crit openwisp: Could not apply configuration, openwisp-update-config exit code was 1 when pulling a configuration. This is even with option test_config 0 in the configuration file on the device.
Not sure where to go from here. Any guidance?
what should be reason
Another fun question ... Things have been building up swimmingly since our last set of threads. I was testing with one device and now with that one happy I plugged in my next device type. This device is newer and so I am running a snapshot version of wrt on it.
I can only get daemon.crit openwisp: Could not apply configuration, openwisp-update-config exit code was 1 when pulling a configuration. This is even with option test_config 0 in the configuration file on the device.
Not sure where to go from here. Any guidance?
Figured it out - this was an issue with a missing lib file for uci on the snapshot build. Which begs the question. Is there any interest to improve the logging in the openwisp-config? The uci threw a good error to help solve the problem but it didn't get bubbled up.
if the
reload_configscript of OpenWrt doesn't figure out it should reload the network, there's not much we can do unfortunately, the max you could do is to execute the network restart in the post reload config hook of openwisp-config.I suggest checking whether
ubus call network reloadfixes it, it should be faster than restarting the whole network stack.using openwisp-config with the sledge hammer (/etc/init.d/network restart) works. I will continue to look for a scalpel for this but so far it is all I can find that works.
FYI for anyone else who may attempt something similar - /sbin/ifdown "interface" and /sbin/ifup "interface" in the reload hook is enough to update the routing table with changed information. It is less time consuming than the sledge hammer.
Wow this is great, we should write it down!
It gets better than this. You only need the /sbin/ifup - it does enough to update the interface routes.
we are getting the following error 2021/12/05 11:04:27 [error] 594740#594740: *324 connect() failed (111: Connection refused) while connecting to upstream, client: 152.57.193.51, server: 103.159.85.85, request: "GET /ws/notification/ HTTP/1.1", upstream: "http://0.0.0.0:8001/ws/notification/", host: "103.159.85.85"
what should be reason
check daphne logs at /opt/openwisp2/logs/daphne.log
Hi @nemesisdesign - so I am using the DEV version of openwisp2 and I have a question. Is there are way to change the requirements in the object properties? For instance I am using a newer device with WiFi 6 and the fields required don't align. Advanced mode won't let me change to what I want because of the "required" checks.
I think that this struggle exists for me because of this:
New network configuration syntax and board.json change
There have been several changes to the network configuration syntax in /etc/config/network:
in config interface, option ifname has been renamed to device (since it refers to a device section)
in config device of type bridge, ifname has been renamed to ports
for new installs, the generated configuration now creates separate sections for layer 2 (config device) and layer 3 (config interface) configuration
I am wondering if the netjson validator isn't able to adapt to these changes?