FreeBSD 8.2, Python2.7, Exim-4 and MM3
Hello everyone,
This is my first post to this list so please bear with me.
I am not a developer and as such I request you again to bear with me. My only endeavor is be able to get MM3 running on FreeBSD with Python2.7 and Exim 4 as the MTA.
So far I have hit a deadlock, hence my coming to you.
I have Python2.7 and py-sqlite3 installed from the ports. These are the latest versions on the FreeBSD ports tree.
I have downloaded and installed MM-3.0 (mailman-3.0.0a7) and closely followed the instructions.
So far, I've gotten stuck on one of the tests - bin/mailman info.
Let me start with the output of bin/test -vv (I've truncated it to just the top and the bottom bits):
<top bits> bin/test -vv Running tests at level 1 Running mailman.testing.layers.ConfigLayer tests: Set up mailman.testing.layers.MockAndMonkeyLayer in 0.000 seconds. Set up mailman.testing.layers.ConfigLayer Traceback (most recent call last): File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 380, in run_layer setup_layer(options, layer, setup_layers) File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 672, in setup_layer layer.setUp() File "/usr/local/mailman-3.0.0a7/src/mailman/testing/layers.py", line 120, in setUp initialize.initialize_2() File "/usr/local/mailman-3.0.0a7/src/mailman/core/initialize.py", line 145, in initialize_2 database.initialize(debug) File "/usr/local/mailman-3.0.0a7/src/mailman/database/stock.py", line 61, in initialize self._create(debug) File "/usr/local/mailman-3.0.0a7/src/mailman/database/stock.py", line 96, in _create database = create_database(url) File "/usr/local/mailman-3.0.0a7/eggs/storm-0.18-py2.7-freebsd-8.2-STABLE-i386.egg/storm/database.py", line 460, in create_database return factory(uri) File "/usr/local/mailman-3.0.0a7/eggs/storm-0.18-py2.7-freebsd-8.2-STABLE-i386.egg/storm/databases/sqlite.py", line 177, in __init__ raise DatabaseModuleError("'pysqlite2' module not found") DatabaseModuleError: 'pysqlite2' module not found
Running mailman.testing.layers.SMTPLayer tests: Set up mailman.testing.layers.ConfigLayer Traceback (most recent call last): File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 380, in run_layer setup_layer(options, layer, setup_layers) File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 667, in setup_layer setup_layer(options, base, setup_layers) File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 672, in setup_layer layer.setUp() File "/usr/local/mailman-3.0.0a7/src/mailman/testing/layers.py", line 91, in setUp initialize.initialize_1(INHIBIT_CONFIG_FILE) File "/usr/local/mailman-3.0.0a7/src/mailman/core/initialize.py", line 116, in initialize_1 mailman.config.config.load(config_path) File "/usr/local/mailman-3.0.0a7/src/mailman/config/config.py", line 105, in load self._post_process() File "/usr/local/mailman-3.0.0a7/src/mailman/config/config.py", line 125, in _post_process Switchboard.initialize() File "/usr/local/mailman-3.0.0a7/src/mailman/queue/__init__.py", line 87, in initialize 'Duplicate qrunner name: {0}'.format(name)) AssertionError: Duplicate qrunner name: retry
Running mailman.testing.layers.RESTLayer tests: Set up mailman.testing.layers.ConfigLayer Traceback (most recent call last): File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 380, in run_layer setup_layer(options, layer, setup_layers) File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 667, in setup_layer setup_layer(options, base, setup_layers) File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 667, in setup_layer setup_layer(options, base, setup_layers) File "/usr/local/mailman-3.0.0a7/eggs/zope.testrunner-4.0.3-py2.7.egg/zope/testrunner/runner.py", line 672, in setup_layer layer.setUp() File "/usr/local/mailman-3.0.0a7/src/mailman/testing/layers.py", line 91, in setUp initialize.initialize_1(INHIBIT_CONFIG_FILE) File "/usr/local/mailman-3.0.0a7/src/mailman/core/initialize.py", line 116, in initialize_1 mailman.config.config.load(config_path) File "/usr/local/mailman-3.0.0a7/src/mailman/config/config.py", line 105, in load self._post_process() File "/usr/local/mailman-3.0.0a7/src/mailman/config/config.py", line 125, in _post_process Switchboard.initialize() File "/usr/local/mailman-3.0.0a7/src/mailman/queue/__init__.py", line 87, in initialize 'Duplicate qrunner name: {0}'.format(name)) AssertionError: Duplicate qrunner name: retry </top bits>
<bottom bits> Ran 134 tests with 0 failures and 0 errors in 0.728 seconds. Tearing down left over layers: Tear down zope.testrunner.layer.UnitTests in 0.000 seconds.
Tests with errors: Layer: mailman.testing.layers.ConfigLayer Layer: mailman.testing.layers.SMTPLayer Layer: mailman.testing.layers.RESTLayer Total: 134 tests, 0 failures, 3 errors in 1.142 seconds. </bottom bits>
So I can see the failures but have no clue of how to fix them.
Now, when I invoke bin/mailman info, this is what I get:
mail# bin/mailman info Traceback (most recent call last): File "bin/mailman", line 20, in <module> mailman.bin.mailman.main() File "/usr/local/mailman-3.0.0a7/src/mailman/bin/mailman.py", line 98, in main initialize(config_file) File "/usr/local/mailman-3.0.0a7/src/mailman/core/initialize.py", line 174, in initialize initialize_2(propagate_logs=propagate_logs) File "/usr/local/mailman-3.0.0a7/src/mailman/core/initialize.py", line 145, in initialize_2 database.initialize(debug) File "/usr/local/mailman-3.0.0a7/src/mailman/database/stock.py", line 61, in initialize self._create(debug) File "/usr/local/mailman-3.0.0a7/src/mailman/database/stock.py", line 96, in _create database = create_database(url) File "/usr/local/mailman-3.0.0a7/eggs/storm-0.18-py2.7-freebsd-8.2-STABLE-i386.egg/storm/database.py", line 460, in create_database return factory(uri) File "/usr/local/mailman-3.0.0a7/eggs/storm-0.18-py2.7-freebsd-8.2-STABLE-i386.egg/storm/databases/sqlite.py", line 177, in __init__ raise DatabaseModuleError("'pysqlite2' module not found") storm.exceptions.DatabaseModuleError: 'pysqlite2' module not found
There is no py-sqlite2 port on FreeBSD 8.2 at the moment. Is there something I can do to get past this deadlock?
The second part of my problem is how to integrate MM3 with Exim4. I am informed that things have greatly changed from the way Exim4 was configured with MM2 (2.1.x). I am hoping that there are Exim gurus here, who have already worked on a configuration for MM3+Exim and have documented the bits required for both exim.conf and mailman.cf.
Thanks.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email.
On Sat, May 28, 2011 at 02:35:39PM +0300, Odhiambo Washington wrote:
The second part of my problem is how to integrate MM3 with Exim4. I am informed that things have greatly changed from the way Exim4 was configured with MM2 (2.1.x). I am hoping that there are Exim gurus here, who have already worked on a configuration for MM3+Exim and have documented the bits required for both exim.conf and mailman.cf.
ISTR there was a post within the last month or so to exim-users WRT MM3.
-- "Saying that road tax should be spent on transport is like saying that alcohol duty should be spent on pubs."
On Sat, May 28, 2011 at 19:37, Adam McGreggor <adam-mailman@amyl.org.uk>wrote:
On Sat, May 28, 2011 at 02:35:39PM +0300, Odhiambo Washington wrote:
The second part of my problem is how to integrate MM3 with Exim4. I am informed that things have greatly changed from the way Exim4 was configured with MM2 (2.1.x). I am hoping that there are Exim gurus here, who have already worked on a configuration for MM3+Exim and have documented the bits required for both exim.conf and mailman.cf.
ISTR there was a post within the last month or so to exim-users WRT MM3.
That must have been myself trying to find out if any fellows there are using it. I did not get any workable responses. Could you please point the thread?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email.
I traded a few emails with Odhiambo before I suggested sending a query here. I have a FreeBSD VM, but don't really know much about the OS.
On May 28, 2011, at 02:35 PM, Odhiambo Washington wrote:
Now, when I invoke
bin/mailman info, this is what I get: ... raise DatabaseModuleError("'pysqlite2' module not found") storm.exceptions.DatabaseModuleError: 'pysqlite2' module not foundThere is no py-sqlite2 port on FreeBSD 8.2 at the moment. Is there something I can do to get past this deadlock?
Here's the weird thing I noticed. After installing Python 2.7 and py-sqlite, this would succeed:
$ python2.7 -c 'import sqlite3'
but, after doing a buildout, this would fail:
$ bin/py -c 'import sqlite3'
So, the sqlite3 module was available from the standard Python, but not the built-out Python. No clue as to why though.
The second part of my problem is how to integrate MM3 with Exim4. I am informed that things have greatly changed from the way Exim4 was configured with MM2 (2.1.x). I am hoping that there are Exim gurus here, who have already worked on a configuration for MM3+Exim and have documented the bits required for both exim.conf and mailman.cf.
There are two parts to this. First, the way Exim is integrated with MM2, there's no need for alias file hacking because Exim can autodetect which mailing lists are available by looking at the config.pck files. Of course, there are no config.pck files in MM3 any more, so a new strategy is needed.
Second, the preferred way to get messages into MM3 is via LMTP, so ideally, there'd be some configuration to get Exim to connect to MM3's LMTP server.
It would be great to have better Exim (and Sendmail, qmail, or any other MTA) support in MM3. Let us know if you're willing and able to help!
-Barry
On 30 May 2011, at 02:37, Barry Warsaw wrote:
There are two parts to this. First, the way Exim is integrated with MM2, there's no need for alias file hacking because Exim can autodetect which mailing lists are available by looking at the config.pck files. Of course, there are no config.pck files in MM3 any more, so a new strategy is needed.
So to make this more generic:-
- how can an external process detect configured lists?
- preferably in a relatively non-active fashion - ie looking at the filesystem
- if needed by running something to say if list x exists
- what addresses does a list provide (ie list-request etc)
- or is there a way of getting mailman to list all the addresses that mailman handles (ideally including domain)
Second, the preferred way to get messages into MM3 is via LMTP, so ideally, there'd be some configuration to get Exim to connect to MM3's LMTP server.
That should be pretty easy.
It would be great to have better Exim (and Sendmail, qmail, or any other MTA) support in MM3. Let us know if you're willing and able to help!
Can't do a great deal on this, but willing to heckle, umm, give some advice from the sidelines. The exim.org machine is moving to a more modern platform later in the year so we may be in a position to realistically look at hosting a MM3 install then.
Nigel.-- [ Nigel Metheringham ------------------------------ nigel@dotdot.it ] [ Ellipsis Intangible Technologies ]
Hi Nigel,
On May 30, 2011, at 09:10 AM, Nigel Metheringham wrote:
So to make this more generic:-
- how can an external process detect configured lists?
- preferably in a relatively non-active fashion - ie looking at the filesystem
- if needed by running something to say if list x exists
I think you could do it either way. In MM3, while there's no config.pck file, there still is a directory under lists/ for each mailing list. This is where things like template customizations can go, and probably more things eventually. One difference is that the directory contains the "fqdn listname" which is the same as the posting address. E.g.:
$ bin/mailman info GNU Mailman 3.0.0a7+ (Where's My Thing?) Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) [GCC 4.5.2] config file: None db url: sqlite:////home/barry/projects/mailman/3.0/var/data/mailman.db REST root url: http://localhost:8001/3.0/ REST credentials: restadmin:restpass $ bin/mailman lists 1 matching mailing lists found: test1@example.com $ ls var/lists test1@example.com/
You could also get this information from the REST API. Here's an example using the Python client library, but of course anything that talks HTTP and can parse JSON will work too.
$ python Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
from mailman.client import Client mm = Client('http://localhost:8001/3.0', 'restadmin', 'restpass') for mlist in mm.lists: ... print mlist.fqdn_listname ... test1@example.com
- what addresses does a list provide (ie list-request etc)
- or is there a way of getting mailman to list all the addresses that mailman handles (ideally including domain)
It's not wonderful, since it's primarily geared toward generating /etc/aliases files (or their mta-specific moral equivalents), but it's there. Of course, it would be easy to add any specific output format that would help Exim. This is the Postfix output:
$ bin/mailman aliases -o - # AUTOMATICALLY GENERATED BY MAILMAN ON 2011-06-01 13:27:42 # # This file is generated by Mailman, and is kept in sync with the binary hash # file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what you're # doing, and can keep the two files properly in sync. If you screw it up, # you're on your own.
# Aliases which are visible only in the @example.com domain.
test1@example.com lmtp:[127.0.0.1]:8024 test1-bounces@example.com lmtp:[127.0.0.1]:8024 test1-confirm@example.com lmtp:[127.0.0.1]:8024 test1-join@example.com lmtp:[127.0.0.1]:8024 test1-leave@example.com lmtp:[127.0.0.1]:8024 test1-owner@example.com lmtp:[127.0.0.1]:8024 test1-request@example.com lmtp:[127.0.0.1]:8024 test1-subscribe@example.com lmtp:[127.0.0.1]:8024 test1-unsubscribe@example.com lmtp:[127.0.0.1]:8024
There's currently no equivalent in the REST API, although it would be trivial to add.
Second, the preferred way to get messages into MM3 is via LMTP, so ideally, there'd be some configuration to get Exim to connect to MM3's LMTP server.
That should be pretty easy.
Awesome.
It would be great to have better Exim (and Sendmail, qmail, or any other MTA) support in MM3. Let us know if you're willing and able to help!
Can't do a great deal on this, but willing to heckle, umm, give some advice from the sidelines. The exim.org machine is moving to a more modern platform later in the year so we may be in a position to realistically look at hosting a MM3 install then.
That would be great. I think we're very soon going to be ready to bring up a (GUI-less) test instance and to let brave souls start using it for real. I've been thinking about python.org or one of my own domains, none of which are entirely ideal. But if you or anyone else has a spare machine that we could use, let's talk!
Cheers, -Barry
On Wed, Jun 1, 2011 at 20:32, Barry Warsaw <barry@list.org> wrote:
Hi Nigel,
On May 30, 2011, at 09:10 AM, Nigel Metheringham wrote:
So to make this more generic:-
- how can an external process detect configured lists?
- preferably in a relatively non-active fashion - ie looking at the filesystem
- if needed by running something to say if list x exists
I think you could do it either way. In MM3, while there's no config.pck file, there still is a directory under lists/ for each mailing list. This is where things like template customizations can go, and probably more things eventually. One difference is that the directory contains the "fqdn listname" which is the same as the posting address. E.g.:
$ bin/mailman info GNU Mailman 3.0.0a7+ (Where's My Thing?) Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) [GCC 4.5.2] config file: None db url: sqlite:////home/barry/projects/mailman/3.0/var/data/mailman.db REST root url: http://localhost:8001/3.0/ REST credentials: restadmin:restpass $ bin/mailman lists 1 matching mailing lists found: test1@example.com $ ls var/lists test1@example.com/
You could also get this information from the REST API. Here's an example using the Python client library, but of course anything that talks HTTP and can parse JSON will work too.
$ python Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
from mailman.client import Client mm = Client('http://localhost:8001/3.0', 'restadmin', 'restpass') for mlist in mm.lists: ... print mlist.fqdn_listname ... test1@example.com
- what addresses does a list provide (ie list-request etc)
- or is there a way of getting mailman to list all the addresses that mailman handles (ideally including domain)
It's not wonderful, since it's primarily geared toward generating /etc/aliases files (or their mta-specific moral equivalents), but it's there. Of course, it would be easy to add any specific output format that would help Exim. This is the Postfix output:
$ bin/mailman aliases -o - # AUTOMATICALLY GENERATED BY MAILMAN ON 2011-06-01 13:27:42 # # This file is generated by Mailman, and is kept in sync with the binary hash # file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what you're # doing, and can keep the two files properly in sync. If you screw it up, # you're on your own.
# Aliases which are visible only in the @example.com domain.
test1@example.com lmtp:[127.0.0.1]:8024 test1-bounces@example.com lmtp:[127.0.0.1]:8024 test1-confirm@example.com lmtp:[127.0.0.1]:8024 test1-join@example.com lmtp:[127.0.0.1]:8024 test1-leave@example.com lmtp:[127.0.0.1]:8024 test1-owner@example.com lmtp:[127.0.0.1]:8024 test1-request@example.com lmtp:[127.0.0.1]:8024 test1-subscribe@example.com lmtp:[127.0.0.1]:8024 test1-unsubscribe@example.com lmtp:[127.0.0.1]:8024
There's currently no equivalent in the REST API, although it would be trivial to add.
Second, the preferred way to get messages into MM3 is via LMTP, so ideally, there'd be some configuration to get Exim to connect to MM3's LMTP server.
That should be pretty easy.
Awesome.
It would be great to have better Exim (and Sendmail, qmail, or any other MTA) support in MM3. Let us know if you're willing and able to help!
Can't do a great deal on this, but willing to heckle, umm, give some advice from the sidelines. The exim.org machine is moving to a more modern platform later in the year so we may be in a position to realistically look at hosting a MM3 install then.
That would be great. I think we're very soon going to be ready to bring up a (GUI-less) test instance and to let brave souls start using it for real. I've been thinking about python.org or one of my own domains, none of which are entirely ideal. But if you or anyone else has a spare machine that we could use, let's talk!
Hello Barry,
I manage several machines (FreeBSD of course) all of which use Exim as the MTA. I'd like to know what sort of conditions you attach to this requirement (for a spare machine). The only downside is that bandwidth is still not cheap in KE, so people connecting from outside will definately feel the slow speeds. If the tests are NOT likely to interfere with the smooth running of Exim on any of these servers, then I am willing to let you use one of them. However, Nigel's input matters most so I must wait till he can work out something for Exim.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email.
On Jun 02, 2011, at 09:10 AM, Odhiambo Washington wrote:
I manage several machines (FreeBSD of course) all of which use Exim as the MTA. I'd like to know what sort of conditions you attach to this requirement (for a spare machine). The only downside is that bandwidth is still not cheap in KE, so people connecting from outside will definately feel the slow speeds. If the tests are NOT likely to interfere with the smooth running of Exim on any of these servers, then I am willing to let you use one of them. However, Nigel's input matters most so I must wait till he can work out something for Exim.
Hi Odhiambo,
There really aren't too many conditions on this, though I think I would need shell access to quickly update the code and restart Mailman. Really, we just want a test server that brave folks like yourself can subscribe to and we can start throwing real traffic at. I think it would be wise at this point to not use a production server for now. Bandwidth isn't that big a deal for the email traffic I'd expect, though latency to the USA might be a problem.
-Barry
On Tue, Jun 7, 2011 at 23:35, Barry Warsaw <barry@list.org> wrote:
On Jun 02, 2011, at 09:10 AM, Odhiambo Washington wrote:
I manage several machines (FreeBSD of course) all of which use Exim as the MTA. I'd like to know what sort of conditions you attach to this requirement (for a spare machine). The only downside is that bandwidth is still not cheap in KE, so people connecting from outside will definately feel the slow speeds. If the tests are NOT likely to interfere with the smooth running of Exim on any of these servers, then I am willing to let you use one of them. However, Nigel's input matters most so I must wait till he can work out something for Exim.
Hi Odhiambo,
There really aren't too many conditions on this, though I think I would need shell access to quickly update the code and restart Mailman. Really, we just want a test server that brave folks like yourself can subscribe to and we can start throwing real traffic at. I think it would be wise at this point to not use a production server for now. Bandwidth isn't that big a deal for the email traffic I'd expect, though latency to the USA might be a problem.
-Barry
Hello Barry,
Is a valid MX record a MUST for this project?
My test box is inside a 2Mbps symmetric connection from anywhere (USofA, etc) but it does not have a valid MX record. Will that do? If it must have, then I will need to register a domain name and talk to the ISP to do the mappings.
However, if this test is non-intrusive to Exim, then I can use one of the production servers I use.
PS: My hope is that we'll be using Exim as the MTA:)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email.
On Jun 08, 2011, at 04:20 PM, Odhiambo Washington wrote:
Is a valid MX record a MUST for this project?
My test box is inside a 2Mbps symmetric connection from anywhere (USofA, etc) but it does not have a valid MX record. Will that do? If it must have, then I will need to register a domain name and talk to the ISP to do the mappings.
However, if this test is non-intrusive to Exim, then I can use one of the production servers I use.
PS: My hope is that we'll be using Exim as the MTA:)
As long as you can send email to foo-list@example.com, I think that's all that matters for right now.
My idea is that we'd bring up a test domain with a couple of test lists, and let people subscribe and unsubscribe via email (e.g. foo-join@example.com and foo-leave@example.com). Then people could post test messages to the list and we'd all see how MM3 performed under real-world conditions.
A few other things:
My main goal right now is to get the core to releasable state by 11.11.11. This probably means it's got to go to beta fairly soon, probably no later than the end of the northern hemisphere summer (probably best right after GSoC ends).
We don't need to wait until the web ui is ready, so we'll start with just the email interface.
Probably best to run the system off of bzr trunk. That way, you can much more quickly deploy bug fixes during this test phase.
I actually don't need shell access if you're willing and able to maintain the system, provide logs if necessary, update the bzr branch, etc.
I think the risk is small, but you should be prepared to deal with any runaway mail storms. Since most of the queuing architecture is a fairly straight port from MM2, and we have at least a *decade* of experience with that subsystem, we should be in good shape. But the MM3 code has been refactored and updated to more modern Pythonic idioms, so it's entirely possible that some catastrophic bug was introduced. Don't be afraid, but be prepared. :)
-Barry
On Thu, Jun 9, 2011 at 01:34, Barry Warsaw <barry@list.org> wrote:
On Jun 08, 2011, at 04:20 PM, Odhiambo Washington wrote:
Is a valid MX record a MUST for this project?
My test box is inside a 2Mbps symmetric connection from anywhere (USofA, etc) but it does not have a valid MX record. Will that do? If it must have, then I will need to register a domain name and talk to the ISP to do the mappings.
However, if this test is non-intrusive to Exim, then I can use one of the production servers I use.
PS: My hope is that we'll be using Exim as the MTA:)
As long as you can send email to foo-list@example.com, I think that's all that matters for right now.
My idea is that we'd bring up a test domain with a couple of test lists, and let people subscribe and unsubscribe via email (e.g. foo-join@example.comand foo-leave@example.com). Then people could post test messages to the list and we'd all see how MM3 performed under real-world conditions.
A few other things:
My main goal right now is to get the core to releasable state by 11.11.11. This probably means it's got to go to beta fairly soon, probably no later than the end of the northern hemisphere summer (probably best right after GSoC ends).
We don't need to wait until the web ui is ready, so we'll start with just the email interface.
Probably best to run the system off of bzr trunk. That way, you can much more quickly deploy bug fixes during this test phase.
I actually don't need shell access if you're willing and able to maintain the system, provide logs if necessary, update the bzr branch, etc.
I think the risk is small, but you should be prepared to deal with any runaway mail storms. Since most of the queuing architecture is a fairly straight port from MM2, and we have at least a *decade* of experience with that subsystem, we should be in good shape. But the MM3 code has been refactored and updated to more modern Pythonic idioms, so it's entirely possible that some catastrophic bug was introduced. Don't be afraid, but be prepared. :)
-Barry
Hello Barry,
I have crafted a subdomain for this purpose.
The 'domain' will be jaribu.kictanet.or.ke. The DNS portions have just been done a few hours ago so they need some hours to propagate, otherwise the IP is 196.200.26.114 Please dig your e-mails (btn me and you) for your logon credentials. The host already has Apache22, Exim-4.76, etc.
Nigel's been quiet!
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email.
Any chance of forging ahead with this, now that I have availed the server??
On Fri, Jun 10, 2011 at 19:33, Odhiambo Washington <odhiambo@gmail.com>wrote:
On Thu, Jun 9, 2011 at 01:34, Barry Warsaw <barry@list.org> wrote:
On Jun 08, 2011, at 04:20 PM, Odhiambo Washington wrote:
Is a valid MX record a MUST for this project?
My test box is inside a 2Mbps symmetric connection from anywhere (USofA, etc) but it does not have a valid MX record. Will that do? If it must have, then I will need to register a domain name and talk to the ISP to do the mappings.
However, if this test is non-intrusive to Exim, then I can use one of the production servers I use.
PS: My hope is that we'll be using Exim as the MTA:)
As long as you can send email to foo-list@example.com, I think that's all that matters for right now.
My idea is that we'd bring up a test domain with a couple of test lists, and let people subscribe and unsubscribe via email (e.g. foo-join@example.comand foo-leave@example.com). Then people could post test messages to the list and we'd all see how MM3 performed under real-world conditions.
A few other things:
My main goal right now is to get the core to releasable state by 11.11.11. This probably means it's got to go to beta fairly soon, probably no later than the end of the northern hemisphere summer (probably best right after GSoC ends).
We don't need to wait until the web ui is ready, so we'll start with just the email interface.
Probably best to run the system off of bzr trunk. That way, you can much more quickly deploy bug fixes during this test phase.
I actually don't need shell access if you're willing and able to maintain the system, provide logs if necessary, update the bzr branch, etc.
I think the risk is small, but you should be prepared to deal with any runaway mail storms. Since most of the queuing architecture is a fairly straight port from MM2, and we have at least a *decade* of experience with that subsystem, we should be in good shape. But the MM3 code has been refactored and updated to more modern Pythonic idioms, so it's entirely possible that some catastrophic bug was introduced. Don't be afraid, but be prepared. :)
-Barry
Hello Barry,
I have crafted a subdomain for this purpose.
The 'domain' will be jaribu.kictanet.or.ke. The DNS portions have just been done a few hours ago so they need some hours to propagate, otherwise the IP is 196.200.26.114 Please dig your e-mails (btn me and you) for your logon credentials. The host already has Apache22, Exim-4.76, etc.
Nigel's been quiet!
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email.
participants (4)
-
Adam McGreggor -
Barry Warsaw -
Nigel Metheringham -
Odhiambo Washington