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]