LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Eric Thomas <[log in to unmask]>
Sat, 28 Jun 1997 14:21:45 +0200
text/plain (46 lines)
On Fri, 27 Jun 1997 17:26:46 -0400 David R Nessl <[log in to unmask]> said:

>The first (and most important) item is that we need an exit to be called
>before logfile creation -- each of our  lists has a primary owner on our
>Unix system, and we store each list's logs in a subdirectory under their
>owner's home directory. The purpose is for charging, but it doesn't work
>under Unix because the logfiles are owned by the username 'listserv'.

I'm not sure I understand the problem. If all the files belonging to user
X  are under  a predictable  subdirectory tree  ('/logs/X' or  whatever),
charging for  the space  should be  as simple  as calculating  disk space
usage for this  directory tree. If the  files *have* to be owned  by X in
order for existing bean counting software to work, you could run a script
before each  bean counting report  is prepared that does  something along
the lines of 'chown -R xxx /logs/X/*'. The exit you are asking for is not
a simple  matter. Log files are  one thing, but logically  you would want
this exit to be  available for every file that can  reasonably need to be
charged  back to  a user,  including  files orderable  via GET,  database
indexes,  etc. While  log files  are append-only  in *most*  cases, these
other files are  usually updated by creating a tempory  file and renaming
it to  the new file (on  occasion this can be  the case for log  files as
well). There would need to be dozens  of calling points for this exit and
inevitable omissions, all  that to implement, in  essence, inheritance of
default permissions from the parent directory, which is normally provided
by an operating system feature. This is  not a minor development and I do
not  see a  general need  for  this exit  when chargeback  can be  easily
implemented by  counting the  space used by  a particular  directory tree
(this is how we do it at L-Soft for our mailing list service).

>The  second item  is that  the SCAN  command doesn't  recurse down  into
>sub-lists.

I don't  agree that SCAN  or list  management commands in  general should
recurse automatically  into sub-lists. This  might be useful  in specific
cases  but  it  is  counter-intuitive  to the  primary  purpose  of  list
management commands, which is to target a specific list.

>We make extensive  use of sub-lists, and I had  a locally-written /WHOIS
>command for VM LISTSERV which would recurse down thru sublists.

Note that  you can also provide  locally developed commands for  the unix
version, using  the same localcmd.file  mechanism. You should be  able to
convert your /WHOIS command to unix with the same syntax.

  Eric

ATOM RSS1 RSS2