- Barry Warsaw barry@python.org:
It seems that Karmic is playing tricks with /etc/hosts. I've got DNS set up to correctly resolve the VM's hostname, but there was actually an entry in /etc/hosts that set xxx.example.com to 127.0.1.1. I'm not entirely sure which process looks at what, when, but clearly this inconsistency was a key part of the problem. The other thing that surprised me was that Postfix was also
On a sidenote: It also confuses a dhcpd server running on a machine that promotes 127.0.1.1 to be xxx.example.com. I've opened a bug ticket for that two Ubuntu releases ago, but it seems they only keep carrying it further from release to release instead of addressing it. At least that's the impression I get without knowing the real cause.
What's the bug number?
https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/340383
consulting /var/spool/postfix/etc/hosts, and I had to change both /etc/hosts
That's because LaMont Jones delivers the Debian/Ubuntu Postfix package chrooted. If Postfix runs chrooted it uses /var/spool/postfix/etc/ hosts instead of /etc/hosts.
Ah, the pieces click together. Thanks!
BTW: Postfix notes that /etc/hosts and /var/spool/postfix/etc/hosts differ on reload (at least on Debian/Ubuntu) and it sends a simliar note to syslog.
I know experience tells us not to look at logs because logging and writing documentation is something you only get when you pay for it... ;) However with Postfix it pays to read the log. Wietse did a good job on this.
After a restart, everything suddenly worked exactly as expected.
suddenly... :)
Yeah. Doesn't everybody call 6 hours on a Saturday "suddenly"? :)
:)
Robert was having a different problem, but hopefully he will follow up here with his experience and let us know if any of the above helps. If any Postfix experts have words of wisdom to make this better, please let me know.
If MM relies on Postfix defaults and the postmaster changes them in Postfix the MM part might end up being unusable.
I recommend to take full control of the settings in the Postfix transport map. Let MM create its own Postfix style transport map. Set the "Postfix service name" (in your example its mailman3), put the hostname in square brackets and set the port.
Yep, I like setting the service name to mailman3. I'll note that Ubuntu's Postfix-Dovecot package already has a service for mailman (i.e. 2.x) which uses postfix-to-mailman.py.
If we came up with a reasonable set of default settings for the mailman3 service I take these to the Postfix developer list and try to have them added to the Postfix default master.cf file.
I probably need to work on better dropping of privileges for qrunners so that you can 'bin/mailman start' as root, and once the LMTP runner binds to port 24, it can drop privs to 'mailman'. I'll put that on the list for something to do after the next alpha.
I like that idea.
I'd also like to try to resurrect William Mead's LMTP branch. Sadly, it won't merge cleanly into trunk any more (not the least of which because it's in the wrong bzr format). If anybody would like to contribute that before I get to it, I'd be grateful.
The good news is that I think Mailman 3 is getting more real every day. My plan over the next few weeks is:
- release alpha 4
- get i18n translations working
- complete the split of the pipermail project
- hopefully get Patrick and friends going on the web u/i
I will update to the latest branch that should fix the language file problem we had discovered and then we will work on the REST client/server.
Excellent! I forgot that one other thing must happen before 3.0 can be released; we need a migration script from 2.1.x to 3.0.
May I complement the list?
- logo contest
- send the web interface off to a usability lab
p@rick
-- state of mind Digitale Kommunikation
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563