On 7/20/2006 15:27, [log in to unmask] wrote:
> The ability to lookup list owners in more capable ways than listserv
> provides has been an ongoing problem for us. We are constantly being asked
> "which lists" do I own or "xxxx is no longer employed, remove them from
> list ownership", etc. With over 2000 lists, the reporting function is
> not usable for this. Or am I missing something?

We currently have over 47,000 lists (down from nearly 55,000), so some functions
that work well on smaller systems are pretty much unusable on our system.
Consequently, we have several home-grown scripts which we use to search the
.list files without submitting commands to LISTSERV.

> (Aside: is there a bug in the documentation? Narrow selection says "If
> you have a particular group of lists that you want to query that all
> contain the text "SALES" in the list name, for example, type "SALES"
> into the box and click "Submit". This will narrow the lists displayed
> to lists such as ..." However, it appears to search both the list NAME and
> DESCRIPTION)

Under the covers, wa is issuing the 'lists' command, and this is the way that
command has always worked.

> In addition, we find that we often need to notify the quiet owners as
> well; there are some things they simply need to know. If people managed
> quiet vs non-quiet designation better it wouldn't be a problem, but they
> don't. It is good to hear that ALL-REQUEST is now limited to
> postmasters/etc- we quit using that because people replied in autopilot (I
> know, I probably should have known of this change sooner, but I didn't).

We have not had an 'all-request' alias on our system for several years, and I
see no reason to add it now, even with the current access control. Long ago, we
created a list to send announcements to all list owners, including quiet owners.
We have a script which chews through all the .list files, executes the listview
command for each list, extracts and parses the 'owner=' statements, and creates
a batch job which refreshes the announcement list (delete current subscribers,
add new subscribers). All owners, quiet and non-quiet, are subscribed to the
announcement list.

> We also periodically have the need to send customized email to our owners.
> For example, we query owners of lists with no activity as to whether the
> list is viable. This is a laborious process of scanning the logs for
> activity, mating the data with list ownership, and then generating
> customized email.

The vast majority of our lists have archives, so it is relatively easy to find
inactive lists by running a unix 'find' command against the /archives directory
to identify directories which have not been updated in x days, where x is the
inactivity threshold.

> So I now have a script that scans all of the list headers for owners, with
> a caching mechanism to provide acceptable performance through a network
> connection and over the large number of lists. And while I was at it, I
> made it look through subscribers because q * for [log in to unmask] performs so
> slowly (yes, I know about the high performance option, but it appears we
> still have a performance issue that Lsoft has not been able to resolve).
> And I can scan for certain list settings for whatever reasons (who has
> sublists, who has confidential=no, etc., etc)

We have a script which will chew through the .list files, execute the listview
command for each list, and search the output for an arbitrary string. We have
used it to find all instances of a given email address, whether specified as an
owner, editor, moderator, or subscriber. We have also used it to find all lists
with a specific keyword setting. We have an explicit policy prohibitting the use
of unconfirmed open subscriptions, and we have a modified version of this script
which runs daily to identify any lists which are configured to accept
unconfirmed open subscriptions.

We run LISTSERV 1.8e on Solaris 8. I am willing to share our general-purpose
utility scripts, with the understanding that there is no warranty, express or
implied, that they will work correctly (or at all) in your environment.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
[log in to unmask]