Re: [cobalt-developers] Peer review needed: Message board

["Matthew Nuzum" <cobalt@xxxxxxxxxxxxx>]

Thanks for your reply Jeff.  I value most of your advise  ;-)

I'll reply to your concerns below...

> Matthew Nuzum wrote:
>
> > - First time a person goes to http://<SITENAME>/bboard a folder is
created
> > in site-root that contains the images, database files, header.html,
> > footer.html (should we allow php here?) and a simple config file.
> > - Config file is plain text, VARIABLE:VALUE type file.  No PHP, so there
can
> > be no malicious code or looking at other people's database.  Default
values
> > will provide a fully functional board, but changing them will allow
better
> > integration with the site.
> > - A username/password is specified in the config file that allows
moderation
> > of posts.
>
> So anyone will end up creating a board just by going there?  Even an
> end-user wandering around?  I'm not sure this is a good idea.  The
> actual setup on a per-site basis needs to be controllable; this is a
> major fault of the Cobalt-specific installation of neomail.  We get
> around it by not telling anyone, but I really don't think that's as much
> protection from setting it up on sites we haven't sold it for as I'd
> like to see.
I heartily agree, but... enabling on a per-site basis would be very
difficult.  That means an admin panel written for the thing.  Because it
would have to get into the httpd.conf to put the alias in on a per-site
basis, that means the panel would have to be part of the cobalt admin panel.
I don't know if I have the time to delve into that.

I did think of an alternate solution, but I don't think many people would
like it, even if it is something that can be easily done.  When the pkg file
is installed, a cron job could be scheduled to do maitenance.  It could be
written to look for a "pending job" file in /home/bboard.  If the pending
job file exists, it will do what's necessary, include creating bboards for
people.


>
> > So here are my specific concerns:
> > What do you think of the virtual URL, http://<sitename>/bboard?  Any
> > concerns or suggestions?
>
> That's fine.
>
> > What do you think of the idea of creating a folder in the site root
called
> > /bboard that contains files that can be customized?  I thought it would
be
> > nice to put the database files in there so that they can use up the
site's
> > storage space.  The alternative is to store all database files in a
central
> > place.  Actually, as I write this, I may have difficulty creating a
folder
> > in the site root, due to permissions.  The webserver doesn't have write
> > permission on the site-root, does it?
>
> The biggest problem I have with site-root (as you call it) is that it
> won't get automatically moved with CMU.
>
> How about putting it inside of <web> with permissions and ownership
> that'll keep it from being readable by end-users.  For example, putting
> an empty index.html file into it keeps people from seeing it's contents.
I think you're describing what I meant.
It would go in /home/sites/siteX/web/bboard.  I could put an index file in
there, but it wouldn't be necessary.  An alias in /etc/httpd/conf/srm.conf
file would override the existing folder, so if anyone tried to go to
http://<SITE>/bboard, they would see the alias, not the real folder.

By making it readable to the user, they could actually make changes to the
look and feel themselves.  For example, they could edit the text config file
to limit the number of messages to display on the page, or the userid and
password for admin.  This would also allow them to change the colors.

Of course we could do all that with a simple little web gui.  We'll see.  It
may be a moot point.  I don't think that I can write to the web directory.

>
> > What do you think of the ability to allow PHP code in the header and
footer
> > of the page?  Probably a bad idea isn't it?  Maybe a config option can
be
> > put in that allows that feature to be selected.  Some server admins may
want
> > it, others may not.  That's probably the way to do it, and by default,
have
> > it turned off.
>
> KISS.  Keep it supremely simple <smile>.  If you're not using PHP for
> the board, I'd not allow it inside the board.
The board is written in PHP, which means inittially it'll be a Raq4 item.
Sorry.

>
> I'm installing ubb for a client now; they sell for $300 and they don't
> have any PHP ability, so why do you need it <smile>?
>
Believe me when I say that if they want UBB, you don't have to worry about
this little free-bee competing.  It's very simple.

> > Any other concerns or gotchas to suggest?
>
> If this were ready I'd be looking at it today, for my own use, and for
> clients.  When <smile>???
Maybe tomorrow, if not, then probably Wednesday.  This will be my first in
two areas:
Making an RPM from scratch and
Making a PKG from scratch.

I'm going to try to use some of Taco's work in the neomail area to speed the
process.

>
> Jeff
> --
> Jeff Lasman <jblists@xxxxxxxxxxxxx>
> Linux and Cobalt/Sun/RaQ Consulting
> nobaloney.net
> P. O. Box 52672, Riverside, CA  92517
> voice: (909) 778-9980  *  fax: (702) 548-9484

Thanks for the input.
Matt Nuzum