The mailing list for listmasters using Sympa

[Tornóci László <address@concealed>]

Olivier Salaün wrote:
> Tornóci László a écrit :
> > 1. I noticed, some large sites allow two kinds of authentication: some 
> > university-wide netid for their own staff, plus regular email+pw for 
> > foreign users. How do you set up sympa and the databases for this? As 
> > far as I see sympa allows only one auth system, not something like if 
> > the first auth fails let's try another. So how is this done?
> Sympa allows to configure multiple authentication mechanisms, see the 
> auth.conf documentation 
> <http://www.sympa.org/manual/authentication#auth.conf>
> You'll notice that there are two kinds of authentication methods 
> supported : 1) the one (like 'database' or 'ldap') that require that the 
> sympa collects the user password ; 2) the one (like 'generic_sso' and 
> 'cas') that are single sign-on services and where sympa does not collect 
> the user password.
>
> You'll note that you can configure 'regexp' and 'negative_regexp' 
> extries in each auth.conf paragraph to skip some configuration mechanisms.

I see, that's nice.

> > 2. I want to set up a list with shared documents which is accessible 
> > only for members (read access for list members, write access for 
> > owners). So far no problem. However, I want to prevent the owners of 
> > this list from being able to set the read access to public. I can do 
> > this with list families, or I could introduce a site-wide restriction 
> > by editing etc/edit_list.conf .
> > This latter solution is not acceptable for me. Can I do it without 
> > list families?
> Sympa also provides a way to ignore some authorization scenarios, at any 
> level (list, robot, host). All you have to do is create an empty file 
> named d_read.public:ignore in your scenari/ directory.
> However, the list owner still has the ability to customize a scenario, 
> from the web interface...

I actually changed edit_list.conf like this:
shared_doc.d_read               privileged_owner                write
shared_doc.d_read               owner                           read
shared_doc.d_edit               owner,privileged_owner          write

So only privileged owners can change d_read. That's a good compromise, I 
think.

                                        Yours: Laszlo