leafwa-devel — Development discussion for Leafwa

[Leafwa-devel] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Re: [Leafwa-devel] Leafwa permissions / Apache

[Andy P. <and...@fr...>]

Sorry for the long delay in replying - holiday was followed by job stuff
was followed by a near-disastrous upgrade to RH8.1beta on one of my
boxes over the weekend, from which I've had to spend a lot of time
recovering :-/

On Sun, 2003-02-02 at 16:22, Kevin R. Bulgrien wrote:
> 1) I like suExec less than sudo.  If anything, Apache configuration is
>    more complex than sudo.
> 
>    a) suExec documentation is not exactly crystal clear - at least to
>       those not experienced with it.
> 

I agree. I just reviewed the documentation in Apache: the Definitive
Guide and it doesn't look straightforward.

>    c) As it is now, .htaccess instructions in leafwa DID NOT work on
>       my installation.  I had to modify apache's configuration by
>       either turning on .htaccess processing, or by entering the
>       equivalent settings in the Apache configuration files.

This is almost certainly a product of my poor documentation and my
arrogant assumption that everyone runs a system like mine ;-) my
apologies though.

>       Certainly I agree that putting the .htaccess file there is
>       wise, but depending on it to enable security is the first
>       mistake.  It didn't do anything on a patched up, vanilla RedHat
>       7.2 system.

It was a first step really - to put something in place quickly. I didn't
intend that to be "the" solution.

>    If used, suExec also strikes me as being something that ties Leafwa
>    to Apache.  I don't think Leafwa should depend on what server is on
>    a system.

That's a good philosophy, I agree.

> 2) I do not want to give Apache blanket rights to a group like news.  Not
>    that this is so inherently awful, but that it is a completely
>    uncontrolled method that could one day be a circuitous course
>    into some other buggy package...

Again, agreed. It's an ugly and unnecessary solution IMHO.

>    BUT! IMPORTANT!  Is the current sudo configuration really done right?
>    When I installed leafnode by RPM, the command paths were different than
>    the sudo configuration.  We can get away from this as I'll show later.

Again, it's what exists on my system. I build the Leafnode RPM to
install in the /usr/bin prefix, I think the default may well be to
install to /usr/local/bin. Blind assumption on my part.

>    By the way, regarding objections to interweaving leafwa/leafnode too
>    tightly... um...  we have to have a better reason than that.  By
>    definition they are married.  I do see the point about hopefully
>    not having Leafwa-specific files sprinkled about in leafnode'e tree
>    though.

I've come around to this view too, don't worry :-)
I think it's important that Leafwa be an optional,
separately-installable and independent package - but it's inherently
dependent on Leafnode itself of course.

> In my opinion though, the current sudo configuration is not optimal, and
> actually requires the system operator to trust Leafwa too much.  I mean,
> what sysadmin (or developer, for that matter) would give blind and
> unthinking permission to do "rm -rf /*"?  This HAS to go.  

Yep. Access to /bin/rm is a really bad aspect of it...

So, comments on aspects of the proposed solution:

>    The leafwa group is created to allow users to be granted permission
>    to use aspects of leafwa that need to be restricted from your average
>    user.  The sysadmin can assign management to particular people by
>    using a simple and familiar method that does not require apache
>    support.

Fine. I don't see why a leafwa group shouldn't be created and I can't
see why sysadmins would object to it.

> 2) The Leafwa code could then be installed in a directory that Apache knows
>    is for a user's web pages (public_html) for simplicity albeit not prettily
>    named.   Or, Apache configuration could be done to add the user directory
>    to the main server.  There's no reason why both couldn't be documented
>    simply, such that the user picks the path easiest for him.

:-/
I'm actually quite cool on this idea, but again it's my own system which
leads me to want to install under /var/www/secure, for instance. As long
as this is documented clearly and simply I don't see why it shouldn't be
there.

>    .htaccess files could be provided to help seal off access as needed in
>    case a system has enabled this feature, but, we would really concentrate
>    on providing other solutions that don't require them... either or both
>    Apache configuration, or wrapping all .sh functionality in a way that
>    causes Apache not to spill the beans.

Also fine. It was a quick and easy way to add some level of security for
my box until something better came along. I take your point. Since the
file is already in existence we can continue to supply it as an option
for users more comfortable with that mechanism, albeit re-documenting it
and making alternative recommendations. 

Of course the other useful thing that .htaccess gives us is the ability
to tell the server not to serve up e.g. the .inc files. I think we still
need that.

> 3) sudo configuration is limited to maybe something like this:
[snip]
>    I think that running as "news" completely eliminates the need for all of
>    the other settings.  It also tells the sysadmin that Leafwa is basically
>    in the same jail that leafnode is in.

I like this. I take it that you tried it, from an earlier comment? I've
not had time to give it a test run here. Seems far simpler.

> 4) copy.sh, touch.sh, rmarticle.sh, subscribe.sh, unsubscribe.sh, and 
>    savelocalng.sh should be trivial to change into PHP functions that
>    issue the same shell commands internally 
[snip]
>    I feel that this conversion could be done in a matter of hours.

Excellent. I'd really like to move in this direction, as I already
stated.

>    purgeng.sh and purgemsg.sh are not as trivial to rewrite, but still
>    could be done.  I have to learn more about PHP before I do that
>    though.  At the least one would think I could convert the necessary
>    shell constructs the same way that I propose doing with copy.sh,
>    et. al.

OK well I'll leave this with you; I don't have any means of testing the
local newsgroups stuff yet. If we can move in the direction of "pure"
PHP, and you learn something as you go, that's all good.

> 5) The leafwa user directory (or maybe a /var derived path is really
>    more appropriate for system health and security) can then be used
>    as a sandbox to store files that help improve the safety of local
>    group functions like the purge/manage operations.  (I don't like
>    the assumptions I make in the current version.)

This still troubles me a bit. It strikes me that we ought to have a
"temp" directory for this storage *within* the directory with the PHP
files. This is how other PHP apps I have installed seem to work (well,
PHPost at least). It doesn't seem to matter where this is on the system
but the standard web server file path seems obvious. So for my system I
would still have leafwa in /var/www/secure/news (which is the https: bit
of my site; the rest is in /var/www/html) and then have a subdirectory
leafwa_temp in there for use as the sandbox.

> - We can simplify sudo configuration to the point where a pre/post
>   install scripts can facilitate or actually do sudo configuration for
>   install and uninstall operation.  The sudo setup can be a simple
>   one-liner!

This is a great idea.
An install or "prepare" script of some sort would be nice.

> - The simplification will also improve security to the rest of the
>   system by taking away unrestricted rm, cp, and chmod rights.  (This
>   is a HUGE GAPING HOLE as far as I am concerned!)

You're absolutely right and I've always felt that this was the case :-(

> With no objections, I have the technology to make it happen in fairly
> short order.

You've got my full support. Not sure I'll have huge amounts of time to
spend immediately myself, but I'll try to follow through as soon as I
can.

Thanks for all of your thought and hard work so far - much appreciated!

Andy

-- 
Andy Piper - Farnborough, Hampshire (UK)
and...@fr...
http://www.andypiper.co.uk/

Re: [Leafwa-devel] Leafwa permissions / Apache

[Kevin R. B. <kbu...@wo...>]

After some thought, I've come up with some thoughts on the options I
listed earlier.

1) I like suExec less than sudo.  If anything, Apache configuration is
   more complex than sudo.

   a) suExec documentation is not exactly crystal clear - at least to
      those not experienced with it.

   b) Messing with the various contortions of httpd.conf, etc., ad
      nauseum, would be far outside the scope of the leafwa project.
      It is evident that not everyone thinks these files should be
      named the same thing on every machine - or at least that they
      think their name is the right one.  (Apache configuration, per
      current documentation, should be in one file, but history was
      that they were separate.  Mandrake, at least, has gone from=20
      merging everything into a file called commonhttpd.conf.  Ugh!)

   c) As it is now, .htaccess instructions in leafwa DID NOT work on
      my installation.  I had to modify apache's configuration by
      either turning on .htaccess processing, or by entering the
      equivalent settings in the Apache configuration files.  Also,
      Apache documentation specifically discourages the use of
      .htaccess processing because of the burden it places on the
      web server - greater than just reading one file each time
      the directory is accessed.

      Certainly I agree that putting the .htaccess file there is
      wise, but depending on it to enable security is the first
      mistake.  It didn't do anything on a patched up, vanilla RedHat
      7.2 system.

   I now tend to think of suExec as being a distraction.  It is really
   more for keeping user CGI scripts in jail, or so it seems.  I would
   have thought it would have been better to allow the server to be
   configured to run scripts in certain <DIRECTORY></DIRECTORY>
   structures as a particular user...  But maybe I am missing
   something.

   If used, suExec also strikes me as being something that ties Leafwa
   to Apache.  I don't think Leafwa should depend on what server is on
   a system.

2) I do not want to give Apache blanket rights to a group like news.  Not
   that this is so inherently awful, but that it is a completely
   uncontrolled method that could one day be a circuitous course
   into some other buggy package...

3) I don't know what I was thinking on that one except that maybe that
   is what we do now.

   BUT! IMPORTANT!  Is the current sudo configuration really done right?
   When I installed leafnode by RPM, the command paths were different than
   the sudo configuration.  We can get away from this as I'll show later.

4) sudo su -l news works!  My proposed solution outline below includes
   this construct.

5) The leaf.wa directory idea doesn't get to the root of the permissions
   issue. (Nevertheless it does provide something else we probably need.
   I'll get to that later, but /var/spool/news isn't where this directory
   would have to go.)

   By the way, regarding objections to interweaving leafwa/leafnode too
   tightly... um...  we have to have a better reason than that.  By
   definition they are married.  I do see the point about hopefully
   not having Leafwa-specific files sprinkled about in leafnode'e tree
   though.

6) The user shouldn't have to arbitrate between leafnode and leafwa projects
   that are in flux.

We are dealing with a permissions problem, therefore we need some good
way of dealing with it.  Though I don't really see a huge problem with
leafnode relaxing permissions on group rights by adding write access to
the group "news", I also see this lack of access as a means by which the
news software protects its sensitive data - you have to do something
conscious to make buggy users or software break it, and conscious thing
is asking for permission to override the write protection... sudo does
that in a relatively clean manner.

In my opinion though, the current sudo configuration is not optimal, and
actually requires the system operator to trust Leafwa too much.  I mean,
what sysadmin (or developer, for that matter) would give blind and
unthinking permission to do "rm -rf /*"?  This HAS to go. =20

What I have come up with seems to be a balanced solution:

1) The leafwa installation requires the addition of a leafwa user and=20
   group.  The leafwa user is given a home directory.  Whether this is
   /home/leafwa or /usr/local/blah is immaterial.  The leafwa files are
   all placed under here for simple installation and removal.

   The leafwa group is created to allow users to be granted permission
   to use aspects of leafwa that need to be restricted from your average
   user.  The sysadmin can assign management to particular people by
   using a simple and familiar method that does not require apache
   support.

   I envision the code Leafwa files being owned by apache:leafwa but I
   haven't followed that line of thinking down to the end.  It could be
   leafwa:apache, and the leafwa group is uneccessary, except that I
   have a feeling the group could be used to advantage.

2) The Leafwa code could then be installed in a directory that Apache knows
   is for a user's web pages (public_html) for simplicity albeit not=
 prettily
   named.   Or, Apache configuration could be done to add the user directory
   to the main server.  There's no reason why both couldn't be documented
   simply, such that the user picks the path easiest for him.

   .htaccess files could be provided to help seal off access as needed in
   case a system has enabled this feature, but, we would really concentrate
   on providing other solutions that don't require them... either or both
   Apache configuration, or wrapping all .sh functionality in a way that
   causes Apache not to spill the beans.

3) sudo configuration is limited to maybe something like this:

     # User alias specification
     Runas_Alias LEAFNODE =3D news

     # Cmnd alias specification
     Cmnd_Alias  NEWS =3D su -l news

     # User privilege specification
     apache      ALL=3D(LEAFNODE) NOPASSWD: NEWS

   I think that running as "news" completely eliminates the need for all of
   the other settings.  It also tells the sysadmin that Leafwa is basically
   in the same jail that leafnode is in.

4) copy.sh, touch.sh, rmarticle.sh, subscribe.sh, unsubscribe.sh, and=20
   savelocalng.sh should be trivial to change into PHP functions that
   issue the same shell commands internally via constructs offered by

   escapeshellarg =97 escape a string to be used as a shell argument
   escapeshellcmd =97 escape shell metacharacters
   exec =97 Execute an external program
   passthru =97 Execute an external program and display raw output
   system =97 Execute an external program and display output

   I feel that this conversion could be done in a matter of hours.

   purgeng.sh and purgemsg.sh are not as trivial to rewrite, but still
   could be done.  I have to learn more about PHP before I do that
   though.  At the least one would think I could convert the necessary
   shell constructs the same way that I propose doing with copy.sh,
   et. al.
  =20
5) The leafwa user directory (or maybe a /var derived path is really
   more appropriate for system health and security) can then be used
   as a sandbox to store files that help improve the safety of local
   group functions like the purge/manage operations.  (I don't like
   the assumptions I make in the current version.)

I think that this proposal covers the permissions issues, simplifies
leafwa setup, and improves security all at the same time.

- sudo is an accepted tool for granting exceptions to standard
  permissions.

- We can simplify sudo configuration to the point where a pre/post
  install scripts can facilitate or actually do sudo configuration for
  install and uninstall operation.  The sudo setup can be a simple
  one-liner!

- The simplification will also improve security to the rest of the
  system by taking away unrestricted rm, cp, and chmod rights.  (This
  is a HUGE GAPING HOLE as far as I am concerned!)

- We don't mess with the web-server arcane setup issues, nor do we make
  Leafwa depend upon a particular server or version of a server.

Well, as long-winded as this is, I may have missed some of my more subtle
thoughts, but, I'll throw this out for consideration.

What do/don't you like about it?

With no objections, I have the technology to make it happen in fairly
short order.

Kevin R. Bulgrien

Re: [Leafwa-devel] Leafwa permissions / Apache

[Kevin R. B. <kbu...@wo...>]

At 03:29 AM 1/31/03, Andy Piper wrote:

>Kevin wrote: 
>> 
>> 1) I've read a bit about suExec in Apache? 
>
>I actually know nothing about this and ought to do some research on it. 
> From your description, it sounds the best option AFAICT, but I want to 
>check it out first.
>
>Does it work the same way in both Apache 1.x and 2.x?
>
>> Even though Apache docs say it isn't on by default,
>> Mandrake, at least, does have suExec enabled in the distribution.  Is
>> this common amongst others also?
>
>I'll check RedHat as soon as I get back from my travels.
>
>> 5) Create /var/spool/news/leaf.wa and copy files there to work on them.
>
>Don't like this one: it causes Leafwa to become more closely interwoven 
>with Leafnode itself, and would be a problem for people (like me) who 
>install Leafnode from RPMs or other packaging system where it interferes 
>with the installed directory hierarchy.

/var/spool/news is the home directory of the news user... at least
the way my system is set up.  For suExec, I think it would be required to
use the home directory of the news user for Leafwa... but I'd have to do
more research.

I'm not sure that I have a problem with /var/spool/news, but I guess I see
your point.  The way leafwa is right now though, it dabbles in this area
anyway.

Something else then...  Make a leafwa user that can use suExec.  The leafwa
user might be a member of group news.  The way leafnode installs, sudo is
still required to write, but reads would work ok.

Note that the way I read things, suExec would require that the php scripts
be in the users "public_html" area.

Re: [Leafwa-devel] Leafwa permissions / Apache

[<and...@fr...>]

Kevin wrote: 
> I've been digging a bit into permissions problems between leafwa and
> leafnode...  With a bit of thought, I've come up with a few ways that
> things could be worked out.
> 
> We currently use sudo to acquire permission to do things with leafwa.
> (I'd rather not have to, and it has limitations right now.  sudo doesn't
> let PHP fopen commands get access to secured areas.)

I agree that we shouldn't use sudo if we can avoid it. I'd really like to 
rewrite the parts of Leafwa that are currently in shell in pure PHP, too. 
It's easily a powerful enough language to do the things we need without 
shelling out.
 
> Anyway, here are some of the ideas for ways of overcoming the problems
> with Leafwa not having permission to look at or work with leafnode's
> files:
> 
> 1) I've read a bit about suExec in Apache? 

I actually know nothing about this and ought to do some research on it. 
From your description, it sounds the best option AFAICT, but I want to 
check it out first.

Does it work the same way in both Apache 1.x and 2.x?

> Even though Apache docs say it isn't on by default,
> Mandrake, at least, does have suExec enabled in the distribution.  Is
> this common amongst others also?

I'll check RedHat as soon as I get back from my travels.

> 2) Another alternative might be to make apache a member of the
> group news?

I came up with a grave concern about this at one stage, but the rationale 
behind it has been forgotten for now - it's an option.

> 5) Create /var/spool/news/leaf.wa and copy files there to work on them.

Don't like this one: it causes Leafwa to become more closely interwoven 
with Leafnode itself, and would be a problem for people (like me) who 
install Leafnode from RPMs or other packaging system where it interferes 
with the installed directory hierarchy.

> 6) Just make the user decide how to give apache access to the
> /var/spool/news directory trees.  I imagine better documentation
> should be generated on this one.  I tend not to like it though.

Definitely not. My goal is to make Leafwa easy and secure to install and 
this would introduce too much of an element of user error, IMO.

Thanks for all of your contributions, they are extremely useful - I'll 
look into the issues in more detail when I get back.

-- 
Andy Piper - Farnborough, Hampshire (UK)
and...@fr...
http://www.andypiper.co.uk/

[Leafwa-devel] Leafwa permissions / Apache

[Kevin R. B. <kbu...@wo...>]

I've been digging a bit into permissions problems between leafwa and
leafnode...  With a bit of thought, I've come up with a few ways that
things could be worked out.

We currently use sudo to acquire permission to do things with leafwa.
(I'd rather not have to, and it has limitations right now.  sudo doesn't
let PHP fopen commands get access to secured areas.)

Anyway, here are some of the ideas for ways of overcoming the problems
with Leafwa not having permission to look at or work with leafnode's
files:

1)

I've read a bit about suExec in Apache?  Might it not be far easier to
simply install leafwa in a public_html directory in a home directory for
the user news?  suExec seems to only work with EITHER virtual hosts or
user directories.  I think virtual host setup is not desireable for
Leafwa users as it looks pretty complicated, but, I think suExec might
not be too bad.  Even though Apache docs say it isn't on by default, 
Mandrake, at least, does have suExec enabled in the distribution.  Is 
this common amongst others also?

If so, then we can have Apache just become the news user while running
Leafwa scripts.  Granted, we need to still be careful what is done, but
this seemingly would remove all permission problems with one fell swoop.

Leafwa users would browse to:
 
  http://my.server.com/~news/leafwa/leafwa.php

or something like that...

Is this a dumb idea?

2) 

Another alternative might be to make apache a member of the group news?
I feel more skeptical about this even though it is one of the easier
solutions.  On one hand it doesn't sound too bad, but then again, it is
a bigger opening in the system than might be advisable.  This still
doesn't address the lack of group permissions in parts of the
/var/spool/news tree either, so whereas suExec might be a complete
solution, this one would still require a bit more configuration.
This won't work with some older leafnode's probably, because leafnode
reassigned permissions to stricter settings for some builds.  I believe
that current/recent leafnode versions do not reset permissions on the
files after the initial installation.

Well, anyway... I want to keep on this while it is fresh.

3)

Sudo could be used to automatically give apache access when needed.
When the script knows it needs access, it could force access.  Not
pretty, but would also work.

4)

Have leafwa sudo su news itself.  I haven't tested it.  Hmm.  I'll
have to try that one out.

5)

Create /var/spool/news/leaf.wa and copy files there to work on them.
The existing sudo access would allow copying edits back into the
directories where apache doesn't have access.

6)

Just make the user decide how to give apache access to the 
/var/spool/news directory trees.  I imagine better documentation
should be generated on this one.  I tend not to like it though.

Thoughts?  Have I missed any important items?

I'm open to having some more learned observations on how to handle this
in as secure a manner as possible.

Re: [Leafwa-devel] Patch for leafwa 01/24/2003 CVS image

[Andy P. <and...@fr...>]

On Sun, 2003-01-26 at 01:34, Kevin R. Bulgrien wrote:
> Here is a patch to apply against the 01/24/2003 image of leafwa
> that is in CVS.  It primarily repairs local group functionality
> so that leafnode versions 2.0b8_ma8 and newer function properly.

Applied, with a couple of very minor changes just to use the CSS styles
in a few places (my aim is never to use FONT and B tags - this makes
"themeability" easier in the future if anyone wants to change the format
and so on).

I don't think I've broken anything! Please let me know if you can see
any problems.


-- 
Andy Piper - Farnborough, Hampshire (UK)
and...@fr...
http://www.andypiper.co.uk/

RE: [Leafwa-devel] Patch for leafwa 01/24/2003 CVS image

[Andy P. <and...@fr...>]

On Sun, 2003-01-26 at 18:10, Jeff Grossman wrote:
> I have the following versions available:
[snip]

Perfect. Thanks. I'll add them somewhere on the Leafwa website the next
time I do an update.


-- 
Andy Piper - Farnborough, Hampshire (UK)
and...@fr...
http://www.andypiper.co.uk/

RE: [Leafwa-devel] Patch for leafwa 01/24/2003 CVS image

[Jeff G. <je...@st...>]

I have the following versions available:

0.0.1
0.1.0
0.2.0
0.3.1
0.4.2
0.4.3
0.6.1

They are all available from ftp://ftp.stikman.com/pub/leafnode/.

Jeff

-- 
Jeff Grossman (je...@st...)

> -----Original Message-----
> From: lea...@li... [mailto:leafwa-devel-
> ad...@li...] On Behalf Of Andy Piper
> Sent: Sunday, January 26, 2003 9:46 AM
> To: Leafwa Mailing List
> Subject: Re: [Leafwa-devel] Patch for leafwa 01/24/2003 CVS image
> 
> On Sun, 2003-01-26 at 01:49, Kevin R. Bulgrien wrote:
> > Phil, you can add this to the ChangeLog / TODO files when you put
> > the stuff up in CVS...
> 
> Well, I will :-)
> 
> Point of fact, Phil Hunt's original website is now completely gone (it
> was still there back in October when I released 0.7.0 and tried to get
> permission from him to re-open the project). I'd be delighted to hear
> from him if he's still around anywhere, but all of my efforts to contact
> him have failed.
> 
> I need to update the website and various links to reflect the fact that
> the original website is now gone. If anyone has any historical tarballs
> of leafwa ( <=0.6.1) I'll host them on the new site for nostalgia
> purposes.
> 
> 
> --
> Andy Piper - Farnborough, Hampshire (UK)
> and...@fr...
> http://www.andypiper.co.uk/
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Leafwa-devel mailing list
> Lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leafwa-devel

Re: [Leafwa-devel] Patch for leafwa 01/24/2003 CVS image

[Andy P. <and...@fr...>]

On Sun, 2003-01-26 at 01:49, Kevin R. Bulgrien wrote:
> Phil, you can add this to the ChangeLog / TODO files when you put
> the stuff up in CVS...

Well, I will :-)

Point of fact, Phil Hunt's original website is now completely gone (it
was still there back in October when I released 0.7.0 and tried to get
permission from him to re-open the project). I'd be delighted to hear
from him if he's still around anywhere, but all of my efforts to contact
him have failed.

I need to update the website and various links to reflect the fact that
the original website is now gone. If anyone has any historical tarballs
of leafwa ( <=0.6.1) I'll host them on the new site for nostalgia
purposes.


-- 
Andy Piper - Farnborough, Hampshire (UK)
and...@fr...
http://www.andypiper.co.uk/

Re: [Leafwa-devel] cvsignore entries

[Andy P. <and...@fr...>]

On Sun, 2003-01-26 at 17:25, Kevin R. Bulgrien wrote:
> If its all the same to you, would you mind adding cvsignore to the
> CVSROOT directory with the following contents:
> 
>   *~
>   patch.diff
> 
> I edit with VIM, and it sticks the *~ files out there as backup
> copies.

Done, along with entries for .htaccess and msgids.ser. Let me know if we
need to cover any other temporary files. I work with two leafwa trees
(one for testing, one for checkin) so I don't generally get my "live"
temporary files in my local CVS copy.

-- 
Andy Piper - Farnborough, Hampshire (UK)
and...@fr...
http://www.andypiper.co.uk/

[Leafwa-devel] cvsignore entries

[Kevin R. B. <kbu...@wo...>]

Andy,

If its all the same to you, would you mind adding cvsignore to the
CVSROOT directory with the following contents:

  *~
  patch.diff

I edit with VIM, and it sticks the *~ files out there as backup
copies.

Re: [Leafwa-devel] Patch for leafwa 01/24/2003 CVS image

[Kevin R. B. <kbu...@wo...>]

At 07:34 PM 1/25/03, you wrote:

>Here is a patch to apply against the 01/24/2003 image of leafwa
>that is in CVS.  It primarily repairs local group functionality
>so that leafnode versions 2.0b8_ma8 and newer function properly.
>The patch set has been tested against the current development
>snapshot of leafnode 2.0b (leafnode-2.0.0.alpha20021229a).

This patch may not address all news spool permissions issues for
the "manage" function, which was not touched in this round of
edits.  I did not recall this being a problem with the last
version of leafnode I had working with it (sometime prior
to 2.0b_ma8), so possibly something in leafnode has changed
since then.  I suspect manageng.php will have to use sudo to
gain read permissions on the directory tree.  I'll check into
this next.

Local groups are added properly, but do not necessarily have file
modes set such that leafwa's manageng.php can read the news group
structure ("cannot stat" error messages appear).

Phil, you can add this to the ChangeLog / TODO files when you put
the stuff up in CVS...

Kevin R. Bulgrien

[Leafwa-devel] Patch for leafwa 01/24/2003 CVS image

[Kevin R. B. <kbu...@wo...>]

Here is a patch to apply against the 01/24/2003 image of leafwa
that is in CVS.  It primarily repairs local group functionality
so that leafnode versions 2.0b8_ma8 and newer function properly.
The patch set has been tested against the current development
snapshot of leafnode 2.0b (leafnode-2.0.0.alpha20021229a).

The patch file was generated with cvs diff -u

The new ChangeLog entries are:

2003-01-25      Kevin R. Bulgrien       <kbu...@wo...>
* Changed my e-mail address in credits.php
* Generated help text content in h_localng.htm
* Improved the description of purgeng.sh in helpdevelop.html
* Enhanced localng.php so that it is able to properly add new local groups for
  leafnode 2.08b_ma8 and later.  The format of leafnode's local.groups file
  changed.  At this time, localng.php requires manual configuration of the
  local.groups file.  This is done via $localNgFormat in settings.inc.  Some
  computed constants ($localNgFields, $localNgDRegEx, and $localNgDelimiter)
  were added to make the new code more abstract.
* Changed localng.php's command processing code to a switch statement, and 
  added handling for unexpected command values.
* Fixed some spelling and punctuation in localng.php
* Re-added table formatting for the list of local groups. PH didn't care for
  it and nuked the earlier code.  With a large list of local groups, the table
  doesn't render as fast as a straight list.  The problem is, readability is
  bad without ordered columns.  This time I got smart and added a constant
  to localng.php called $localNgTable that can be set to 0 to disable the
  table formatting.  I don't care if he doesn't like it, I use it all the
  time, ergo, other people will too.
* Modified localng.php's local group listing to properly handle the different
  number of fields in leafnode's local.groups file - according the the version
  in use.
* Corrected the sorting of local.groups by adding case-insensitivity flags to
  the sort command in localng.php.
* To support leafnode 2.0b_ma8 and higher, the "Create new local group:" form
  was updated to add a "Status" field when localNgFormat indicates that a new
  version of leafnode is in use.  The dialog is not really necessary, but was
  added to allow Leafwa to be prepared to support moderated local groups.
* Added the variable $localNgFormat to settings.inc to support code that
  requires knowledge about the format of leafnode's local.groups file.  It is
  hoped that in the future, this setting will be automatically determined.
* Addedit instructions for $localNgFormat in h_viewset.html
* Updated viewsettings.php to accomodate $localNgFormat.
* Added items to the TODO document.
* Updated docs/settings.inc.default.
* KNOWN ISSUE: View Queued News does not seem to work with the latest
  leafnode snapshot.  It looks like newsq's output is not being parsed
  properly.

[Leafwa-devel] Minor updates

[Andy P. <and...@fr...>]

After a period of inactivity, I've begun some incremental updates to
Leafwa.

The first change is that it's actually in CVS at SourceForge :-)

I've made a few very small changes so far. The first is to use
leafnode-version to detect which version of Leafnode is actually on the
system - if it can't be executed, it is assumed that a pre-1.9.28
version is installed, or that there's a problem with the installation.
Now that I've moved in this direction, we can think about a slight fork
to enable 2.0 features to be hidden from 1.9.x administrators.

I've also added a docs/HACKING file detailing how I'd like to receive
patches, and started to add some common installation problems into the
installation help.

I'm still considering whether to upgrade my own system to 2.0 - once I
do so, the 1.9.x functionality in leafwa will probably become
effectively frozen. Are there any leafwa users who want me to continue
to enhance the 1.9.x features (is anyone reading this list?!)



-- 
Andy Piper - Farnborough, Hampshire (UK)
and...@fr...
http://www.andypiper.co.uk/

[Leafwa-devel] RE: Leafwa on SourceForge

[Kevin R. B. <kbu...@wo...>]

Ok, my bad.  I changed server configurations since my last use of
Leafwa, and so I made some assumptions I should not have made. 
This was a case of my not reading the installation help.  Sorry
about causing confusion.

The PHP configuration was not set to use short tags.  After turning
short tags on, leafwa at least appears to function with the version
2 strain of leafnode.  

Local group support is still definitely broken for 2.0b8_ma8 and
later.  Trust me on this one.  The local group code does not handle
the new format for the local.groups file.  I'm working on fixing 
this now.

I'll report more as I find it, but hopefully I can just patch the
local group stuff up in fairly short order.

Kevin R. Bulgrien

> I previously wrote:
> > leafwa.php in CVS is broken.
> 

[Leafwa-devel] RE: Leafwa on SourceForge

[<and...@fr...>]

You wrote:
> leafwa.php in CVS is broken.

Hmm. Well it should *definitely* work with the 1.9.x series, I've 
*never* tested with with 2.0 and had no feedback since my initial 
release in October.

> It almost looks like getNewsqDepthStr in funlib.inc is screwing up, but I
> don't get why the ?> is showing up...

You're almost certainly right. That's completely dependent on the 
output of newsq and the output is very different in 2.x from what 
I can tell from what you've posted :-(
As you say, it's not clear why the PHP tags are showing up.

> Do you mind taking a bit of time to help me get
> a clue about what might be going on?

I think you've hit it right on the head, at first glance.
The answer is simply that I have to upgrade. I may have a 
strategy that will enable me to continue to maintain and 
test a 1.x version but if that falls through I'll just have 
to abandon compatibility. My original plan was to have a 
flag which checked the major version of Leafnode (which is 
why I persuaded Matthias to back-port leafnode-version to 
1.x) and then enabled different functionality depending on 
that. I'll think more about how this can be done.

> It might have to do with newsq's output not being the same as your
> version?

Basically this functionality needs enhancement. In 1.9.x you 
get a simple readout of all the articles waiting to go 
upstream; in 2.0 you get much more. I should think about how 
this can be obtained and represented.

There are bigger problems too - posted in the mailing list a 
couple of months ago - to do with the way local editing is 
allowed in the current version of leafwa.

> Oh, do you want this stuff on the mailing list?

Probably worthwhile - it will give us a good reference if 
people ever want to go back and look at discussions. I'll 
cc: this there.


-- 
Andy Piper - Farnborough, Hampshire (UK)
and...@fr...
http://www.andypiper.co.uk/