On Fri, Feb 11, 2005 at 03:21:49PM +0100, Julian Mehnle wrote:
> Jonas Meurer wrote:
> > [...] you'll have to install seperate instances of lurkers binary to
> > configure different htdocs (webcache) directories as well. therefore i
> > see currently no possibility to run more than one lurker instance with
> > the debian lurker package installation.
>
> Huh? Why is that? Is the web cache directory hard-coded in the Lurker
> binary? Or what do you mean with "instance"? AFAIK Lurker hasn't been
> using a daemon for quite a while, if that's what you mean (but I guess you
> knew that). Now I'm confused.
You are correct, lurker has no daemon anymore and webcache is not hard-coded.
I think what Jonas meant was that you'd have to copy /var/www/lurker to
/var/www/lurker-private to have two copies of the webcache.
If you wanted a 'dual lurker' install for public+private or multiple vhosts,
you could do:
1. make a new lurker-private.conf and point the dbdir at
/var/lib/lurker-private.
2. Add another config option to apache to invoke lurker for missing pages
in /var/www/lurker-private that passed the correct new config file and
web cache dir. (see /etc/lurker/apache.conf)
3. Add an entry to /etc/cron.d/lurker to clean up cache in the new webcache
> > the biggest problem is how to connect these two archives? do you need to
> > have access to all lists in the private area? or would you split the
> > archives without any connection?
> >
> > what about that situation: you have 5 public and 5 private lists.
> > now the first private list has 20 subscribers, second, third and fourth
> > each 30 and the fifth private list has 40 subscribers.
> >
> > remember, you need a unique account for every subscriber of every list.
> >
> > every private list would need a seperate private lurker instance here,
> > wouldn't it?
> >
> > to make it even more complicated, what about people who have access to
> > more than one private list? should they have one account for all, or one
> > account for each of the lists?
I still don't like the thought of having to add authentication to lurker...
This should be apache's job. :-(
After having had some more time to think about this and gain perspective, I
have started to converge on what I think is the right thing to do. I think
the original plan of 'mergable databases' could work. (For those not
familiar with the topic, this means to allow having multiple 'dbdir'
settings in a config file and having lurker.cgi magically combine them to
appear as a single database including all messages)
Your (Jonas') main complaint with this system was that the user has to do
too much work to configure all the different possible combinations. However,
I think as long as I hide how this works to a sufficient degree, then the
problem can be resolved.
First, allow 'dbdir' in the scope of a list configuration to override the
public (global) 'dbdir' setting. This is taken relative to the last 'dbdir'
option. Then I could include a new configuration options 'webcache' and
'frontend'.
# global/public database
dbdir = /var/lib/lurker
list = lurker-users
# stored by default into the normal 'dbdir'
list = lista
# messages to this list are stored into somewhere else:
dbdir = secreta # means: /var/lib/lurker/secreta
list = listb
dbdir = secretb
# global/public lurker webcache will be used by lurker-prune and lurker.cgi
# when no overriding option (-d or ?cfg?webcache respectively) is given.
webcache = /var/www/lurker
frontend = lista
webcache = lista # relative to global webcache
# implicitly includes the global/public dbdir too
dbdir = secreta
frontend = listb
webcache = listb
dbdir = secretb
frontend = everything
webcache = everything
dbdir = secreta
dbdir = secretb
Then, I could add some intelligence to lurker.cgi to detect which frontend
the webserver was trying to use. eg: if it was asked to generate
/var/www/lurker/lista/message/asfasfasf.html, it would determine that it
should be using the 'lista' frontend. Therefore, it would combine the two
databases in answering your requests.
I could also add support to lurker-index to create the dbdir and webcache
directories automatically when the first message is imported. The imgs and
fmt directories would be symlinked to the global webcache directory.
In order to create a new private list, the steps would be:
1. add the list entry, include a 'dbdir' option to keep it out of public
2a. add a new frontend which includes this new dbdir and possibly others
2b. ... and/or add this dbdir to existing frontends
3a. run lurker-index to import some new mail
3b. if lurker-index complains about permissions, run the commands it
suggests (chown/chmod) as root
4. edit /var/www/lurker/frontend/.htaccess to setup apache's authentication
> * It should be possible to run multiple sites (domains / Apache vhosts),
> i.e. essentially separate groups of list web archives. These may very
> well generally run from the same database, but should be able to
> appear as separate groups of lists on the different web sites.
> E.g. the cookmaster-pro-users list archive should appear on
> http://www.cookmaster-pro.com/lurker, but not on
> http://www.lawnmower-pro.com/lurker, even if everything runs on the
> same physical host.
> AFAICT this is already possible with Lurker (but how?).
Yes, this already works since v0.6, see my earlier comments.
I don't plan on streamlining this; if you run multiple vhosts, then you
really should have multiple web cache directories and config files, imo.
> * It should be possible to define separate access to each private list
> archive. If this means that users have to authenticate multiple times
> to access multiple private list archives, then so be it. I agree with
> Wesley that authentication should be handled by the web server, so
> admins can choose what auth method to use. This means that it must be
> possible for individual private list archives to be accessed from
> different, <Location(Match)>-matchable URL paths.
This can also be done by lurker v1.2 as long you don't need more than the
single private mailing list to appear in each private section. You need
multiple databases, config files, and web cache directories. The 'include'
option in the config file may prove useful.
However, if you need a more elegent solution, you will need to wait for
lurker 2.0 which will handle private lists properly (somehow). See the
middle of this email for one potential method of acheiving this.
--
Wesley W. Terpstra <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
