Fwd: [Django] ERROR (EXTERNAL IP): Internal Server Error: /archives/search
Hello everyone!
below is a "permission denied" error I get when trying to perform a fulltext search.
-------- Weitergeleitete Nachricht -------- Betreff: [Django] ERROR (EXTERNAL IP): Internal Server Error: /archives/search Datum: Mon, 23 Jan 2023 10:30:14 -0000 Von: johannes@rohr.org An: johannes@rohr.org
Internal Server Error: /archives/search
PermissionError at /archives/search [Errno 13] Permission denied: 'fulltext_index'
Request Method: GET Request URL: http://lists.*****.org/archives/search?mlist=pinnwand%40lists.*****&q=meditation Django Version: 4.1.5 Python Executable: /opt/mailman/venv/bin/uwsgi Python Version: 3.10.6 Python Path: ['.', '', '/etc/mailman3', '/usr/lib/python310.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload', '/opt/mailman/venv/lib/python3.10/site-packages'] Server time: Mon, 23 Jan 2023 11:30:14 +0100 Installed Applications: ['hyperkitty', 'postorius', 'django_mailman3', 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_gravatar', 'compressor', 'haystack', 'django_extensions', 'django_q', 'allauth', 'allauth.account', 'allauth.socialaccount'] Installed Middleware: ('django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.middleware.locale.LocaleMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'django.middleware.security.SecurityMiddleware', 'django_mailman3.middleware.TimezoneMiddleware', 'postorius.middleware.PostoriusMiddleware')
Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/base.py", line 197, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/views/search.py", line 88, in search emails = paginate( File "/opt/mailman/venv/lib/python3.10/site-packages/django_mailman3/lib/paginator.py", line 71, in paginate objects = paginator.page(page_num) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 75, in page number = self.validate_number(number) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 53, in validate_number if number > self.num_pages: File "/opt/mailman/venv/lib/python3.10/site-packages/django/utils/functional.py", line 57, in __get__ res = instance.__dict__[self.name] = self.func(instance) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 102, in num_pages if self.count == 0 and not self.allow_empty_first_page: File "/opt/mailman/venv/lib/python3.10/site-packages/django/utils/functional.py", line 57, in __get__ res = instance.__dict__[self.name] = self.func(instance) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 96, in count return c() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/query.py", line 527, in count return len(self) File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/query.py", line 82, in __len__ self._result_count = self.query.get_count() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/__init__.py", line 658, in get_count self.run() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/__init__.py", line 593, in run results = self.backend.search(final_query, **search_kwargs) File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/__init__.py", line 32, in wrapper return func(obj, query_string, *args, **kwargs) File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/whoosh_backend.py", line 412, in search self.setup() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/whoosh_backend.py", line 133, in setup os.makedirs(self.path) File "/usr/lib/python3.10/os.py", line 225, in makedirs mkdir(name, mode)
Exception Type: PermissionError at /archives/search Exception Value: [Errno 13] Permission denied: 'fulltext_index' Raised during: hyperkitty.views.search.search
I don't understand what the cause for the "permission denied" could be. The directory "fulltext_index" is owned by mailman:mailman
Does anyone have a hint? I did some googling for the error, but to no avail, unfortunately.
Thanks!
Johannes
On 1/23/23 02:41, Johannes Rohr wrote:
I don't understand what the cause for the "permission denied" could be. The directory "fulltext_index" is owned by mailman:mailman
Does anyone have a hint? I did some googling for the error, but to no avail, unfortunately.
It's actually trying to create fulltext_index, so clearly it's not looking at the fulltext_index that you are. If you are following https://docs.mailman3.org/en/latest/install/virtualenv.html you probably need to specify the path in /etc/mailman3/settings.py as in, e.g.
HAYSTACK_CONNECTIONS['default']['PATH'] =
'/opt/mailman/mm/var/fulltext_index'
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Mon, Jan 23, 2023, 23:09 Mark Sapiro <mark@msapiro.net> wrote:
On 1/23/23 02:41, Johannes Rohr wrote:
I don't understand what the cause for the "permission denied" could be. The directory "fulltext_index" is owned by mailman:mailman
Does anyone have a hint? I did some googling for the error, but to no avail, unfortunately.
It's actually trying to create fulltext_index, so clearly it's not looking at the fulltext_index that you are. If you are following https://docs.mailman3.org/en/latest/install/virtualenv.html you probably need to specify the path in /etc/mailman3/settings.py as in, e.g.
HAYSTACK_CONNECTIONS['default']['PATH'] = '/opt/mailman/mm/var/fulltext_index'
Doesn't this follow the same rules of getting the settings.py from gitlab?
On 1/23/23 12:17, Odhiambo Washington wrote:
On Mon, Jan 23, 2023, 23:09 Mark Sapiro <mark@msapiro.net> wrote:
It's actually trying to create fulltext_index, so clearly it's not looking at the fulltext_index that you are. If you are following https://docs.mailman3.org/en/latest/install/virtualenv.html you probably need to specify the path in /etc/mailman3/settings.py as in, e.g.
HAYSTACK_CONNECTIONS['default']['PATH'] = '/opt/mailman/mm/var/fulltext_index'Doesn't this follow the same rules of getting the settings.py from gitlab?
I don't understand. Can you be more specific?
Note that when following https://docs.mailman3.org/en/latest/install/virtualenv.html you create /etc/mailman3/settings.py and it contains
from mailman_web.settings.base import *
from mailman_web.settings.mailman import *
to establish a base set of settings that can be augmented or overridden in /etc/mailman3/settings.py. mailman_web.settings.mailman in turn contains
HAYSTACK_CONNECTIONS = {
'default': {
'ENGINE': 'haystack.backends.whoosh_backend.WhooshEngine',
'PATH': "fulltext_index",
which is a relative path for fulltext_index and may need to be set to an absolute path.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Mon, Jan 23, 2023 at 11:48 PM Mark Sapiro <mark@msapiro.net> wrote:
On Mon, Jan 23, 2023, 23:09 Mark Sapiro <mark@msapiro.net> wrote:
It's actually trying to create fulltext_index, so clearly it's not looking at the fulltext_index that you are. If you are following https://docs.mailman3.org/en/latest/install/virtualenv.html you
On 1/23/23 12:17, Odhiambo Washington wrote: probably
need to specify the path in /etc/mailman3/settings.py as in, e.g.
HAYSTACK_CONNECTIONS['default']['PATH'] = '/opt/mailman/mm/var/fulltext_index'Doesn't this follow the same rules of getting the settings.py from gitlab?
I don't understand. Can you be more specific?
Note that when following https://docs.mailman3.org/en/latest/install/virtualenv.html you create /etc/mailman3/settings.py and it contains
from mailman_web.settings.base import * from mailman_web.settings.mailman import *to establish a base set of settings that can be augmented or overridden in /etc/mailman3/settings.py. mailman_web.settings.mailman in turn contains
HAYSTACK_CONNECTIONS = { 'default': { 'ENGINE': 'haystack.backends.whoosh_backend.WhooshEngine', 'PATH': "fulltext_index",which is a relative path for fulltext_index and may need to be set to an absolute path.
Mi Mark,
I have read this page - https://docs.mailman3.org/en/latest/install/virtualenv.html and further - https://docs.mailman3.org/en/latest/install/virtualenv.html#initial-config that page.
- without clicking any external links. I still don't see the HAYSTACK_CONNECTIONS in the settings.py included on
I am missing something obvious, no?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
On 1/27/23 05:53, Odhiambo Washington wrote:
On Mon, Jan 23, 2023 at 11:48 PM Mark Sapiro <mark@msapiro.net> wrote:
Note that when following https://docs.mailman3.org/en/latest/install/virtualenv.html you create /etc/mailman3/settings.py and it contains
from mailman_web.settings.base import * from mailman_web.settings.mailman import *to establish a base set of settings that can be augmented or overridden in /etc/mailman3/settings.py. mailman_web.settings.mailman in turn contains
HAYSTACK_CONNECTIONS = { 'default': { 'ENGINE': 'haystack.backends.whoosh_backend.WhooshEngine', 'PATH': "fulltext_index",which is a relative path for fulltext_index and may need to be set to an absolute path.
Mi Mark,
I have read this page - https://docs.mailman3.org/en/latest/install/virtualenv.html and further - https://docs.mailman3.org/en/latest/install/virtualenv.html#initial-config that page.
- without clicking any external links. I still don't see the HAYSTACK_CONNECTIONS in the settings.py included on
I am missing something obvious, no?
Please reread what I wrote above. HAYSTACK_CONNECTIONS is not in the suggested settings.py but it is in mailman_web.settings.mailman and is imported by the suggested settings.py.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Fri, Jan 27, 2023 at 9:34 PM Mark Sapiro <mark@msapiro.net> wrote:
On Mon, Jan 23, 2023 at 11:48 PM Mark Sapiro <mark@msapiro.net> wrote:
Note that when following https://docs.mailman3.org/en/latest/install/virtualenv.html you create /etc/mailman3/settings.py and it contains
from mailman_web.settings.base import * from mailman_web.settings.mailman import *to establish a base set of settings that can be augmented or overridden in /etc/mailman3/settings.py. mailman_web.settings.mailman in turn
contains
HAYSTACK_CONNECTIONS = { 'default': { 'ENGINE': 'haystack.backends.whoosh_backend.WhooshEngine', 'PATH': "fulltext_index",which is a relative path for fulltext_index and may need to be set to an absolute path.
Mi Mark,
I have read this page - https://docs.mailman3.org/en/latest/install/virtualenv.html and further
On 1/27/23 05:53, Odhiambo Washington wrote: -
https://docs.mailman3.org/en/latest/install/virtualenv.html#initial-config
- without clicking any external links. I still don't see the HAYSTACK_CONNECTIONS in the settings.py included on that page. I am missing something obvious, no?
Please reread what I wrote above. HAYSTACK_CONNECTIONS is not in the suggested settings.py but it is in mailman_web.settings.mailman and is imported by the suggested settings.py.
I have reread what you wrote now and I'm beginning to get the hang of this method. My observation is that it can only be _obvious_ to someone very familiar with Python config to decipher that *additional* settings *that can be augmented or overridden in /etc/mailman3/settings.py* can be obtained from: /PATH-TO/mailman_web/settings/{base|mailman}.py after they have noticed these two lines in the sample settings given in /etc/mailman3/settings.py:
from mailman_web.settings.base import *from mailman_web.settings.mailman import *
[At first instance, it is not obvious that mailman_web.settings.base and mailman_web.settings.mailman are actually paths in Python - which magically translates to mailman_web/settings/base.py and mailman_web/settings/mailman.py] Granted, I am a slow learner, and perhaps already so mixed up after reading the myriad HOWTOs for installing MM3 that are available online. I am tempted to say there are many like me who are likely to miss "where to obtain" other settings from.
For example, my mind all along has been tuned to having a settings_local.py for overriding the settings.py. However, with this particular documentation, it would appear that everything is intended to just go into /etc/mailman3/settings.py.
Is it possible to modify the documentation to somehow make it obvious (in a language that a layman can easily understand, that those two "import *" _DO establish a base set of settings that can be augmented or overridden in /etc/mailman3/settings.py_ and that those settings are in what file(s) ?
I am not saying @Johannes Rohr <johannes@rohr.org> is a layman like me, but I think that is what hit him.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
On 1/27/23 23:53, Odhiambo Washington wrote:
I have reread what you wrote now and I'm beginning to get the hang of this method. My observation is that it can only be _obvious_ to someone very familiar with Python config to decipher that *additional* settings *that can be augmented or overridden in /etc/mailman3/settings.py* can be obtained from: /PATH-TO/mailman_web/settings/{base|mailman}.py after they have noticed these two lines in the sample settings given in /etc/mailman3/settings.py:
from mailman_web.settings.base import *from mailman_web.settings.mailman import *
This is how it was always done in Mailman 2.1 and how it should have been done in Mailman 3's Django web UI from the start, but wasn't.
MM 2.1 had mm_cfg.py which had
from Defaults import *
##################################################
# Put YOUR site-specific settings below this line.
[At first instance, it is not obvious that mailman_web.settings.base and mailman_web.settings.mailman are actually paths in Python - which magically translates to mailman_web/settings/base.py and mailman_web/settings/mailman.py]
This is very basic Python.
Granted, I am a slow learner, and perhaps already so mixed up after reading the myriad HOWTOs for installing MM3 that are available online. I am tempted to say there are many like me who are likely to miss "where to obtain" other settings from.
For example, my mind all along has been tuned to having a settings_local.py for overriding the settings.py. However, with this particular documentation, it would appear that everything is intended to just go into /etc/mailman3/settings.py.
In that method you had the defaults in settings.py which at the end imported settings_local.py.
This method has defaults in /PATH-TO/mailman_web/settings/{base|mailman}.py and those are imported at the beginning of settings.py which then has overrides. This is preferable because it allows things in settings.py like
HAYSTACK_CONNECTIONS['default']['PATH'] = 'some path'
to just override that one thing rather than having to redefine all of HAYSTACK_CONNECTIONS or import it from settings in settings_local.py.
Is it possible to modify the documentation to somehow make it obvious (in a language that a layman can easily understand, that those two "import *" _DO establish a base set of settings that can be augmented or overridden in /etc/mailman3/settings.py_ and that those settings are in what file(s) ?
Again, this is very basic Python, but if you submit a merge request to update https://gitlab.com/mailman/mailman-suite-doc/-/blob/master/source/install/vi..., we'll certainly consider it.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sat, Jan 28, 2023 at 7:44 PM Mark Sapiro <mark@msapiro.net> wrote:
On 1/27/23 23:53, Odhiambo Washington wrote:
I have reread what you wrote now and I'm beginning to get the hang of
this
method. My observation is that it can only be _obvious_ to someone very familiar with Python config to decipher that *additional* settings *that can be augmented or overridden in /etc/mailman3/settings.py* can be obtained from: /PATH-TO/mailman_web/settings/{base|mailman}.py after they have noticed these two lines in the sample settings given in /etc/mailman3/settings.py:
from mailman_web.settings.base import *from mailman_web.settings.mailman import *
This is how it was always done in Mailman 2.1 and how it should have been done in Mailman 3's Django web UI from the start, but wasn't.
MM 2.1 had mm_cfg.py which had
from Defaults import * ################################################## # Put YOUR site-specific settings below this line.[At first instance, it is not obvious that mailman_web.settings.base and mailman_web.settings.mailman are actually paths in Python - which magically translates to mailman_web/settings/base.py and mailman_web/settings/mailman.py]
This is very basic Python.
Granted, I am a slow learner, and perhaps already so mixed up after reading the myriad HOWTOs for installing MM3 that are available online. I am tempted to say there are many like me who are likely to miss "where to obtain" other settings from.
For example, my mind all along has been tuned to having a settings_local.py for overriding the settings.py. However, with this particular documentation, it would appear that everything is intended to just go into /etc/mailman3/settings.py.
In that method you had the defaults in settings.py which at the end imported settings_local.py.
This method has defaults in /PATH-TO/mailman_web/settings/{base|mailman}.py and those are imported at the beginning of settings.py which then has overrides. This is preferable because it allows things in settings.py like
HAYSTACK_CONNECTIONS['default']['PATH'] = 'some path'to just override that one thing rather than having to redefine all of HAYSTACK_CONNECTIONS or import it from settings in settings_local.py.
Is it possible to modify the documentation to somehow make it obvious (in a language that a layman can easily understand, that those two "import *" _DO establish a base set of settings that can be augmented or overridden in /etc/mailman3/settings.py_ and that those settings are in what file(s) ?
Again, this is very basic Python, but if you submit a merge request to update
https://gitlab.com/mailman/mailman-suite-doc/-/blob/master/source/install/vi...,
we'll certainly consider it.
Hi Mark,
Before I wrote this email that you have responded to, I was in the process of writing another email to you offlist. I kept it in abbeyance. Now that you have mentioned https://gitlab.com/mailman/mailman-suite-doc/-/blob/master/source/install/vi...,, please show me how to import it, edit. Then I can submit a diff. Alternatively, I'd love to be given access to edit that document (and the edit can be reviewed before getting published) to make it easy to follow by someone with zero python background. I am willing to invest some time in improving it for laymen.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
On 1/28/23 09:39, Odhiambo Washington wrote:
Now that you have mentioned https://gitlab.com/mailman/mailman-suite-doc/-/blob/master/source/install/vi...,, please show me how to import it, edit. Then I can submit a diff. Alternatively, I'd love to be given access to edit that document (and the edit can be reviewed before getting published) to make it easy to follow by someone with zero python background. I am willing to invest some time in improving it for laymen.
There are multiple ways to proceed. The simplest is to just download https://gitlab.com/mailman/mailman-suite-doc/-/blob/master/source/install/vi... (there's a download button on that page), edit that and post the edited file somewhere where we can get it to look at.
The better way is more complex. That way is for you to create a personal project space at https://gitlab.com/users/sign_up and clone the mailman/mailman-suite-doc project into your personal space and edit it there and then create a merge request to merge your edits into the mailman/mailman-suite-doc project. GitLab documentation is at https://gitlab.com/help
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I'll create the merge request.
On Sat, Jan 28, 2023, 21:49 Mark Sapiro <mark@msapiro.net> wrote:
On 1/28/23 09:39, Odhiambo Washington wrote:
Now that you have mentioned
https://gitlab.com/mailman/mailman-suite-doc/-/blob/master/source/install/vi..., ,
please show me how to import it, edit. Then I can submit a diff. Alternatively, I'd love to be given access to edit that document (and the edit can be reviewed before getting published) to make it easy to follow by someone with zero python background. I am willing to invest some time in improving it for laymen.
There are multiple ways to proceed. The simplest is to just download
https://gitlab.com/mailman/mailman-suite-doc/-/blob/master/source/install/vi... (there's a download button on that page), edit that and post the edited file somewhere where we can get it to look at.
The better way is more complex. That way is for you to create a personal project space at https://gitlab.com/users/sign_up and clone the mailman/mailman-suite-doc project into your personal space and edit it there and then create a merge request to merge your edits into the mailman/mailman-suite-doc project. GitLab documentation is at https://gitlab.com/help
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to odhiambo@gmail.com
Odhiambo Washington writes:
from mailman_web.settings.base import * from mailman_web.settings.mailman import *
I think just putting these as close to the top as possible, and including a comment (or two) saying that this is importing defaults that can be overridden by any assignment made later in the file is about as far as we can go for explaining. If you don't know how Python imports work, just ask about the specific case. There's quite a bit of potential complexity hiding in those '.'s; much more complicated than the '/'s in a file system path. Trying to explain the ins and outs of the Python import system is way beyond the scope of Mailman docs.
[At first instance, it is not obvious that mailman_web.settings.base and mailman_web.settings.mailman are actually paths in Python - which magically translates to mailman_web/settings/base.py and mailman_web/settings/mailman.py]
You shouldn't have to know that, it doesn't help with the bigger problem of finding mailman_web, and any simple explanation might turn out not to be true in your installation. This is why I prefer flat files for end-user configuration, even if they get pretty big. I understand why developers do stuff like this, but it's not "naive user"-friendly.
For example, my mind all along has been tuned to having a settings_local.py for overriding the settings.py.
Yes, and that is a better system unless our intent is to *hide* settings from the user, in my opinion. I don't see why you chose to deviate from it. Either way you have to integrate settings you have changed with settings the developers have changed. It's easier if you stick with the system you're most familiar with.
However, with this particular documentation, it would appear that everything is intended to just go into /etc/mailman3/settings.py.
Is it possible to modify the documentation
Which documentation? We can modify our own, but that's a pretty big task because we have several different systems for managing config files over the last five or ten years. We shouldn't mandate any particular organization because they all still work, and people who use older setups shouldn't have to do without our docs. And we can't do anything about out-of-date mirrors or HOWTOs by random admins on the web.
and that those settings are in what file(s) ?
But we don't know where those files are. If you use a venv install, they're almost certainly in $MAILMAN_HOME/venv/lib/python3.N/site-packages/mailman_web/settings/, but otherwise the mailman_web/settings part could be anywhere on Python's search path. And on modern systems unless you have a dedicated host with everything installed at once, you're likely to have 3 or more Pythons installed (Python 2.7, and two or more Python 3s). So tools like find and grep -l are often more confusing than enlightening.
I think if you get confused, the most efficient solution is to just ask. If Mark or I or whoever directs you to check out the defaults, and you can't find them, ask again.
Steve
On 1/28/23 11:48, Stephen J. Turnbull wrote:
Odhiambo Washington writes:
from mailman_web.settings.base import * from mailman_web.settings.mailman import *
I think just putting these as close to the top as possible, and including a comment (or two) saying that this is importing defaults that can be overridden by any assignment made later in the file is about as far as we can go for explaining.
I've Just updated this. It now says:
# Get the default settings.
from mailman_web.settings.base import *
from mailman_web.settings.mailman import *
# Settings below supplement or override the defaults.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sat, Jan 28, 2023 at 11:25 PM Mark Sapiro <mark@msapiro.net> wrote:
On 1/28/23 11:48, Stephen J. Turnbull wrote:
Odhiambo Washington writes:
from mailman_web.settings.base import * from mailman_web.settings.mailman import *
I think just putting these as close to the top as possible, and including a comment (or two) saying that this is importing defaults that can be overridden by any assignment made later in the file is about as far as we can go for explaining.
I've Just updated this. It now says:
# Get the default settings. from mailman_web.settings.base import * from mailman_web.settings.mailman import * # Settings below supplement or override the defaults.
>
Yes, this now is awesome - for reading between the lines :)
Thank you.
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
On Sat, Jan 28, 2023 at 10:48 PM Stephen J. Turnbull < stephenjturnbull@gmail.com> wrote:
Odhiambo Washington writes:
from mailman_web.settings.base import * from mailman_web.settings.mailman import *
I think just putting these as close to the top as possible, and including a comment (or two) saying that this is importing defaults that can be overridden by any assignment made later in the file is about as far as we can go for explaining. If you don't know how Python imports work, just ask about the specific case. There's quite a bit of potential complexity hiding in those '.'s; much more complicated than the '/'s in a file system path. Trying to explain the ins and outs of the Python import system is way beyond the scope of Mailman docs.
[At first instance, it is not obvious that mailman_web.settings.base and mailman_web.settings.mailman are actually paths in Python - which magically translates to mailman_web/settings/base.py and mailman_web/settings/mailman.py]
You shouldn't have to know that, it doesn't help with the bigger problem of finding mailman_web, and any simple explanation might turn out not to be true in your installation. This is why I prefer flat files for end-user configuration, even if they get pretty big. I understand why developers do stuff like this, but it's not "naive user"-friendly.
For example, my mind all along has been tuned to having a settings_local.py for overriding the settings.py.
Yes, and that is a better system unless our intent is to *hide* settings from the user, in my opinion. I don't see why you chose to deviate from it. Either way you have to integrate settings you have changed with settings the developers have changed. It's easier if you stick with the system you're most familiar with.
However, with this particular documentation, it would appear that everything is intended to just go into /etc/mailman3/settings.py.
Is it possible to modify the documentation
Which documentation? We can modify our own, but that's a pretty big task because we have several different systems for managing config files over the last five or ten years. We shouldn't mandate any particular organization because they all still work, and people who use older setups shouldn't have to do without our docs. And we can't do anything about out-of-date mirrors or HOWTOs by random admins on the web.
and that those settings are in what file(s) ?
But we don't know where those files are. If you use a venv install, they're almost certainly in $MAILMAN_HOME/venv/lib/python3.N/site-packages/mailman_web/settings/, but otherwise the mailman_web/settings part could be anywhere on Python's search path. And on modern systems unless you have a dedicated host with everything installed at once, you're likely to have 3 or more Pythons installed (Python 2.7, and two or more Python 3s). So tools like find and grep -l are often more confusing than enlightening.
I think if you get confused, the most efficient solution is to just ask. If Mark or I or whoever directs you to check out the defaults, and you can't find them, ask again.
Steve
All the above noted, and well-received. I only decided to experiment with this particular documentation because it is the *OFFICIAL* one. And to be honest, I am yet to wrap my head around everything, so I still have a lot of questions in my head. Will be seeing you often :)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
Odhiambo Washington writes:
All the above noted, and well-received. I only decided to experiment with this particular documentation because it is the *OFFICIAL* one.
Yup, and thank you for that!
But not everyone has the time or the skills for it, so I wanted to say in a public place that questions really are welcome (and please don't be deterred if occasionally we seem exasperated by somebody's questions, that happens but we get over it, it's not your fault :-).
Steve
On Wed, Feb 1, 2023 at 2:03 PM Stephen J. Turnbull < stephenjturnbull@gmail.com> wrote:
Odhiambo Washington writes:
All the above noted, and well-received. I only decided to experiment with this particular documentation because it is the *OFFICIAL* one.
Yup, and thank you for that!
But not everyone has the time or the skills for it, so I wanted to say in a public place that questions really are welcome (and please don't be deterred if occasionally we seem exasperated by somebody's questions, that happens but we get over it, it's not your fault :-).
Steve
Hello Steve,
That is quite well understood. I am all too happy to be asking questions and yes, I know you and Mark do give us a lot of your time and we are grateful.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
Am 23.01.23 um 21:08 schrieb Mark Sapiro:
On 1/23/23 02:41, Johannes Rohr wrote:
I don't understand what the cause for the "permission denied" could be. The directory "fulltext_index" is owned by mailman:mailman
Does anyone have a hint? I did some googling for the error, but to no avail, unfortunately.
It's actually trying to create fulltext_index, so clearly it's not looking at the fulltext_index that you are. If you are following https://docs.mailman3.org/en/latest/install/virtualenv.html you probably need to specify the path in /etc/mailman3/settings.py as in, e.g.
HAYSTACK_CONNECTIONS['default']['PATH'] = '/opt/mailman/mm/var/fulltext_index'
Thanks! Indeed. Including this line helps. It makes the error go away. So I guess the instructions should be amended.
After that, for some reason, I have to re-index all lists, because initially, empty results were returned for any query, only after re-indexing to I get results.
Again, thanks so much for your support!
Johannes
On 1/23/23 14:00, Johannes Rohr wrote:
Am 23.01.23 um 21:08 schrieb Mark Sapiro:
e.g.
HAYSTACK_CONNECTIONS['default']['PATH'] = '/opt/mailman/mm/var/fulltext_index'Thanks! Indeed. Including this line helps. It makes the error go away. So I guess the instructions should be amended.
After that, for some reason, I have to re-index all lists, because initially, empty results were returned for any query, only after re-indexing to I get results.
Did you adjust the path to point to your existing fulltext_index? If not and if you had, I don't thing you would have needed to reindex.
The question is what changed so that the relative "fulltext_index" no longer pointed to where the actual directory was.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Am 24.01.2023 um 01:26 schrieb Mark Sapiro:
On 1/23/23 14:00, Johannes Rohr wrote:
Am 23.01.23 um 21:08 schrieb Mark Sapiro:
e.g.
HAYSTACK_CONNECTIONS['default']['PATH'] = '/opt/mailman/mm/var/fulltext_index'Thanks! Indeed. Including this line helps. It makes the error go away. So I guess the instructions should be amended.
After that, for some reason, I have to re-index all lists, because initially, empty results were returned for any query, only after re-indexing to I get results.
Did you adjust the path to point to your existing fulltext_index?
yes, I did.
If not and if you had, I don't thing you would have needed to reindex. That's precisely, why I was surprised.
The question is what changed so that the relative "fulltext_index" no longer pointed to where the actual directory was.
I don't think that anything had changed, I just don't think I never checked whether the fulltext search actually works and so I spotted this error rather late in the game.
Thanks,
Johannes
participants (4)
-
Johannes Rohr -
Mark Sapiro -
Odhiambo Washington -
Stephen J. Turnbull