Steve Matzura wrote:

The MTA is postfix. The file in question is /var/lib/mailman/data/aliases which, according to what I've read, is created from aliases.db.

The other way around.

The interesting thing is, virtual-mailman *is* updated correctly from virtual-mailman.db while aliases is not.

You have it backwards. Mailman writes aliases and virtual-mailman and then calls postalias and postmap to update the .db files from the text files. Postfix uses the .db files even though the extensions are not mentioned in main.cf.

You need to 'chmod 660 /var/lib/mailman/data/virtual-mailman.db' It must be writable by the 'list group or it can't be updated by the web server running the create CGI.

Mailman was installed long before I got here, but I'm assuming it was installed via the standard package installer when Ubuntu was originally built a few years ago. I also recognize I'm not running the latest Ubuntu or Mailman.

Also, see the FAQ at <http://wiki.list.org/x/OIDD>.

Here's the perms on those four files:

-rw-rw---- 1 root list 6725 2012-03-28 19:07 aliases -rw-rw---- 1 list list 12288 2012-03-28 19:07 aliases.db -rw-rw---- 1 root list 5830 2012-03-28 19:07 virtual-mailman -rw-r----- 1 root list 12288 2012-03-28 19:07 virtual-mailman.db

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

It would *never* be in my best interest not to give you all the info. The problem is, I don't know exactly what info you need or want, and what would be superfluous. Let's see if I can provide more below. Anything I've omitted, just ask and it shall be yours for the knowing.

On Wed, 28 Mar 2012 12:28:27 -0700, you wrote:

Mark Sapiro wrote:

...

Steve Matzura wrote:

...

and second, the aliases file is not updated, so if a subscriber tries to send a message to the list, they receive an auto-reply telling them "user unknown in virtual mailbox table". My question is, why doesn't the web interface create new list feature update the aliases file? Is this a bug or a feature, or is there something I should put into mm_cfg.py to enable this, similar to owners-may-delete-their-own-lists?

If bin/newlist updates the aliases, web create should too, so clearly this has something to do with the error.

If the list is created and the only problem is that aliases aren't updated, it could be a permissions issue. Is Mailman's cgi-bin/create wrapper group 'mailman' and SETGID and does group 'mailman' have write permission on the aliases?

In case it went by and you didn't see it, here are the perms on those four files in /var/lib/mailman/data:

-rw-rw---- 1 root list 6725 2012-03-28 19:07 aliases -rw-rw---- 1 list list 12288 2012-03-28 19:07 aliases.db -rw-rw---- 1 root list 5830 2012-03-28 19:07 virtual-mailman -rw-r----- 1 root list 12288 2012-03-28 19:07 virtual-mailman.db

Also, the "user unknown in virtual mailbox table" error indicates the list domain is a virtual domain. If the issue is that Mailman's data/aliases is updated, but data/virtual-mailman is not, the problem is that the email host_name for the list is not in POSTFIX_STYLE_VIRTUAL_DOMAINS. For a web create, the host_name is determined by taking the web host from the URL used to go to the create page and looking it up in the VIRTUAL_HOSTS dictionary

That would be www.theglobalvoice.info with the additional mailman suffix string, of course. I tried putting add_virtualhost in mm_cfg.py, but all that did was generate an error saying I'd found a bug! Obviously that was the wrong thing to do, so I removed it, and now we're back to the "unknown virtual host" error on the web create form.

(basically your add_virtualhost entries) and getting the host name from there.

But, as Stephen suggests, don't make us guess. Give us all the information.

On Wed, 28 Mar 2012 16:24:07 -0500 (CDT), you wrote:

On Wed, 28 Mar 2012, Steve Matzura wrote:

...

It would *never* be in my best interest not to give you all the info. The problem is, I don't know exactly what info you need or want, and what would be superfluous. Let's see if I can provide more below. Anything I've omitted, just ask and it shall be yours for the knowing.

How about the error message you get when you try to create a list via the web interface. The one that you assumed we would somehow all know without you telling us (having never had an error when creating a list or if I did, not in recent years, I haven't the slightest clue what sort of error message you might have recieved). It seems rather likely that the error you received dealt with alias creation which you seem to want to think of as a second unrelated problem.

Error already reported in a previous message, but here's the Reader's Digest version. After going through the process of creating a new list via the Web interface, the error message "unknown virtual host" is given, and no mailing list is created.

I'd strongly suggest you start over and provide all relevant information in one post so we don't have to go through several messages to find the information you've dribbled out to us in multiple messages.

What's relevant? As previously stated, if I knew all the info to provide, I would have done so in the first place. I've since provided everything I know about what's going on when I try to create a list. The real problem here is, I know just enough about Mailman to be dangerous, so before I get dangerous and break something even further than it's already broken, I ask questions. If I provide insufficient information for you to help solve my problem, it's totally and completely unintentional. The expression "I don't know what I don't know" comes to mind.

I've obviously bunged this up badly. Now here it is, all correct and properly assigned to each half of the problem:

When creating the list admin@theglobalvoice.info, "unknown virtual host" is the error, but some way, somehow, the list gets partially created.

If I send a message to that partially created list, Mailman sends back a message of undeliverability with this error text:

Remote host said: 550 5.1.1 <admin@theglobalvoice.info>: Recipient address rejected: User unknown in virtual mailbox table

I looked in postfix.cf and discovered the virtual host name is really patronus.theglobalvoice.info, which may have something to do with why the Web create doesn't work, but 'newlist' does.

On Wed, 28 Mar 2012 18:19:29 -0500, you wrote:

On Mar 28, 2012, at 4:40 PM, Steve Matzura wrote:

...

On Wed, 28 Mar 2012 16:24:07 -0500 (CDT), you wrote:

...

...

How about the error message you get when you try to create a list via the web interface. The one that you assumed we would somehow all know without you telling us (having never had an error when creating a list or if I did, not in recent years, I haven't the slightest clue what sort of error message you might have recieved). It seems rather likely that the error you received dealt with alias creation which you seem to want to think of as a second unrelated problem.

Error already reported in a previous message, but here's the Reader's Digest version. After going through the process of creating a new list via the Web interface, the error message "unknown virtual host" is given, and no mailing list is created.

Just to show you how confused this became, I thought "unknown virtual host" was the error being returned to someone trying to post. I do not recall you ever saying that was the error the web interface was returning.

On Wed, 28 Mar 2012 17:28:25 -0700, you wrote:

How do you know this? Is the list visible in the web UI? In bin/list_lists?

Neither.

It may, but I can't say with the information I have. I'd need to see 'postconf -n' but I don't think that's necessary. I think the issue is the aliases were never created because of the error in the create CGI.

Do you have

add_virtualhost('www.theglobalvoice.info', 'theglobalvoice.info')

or perhaps the equivalent

DEFAULT_URL_HOST = 'www.theglobalvoice.info' DEFAULT_EMAIL_HOST = 'theglobalvoice.info'

followed by add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)

in mm_cfg.py.

The line:

add_virtualhost('www.theglobalvoice.info', 'theglobalvoice.info')

did not exist in mm_cfg.py until now. I added it directly in front of:

add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)

I then saved mm_cfg.py and restarted mailman with `mailmanctl restart' and attempted to create the mailing list. IT WORKED! It showed up in all four placess-output from list_lists, as the last stanza in virtual-mailman, as the last stanza in aliases, and in the Web UI! I thank you for bearing with me, I apologize for insufficient detailed error reporting, but with your collective assistance, it's now running correctly.

What is the purpose of the line I added? Does it "point" www.theglobalvoice.info to the real domain of theglobalvoice.info since that's where all the email list addresses go? If that's the case, why did the Web UI create not work? Does it carry the "www" subdomain with it in the underlying commands that actually do the list creation? If so, then that explains everything to me. If I'm totally off the mark, then I need to go back to school!

To recap:

I changed permissions on the aliases and virtual-mailman db files to +660 (-rw-rw----).

I added the line:

add_virtualhost('www.theglobalvoice.info', 'theglobalvoice.info')

to /etc/mailman/mm_cfg.py directly in front of the line:

add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)

and saved mm_cfg.py.

I restarted Mailman wit `/var/lib/mailman/bin/mailmanctl restart'.

To test, I created a mailing list with the Web UI and checked for its existence in list_lists and in the aliases and virtual-mailman files in /var/lib/mailman/data.

Everything checks out and the new mailing list is operating correctly.

Did I forget to check or report on anything?

On Wed, 28 Mar 2012 19:37:42 -0700, you wrote:

...

Did I forget to check or report on anything?

Well, you never answered the questions I asked at <http://mail.python.org/pipermail/mailman-users/2012-March/073113.html> so we don't know what was wrong there, but presumably, you don't care as you reversed whatever you did and it's working now.

Actually, I didn't "reverse" anything. You asked:

So what add_virtualhost() did you put in mm_cfg.py?

I actually tried, and backed out, two things before coming for help to this list, both of which made things worse! I tried add_virtualhost('www.theglobalvoice.info', 'www.theglobalvoice.info'), and the same line without the "www.". Adding this line gave me the "You hit a bug" message in the Web create UI, which is why I backed it out and set things back the way they'd been.

Regarding:

What is in Mailman's error log corresponding to the "we hit a bug"?

I don't know because I don't know enough about Mailman to have even had a chance to look. There's one thing about all of this you don't know because I haven't mentioned it, and it goes back to when I said I don't even know what I don't know. While I've been tasked to keeping theglobalvoice.info running, my only credentials for doing so are that I'm reasonably good at learning quickly--I am not a *ux system or site administrator of any stripe. Ask me lots of questions about VAX/Alpha VMS and I can talk your ear off, as that's what I've spent the last 30 years doing professionally. Show me a *ux system prompt and the first thing I know to do is "man {something}", and if that doesn't solve whatever is wrong, I start Googling until I find something to at least try. I'd gotten to that point and figured out it probably had something to do with add_virtualhost, but not understanding (until now) exactly what that directive does, I was floundering. Apparently my predecessor, someone actually far more qualified to do this job than I, either didn't know about the proper use of add_virtualhost, or was happy enough with using the command-line newlist' to create new mailing lists, because there are eight of them already on the system running successfully. The site owner told me that she always knew there was a problem with the Web UI, but the previous techie guy had a workaround for it--namely, using newlist' as root. I, being the type who doesn't like loose ends or unsolved mysteries, stuck my neck out and said I'd fix it ... and you know the rest.

Steve Matzura wrote:

The MTA is postfix. The file in question is /var/lib/mailman/data/aliases which, according to what I've read, is created from aliases.db.

The other way around.

The interesting thing is, virtual-mailman *is* updated correctly from virtual-mailman.db while aliases is not.

You have it backwards. Mailman writes aliases and virtual-mailman and then calls postalias and postmap to update the .db files from the text files. Postfix uses the .db files even though the extensions are not mentioned in main.cf.

You need to 'chmod 660 /var/lib/mailman/data/virtual-mailman.db' It must be writable by the 'list group or it can't be updated by the web server running the create CGI.

Mailman was installed long before I got here, but I'm assuming it was installed via the standard package installer when Ubuntu was originally built a few years ago. I also recognize I'm not running the latest Ubuntu or Mailman.

Also, see the FAQ at <http://wiki.list.org/x/OIDD>.

Here's the perms on those four files:

-rw-rw---- 1 root list 6725 2012-03-28 19:07 aliases -rw-rw---- 1 list list 12288 2012-03-28 19:07 aliases.db -rw-rw---- 1 root list 5830 2012-03-28 19:07 virtual-mailman -rw-r----- 1 root list 12288 2012-03-28 19:07 virtual-mailman.db

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

It would *never* be in my best interest not to give you all the info. The problem is, I don't know exactly what info you need or want, and what would be superfluous. Let's see if I can provide more below. Anything I've omitted, just ask and it shall be yours for the knowing.

On Wed, 28 Mar 2012 12:28:27 -0700, you wrote:

Mark Sapiro wrote:

...

Steve Matzura wrote:

...

and second, the aliases file is not updated, so if a subscriber tries to send a message to the list, they receive an auto-reply telling them "user unknown in virtual mailbox table". My question is, why doesn't the web interface create new list feature update the aliases file? Is this a bug or a feature, or is there something I should put into mm_cfg.py to enable this, similar to owners-may-delete-their-own-lists?

If bin/newlist updates the aliases, web create should too, so clearly this has something to do with the error.

If the list is created and the only problem is that aliases aren't updated, it could be a permissions issue. Is Mailman's cgi-bin/create wrapper group 'mailman' and SETGID and does group 'mailman' have write permission on the aliases?

In case it went by and you didn't see it, here are the perms on those four files in /var/lib/mailman/data:

-rw-rw---- 1 root list 6725 2012-03-28 19:07 aliases -rw-rw---- 1 list list 12288 2012-03-28 19:07 aliases.db -rw-rw---- 1 root list 5830 2012-03-28 19:07 virtual-mailman -rw-r----- 1 root list 12288 2012-03-28 19:07 virtual-mailman.db

Also, the "user unknown in virtual mailbox table" error indicates the list domain is a virtual domain. If the issue is that Mailman's data/aliases is updated, but data/virtual-mailman is not, the problem is that the email host_name for the list is not in POSTFIX_STYLE_VIRTUAL_DOMAINS. For a web create, the host_name is determined by taking the web host from the URL used to go to the create page and looking it up in the VIRTUAL_HOSTS dictionary

That would be www.theglobalvoice.info with the additional mailman suffix string, of course. I tried putting add_virtualhost in mm_cfg.py, but all that did was generate an error saying I'd found a bug! Obviously that was the wrong thing to do, so I removed it, and now we're back to the "unknown virtual host" error on the web create form.

(basically your add_virtualhost entries) and getting the host name from there.

But, as Stephen suggests, don't make us guess. Give us all the information.

On Wed, 28 Mar 2012 16:24:07 -0500 (CDT), you wrote:

On Wed, 28 Mar 2012, Steve Matzura wrote:

...

It would *never* be in my best interest not to give you all the info. The problem is, I don't know exactly what info you need or want, and what would be superfluous. Let's see if I can provide more below. Anything I've omitted, just ask and it shall be yours for the knowing.

How about the error message you get when you try to create a list via the web interface. The one that you assumed we would somehow all know without you telling us (having never had an error when creating a list or if I did, not in recent years, I haven't the slightest clue what sort of error message you might have recieved). It seems rather likely that the error you received dealt with alias creation which you seem to want to think of as a second unrelated problem.

Error already reported in a previous message, but here's the Reader's Digest version. After going through the process of creating a new list via the Web interface, the error message "unknown virtual host" is given, and no mailing list is created.

I'd strongly suggest you start over and provide all relevant information in one post so we don't have to go through several messages to find the information you've dribbled out to us in multiple messages.

What's relevant? As previously stated, if I knew all the info to provide, I would have done so in the first place. I've since provided everything I know about what's going on when I try to create a list. The real problem here is, I know just enough about Mailman to be dangerous, so before I get dangerous and break something even further than it's already broken, I ask questions. If I provide insufficient information for you to help solve my problem, it's totally and completely unintentional. The expression "I don't know what I don't know" comes to mind.

I've obviously bunged this up badly. Now here it is, all correct and properly assigned to each half of the problem:

When creating the list admin@theglobalvoice.info, "unknown virtual host" is the error, but some way, somehow, the list gets partially created.

If I send a message to that partially created list, Mailman sends back a message of undeliverability with this error text:

Remote host said: 550 5.1.1 <admin@theglobalvoice.info>: Recipient address rejected: User unknown in virtual mailbox table

I looked in postfix.cf and discovered the virtual host name is really patronus.theglobalvoice.info, which may have something to do with why the Web create doesn't work, but 'newlist' does.

On Wed, 28 Mar 2012 18:19:29 -0500, you wrote:

On Mar 28, 2012, at 4:40 PM, Steve Matzura wrote:

...

On Wed, 28 Mar 2012 16:24:07 -0500 (CDT), you wrote:

...

...

How about the error message you get when you try to create a list via the web interface. The one that you assumed we would somehow all know without you telling us (having never had an error when creating a list or if I did, not in recent years, I haven't the slightest clue what sort of error message you might have recieved). It seems rather likely that the error you received dealt with alias creation which you seem to want to think of as a second unrelated problem.

Error already reported in a previous message, but here's the Reader's Digest version. After going through the process of creating a new list via the Web interface, the error message "unknown virtual host" is given, and no mailing list is created.

Just to show you how confused this became, I thought "unknown virtual host" was the error being returned to someone trying to post. I do not recall you ever saying that was the error the web interface was returning.

On Wed, 28 Mar 2012 17:28:25 -0700, you wrote:

How do you know this? Is the list visible in the web UI? In bin/list_lists?

Neither.

It may, but I can't say with the information I have. I'd need to see 'postconf -n' but I don't think that's necessary. I think the issue is the aliases were never created because of the error in the create CGI.

Do you have

add_virtualhost('www.theglobalvoice.info', 'theglobalvoice.info')

or perhaps the equivalent

DEFAULT_URL_HOST = 'www.theglobalvoice.info' DEFAULT_EMAIL_HOST = 'theglobalvoice.info'

followed by add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)

in mm_cfg.py.

The line:

add_virtualhost('www.theglobalvoice.info', 'theglobalvoice.info')

did not exist in mm_cfg.py until now. I added it directly in front of:

add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)

I then saved mm_cfg.py and restarted mailman with `mailmanctl restart' and attempted to create the mailing list. IT WORKED! It showed up in all four placess-output from list_lists, as the last stanza in virtual-mailman, as the last stanza in aliases, and in the Web UI! I thank you for bearing with me, I apologize for insufficient detailed error reporting, but with your collective assistance, it's now running correctly.

What is the purpose of the line I added? Does it "point" www.theglobalvoice.info to the real domain of theglobalvoice.info since that's where all the email list addresses go? If that's the case, why did the Web UI create not work? Does it carry the "www" subdomain with it in the underlying commands that actually do the list creation? If so, then that explains everything to me. If I'm totally off the mark, then I need to go back to school!

To recap:

I changed permissions on the aliases and virtual-mailman db files to +660 (-rw-rw----).

I added the line:

add_virtualhost('www.theglobalvoice.info', 'theglobalvoice.info')

to /etc/mailman/mm_cfg.py directly in front of the line:

add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)

and saved mm_cfg.py.

I restarted Mailman wit `/var/lib/mailman/bin/mailmanctl restart'.

To test, I created a mailing list with the Web UI and checked for its existence in list_lists and in the aliases and virtual-mailman files in /var/lib/mailman/data.

Everything checks out and the new mailing list is operating correctly.

Did I forget to check or report on anything?

On Wed, 28 Mar 2012 19:37:42 -0700, you wrote:

...

Did I forget to check or report on anything?

Well, you never answered the questions I asked at <http://mail.python.org/pipermail/mailman-users/2012-March/073113.html> so we don't know what was wrong there, but presumably, you don't care as you reversed whatever you did and it's working now.

Actually, I didn't "reverse" anything. You asked:

So what add_virtualhost() did you put in mm_cfg.py?

I actually tried, and backed out, two things before coming for help to this list, both of which made things worse! I tried add_virtualhost('www.theglobalvoice.info', 'www.theglobalvoice.info'), and the same line without the "www.". Adding this line gave me the "You hit a bug" message in the Web create UI, which is why I backed it out and set things back the way they'd been.

Regarding:

What is in Mailman's error log corresponding to the "we hit a bug"?

I don't know because I don't know enough about Mailman to have even had a chance to look. There's one thing about all of this you don't know because I haven't mentioned it, and it goes back to when I said I don't even know what I don't know. While I've been tasked to keeping theglobalvoice.info running, my only credentials for doing so are that I'm reasonably good at learning quickly--I am not a *ux system or site administrator of any stripe. Ask me lots of questions about VAX/Alpha VMS and I can talk your ear off, as that's what I've spent the last 30 years doing professionally. Show me a *ux system prompt and the first thing I know to do is "man {something}", and if that doesn't solve whatever is wrong, I start Googling until I find something to at least try. I'd gotten to that point and figured out it probably had something to do with add_virtualhost, but not understanding (until now) exactly what that directive does, I was floundering. Apparently my predecessor, someone actually far more qualified to do this job than I, either didn't know about the proper use of add_virtualhost, or was happy enough with using the command-line newlist' to create new mailing lists, because there are eight of them already on the system running successfully. The site owner told me that she always knew there was a problem with the Web UI, but the previous techie guy had a workaround for it--namely, using newlist' as root. I, being the type who doesn't like loose ends or unsolved mysteries, stuck my neck out and said I'd fix it ... and you know the rest.