Add domain to Mailman, can't create list with that new domain
I'm testing locally to try and support additional domains.
I can add new mailing lists with a domain: announce-123@mydomain.com I can't add a new mailing list with an alternate domain: announce-123@testing.com
Following the documentation for domains I'm able to successfully add the new domain (locally) with the following steps: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/model/docs/...
- Shell into the mailman server
- Shell into the mailman Python environment: mailman shell
- Add a new mailing list. from mailman.interfaces.domain import IDomainManager from zope.component import getUtility manager = getUtility(IDomainManager) manager.add('testing.com') show_domains() # with method from the above documentation URL <Domain testing.com> <Domain mydomain.com>
But then when I run a cURL command (from the mailman server) to add a list with that new domain I get an error: $ curl -k -u restadmin:restpass -X POST -H "Content-Type: application/json" --data '{"fqdn_listname": "new-list@testing.com"}' https://0.0.0.0:8001/3.1/lists {"title": "400 Bad Request", "description": "Domain does not exist: testing.com"}
Am I doing something wrong, or missing a step? If not, how do I add support for additional domains such that I can provide mailing list support for that domain?
One thing that might help me understand this is knowing how Mailman sets the "primary" domain, in our case it's mydomain.com. I've searched through our codebases and the only places I find references to our domain are
- hostname and site_owner in a file called mailman3.cfg
- A few assorted "domain" settings in our kuberbetes values.yaml file.
I'm tempted to think it might be those domain settings, because Mailman has to be getting it's "primary" domain from somewhere, but I suspect those might be unrelated.
On Thu, Oct 17, 2024 at 5:32 PM Andy Matthews <andy.matthews@zaxiom.com> wrote:
I'm testing locally to try and support additional domains.
I can add new mailing lists with a domain: announce-123@mydomain.com I can't add a new mailing list with an alternate domain: announce-123@testing.com
Following the documentation for domains I'm able to successfully add the new domain (locally) with the following steps:
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/model/docs/...
- Shell into the mailman server
- Shell into the mailman Python environment: mailman shell
- Add a new mailing list. from mailman.interfaces.domain import IDomainManager from zope.component import getUtility manager = getUtility(IDomainManager) manager.add('testing.com') show_domains() # with method from the above documentation URL <Domain testing.com> <Domain mydomain.com>
But then when I run a cURL command (from the mailman server) to add a list with that new domain I get an error: $ curl -k -u restadmin:restpass -X POST -H "Content-Type: application/json" --data '{"fqdn_listname": "new-list@testing.com"}' https://0.0.0.0:8001/3.1/lists {"title": "400 Bad Request", "description": "Domain does not exist: testing.com"}
Am I doing something wrong, or missing a step? If not, how do I add support for additional domains such that I can provide mailing list support for that domain?
I am not sure I understand your question. Do you use Postorius and you can't add new domains from there?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
Greetings Odhiambo, thanks for your response. I personally don't use Postorius, and I'm not even sure anyone on our team is using it. A quick search of all our repositories shows only a single mention, back in 2017. A member of my team uses hand-written Python scripts to do much of the configuration, which is why I'm slowly trying to convert everything over to using the REST API.
As to your comment about not understanding my question. I basically want to add a domain to our Mailman installation, or to set a different primary for different environments, so that I can create mailing lists against those other domains.
mydomain.com <- primary in production and local development staging.mydomain.dev <- I want this to become primary in our staging environment.
Okay, I'm making progress. in our kubernetes config for mailman we're calling a shell script, and in the script is this line: mailman create mailman@mydomain.com --owner=admin@mydomain.com
When I changed that line to read mailman create mailman@foobar.com --owner=admin@foobar.com
and then rebuilt kubernetes, I found that when I hit the API to get all lists, the list mailman@foobar.com existed, and was the default. I could create lists against foobar.com but could no longer create them against mydomain.com.
So it looks like when you're initially configuring mailman you have to create your first mailing list, and whatever domain you use becomes your "primary domain". I don't know where this is documented, but could someone confirm this behavior for me so that I know that I'm on the right path?
On 10/17/24 13:41, Andy Matthews wrote:
and then rebuilt kubernetes, I found that when I hit the API to get all lists, the list mailman@foobar.com existed, and was the default. I could create lists against foobar.com but could no longer create them against mydomain.com.
So it looks like when you're initially configuring mailman you have to create your first mailing list, and whatever domain you use becomes your "primary domain". I don't know where this is documented, but could someone confirm this behavior for me so that I know that I'm on the right path?
And previously you wrote:
- Shell into the mailman server
- Shell into the mailman Python environment: mailman shell
- Add a new mailing list. from mailman.interfaces.domain import IDomainManager from zope.component import getUtility manager = getUtility(IDomainManager) manager.add('testing.com') show_domains() # with method from the above documentation URL <Domain testing.com> <Domain mydomain.com>
Did you commit() after doing the above?
I'm not sure how kubernetes fits in to this, but mailman create for a
list in an unknown domain will create the domain unless -D or
--no-domain is specified. See mailman create --help.
Mailman core has no concept of primary domain which is why it's not
documented.
Are you creating lists via REST as you posted previously. If so, the domain must exist, but if you created domains as above, they should exist as long as you committed your changes.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hey Mark, I'm looking at the documentation here: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/model/docs/...
Which seems to indicate that adding a domain via the CLI is as easy as:
from mailman.interfaces.domain import IDomainManager from zope.component import getUtility manager = getUtility(IDomainManager) manager.add('example.org')
It's not until much further down the page that there's any reference to "committing" a change. But sure enough when I add the following three lines to the previous 4, I'm able to create a mailing list with staging.mydomain.dev using the REST API.
from mailman.config import config transaction = config.db transaction.commit()
I created an issue suggesting as much on GitLab: https://gitlab.com/mailman/mailman/-/issues/1178
Thank you for pointing me in the right direction.
On 10/17/24 15:06, Andy Matthews wrote:
Hey Mark, I'm looking at the documentation here: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/model/docs/...
Which seems to indicate that adding a domain via the CLI is as easy as:
from mailman.interfaces.domain import IDomainManager from zope.component import getUtility manager = getUtility(IDomainManager) manager.add('example.org')
It's not until much further down the page that there's any reference to "committing" a change. But sure enough when I add the following three lines to the previous 4, I'm able to create a mailing list with staging.mydomain.dev using the REST API.
from mailman.config import config transaction = config.db transaction.commit()
I don't know how you are running these Python interactions, but if you
are using mailman shell interactively, things like IDomainManager, and
getUtility and lots of other things are imported automatically and
commit() and abort() are also predefined.
I created an issue suggesting as much on GitLab: https://gitlab.com/mailman/mailman/-/issues/1178
Also when using mailman shell, at startup it says:
Welcome to the GNU Mailman shell
Use commit() to commit changes.
Use abort() to discard changes since the last commit.
Exit with ctrl+D does an implicit commit() but exit() does not.
I've seen issue #1178. The issue is actually more widespread than that.
There are lots of things done in the Python snippets in the docs to
support the fact that they are all actually run as doctests as part of
our CI to ensure they are correct. In practice it is generally easier to
run these in mailman shell. However, the docs themselves don't say that.
We say a bit at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/commands/do... but I don't know a good way to say that globally.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Oh, I can't believe I never noticed the system message when running the mailman shell, but sure enough there it is.
I think I'm always so focused on jumping to what I'm looking to accomplish that I just skipped past it. Thank you for pointing it out.
One quick question. When I run the "mailman create mailman@mydomain.com --owner=admin@mydomain.com" command, it implicitly adds a domain to Mailman 3. Is it the create command which does that, or the fact that I'm passing the --owner flag?
One quick question. When I run the "mailman create mailman@mydomain.com --owner=admin@mydomain.com" command, it implicitly adds a domain to Mailman 3. Is it the create command which does that, or the fact that I'm passing the --owner flag?
It is the create command itself. If the domain of the created list is not currently known it will be registered unless the -D/--no-domain option is given.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Andy Matthews -
Mark Sapiro -
Odhiambo Washington