Continued problems with Mailman on RHEL6.1

Hi,
I am trying to create a new list via the mailman web interface, it appears to create a list but inbound emails to the list(s) are failing saying, user unknown in local recipient table.
I am assuming that the web interface should add the list controls to the /etc/aliases file? it looks like it isnt... Either that or I suspect its meant to add to a file in /etc/mailman/aliases? and re-generate a /etc/mailman/aliases.db? and the above path should be in main.cf? so its found?
However mailman is meant to work, it obviously isnt....or do I have it wrong?
regards

On 6/8/11 6:54 PM, Steven Jones wrote:
So integration with your MTA is not properly configured or even available.
I am assuming that the web interface should add the list controls to the /etc/aliases file?
Nope. It never does this. If Mailman generates aliases (MTA = 'Postfix' in mm_cfg.py) it generates them in $var-prefix/data/aliases which in RedHat may be symlinked or redirected to /etc/mailman/aliases.
Yes.
However mailman is meant to work, it obviously isnt....or do I have it wrong?
This list is not the appropriate place for your RedHat packaging issues.
See the installation manual section at <http://www.list.org/mailman-install/postfix-integration.html> for the standard GNU Mailman/Postfix integration, and see the FAQ at <http://wiki.list.org/x/KYCB> for RedHat file mappings.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California Better use your sense - B. Dylan

8><-----
This list is not the appropriate place for your RedHat packaging issues.
8><-------
I can appreciate this, but Im trying to determine what is going wrong so I can be sure in taking it to RH they have stuffed up.
regards

Steven Jones writes:
This is *exactly* why you should go to Red Hat *first*. They have changed a known working system; they have *already* "stuffed up" by definition!
The practical problem with asking here first is that the Mailman project members would find it very expensive to help you do that, unless they happen to be very familiar with Red Hat themselves. However, almost all of us build Mailman from source without OS-specific patches because *we know it works that way*! We *know* that Red Hat changes Mailman; but even if shown the patches, we don't know why or how the behavior of Mailman is affected by these changes, because in many cases it has to do with Red Hat-specific features of the OS.
OTOH, the Red Hat maintainer knows all of the above (unless the original maintainer has gone AWOL and not bothered to train a successor, in which case our advice is surely going to be "nuke the RH package and install from source"). He can probably diagnose such problems off the top of his head, as well as have a much better idea of when to bat the ball back into our court than we have about blaming it on Red Hat.

On 6/8/11 6:54 PM, Steven Jones wrote:
So integration with your MTA is not properly configured or even available.
I am assuming that the web interface should add the list controls to the /etc/aliases file?
Nope. It never does this. If Mailman generates aliases (MTA = 'Postfix' in mm_cfg.py) it generates them in $var-prefix/data/aliases which in RedHat may be symlinked or redirected to /etc/mailman/aliases.
Yes.
However mailman is meant to work, it obviously isnt....or do I have it wrong?
This list is not the appropriate place for your RedHat packaging issues.
See the installation manual section at <http://www.list.org/mailman-install/postfix-integration.html> for the standard GNU Mailman/Postfix integration, and see the FAQ at <http://wiki.list.org/x/KYCB> for RedHat file mappings.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California Better use your sense - B. Dylan

8><-----
This list is not the appropriate place for your RedHat packaging issues.
8><-------
I can appreciate this, but Im trying to determine what is going wrong so I can be sure in taking it to RH they have stuffed up.
regards

Steven Jones writes:
This is *exactly* why you should go to Red Hat *first*. They have changed a known working system; they have *already* "stuffed up" by definition!
The practical problem with asking here first is that the Mailman project members would find it very expensive to help you do that, unless they happen to be very familiar with Red Hat themselves. However, almost all of us build Mailman from source without OS-specific patches because *we know it works that way*! We *know* that Red Hat changes Mailman; but even if shown the patches, we don't know why or how the behavior of Mailman is affected by these changes, because in many cases it has to do with Red Hat-specific features of the OS.
OTOH, the Red Hat maintainer knows all of the above (unless the original maintainer has gone AWOL and not bothered to train a successor, in which case our advice is surely going to be "nuke the RH package and install from source"). He can probably diagnose such problems off the top of his head, as well as have a much better idea of when to bat the ball back into our court than we have about blaming it on Red Hat.
participants (4)
-
D G Teed
-
Mark Sapiro
-
Stephen J. Turnbull
-
Steven Jones