Re: [Mailman-Developers] Mailman and Extend.py

2009-04-14 Thread C Nulk


Mark Sapiro wrote:
> C Nulk wrote:
>> While I waited, I did do some reading/researching on __init__ which lead
>> me to reading about __getattr__ and getattr.  If I understand correctly,
>> the LDAPMemberships uses them to get the isMember() and getMembers()
>> methods among others.
> 
> 
> Not exactly. Since the MemberAdaptor is replaceable, it can't simply be
> a super class of the MailList class. Thus, it's methods are not in the
> name space of the MailList object so we need an __getattr__ method to
> access them from whatever class is assigned as the list's
> _memberadaptor. So when you reference a method such as
> mlist.isMember() that is not directly in the name space of the mlist
> instance so mlist.__getattr__('isMember') is called (behind the
> scenes) and it finds mlist._memberadaptor.isMember() and returns that.

Sorry about that.  Your explanation is what I understood was the correct
action(s) for the interaction between MailList and the MemberAdaptor.  I
just way to short in my explanation.

> 
> This is true whether _memberadaptor is the default OldStyleMemberships
> class or the LDAPMemberships class or something else. The only thing
> that is specific to LDAPMemberships is the fact that the list's
> extend.py module assigned LDAPMemberships to _memberadaptor.
> 
> 
>>> From then on, whenever a member adaptor method is called for that list,
>>> the method that is called is the one defined in LDAPMemberships.py.
>>>
>>> So, for example, if your Mailman version is 2.1.10 or later so that it
>>> supports the @LISTNAME entry in *_these_nonmembers, and you put say
>>> @list2 in accept_these_nonmembers of list1, list1's processing of a
>>> non-member post will call list2's isMember() method to see if the
>>> poster is a member of list2, and if list2 already uses
>>> LDAPMemberships, that's it - it's isMember() method will use its LDAP
>>> database.
>> Unfortunately, I am stuck at v2.1.9 for now.
>>
>>> See the matches_p function in Mailman/Handlers/Moderate.py for more
>>> detail.
>> I did look at Mailman/Handlers/Moderate.py, specifically the matches_p
>> function.  What I envisioned doing was to modify the matches_p function
>> to single out "ldap" entries similar to the regex entries.  Then for
>> each "ldap" entry, call an LDAP2Dict function (to be written) which
>> returns a dictionary of email addresses, then check if the sender was in
>> the returned dictionary.
> 
> 
> That would work, but if this dictionary could be equated to the
> membership of some list, it seems to me that it would be easier to
> just backport the @listname feature to 2.1.9. You can find the
> original patch at
> .
> The 2.1.10 implementation is a bit more elaborate, but the SourceForge
> patch should be sufficient for your purpose.
> 
> Note that there is nothing magic about the dictionary in
> 
> plainaddrs = [addr for addr in nonmembers if not
>addr.startswith('^')]
> addrdict = Utils.List2Dict(plainaddrs, foldcase=1)
> if addrdict.has_key(sender):
> return 1
> 
> This could just as easily have been spelled
> 
> plainaddrs = [addr.lower() for addr in nonmembers if not
>addr.startswith('^')]
> if sender in plainaddrs:
> return 1
> 

I will have to take a closer look at the patch.  And, I probably will
apply it.  From the quick glance on sourceforge, it looks like it should
work for v2.1.9.  All I should have to do is adjust the diff lines to
point to the actual locations.

Being able to use another list as a source is great.  I would still like
to try to have everything defined/set within the list itself without
cross-referencing other "management" lists.  For us, it would be easier
to manage.

> 
>> The changes made to LDAPMemberships.py would help since you explained to
>> me that one of your changes was to make members a dictionary.  The
>> getMembers() method would essentially return that dictionary.
> 
> 
> No. getMembers() MUST return a list or everything breaks.
> 

Okay.  My mistake.  Still trying to figure out Python and how things
work.  Since getMembers() returns a list, I suppose I could use the
List2Dict() function to convert the list to a dictionary to be returned
by my LDAP2Dict() function.

> 
>> The key would be the changes to extend.py so everything works.
> 
> 
> If you are accessing some LDAP directly (not via the @list construct)
> in the matches_p function, extend.py has nothing to do with it.

You will have to correct me if I am really off-base here on my
understanding.

The extend.py module defines the extend() function which appears to set
ldap (as an object of the LDAPMemberships class)
   ldap = LDAPMemberships(list)
along with additional definitions, like
   ldap.ldapsearch = "(uid=somebody)"
   ldap.ldapserver = ldap.example.net
and to tie it to the list, set the _memberadaptor to the object by
   

Re: [Mailman-Developers] Mailman and Extend.py

2009-04-14 Thread Mark Sapiro
C Nulk wrote:
>
>I will have to take a closer look at the patch.  And, I probably will
>apply it.  From the quick glance on sourceforge, it looks like it should
>work for v2.1.9.  All I should have to do is adjust the diff lines to
>point to the actual locations.


That's correct.


>Being able to use another list as a source is great.  I would still like
>to try to have everything defined/set within the list itself without
>cross-referencing other "management" lists.  For us, it would be easier
>to manage.


That's your decision, but I think it complicates things. See below.


>
>You will have to correct me if I am really off-base here on my
>understanding.
>
>The extend.py module defines the extend() function which appears to set
>ldap (as an object of the LDAPMemberships class)
>   ldap = LDAPMemberships(list)
>along with additional definitions, like
>   ldap.ldapsearch = "(uid=somebody)"
>   ldap.ldapserver = ldap.example.net
>and to tie it to the list, set the _memberadaptor to the object by
>   list._memberadaptor = ldap


Yes.


>So when the list membership or some other method is accessed and not in
>the list namespace, your explanation above applies.
>
>My idea of changing extend.py was to add additional objects of the
>LDAPMemberships class.  Say an ldap2 and ldap3 like
>ldap2 = LDAPMemberships(list)
>ldap2.ldapsearch = "(uid=person1)"
>ldap2.ldapserver = ldap2.example.net
>list. = ldap2
>ldap3 = LDAPMemberships(list)
>ldap3.ldapsearch = "(role=list-poster)" # as an example
>ldap3.ldapserver = ldap3.example.net
>list. = ldap3
>
>both  and  are similar but not the
>same as the _memberadapter.  The difference is  and
> are specified in the accept_these_nonmembers (and the
>others) lists as LDAP= and likewise for any other
>"LDAP=" identifier.


Consider the following instead.

Create a list named say posters with it's own extend.py with settings
like
ldap = LDAPMemberships(list)
ldap.ldapsearch = "(role=list-poster)" # as an example
ldap.ldapserver = ldap3.example.net
list._memberadaptor = ldap
etc.

Then all you need do is install the patch and put @posters in the
original list's accept_these_nonmembers. You would also want to set
the 'posters' list with attributes like

archive = No
advertised = No
default_member_moderation = Yes
member_moderation_action = Discard
generic_nonmember_action = Discard

so people wouldn't be aware of it and posts would not be accepted.

That way, the different LDAP functions would be defined for different
"pseudo lists" and you wouldn't need any Mailman modifications other
than installing a feature that's already implemented in current
versions.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


Re: [Mailman-Developers] Mailman and Extend.py

2009-04-14 Thread C Nulk
Mark Sapiro wrote:
> 
> Consider the following instead.
> 
> Create a list named say posters with it's own extend.py with settings
> like
> ldap = LDAPMemberships(list)
> ldap.ldapsearch = "(role=list-poster)" # as an example
> ldap.ldapserver = ldap3.example.net
> list._memberadaptor = ldap
> etc.
> 
> Then all you need do is install the patch and put @posters in the
> original list's accept_these_nonmembers. You would also want to set
> the 'posters' list with attributes like
> 
> archive = No
> advertised = No
> default_member_moderation = Yes
> member_moderation_action = Discard
> generic_nonmember_action = Discard
> 
> so people wouldn't be aware of it and posts would not be accepted.
> 
> That way, the different LDAP functions would be defined for different
> "pseudo lists" and you wouldn't need any Mailman modifications other
> than installing a feature that's already implemented in current
> versions.
> 

Okay, okay, you've beaten me down. :):):)  I do see your point.  It is
an additional management issue I wanted to avoid with the unadvertised
lists.

Will this @list method also work for the other parameters/options that
have a list of email addresses (like owner, moderator, ban_list, ...) or
just the *_these_nonmembers options?

It probably sounds silly to do but if those options also take the @list
method, I can set up several of my lists so all the options (with email
address lists) are based out of ldap and have our system for creating
accounts out of our HR system build the ldap entries, resulting minimal
list management (for me at least :):))  The ban_list would not be an
ldap list but in theory it could.

If not, I guess I will have to live with it. :)

Thanks,
Chris
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


Re: [Mailman-Developers] Mailman and Extend.py

2009-04-14 Thread Mark Sapiro
C Nulk wrote:
>
>Okay, okay, you've beaten me down. :):):)  I do see your point.  It is
>an additional management issue I wanted to avoid with the unadvertised
>lists.
>
>Will this @list method also work for the other parameters/options that
>have a list of email addresses (like owner, moderator, ban_list, ...) or
>just the *_these_nonmembers options?


It only works for *_these_nonmembers. It could be implemented for
owner/moderator/etc, but these are more difficult as owner and
moderator are referred to in more than one place.

Note that Mailman 3 will support a true back-end database for list
membership and other roles. At that time, this will all become much
easier.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


Re: [Mailman-Developers] Mailman and Extend.py

2009-04-14 Thread C Nulk
Mark Sapiro wrote:
> C Nulk wrote:
>>
>> Will this @list method also work for the other parameters/options that
>> have a list of email addresses (like owner, moderator, ban_list, ...) or
>> just the *_these_nonmembers options?
> 
> 
> It only works for *_these_nonmembers. It could be implemented for
> owner/moderator/etc, but these are more difficult as owner and
> moderator are referred to in more than one place.
> 
> Note that Mailman 3 will support a true back-end database for list
> membership and other roles. At that time, this will all become much
> easier.
> 

I figured as much.  And thank you for answering my next question about
Mailman 3.  Is there documentation somewhere I can read how to configure
MM3 for using LDAP or any other back-end database?

Now back to the patch.

Thanks again,
Chris
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9


Re: [Mailman-Developers] Mailman and Extend.py

2009-04-14 Thread Barry Warsaw

On Apr 14, 2009, at 5:28 PM, C Nulk wrote:


I figured as much.  And thank you for answering my next question about
Mailman 3.  Is there documentation somewhere I can read how to  
configure

MM3 for using LDAP or any other back-end database?


Yes and no.  There are lots of doctests in the MM3 code, which  
primarily serve as documentation.  Navigating around to find the  
information you want may take some time as there's no overview.  There  
are currently no doctests describing how to use different backends,  
but the basic idea is that MM3 is strongly component based, using Zope  
style interfaces.  If you can provide different implementations of the  
backends for core objects (mostly in the mailman/database package),  
then the rest of Mailman will just work.


Integrating different RDBMS should be pretty trivial.  If Storm  
supports it, then it's just changing a URL in a config file.  For an  
LDAP backend, it will take some additional implementation work to  
write different implementations of IMailingList and such that don't do  
SQL queries to gather the necessary information.


I'd be happy to help anybody who's interesting in building out an LDAP  
backend.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9