|
Sender: |
|
Subject: |
|
From: |
|
Date: |
Thu, 25 Oct 1990 15:47:41 +0100 |
In-Reply-To: |
Message of Thu,
25 Oct 1990 06:30:00 EDT from "Forum on LISTSERV release 1.6"
<LSTSRV-L@SEARN> |
Reply-To: |
|
>When a list's log disk fills up LISTSERV puts that list on hold and
>transfers the offending file to the primary postmaster.
This is an error, it should leave the file in its reader in HOLD status.
I will fix it.
>I tried both CP class G and D TRANSFERs back to LISTSERV; both resulted
>in the file being retransferred back to the postmaster, possibly because
>of a local CP mod to the class G TRANSFER command that reORIGINates the
>file with the transferrer's userid.
c/possibly//
>Would the class D transfer from postmaster have worked properly if the
>ORIGIN of the file had been the list's userid? If so, we can accomplish
>that by ensuring that LISTSERV uses the unambiguous class D TRANSFER
>command syntax: TRANSFER LISTSERV RDR... rather than TRANSFER * RDR.)
Yes, but there is no way I will change the code just because a particular
site happens to have a mod to class G TRANSFER that does not affect class
D TRANSFER.
>We have been logging all of our lists on a common log disk, but the
>YALEVM postmasters are tiring of managing that common disk space for the
>list owners. Has anyonelse come up with a good scheme that puts the
>burden of list and log management solely on the list owners?
So how do you allow a list owner to create and extend minidisks, etc?
>I don't see how they will help create the scenario that we would like to
>set up: where the log disk belongs to some other user (probably the
>list's userid) and LISTSERV simply links that disk MR at it's native (or
>the next available) virtual address and remembers that address to use
>with dynamic filemodes. Has anyonelse got this or something similarly
>easy to work?
Q1: in what way is this different from LISTSERV being the owner of the
disk and the list userid having a MR link?
Q2: why do you want the list userid to have R/W access to the disk? It is
VERY dangerous. LISTSERV sometimes creates files associated with the list
archives which should not be "ramdomly" modified. The list owner can use
the PUT command to alter or delete list archive files.
> * Notebook= Yes,L1/userid.vaddr,... (e.g, userid.vaddr could be
> OWEN.200)
Personally, I would call that a security exposure.
>Is it possible to define primary and secondary postmasters such that the
>error and informational mailings only go to the primary postmaster??
Use the "quiet:" keyword to suppress any mailing to the postmasters
following the keyword (they only have privs, but no junk mail).
Eric
|
|
|