|
Tech Tip (LISTSERV) – Issue 4 – 2008
Q: How can I maintain a dynamic list of people authorized to manage or post to multiple lists?
Answer by Liam Kelly
Senior Consulting Analyst, L-Soft
When managing a single list, maintaining access permissions is as simple as including the list of authorized addresses in the list header. But when managing many lists with a common set of owners or editors, manually maintaining each list header individually may not be practical. Fortunately, there are at least three different ways to save time and simplify the task with LISTSERV.
1. Maintain a separate LISTSERV list to manage the authorized addresses
First, create a new LISTSERV list, and add the authorized contacts as subscribers. For example, if we want the History department faculty to be able to post to any of the History department lists, we might make a list called HISTORY-FACULTY, and add all of our faculty members as subscribers. The configuration of the HISTORY-FACULTY list itself is not important for the purposes of this discussion; it could be either an announcement-style or discussion-style list.
Then we need to make the HISTORY-FACULTY list an authorized sender for each of our History department lists. For any LISTSERV list configuration keyword that accepts an access level (Owner, Send, Editor, Notebook, etc.), we can specify the name of another list instead of an email address. For example:
- SEND = DEPARTMENT_CHAIR@EXAMPLE.EDU, (HISTORY-FACULTY)
In the example above, both department_chair@example.edu and the members of the HISTORY-FACULTY list have permission to post to our list. We could add this setting to all lists in the History department if desired. Then, if a faculty member joins or leaves the department, we only have to add or delete their subscription to the HISTORY-FACULTY list, and there is no need to edit any of the individual list headers to grant or revoke posting permission.
For further information on setting access levels in LISTSERV, see the List Keyword Reference at: http://www.lsoft.com/manuals/15.5/listkeyw.html
2. Use an included keywords file
Another way to address the same issue is with the keywords file inclusion feature in LISTSERV. Using an included keywords file is as simple as creating a catalog entry for it, and then storing the file with a PUT command. If we want to add a number of faculty members to the keywords list, we could include them in the file as follows:
- PUT HISTORY_FACULTY KEYWORDS PW=password
- Send = faculty_member_1@example.edu
- Send = faculty_member_2@example.edu
- Send = faculty_member_3@example.edu
Then, in each of our History department list configurations, we would include the keywords file as follows:
When we want to change the list of faculty members, we now only have to update the HISTORY_FACULTY keywords file with a GET/PUT of the file, and all of the lists that include the keywords file will be automatically updated.
For further information on creating, storing, and using a keywords file, see section 7.13.13 of the LISTSERV Site Manager's Manual at:
http://www.lsoft.com/manuals/15.5/LISTSERV15.5_SiteManagersManual.pdf
3. Use a dynamic query
Starting with LISTSERV 15.5, we can also use a dynamic query through either LDAP or a DBMS data source to retrieve a dynamic list of authorized addresses. To use dynamic queries, the LISTSERV site manager must first define the dynamic query in the LISTSERV site configuration file. An example from a Windows SITE.CFG file might look as follows:
DYN_QUERY_HISTORYFACULTY="TYPE=LDAP SERVER=LDAP.EXAMPLE.EDU EMAIL=mail NAME=displayName BASE='dc=ldap,dc=example,dc=edu' FILTER='(&(objectclass=person)(OU=History))"
With the query defined in our site configuration, we can reference the query in a list header to define an access level. For example:
- Send = Query(HISTORYFACULTY)
When someone posts to the list, LISTSERV will run the HISTORYFACULTY query against the LDAP directory to retrieve the list of History faculty members and will check to see if the poster's email address matches the output of the query. We could do the same for "Owner", "Editor", or any other list configuration keyword that requires an access level.
Queries can also be parameterized, so that instead of specifying a separate dynamic query for each academic department, we can create a single query and pass one or more parameters to it. We use %1 for the first parameter, %2 for the second, etc.:
DYN_QUERY_FACULTY="TYPE=LDAP SERVER=LDAP.EXAMPLE.EDU EMAIL=mail NAME=displayName BASE='dc=ldap,dc=example,dc=edu' FILTER='(&(objectclass=person)(OU=%1))"
With the new FACULTY query above, we can set our list header as follows:
- Send = Query(FACULTY,History)
Now, when the list receives a post, LISTSERV will run the FACULTY query, replacing '%1' with 'History', and check the sender's email address against the result of the query.
Dynamic queries are not limited to LDAP. A similar query can be run against a DBMS data source. See the LISTSERV 15.5 DQL Overview for more details and examples:
http://www.lsoft.com/manuals/15.5/DQL%20Overview.pdf
Pros and cons
Each of the methods described above has pros and cons that may make one method more appropriate than the others for particular sites:
Separate LISTSERV List
Pros:
- Requires no Postmaster intervention after list creation
- List Owner can use Subscriber Management features to manage the list of privileged addresses
Cons:
- List not automatically updated from external data source like LDAP or DBMS
- Requires additional list on LISTSERV server
Included keywords file
Pros:
- Any LISTSERV list configuration keyword may be included in the keywords file, including those not directly related to access levels (e.g., Auto-Delete, Review, etc.)
Cons:
- Keywords file must be created by Postmaster, not list owner
- List not automatically updated from external data source like LDAP or DBMS
Dynamic Query
Pros:
- List access permissions can be updated in real-time against a master LDAP or DBMS data source
Cons:
- Query creation must be done by Postmaster
- Incurs overhead on LDAP or DBMS data source
Using one or more of the methods described above, LISTSERV postmasters and list owners can greatly simplify management of multiple lists with common sets of owners or editors.
References
| 