nsb@thumper.bellcore.com (Nathaniel Borenstein) (07/04/90)
First of all, the instructions are out of date. I'm running a bboard
system happily without AFS, as are several other sites that I know of.
So don't worry about AFS in this case.
As for security, AMS bboards are as secure as the file system they use.
They're much more secure if you use AFS, because AFS authentication and
protection are so good.
Basically, to set up a bboard system you need to do a few things, which
I'll outline here in not-too much detail; I encourage you to ask more
specific questions as needed. I'll describe how you create ONE bboard,
and then talk about how you can generalize the process. My take on it
is that if you don't know anything about AMS bboards it should still
only take you an hour or two to set up one bboard as described below.
Beyond that, you can probably put in an arbitrary amount of time making
your bboard system more complex and fancy. Anyway, the instructions
follow. (CMU PEOPLE: MAYBE YOU MIGHT WANT TO POLISH THIS UP FOR A HELP
FILE?)
1. Set up a bboard account, which I'll assume below is called "bboard".
2. Logged in as "bboard", run the cui program and type "create bb" to
create a bboard called "bb".
3. Ensure that any mail that comes to "bboard" gets posted on this
bboard by creating the file ~bboard/.AMS.flames, with contents much like
the following single line:
(defun bb-hook (msg) (appendmsgtodir msg (findfolder "bb" "w")))
4. Create the file ~bboard/.MESSAGES/bb/.MS.DirectPost and put the
following two lines, more or less, in it:
0
"bb" <bboard@local-host>
Note that due to a BUG in AMS, you should use some name OTHER THAN your
"ThisDomain" configuration to refer to your local host. (For example,
my ThisDomain is "thumper.bellcore.com", and my DirectPost files say
"blah" <foo@thumper> instead of "blah" <foo@thumper.bellcore.com>.) The
reason you have to go through this is that if "local-host" is identical
to ThisDomain, currently the "bb" portion of this address is sometimes
dropped by the address rewriter. THIS SHOULD BE FIXED and, indeed,
might already have been fixed for the next patch release -- I just don't
know.
5. Set up one or more daemons to process the bboards. This can be done
in several different ways. Using SunOS 4.0.X, I do it using the
extended crontab facility. Typing "crontab -l" as the bboard account, I
see that I currently have 4 daemons set up:
0 * * * * /u/andrew/bin/processmsgs
5 1 * * * /u/andrew/bin/collectlogs
5 0 * * * /u/andrew/bin/dailypurge
15 0 * * 0 /u/andrew/bin/weeklypurge
The first one posts the notices. The second runs nightly to collect the
logs from the other daemons. The last two purge different bboards at
daily and weekly intervals. Note that these daemons all run as "bboard"
(or, in my case, as "andrew"). The shell scripts used will be
appended below.
That's it! I think that's all you really have to do. Once you're set
up like this, you can use any AMS interface to send mail to "bb" and it
will get routed to the bboard. To generalize beyond this to a rich set
of zillions of bboards, you need to learn a little more about
.MS.DirectPost files, and potentially a lot more about .AMS.flames
files. (FLAMES is a LISP-like language that you can use to route
incoming messages to the correct bboards.) I believe that both are
documented in the help system, but feel free to ask if you have any more
questions. Good luck. -- Nathaniel
________________________________
The four crontab scripts referred to above follow below. You'll
probably need to change some path names, bb names, etc. -- think of
these as just suggestions regarding how to set up such daemons, because
I make no guarantees that they'll work for anyone else. Bear in mind,
they're intended to be running for the "andrew" account here at
Bellcore. Also, the "arch" program is a local hack that returns the cpu
type of the machine, e.g. sun3, sun4, etc. -- it is used below to find
the right path names for some binaries.
________________________________
processmsgs
________________________________
#!/bin/csh -f
echo $$ > /tmp/cronlock.processmsgs
sleep 5
if ($$ != `cat /tmp/cronlock.processmsgs`) exit
set CUIPS = `ps ux | grep cui | grep andrew | grep -v grep`
set LOGFILE = ~/bb.log
if ("" == "$CUIPS") then
echo "Starting CUI now" >>& $LOGFILE
/u/andrew/`arch`/bin/cui set script on \; set log $LOGFILE \; set
term 0 \; set level wizard \; loop -1 300 check >& /dev/null
else
# echo "CUI is already running for me" >>& $LOGFILE
endif
________________________________
collectlogs
________________________________
#!/bin/csh -f
echo $$ > /tmp/cronlock.collectlogs
sleep 5
if ($$ != `cat /tmp/cronlock.collectlogs`) exit
set LOGFILE=~/bb.log
set PURGEFILE=~/bbpurge.log
set DOUBLINESFILE=~/bin/doublines.sed
touch $PURGEFILE
set TMPFILE=/tmp/bb.log.$$
echo "From: Bboard Daemon" >& $TMPFILE
echo "Subject: Yesterday's bboard activity" >> $TMPFILE
echo -n "Date: " >> $TMPFILE
/u/andrew/sun4/etc/arpadate >> $TMPFILE
echo "Content-Type: X-BE2; 12" >> $TMPFILE
echo "" >> $TMPFILE
echo "\begindata{text, 42}" >> $TMPFILE
echo "\majorheading{Critical error summary from yesterday's bboards}" >>
$TMPFILE
echo "" >> $TMPFILE
echo "" >> $TMPFILE
grep critical $LOGFILE | sed -f $DOUBLINESFILE >> $TMPFILE
echo "" >> $TMPFILE
echo "" >> $TMPFILE
echo "\majorheading{Purging Report}" >> $TMPFILE
echo "" >> $TMPFILE
echo "" >> $TMPFILE
cat $PURGEFILE | sed -f $DOUBLINESFILE >> $TMPFILE
echo "" >> $TMPFILE
echo "" >> $TMPFILE
echo "\majorheading{Statistics on numbers of messages processed}" >> $TMPFILE
echo "" >> $TMPFILE
echo "" >> $TMPFILE
echo "These statistics are not yet being computed. Here, however, is
some of the raw data:" >> $TMPFILE
echo "" >> $TMPFILE
echo "" >> $TMPFILE
echo "" >> $TMPFILE
grep "read in" $LOGFILE | sed -f $DOUBLINESFILE >> $TMPFILE
echo "\enddata{text, 42}" >> $TMPFILE
mv $TMPFILE ~/Mailbox
if ($status == 0) then
rm $LOGFILE
rm $PURGEFILE
rm $WEATHERLOGFILE
endif
________________________________
dailypurge
________________________________
#!/bin/csh -f
echo $$ > /tmp/cronlock.dailypurge
sleep 5
if ($$ != `cat /tmp/cronlock.dailypurge`) exit
/u/andrew/`arch`/bin/cui set script on \; set term 0 \; set level wizard
\; epoch /u/andrew/.MESSAGES/bb/apnews one days ago \; epoch
/u/andrew/.MESSAGES/bb/weather one days ago \; quit >>& ~/bbpurge.log
________________________________
weeklypurge
________________________________
#!/bin/csh -f
echo $$ > /tmp/cronlock.weeklypurge
sleep 5
if ($$ != `cat /tmp/cronlock.weeklypurge`) exit
/u/andrew/`arch`/bin/cui set script on \; set term 0 \; set level
wizard \; epoch /u/andrew/.MESSAGES/bb ten days ago \; epoch
/u/andrew/.MESSAGES/internet ten days ago \;epoch
/u/andrew/.MESSAGES/lost ten days ago \; quit >>& ~/bbpurge.log oun@clbull.cl.bull.fr (07/05/90)
in the message "How to Create an AMS Bboard System" in the newsgroups comp.soft-sys.andrew, nsb@thumper.bellcore.com (Nathaniel Borenstein) says: >First of all, the instructions are out of date. I'm running a bboard >system happily without AFS, as are several other sites that I know of. >So don't worry about AFS in this case. > > ....... Thanks for your help. I'd like to have some more detail: Running bboard system in a multi-machine environment WITHOUT AFS, can you control the access right of people from other machines who want to subscribe to your bboard? -- Jean-Luc -- Jean-Luc Oun, Bull ---------------------------------- Software Development Methodology email: oun@cl.bull.fr Les-Clayes(Paris), France tel: (33-1) 34 62 70 00 ext. 6374
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/05/90)
Excerpts from internet.info-andrew: 5-Jul-90 Re: How to Create an AMS Bb.. oun@clbull.cl.bull.fr (780) > Running bboard system in a multi-machine environment WITHOUT AFS, can > you control the access right of people from other machines who want to > subscribe to your bboard? Only to the extent that you can use the underlying file system protection to do so. That is, you can use UNIX groups, or whatever, but as we all know that's not a very fine-grained mechanism, which is why they added such better protection to AFS. In particular, it would be pretty easy to set up two kinds of bboards, regular and special. Anyone could read the regular bboards, but you'd have to be a member of the "special" group as defined in /etc/group to read the special bboards. (Note that the bboard processing daemon would be the owner of the bboard, and would have write permission, and therefore all you'd give to the group would be read permission.) At any rate, I think something like that would work, but I haven't tried it. Our bboards at Bellcore are all pretty much open to anyone who has an account on our machines right now...
Craig_Everhart@TRANSARC.COM (07/05/90)
(aside first: yes, andrew.cmu.edu has ~10^4 users, not ~10^5. Apologies.) AFS uses Kerberos authentication. (AFS is now a registered trademark of Transarc Corp., US 412-338-4467) As Nathaniel says, you can build an AMS bboard system out of any Unix-like file system. Bboards are simply directories and files in the file system, and can thus be made as public or as private as the underlying file system permits. There are many possible classes of permissions: the popular ``public'' one requires that everybody have read access to the directory (and its files), but only that the posting daemon, presumably running as a dedicated account, have write/update access to those directories and files. For a bboard that's private to a group, if you can give read access to only the members of that group (and to the posting daemon), you've got it made, to the extent that you trust your file system's access control. In short, AMS doesn't provide for any security above that provided by the underlying storage system. To Nathaniel's point about the ``AMS BUG'': I submitted a patch that should fix it on 16 April (1990); I don't know when the next patch will emerge. We've been running with the locally-patched software, but we don't have Nathaniel's problem since we're using AMDS. (The problem was a problem only for non-AMDS sites.) In any event, the fix simply doesn't discard the route-phrase if there was one. Craig