kenw@NOAH.ARC.AB.CA (Ken Wallewein CDP) (02/27/90)
We are running NEWS V5.8 on this system; it appears that V5.9+ cannot run
on our VMS V4.7 due to reliance on sharable mail (is there a way around
that?). In any case, I'm looking at merging our old kludged separate
"Forum" NEWS V4.2-based facility (I had to make hard-coded name changes to
keep the two data bases separate) with the ANU NEWS V5.8 setup. I plan to
use CLASSes and ACLs to:
a) Implement the FORUM command as NEWS/CLASS=FORUM
b) Prevent the few user IDs with the identifier EXTERNAL from reading
the FORUM class newsgroups.
Is there an easy way to merge data bases, assuming that the newsgroups
all different names? It would be nice if I could simply $ RENAME the
appropriate directory structures to the new locations and ask NEWS to
update its indices accordingly. The alternative appears to be to ADD FILE
[FORUM...]*.ITM. Unfortunately, that would cause the messages to be ADDed
out of sequence, unless I first ran a DCL procedure over the files and
leadiing-zero-filled all the .ITM file name/numbers. And of course, those
files would then be inaccessible from FORUM during the transition period,
making a fallback more difficult.
When I use the command NEWS/CLASS=FORUM/SCAN, the scan does not appear to
be restricted to the specified class. It there a way to correct this?
Finally, are there changes in NEWS V5.9c or its immediate successor that
would significantly alleviate or impact these 'challenges', making it
worthwhile to wait until we have upgraded VMS to V5.3+?
/kenw
Ken Wallewein A L B E R T A
kenw@noah.arc.ab.ca R E S E A R C H
(403)297-2660 C O U N C I Lgih900@SAO.ANU.OZ.AU (Geoff Huston) (02/28/90)
> We are running NEWS V5.8 on this system; it appears that V5.9+ cannot run >on our VMS V4.7 due to reliance on sharable mail (is there a way around >that?). The stuff will compile and will link with a warning, but will automatically use a LIB$SPAWN call for mail - so yes, V5.9 should run on VMS V4.7 ('though I haven't tried it!) > In any case, I'm looking at merging our old kludged separate >"Forum" NEWS V4.2-based facility (I had to make hard-coded name changes to >keep the two data bases separate) with the ANU NEWS V5.8 setup. I plan to >use CLASSes and ACLs to: > > a) Implement the FORUM command as NEWS/CLASS=FORUM > b) Prevent the few user IDs with the identifier EXTERNAL from reading > the FORUM class newsgroups. > > Is there an easy way to merge data bases, assuming that the newsgroups >all different names? It would be nice if I could simply $ RENAME the >appropriate directory structures to the new locations and ask NEWS to >update its indices accordingly. The alternative appears to be to ADD FILE >[FORUM...]*.ITM. Unfortunately, that would cause the messages to be ADDed >out of sequence, unless I first ran a DCL procedure over the files and >leadiing-zero-filled all the .ITM file name/numbers. And of course, those >files would then be inaccessible from FORUM during the transition period, >making a fallback more difficult. no - either write an application to merge the two databases, or go around the long way with a large ADD command. > When I use the command NEWS/CLASS=FORUM/SCAN, the scan does not appear to >be restricted to the specified class. It there a way to correct this? in theory yes, but I implemented scan to be as fast as possible in execution, and hence do not examine class attributes of newsgroups. It can be added, but it will therefore take more time. > Finally, are there changes in NEWS V5.9c or its immediate successor that >would significantly alleviate or impact these 'challenges', making it >worthwhile to wait until we have upgraded VMS to V5.3+? None are planned at this stage (unless someone sends me the code :-) ) Geoff Huston
kenw@NOAH.ARC.AB.CA (Ken Wallewein CDP) (02/28/90)
>... > This was a somewhat belated addition to the code to support the relevant > USENET RFC. On very careful inspection of the standard it states that > newsgroups which no not contain a '.' character are considered local to the > host (i.e. general, junk, local, control, etc) and are not to be passed to > neighbouring sites. > > > It appears that, contrary to my interpretation of the documentation > >(which is clear on the point), NEWS.SYS is _not_ consulted for the ADD FILE > >command. When _is_ it consulted regarding additions to the local nodes? > >Is it ever likely to change? We seem to have a misunderstanding here. I do _not_ have my NEWS.SYS configured to accept all newsgroups; nearly none, in fact. It contains only one active line: calarc:ean_feed,local,slug:: Until recently, we had no NEWS.SYS at all. I use ADD FILE/CREGRP with JUNKNODOT turned off, and use no-dot newsgroups such as "info-vax". I have no trouble adding items and groups. To me, that means that NEWS.SYS is not doing anything. Is this a bug, a feature, or what? Up until now, it's been a convenience, actually. > > If it were possible to override the NEWS system logicals through the use > >of user logicals, I would be able to redirect NEWS to use two different > >data bases. How hard would that be? Are there many routines that would be > >affected? Have you ever considered building in support for separate data > >bases? > > This then brings up the problems of user logicals driving a program > installed with SYSPRV. It has the potential to blast your system security > to shreds. Where NEWS uses SYSPRV to access the file system, the relevant > logical names used are all translated as SYSTEM EXEC logical names as a > precaution against such security issues. Good point. Actually, it turns out that /JOB/EXEC logicals work, too. And although I haven't tried it yet, I'm seriously considering /USER/EXEC logicals created by a priviledged image. It appears that this would allow me to actually use two completely separate data bases; somewhat like NEWSMGR-defined CLASSes, eh wot? /kenw
gih900@SAO.ANU.OZ.AU (Geoff Huston) (02/28/90)
>From: Ken Wallewein CDP <kenw@noah.arc.ab.ca> This came through as personal mail, but the answers may be of common interest, so I'll post the reply to the newsgroup/mailing list. > A comment on V5.8+... I'd rather JUNKNODOT (in NEWSADD) were a command >line switch, instead of a compile-time switch. I currently use a >mail-based feed for my NEWS, rather than a news-based feed. None of my >newsgroups currently have a dot, but that may change. It was a real gotcha >when I upgraded. What was worse, though, was that there was absolutely no >clue as to the nature of the problem. Nothing went into 'junk', there were >no error or diagnostic messages (ever though of making a 'verbose' mode?), >and if the /DELETE switch was uses, the ADD file was deleted as though >there was no problem. This was a somewhat belated addition to the code to support the relevant USENET RFC. On very careful inspection of the standard it states that newsgroups which no not contain a '.' character are considered local to the host (i.e. general, junk, local, control, etc) and are not to be passed to neighbouring sites. This brings up the more general area of what is a compile-time setting and what is a run time qualifier. On this particular one my feeling was that the site manager would decide once only whether to allow a feed of such newsgroups, or not, and making it a compile time option was therefore reasonable. I really am not overly keen on overloading commands with qualifiers if it can be avoided. It all adds to the size and slowness of the code in the long run. > It appears that, contrary to my interpretation of the documentation >(which is clear on the point), NEWS.SYS is _not_ consulted for the ADD FILE >command. When _is_ it consulted regarding additions to the local nodes? >Is it ever likely to change? And is there a way to simply allow >_everything_? In my poking through the code so far, I haven't seen exactly >where NEWS.SYS is read and applied. NEWS.SYS is consulted during the add phase via the call to check on the valid newsgroups (do_new_group() which calls into local accept code using news.sys for newsgroups). Yes there is a simply way to allow everything: mynode:all > As far as compile-time switches, I'd say CLASS-checking on SCAN should be >such a switch. I certainly appreciate the speed issue, but you may >remember that I'm trying to use the CLASS switch to maintain the appearance >of two separate news facilities Is anyone willing to send over the appropriate code changes to fastscan() to implement this please? > You say that the use of ACLs to restrict access to certain newsgroups is not >recommended. It certainly makes sense for us: we want to prevent outsiders >from reading confidential information, and it's all done via a single rights >identifier. What are the problems with doing it this way? This was my original intention, BUT in protecting newsgroups with ACL's, there is also the desire to block even the display of the newsgroup name if the newsgroup is not accessible. I implemented this some years ago, but then found that I had to check the protection of each newsgroup directory on startup to ensure that only accessible newsgroups were displayed, and the consequent startup delays were unacceptable. This lead to a NEWS-specific access mechanism, which can block or allow users to newsgroups based on either username, identifiers, or both, which is significantly faster in startup time. The answer to the query is yes, you can use ACLS to block off access to newsgroups, but the newsgroup entry will still be displayed in the directory screen. > If the NEWSMANAGER could assign global classes, it would be most >convenient; otherwise, I have to do it with priviledged use of batch >processing in the users' contexts. Worth doing, and practical, but a >kluge. Yes - this is supported with the file news_manager:news.classes. The internal format of the file is classname newsgroup,newsgroup(,...) to distinguish these names from user names, they are prefixed with '$' automatically. > If it were possible to override the NEWS system logicals through the use >of user logicals, I would be able to redirect NEWS to use two different >data bases. How hard would that be? Are there many routines that would be >affected? Have you ever considered building in support for separate data >bases? This then brings up the problems of user logicals driving a program installed with SYSPRV. It has the potential to blast your system security to shreds. Where NEWS uses SYSPRV to access the file system, the relevant logical names used are all translated as SYSTEM EXEC logical names as a precaution against such security issues. cheers, Geoff