From cfreemesser at mail.cvs.rochester.edu  Tue Mar  8 15:12:02 2016
From: cfreemesser at mail.cvs.rochester.edu (Chris Freemesser)
Date: Tue, 8 Mar 2016 15:12:02 -0500
Subject: [Moin-user] Wiki server ignoring ACLs
Message-ID: <56DF3212.9040608@mail.cvs.rochester.edu>

Hi all.

I just finished migrating our wikis to a new server and am pulling my hair out 
trying to figure out a bizarre problem:  the new server is ignoring some of the 
ACLs for no apparent reason.

Our old server ran MoinMoin 1.9.3 on a Mac running OSX 10.6.x.  We have half a 
dozen wiki instances...each was configured with its own 'wikiconfig.py' file, 
located within that wiki's instance directory.  No 'farmconfig.py' file was 
used.  ACLs on the old server worked fine.

The new server is running Moinmoin 1.9.8 using the Turnkey Linux MoinMoin 
distribution.  I got the server set up and eventually copied over 5 of the 
existing wikis.

The instance directory for each wiki was placed in /var/www/moin.

A cache folder for each wiki was created in /var/lib/moin/cache.

This new server stores all of the "wikiconfig.py" files in the /etc/moin 
directory.  The ones from the old server didn't seem to work, so I made copies 
of the "mywiki.py" file that came with the new server and modified them 
as-needed for each of my wiki instances.  The files were saved with the name 
"<WikiInstanceName>.py", per the instructions.  Each .py file has an 
"acl_rights_before" line that gives my account full access, and an 
"acl_rights_default" line that gives the wiki's group full access AND read 
access for "All".

I performed a "maint cleancache" and "migration data" command on each wiki when 
I moved the data to the new server, and went to great lengths to ensure that 
file permissions were set correctly in the various locations.

The end result of all this work is that all of the wikis work, all pages are 
viewable, and I can edit them with MY account.  However, the 
"acl_rights_default" line as well as any #acl line in a wiki page are 
apparently being completely ignored.  The "acl_rights_before" line is obeyed 
though.

For example, one page in the wiki should not be viewable by "All", so I add the 
line "#acl All:" as the first line in the page to deny access.  Worked fine on 
the old server, but the new server ignores it and still allows a non-logged in 
user to see the page.

This happens with ALL of my wiki instances.

I have NO idea why the new server obeys the "acl_rights_before" line, but not 
the others.  I've gone over the wikis' config files numerous times and can't 
find an obvious mistake.  The config files are all based on the same original, 
so it could be an issue in them, or it could be a system-wide setting someplace.

Would anybody have any idea what the problem is?  Other than this, the new 
server seems to work just fine.

TIA for any help you can provide!

Chris

_____________________________________________
Chris Freemesser, Systems Administrator
University of Rochester
Department of Brain and Cognitive Sciences
The Center for Visual Science
Meliora Hall, Room 255
Phone:  (585)275-0786
_____________________________________________



From cfreemesser at mail.cvs.rochester.edu  Wed Mar  9 15:46:08 2016
From: cfreemesser at mail.cvs.rochester.edu (Chris Freemesser)
Date: Wed, 9 Mar 2016 15:46:08 -0500
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <56DF3212.9040608@mail.cvs.rochester.edu>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
Message-ID: <56E08B90.6050406@mail.cvs.rochester.edu>

Just a follow-up on my e-mail from yesterday about this weird ACL problem I'm 
experiencing.  I did some testing today to get a better understanding of what's 
going on.

=======
For the purposes of explaining all this:

WikiAdministrator is the admin/superuser for the wiki.

WikiGroup is the list of users with full admin rights to the wiki.

WikiUser is a user account that's a member of WikiGroup.
=======

If I add WikiAdministrator to the "acl_rights_before" line in the config file, 
the rights are recognized by the wiki pages.

If I add WikiAdministrator AND WikiGroup to the "acl_rights_before" line in the 
config file, the rights for each are recognized by the wiki pages.

So, the "acl_rights_before" line appears to work correctly.

If I add *anything* or *anybody* to the "acl_rights_default" line in the config 
file, *none* of the rights are recognized by the wiki pages.

So, the "acl_rights_default" line doesn't work at all.

For the next test, I added WikiAdministrator to the "acl_rights_before" line, 
and commented out the "acl_rights_default" line.

I then add an #acl line on a wiki page.  If I set the line to "All:" or 
"All:read", both settings function as intended.

If I add WikiUser to the #acl line, any rights I give that user (read, write, 
etc.) function as intended.

However, if I change the #acl line to only include WikiGroup, any rights 
assigned to WikiGroup are ignored.

So, the rights assigned via the #acl line work only for ALL or a USER, not for 
a GROUP.

Any thoughts as to why this may be happening?

Thanks,

Chris


_____________________________________________
Chris Freemesser, Systems Administrator
University of Rochester
Department of Brain and Cognitive Sciences
The Center for Visual Science
Meliora Hall, Room 255
Phone:  (585)275-0786
_____________________________________________



From paul at boddie.org.uk  Wed Mar  9 16:25:32 2016
From: paul at boddie.org.uk (Paul Boddie)
Date: Wed, 9 Mar 2016 22:25:32 +0100
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <56E08B90.6050406@mail.cvs.rochester.edu>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
	<56E08B90.6050406@mail.cvs.rochester.edu>
Message-ID: <201603092225.32793.paul@boddie.org.uk>

On Wednesday 9. March 2016 21.46.08 Chris Freemesser wrote:
> 
> If I add *anything* or *anybody* to the "acl_rights_default" line in the
> config file, *none* of the rights are recognized by the wiki pages.
> 
> So, the "acl_rights_default" line doesn't work at all.

Maybe someone will reply to your mail, but looking at the MoinMoin.security 
module, the acl_rights_default setting does appear to be influenced by the 
cache. Although you've run the maintenance commands to clean that, it might 
still be interesting to try adding the "Default" keyword to an explicit ACL, 
just to see what happens.

Also, I'd be tempted to add some debugging statements to the 
AccessControlList.may method; something like...

print >>open("/tmp/debug.txt", "a"), repr(acl)

...after the acl variable has been initialised. If anything, it would help 
check the data involved.

> For the next test, I added WikiAdministrator to the "acl_rights_before"
> line, and commented out the "acl_rights_default" line.
> 
> I then add an #acl line on a wiki page.  If I set the line to "All:" or
> "All:read", both settings function as intended.
> 
> If I add WikiUser to the #acl line, any rights I give that user (read,
> write, etc.) function as intended.
> 
> However, if I change the #acl line to only include WikiGroup, any rights
> assigned to WikiGroup are ignored.
> 
> So, the rights assigned via the #acl line work only for ALL or a USER, not
> for a GROUP.
> 
> Any thoughts as to why this may be happening?

The one thing that came to mind was the page_group_regex setting, which should 
be set to a sensible default. I presume that the format of your group pages is 
still correct, too. Again, some tracing in the AccessControlList.may method 
might indicate whether the groups are being recognised...

print >>open("/tmp/debug.txt", "a"), repr(groups)

...and so on.

Unfortunately, Moin isn't the friendliest thing to interactively test, just to 
see if the basics are functioning, but printing stuff out to a temporary file 
and seeing what is happening tends to provide a few answers.

Paul



From cfreemesser at mail.cvs.rochester.edu  Thu Mar 10 10:31:39 2016
From: cfreemesser at mail.cvs.rochester.edu (Chris Freemesser)
Date: Thu, 10 Mar 2016 10:31:39 -0500
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <201603092225.32793.paul@boddie.org.uk>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
	<56E08B90.6050406@mail.cvs.rochester.edu>
	<201603092225.32793.paul@boddie.org.uk>
Message-ID: <56E1935B.1070907@mail.cvs.rochester.edu>

On 3/9/16 4:25 PM, Paul Boddie wrote:

> Maybe someone will reply to your mail, but looking at the MoinMoin.security
> module, the acl_rights_default setting does appear to be influenced by the
> cache. Although you've run the maintenance commands to clean that, it might
> still be interesting to try adding the "Default" keyword to an explicit ACL,
> just to see what happens.

Thank you for the reply and the suggestion.  Changing the #acl line to 
"Default" does work, but only partially.

If I change the "acl_rights_default" line to this...

acl_rights_default = u"WikiGroup:read,write,delete,revert,admin All:read"

...and set the #acl line to this:

#acl Default

Then the rights are properly applied.  Also, changes made to the 
"acl_rights_default" line work correctly.  For example, if I disable read 
rights for either "WikiGroup" or "All" in this line, they then can't read the page.

However, if I change the #acl line in the page to this:

#acl Default -All:read

or

#acl Default All:

These changes to All's rights are NOT recognized...they can still read the 
page.  Similarly, if I give All zero rights in the "acl_rights_default" line 
and try to then give them read right in the #acl line, that doesn't work either.

However, if I remove "All" from the "acl_rights_default" line completely and 
assign rights in the #acl line, that works.

> Also, I'd be tempted to add some debugging statements to the
> AccessControlList.may method; something like...
>
> print >>open("/tmp/debug.txt", "a"), repr(acl)
>
> ...after the acl variable has been initialised. If anything, it would help
> check the data involved.

I have to admit that my programming skills are essentially non-existent.  If 
what you suggest requires me to edit a specific file and add that line, I'm 
afraid I need more explicit instructions as to which file this is.

> The one thing that came to mind was the page_group_regex setting, which should
> be set to a sensible default. I presume that the format of your group pages is
> still correct, too.

I've not changed the "page_group_regex" line in the wiki's config.py file from 
its default, and the WikiGroup page was not changed at all (worked fine on the 
old server).  I did try creating a different Group page, but it didn't make a 
difference.

Thanks,

Chris

_____________________________________________
Chris Freemesser, Systems Administrator
University of Rochester
Department of Brain and Cognitive Sciences
The Center for Visual Science
Meliora Hall, Room 255
Phone:  (585)275-0786
_____________________________________________



From paul at boddie.org.uk  Thu Mar 10 12:38:22 2016
From: paul at boddie.org.uk (Paul Boddie)
Date: Thu, 10 Mar 2016 18:38:22 +0100
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <56E1935B.1070907@mail.cvs.rochester.edu>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
	<201603092225.32793.paul@boddie.org.uk>
	<56E1935B.1070907@mail.cvs.rochester.edu>
Message-ID: <201603101838.23219.paul@boddie.org.uk>

On Thursday 10. March 2016 16.31.39 Chris Freemesser wrote:
> On 3/9/16 4:25 PM, Paul Boddie wrote:
> > Maybe someone will reply to your mail, but looking at the
> > MoinMoin.security module, the acl_rights_default setting does appear to
> > be influenced by the cache. Although you've run the maintenance commands
> > to clean that, it might still be interesting to try adding the "Default"
> > keyword to an explicit ACL, just to see what happens.
> 
> Thank you for the reply and the suggestion.  Changing the #acl line to
> "Default" does work, but only partially.

Note that this was really only for diagnostic purposes. You shouldn't need to 
apply "Default" explicitly unless there's a page-specific ACL that would make 
use of it. We're hoping to not have to use it eventually here, but for the 
moment it helps to rule out certain problems.

> If I change the "acl_rights_default" line to this...
> 
> acl_rights_default = u"WikiGroup:read,write,delete,revert,admin All:read"
> 
> ...and set the #acl line to this:
> 
> #acl Default
> 
> Then the rights are properly applied.  Also, changes made to the
> "acl_rights_default" line work correctly.  For example, if I disable read
> rights for either "WikiGroup" or "All" in this line, they then can't read
> the page.

So it looks like the default ACL is being used, at least if it is explicitly 
set in the page ACL.

> However, if I change the #acl line in the page to this:
> 
> #acl Default -All:read
> 
> or
> 
> #acl Default All:
> 
> These changes to All's rights are NOT recognized...they can still read the
> page.  Similarly, if I give All zero rights in the "acl_rights_default"
> line and try to then give them read right in the #acl line, that doesn't
> work either.
> 
> However, if I remove "All" from the "acl_rights_default" line completely
> and assign rights in the #acl line, that works.

The Moin documentation isn't as clear as it should be about all this. With 
this...

acl_rights_default = u"WikiGroup:read,write,delete,revert,admin All:read"
#acl Default -All:read

...what the documentation says should happen is that the page ACL is read...

   "Default -All:read"
-> "Default" is found and expanded
-> "WikiGroup:read,write,delete,revert,admin All:read"
-> "All:read" applies

...and then the result of "read" is returned for the unidentified user. The "-
All:read" rule doesn't get considered because a rule has already been found 
for "All".

Giving "All" zero rights (I guess that's "All:") in the acl_rights_default 
will cause the same thing to happen again. To clarify, we're talking about 
this...

acl_rights_default = u"WikiGroup:read,write,delete,revert,admin All:"
#acl Default +All:read

Here's what happens:

   "Default +All:read"
-> "Default" is found and expanded
-> "WikiGroup:read,write,delete,revert,admin All:"
-> "All:" applies

...and no rights are granted. Again, any following "+All:read" won't get 
considered.

However, you may have better luck with something like this:

acl_rights_default = u"WikiGroup:read,write,delete,revert,admin All:"
#acl +All:read Default

This should have the "+All:read" rule considered before the default, and the 
"All:" rule will not revoke the added "read" right.

Of course, all of this involves use of the default rules and page ACLs, but it 
looks as if we really want to avoid this approach and to use the default rules 
as much as possible, saving the page ACLs for specific cases.

Now, if I understand, what you want to do is to have is administration and 
editing access set in the before rule. For example:

acl_rights_before = u"WikiAdministrator:read,write,delete,revert,admin " \
                    u"WikiGroup:read,write,delete,revert"

And then you want unidentified users only being able to read pages:

acl_rights_default = u"All:read"

And on pages where such users shouldn't even be able to read the page, you 
would put this:

#acl All:

Or you might even put something else that doesn't even mention "All" or 
"Default".

This seems to work when I test it in a Moin 1.9.7 wiki that I have to hand, 
but I can't see any differences between that and 1.9.8.

> > Also, I'd be tempted to add some debugging statements to the
> > AccessControlList.may method; something like...
> > 
> > print >>open("/tmp/debug.txt", "a"), repr(acl)
> > 
> > ...after the acl variable has been initialised. If anything, it would
> > help check the data involved.
> 
> I have to admit that my programming skills are essentially non-existent. 
> If what you suggest requires me to edit a specific file and add that line,
> I'm afraid I need more explicit instructions as to which file this is.

Sorry, I probably shouldn't have assumed familiarity with the code, here. To 
save you the bother, I've been doing the same thing myself on a wiki that 
should be using the same code in this area.

What did intrigue me was why you should experience a difference in behaviour 
between 1.9.3 and 1.9.8. There was a significant change that might have made a 
difference:

----
changeset:   5870:7b9f39289e16
user:        Thomas Waldmann <tw AT waldmann-edv DOT de>
date:        Mon Sep 03 15:30:35 2012 +0200
files:       MoinMoin/security/__init__.py 
MoinMoin/security/_tests/test_security.py
description:
security fix: fix virtual group bug in ACL evaluation, add a test for it

affected moin releases: all 1.9 releases up to and including 1.9.4
----

It's not immediately obvious that this might have changed the behaviour of 
ACLs in your code, but I suppose it could have done.

> > The one thing that came to mind was the page_group_regex setting, which
> > should be set to a sensible default. I presume that the format of your
> > group pages is still correct, too.
> 
> I've not changed the "page_group_regex" line in the wiki's config.py file
> from its default, and the WikiGroup page was not changed at all (worked
> fine on the old server).  I did try creating a different Group page, but
> it didn't make a difference.

My advice is to look into the before and default settings and to make sure 
that rules don't cause definitive decisions to be made without the modifying 
rules getting considered. So, avoid mentioning "All:..." before anything that 
might modify All's access (like "+All:..." or "-All:..."), likewise with any 
user or group identities that also need such treatment.

I hope this helps - I always seem to need my memory refreshing when it comes 
to ACLs - and please let us know whether it does help or not!

Paul



From cfreemesser at mail.cvs.rochester.edu  Fri Mar 11 13:57:23 2016
From: cfreemesser at mail.cvs.rochester.edu (Chris Freemesser)
Date: Fri, 11 Mar 2016 13:57:23 -0500
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <201603101838.23219.paul@boddie.org.uk>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
	<201603092225.32793.paul@boddie.org.uk>
	<56E1935B.1070907@mail.cvs.rochester.edu>
	<201603101838.23219.paul@boddie.org.uk>
Message-ID: <56E31513.2000103@mail.cvs.rochester.edu>

On 3/10/16 12:38 PM, Paul Boddie wrote:

> Now, if I understand, what you want to do is to have is administration and
> editing access set in the before rule. For example:
>
> acl_rights_before = u"WikiAdministrator:read,write,delete,revert,admin " \
>                      u"WikiGroup:read,write,delete,revert"
>
> And then you want unidentified users only being able to read pages:
>
> acl_rights_default = u"All:read"
>
> And on pages where such users shouldn't even be able to read the page, you
> would put this:
>
> #acl All:
>
> Or you might even put something else that doesn't even mention "All" or
> "Default".
>
> This seems to work when I test it in a Moin 1.9.7 wiki that I have to hand,
> but I can't see any differences between that and 1.9.8.

First, thanks very much for taking the time to do the testing and reply...I 
greatly appreciate it!  These ACLs are making my head spin.  ;)

What you've mentioned above could be a workaround for the issues I'm 
experiencing, though I do have to give the WikiGroup admin rights so they can 
create new pages.  I tried this out and it seems to be working.

However, the workaround does not allow me to disable WikiGroup's access to a 
page.  For example, I don't allow them editing rights to the WikiGroup page 
itself, but with this workaround, I can't take away the rights.  Adding a #acl 
line to the page with instructions to remove their access does nothing.

So, it looks like I need to ultimately get the acl problem solved so it works 
as designed.  As soon as I can find the time I'm going to set up a 2nd server 
from scratch using the same TurnKey Linux MoinMoin distribution to see if this 
problem exists out-of-the-box.  If it does, then it's an issue with the 
distribution, and not a problem with my wiki instances.  I'll do my best to 
provide updates on my progress.

Thanks again!

Chris

_____________________________________________
Chris Freemesser, Systems Administrator
University of Rochester
Department of Brain and Cognitive Sciences
The Center for Visual Science
Meliora Hall, Room 255
Phone:  (585)275-0786
_____________________________________________



From cfreemesser at mail.cvs.rochester.edu  Fri Mar 11 14:11:57 2016
From: cfreemesser at mail.cvs.rochester.edu (Chris Freemesser)
Date: Fri, 11 Mar 2016 14:11:57 -0500
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <201603101838.23219.paul@boddie.org.uk>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
	<201603092225.32793.paul@boddie.org.uk>
	<56E1935B.1070907@mail.cvs.rochester.edu>
	<201603101838.23219.paul@boddie.org.uk>
Message-ID: <56E3187D.7090109@mail.cvs.rochester.edu>

On 3/10/16 12:38 PM, Paul Boddie wrote:

> Now, if I understand, what you want to do is to have is administration and
> editing access set in the before rule. For example:
>
> acl_rights_before = u"WikiAdministrator:read,write,delete,revert,admin " \
>                      u"WikiGroup:read,write,delete,revert"
>
> And then you want unidentified users only being able to read pages:
>
> acl_rights_default = u"All:read"
>
> And on pages where such users shouldn't even be able to read the page, you
> would put this:
>
> #acl All:
>
> Or you might even put something else that doesn't even mention "All" or
> "Default".
>
> This seems to work when I test it in a Moin 1.9.7 wiki that I have to hand,
> but I can't see any differences between that and 1.9.8.

First, thanks very much for taking the time to do the testing and reply...I 
greatly appreciate it!  These ACLs are making my head spin.  ;)

What you've mentioned above could be a workaround for the issues I'm 
experiencing, though I do have to give the WikiGroup admin rights so they can 
create new pages.  I tried this out and it seems to be working.

However, the workaround does not allow me to disable WikiGroup's access to a 
page.  For example, I don't allow them editing rights to the WikiGroup page 
itself, but with this workaround, I can't take away the rights.  Adding a #acl 
line to the page with instructions to remove their access does nothing.

So, it looks like I need to ultimately get the acl problem solved so it works 
as designed.  As soon as I can find the time I'm going to set up a 2nd server 
from scratch using the same TurnKey Linux MoinMoin distribution to see if this 
problem exists out-of-the-box.  If it does, then it's an issue with the 
distribution, and not a problem with my wiki instances.  I'll do my best to 
provide updates on my progress.

Thanks again!

Chris

_____________________________________________
Chris Freemesser, Systems Administrator
University of Rochester
Department of Brain and Cognitive Sciences
The Center for Visual Science
Meliora Hall, Room 255
Phone:  (585)275-0786
_____________________________________________



From paul at boddie.org.uk  Fri Mar 11 15:15:27 2016
From: paul at boddie.org.uk (Paul Boddie)
Date: Fri, 11 Mar 2016 21:15:27 +0100
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <56E3187D.7090109@mail.cvs.rochester.edu>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
	<201603101838.23219.paul@boddie.org.uk>
	<56E3187D.7090109@mail.cvs.rochester.edu>
Message-ID: <201603112115.27991.paul@boddie.org.uk>

On Friday 11. March 2016 20.11.57 Chris Freemesser wrote:
> On 3/10/16 12:38 PM, Paul Boddie wrote:
> > Now, if I understand, what you want to do is to have is administration
> > and editing access set in the before rule. For example:
> > 
> > acl_rights_before = u"WikiAdministrator:read,write,delete,revert,admin "
> > \
> > 
> >                      u"WikiGroup:read,write,delete,revert"
> > 
> > And then you want unidentified users only being able to read pages:
> > 
> > acl_rights_default = u"All:read"
> > 
> > And on pages where such users shouldn't even be able to read the page,
> > you would put this:
> > 
> > #acl All:
> > 
> > Or you might even put something else that doesn't even mention "All" or
> > "Default".
> > 
> > This seems to work when I test it in a Moin 1.9.7 wiki that I have to
> > hand, but I can't see any differences between that and 1.9.8.
> 
> First, thanks very much for taking the time to do the testing and reply...I
> greatly appreciate it!  These ACLs are making my head spin.  ;)

That happens to us all. ;-)

> What you've mentioned above could be a workaround for the issues I'm
> experiencing, though I do have to give the WikiGroup admin rights so they
> can create new pages.  I tried this out and it seems to be working.

OK.

> However, the workaround does not allow me to disable WikiGroup's access to
> a page.  For example, I don't allow them editing rights to the WikiGroup
> page itself, but with this workaround, I can't take away the rights. 
> Adding a #acl line to the page with instructions to remove their access
> does nothing.

With the rights as described above (in my previous mail), you won't be able to 
change what WikiGroup can do in a page ACL because acl_rights_before will have 
decided that already, at least as I understand things. It would be like 
this...

   acl_rights_before
-> "... WikiGroup:read,write,delete,revert,admin"
-> "WikiGroup:read,write,delete,revert,admin"
-> "read,write,delete,revert,admin" applies

What wouldn't happen is the bit where Moin looks at the page ACL and/or the 
acl_rights_before setting.

I'm not sure if I considered this properly before, but I'm somewhat convinced 
that this is what happens now: even acl_rights_before will short-circuit the 
decision-making process.

> So, it looks like I need to ultimately get the acl problem solved so it
> works as designed.  As soon as I can find the time I'm going to set up a
> 2nd server from scratch using the same TurnKey Linux MoinMoin distribution
> to see if this problem exists out-of-the-box.  If it does, then it's an
> issue with the distribution, and not a problem with my wiki instances. 
> I'll do my best to provide updates on my progress.

I think that the change I described may have influenced the situation but I 
haven't really thought too hard about how that has happened. Meanwhile, you 
could try changing things to this:

acl_rights_before = u"WikiAdministrator:read,write,delete,revert,admin " \
                    u"+WikiGroup:read,write,delete,revert,admin"
acl_rights_default = u"+All:read"

And then try and change the ACL on the WikiGroup page to...

#acl WikiGroup:read

If my mental model of the ACL system is correct, WikiGroup should have all the 
"before" rights, but instead of stopping there, Moin should then look at the 
page ACL, see that WikiGroup has been given only the "read" right, and then 
return that single right as its decision.

   acl_rights_before
-> "... WikiGroup:read,write,delete,revert,admin"
-> "+WikiGroup:read,write,delete,revert,admin"
-> "read,write,delete,revert,admin" apply, but not definitively
-> page ACL
-> "WikiGroup:read"
-> "read" applies, overriding the "+WikiGroup" rights

I hope this makes some sense. :-)

Paul



From cfreemesser at mail.cvs.rochester.edu  Fri Mar 11 15:36:47 2016
From: cfreemesser at mail.cvs.rochester.edu (Chris Freemesser)
Date: Fri, 11 Mar 2016 15:36:47 -0500
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <201603112115.27991.paul@boddie.org.uk>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
	<201603101838.23219.paul@boddie.org.uk>
	<56E3187D.7090109@mail.cvs.rochester.edu>
	<201603112115.27991.paul@boddie.org.uk>
Message-ID: <56E32C5F.90701@mail.cvs.rochester.edu>

On 3/11/16 3:15 PM, Paul Boddie wrote:

> I'm not sure if I considered this properly before, but I'm somewhat convinced
> that this is what happens now: even acl_rights_before will short-circuit the
> decision-making process.

The way I see it, "acl_rights_before" are the settings you never want anybody 
to be able to change, "acl_rights_default" are the settings you normally want 
applied, and #acl gets added when you need to make a page "abnormal".  It all 
makes sense and works great...when it works.  ;)

I was able to get a second server set up with a bone stock install of TurnKey 
Linux MoinMoin (greatest distro ever...took 15 minutes for it to be up and 
running).  Using the default wiki instance, everything works as it should, so 
there has to be something about the way my wiki instances got migrated over 
that created this acl issue.  Next step will be to try migrating an instance 
over to this test server to see what happens.  That'll be early next week though.

Thanks again for all the help, and have a good weekend!

Chris
_____________________________________________
Chris Freemesser, Systems Administrator
University of Rochester
Department of Brain and Cognitive Sciences
The Center for Visual Science
Meliora Hall, Room 255
Phone:  (585)275-0786
_____________________________________________



From paul at boddie.org.uk  Fri Mar 11 16:09:38 2016
From: paul at boddie.org.uk (Paul Boddie)
Date: Fri, 11 Mar 2016 22:09:38 +0100
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <56E32C5F.90701@mail.cvs.rochester.edu>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
	<201603112115.27991.paul@boddie.org.uk>
	<56E32C5F.90701@mail.cvs.rochester.edu>
Message-ID: <201603112209.39422.paul@boddie.org.uk>

On Friday 11. March 2016 21.36.47 Chris Freemesser wrote:
> On 3/11/16 3:15 PM, Paul Boddie wrote:
> > I'm not sure if I considered this properly before, but I'm somewhat
> > convinced that this is what happens now: even acl_rights_before will
> > short-circuit the decision-making process.
> 
> The way I see it, "acl_rights_before" are the settings you never want
> anybody to be able to change, "acl_rights_default" are the settings you
> normally want applied, and #acl gets added when you need to make a page
> "abnormal".  It all makes sense and works great...when it works.  ;)

Yes, this is a good explanation of what I think should be happening. Maybe we 
both even agree with what the documentation says and what the code does. ;-)

> I was able to get a second server set up with a bone stock install of
> TurnKey Linux MoinMoin (greatest distro ever...took 15 minutes for it to
> be up and running).  Using the default wiki instance, everything works as
> it should, so there has to be something about the way my wiki instances
> got migrated over that created this acl issue.  Next step will be to try
> migrating an instance over to this test server to see what happens. 
> That'll be early next week though.

It's a bit baffling, really. Maybe creating a separate test instance on your 
server with the basic elements of the desired configuration might help.

> Thanks again for all the help, and have a good weekend!

No problem! Given that people are still using MoinMoin, and despite the lack 
of core developer presence on this and other channels, I'm inclined to start 
looking at doing Moin-related things again just to keep it viable. It would be 
a shame if people stopped using it because they felt it wasn't getting much 
developer attention any more.

Paul

P.S. I guess Thomas and others are busy developing Moin 2 on Bitbucket (as 
well as other things), and perhaps they're on some IRC channel that isn't 
logged in a place I know about, but I have to say that I am a bit worried 
about the relative silence from the core developers.



From cfreemesser at mail.cvs.rochester.edu  Mon Mar 14 15:31:48 2016
From: cfreemesser at mail.cvs.rochester.edu (Chris Freemesser)
Date: Mon, 14 Mar 2016 15:31:48 -0400
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <201603112209.39422.paul@boddie.org.uk>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
	<201603112115.27991.paul@boddie.org.uk>
	<56E32C5F.90701@mail.cvs.rochester.edu>
	<201603112209.39422.paul@boddie.org.uk>
Message-ID: <56E711A4.4040408@mail.cvs.rochester.edu>

On 3/11/16 4:09 PM, Paul Boddie wrote:

> It's a bit baffling, really. Maybe creating a separate test instance on your
> server with the basic elements of the desired configuration might help.

I think I found the problem.  I migrated one of my existing instances to the 
test server I set up on Friday, and did not experience the right problems I was 
seeing on my problematic server.

Thinking back about something you mentioned regarding it possibly being a cache 
problem, I returned to my problematic server and simply deleted the entire 
cache folder for one of my instances.  Created a replacement folder for it, 
assigned ownership of it to "www-data", then ran a "maint cleancache" command 
on the instance.  After doing this, I then had to again reassign ownership 
rights for the entire cache folder to "www-data".  I think this may be an issue 
unique to how TurnKey Linux works...the subfolders within the cache folder that 
were recreated had "root" ownership for some reason, and the server doesn't 
seem to like that.

However, once rights were reassigned, now the ACLs work properly.  Go figure.

The location of the cache folder on this server is different than my old 
server, and I suspect I copied the cache files to the new location when I first 
migrated the instances.  Looks like that isn't a good thing to do.

I'm going to try this fix for all of my wiki instances tomorrow, so fingers 
crossed it works for all of those as well.

Thanks again for the help!  I doubt I wouldn't have found this if you hadn't 
put the bug about the cache in my ear.

Chris

_____________________________________________
Chris Freemesser, Systems Administrator
University of Rochester
Department of Brain and Cognitive Sciences
The Center for Visual Science
Meliora Hall, Room 255
Phone:  (585)275-0786
_____________________________________________



From paul at boddie.org.uk  Mon Mar 14 16:33:29 2016
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 14 Mar 2016 21:33:29 +0100
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <56E711A4.4040408@mail.cvs.rochester.edu>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
	<201603112209.39422.paul@boddie.org.uk>
	<56E711A4.4040408@mail.cvs.rochester.edu>
Message-ID: <201603142133.30030.paul@boddie.org.uk>

On Monday 14. March 2016 20.31.48 Chris Freemesser wrote:
> On 3/11/16 4:09 PM, Paul Boddie wrote:
> > It's a bit baffling, really. Maybe creating a separate test instance on
> > your server with the basic elements of the desired configuration might
> > help.
> 
> I think I found the problem.  I migrated one of my existing instances to
> the test server I set up on Friday, and did not experience the right
> problems I was seeing on my problematic server.
> 
> Thinking back about something you mentioned regarding it possibly being a
> cache problem, I returned to my problematic server and simply deleted the
> entire cache folder for one of my instances.  Created a replacement folder
> for it, assigned ownership of it to "www-data", then ran a "maint
> cleancache" command on the instance.  After doing this, I then had to
> again reassign ownership rights for the entire cache folder to "www-data".
>  I think this may be an issue unique to how TurnKey Linux works...the
> subfolders within the cache folder that were recreated had "root"
> ownership for some reason, and the server doesn't seem to like that.

I often find file ownership to be a significant problem when performing 
maintenance tasks, assuming that the maintenance command actually functions 
correctly. I therefore find myself running some of these commands using sudo 
like this...

sudo -u www-data moin ...

(In fact, I use a helper script called moinsetup.py that I wrote to do common 
configuration tasks, and it is often the case that I run that instead of moin 
directly in the above way.)

> However, once rights were reassigned, now the ACLs work properly.  Go
> figure.
> 
> The location of the cache folder on this server is different than my old
> server, and I suspect I copied the cache files to the new location when I
> first migrated the instances.  Looks like that isn't a good thing to do.

I don't have an overview of what kind of location-sensitive information might 
be found in those files, but maybe it has an influence.

> I'm going to try this fix for all of my wiki instances tomorrow, so fingers
> crossed it works for all of those as well.
> 
> Thanks again for the help!  I doubt I wouldn't have found this if you
> hadn't put the bug about the cache in my ear.

Not a problem! The one thing I often found problematic and remedied only by 
full-on deletion at the filesystem level was the Xapian search support. There 
would be the annoying creation of lock files despite nothing actually getting 
re-indexed, and then Moin wouldn't manage to update the indexes. Various 
maintenance tasks would also "half fail" because these spurious locks would 
still be around.

Again, digging into this stuff is another nagging thing lurking in the 
background that one day might need get proper attention.

Paul



From cfreemesser at mail.cvs.rochester.edu  Tue Mar 15 11:03:52 2016
From: cfreemesser at mail.cvs.rochester.edu (Chris Freemesser)
Date: Tue, 15 Mar 2016 11:03:52 -0400
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <201603142133.30030.paul@boddie.org.uk>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
	<201603112209.39422.paul@boddie.org.uk>
	<56E711A4.4040408@mail.cvs.rochester.edu>
	<201603142133.30030.paul@boddie.org.uk>
Message-ID: <56E82458.9090007@mail.cvs.rochester.edu>

On 3/14/16 4:33 PM, Paul Boddie wrote:

> I often find file ownership to be a significant problem when performing
> maintenance tasks, assuming that the maintenance command actually functions
> correctly. I therefore find myself running some of these commands using sudo
> like this...
>
> sudo -u www-data moin ...

Good idea...I hadn't thought of that. I'll give that a try tomorrow when I 
re-migrate my instances to the new server.

Chris

_____________________________________________
Chris Freemesser, Systems Administrator
University of Rochester
Department of Brain and Cognitive Sciences
The Center for Visual Science
Meliora Hall, Room 255
Phone:  (585)275-0786
_____________________________________________



From paul at boddie.org.uk  Tue Mar 15 11:13:11 2016
From: paul at boddie.org.uk (Paul Boddie)
Date: Tue, 15 Mar 2016 16:13:11 +0100
Subject: [Moin-user] Wiki server ignoring ACLs *followup*
In-Reply-To: <56E82458.9090007@mail.cvs.rochester.edu>
References: <56DF3212.9040608@mail.cvs.rochester.edu>
	<201603142133.30030.paul@boddie.org.uk>
	<56E82458.9090007@mail.cvs.rochester.edu>
Message-ID: <201603151613.12447.paul@boddie.org.uk>

On Tuesday 15. March 2016 16.03.52 Chris Freemesser wrote:
> On 3/14/16 4:33 PM, Paul Boddie wrote:
> > I often find file ownership to be a significant problem when performing
> > maintenance tasks, assuming that the maintenance command actually
> > functions correctly. I therefore find myself running some of these
> > commands using sudo like this...
> > 
> > sudo -u www-data moin ...
> 
> Good idea...I hadn't thought of that. I'll give that a try tomorrow when I
> re-migrate my instances to the new server.

What I have also experimented with is the use of POSIX ACLs when initialising 
wiki installations. However, this can be pretty confusing, and the Web server 
will happily set the ownership of new files and directories to whatever it is 
running under, anyway.

I guess some use of the sticky bits (and equivalent with ACLs) might be 
helpful in preserving permissions, and I suppose that is worth some 
investigation, too.

Paul



From phatbuckett at gmail.com  Wed Mar 23 13:34:06 2016
From: phatbuckett at gmail.com (Darren S.)
Date: Wed, 23 Mar 2016 10:34:06 -0700
Subject: [Moin-user] Variable replacement based templates
Message-ID: <CAKVSOJWz4JnS+T-Fw33eYYbJnQP=fj6G7gnGuu_XrEe5i41Xtw@mail.gmail.com>

MoinMoin supports traditional page templates (page name: FooTemplate),
which is useful for including boilerplate text in other pages. It also
supports page-render time content inclusion style templates via the
<<Include()>> macro. Someone please stop me if the below is noise
because there's support in MoinMoin I couldn't identify.


There is some confusing discussion of an alternate style of templates
based on "variable replacement" here:

https://moinmo.in/FeatureRequests/Templates

The feature request author is describing functionality like
MediaWiki's support for very flexible templates based on parameter
substitution, in which values for variables in the template are passed
in to the template and rendered in the output at the time of page
rendering. This is described here:

https://www.mediawiki.org/wiki/Help:Templates

The difference between MoinMoin's Include-based templates and
MediaWiki's parameter substitution based templates can be significant
in use cases where one wants to create page or content block templates
that can provide a basic structure for a page, but pages using those
templates only have to pass a list of parameters to the template to
render entire pages or content blocks with different
values/information on the page when displayed. The latter is similar
to template engines like Jinja and allows for very flexible sets of
pages in a wiki created from a core template but with user-specified
values from templates pages passed to the included template.

If it doesn't make sense, you kind of have to see how it works in
MediaWiki to appreciate it. One possible implementation in MoinMoin
would be to extend the Include() macro to accept either a list of
parameter values or (the useful one I think) parameter names and
values so that they can be substituted into variables in the included
page.

-- 
Darren Spruell
phatbuckett at gmail.com



From antonxx at gmx.de  Wed Mar 23 16:50:18 2016
From: antonxx at gmx.de (anton)
Date: Wed, 23 Mar 2016 21:50:18 +0100
Subject: [Moin-user] MoinMoin Development Activity
References: <201602050032.31692.paul@boddie.org.uk>
Message-ID: <ncuvia$unl$1@ger.gmane.org>

Hi,

I just looked at moinmoin since a longer time period.

The last bitbucket comit is about 9 months ago,
so for me it looks thats its silently dead ...
as your question has not got an answer since one month...

Its sad.

Anton

Paul Boddie wrote:

> Hello,
> 
> I guess this isn't the most effective place to ask this question, but I
> suppose it reaches an audience who might also be wondering the same thing.
> What is the current situation around MoinMoin development, with respect to
> Moin 1.9 (which is noted as being the current production version) as well
> as with Moin 2.0 (which still seems to be in a rather fluid state)?
> 
> I was indeed trying to follow what has been going on with Moin 2.0,
> finding that the repository hadn't been updated for months, until I
> discovered that only the Bitbucket-hosted repository seems to be updated
> these days. I have had some vague intentions to port some extensions to
> Moin 2.0, but it appears that there are lots of packages I have to get
> from the Python Package Index (or whatever it is called these days), and
> my perception is that porting those extensions hasn't become any easier
> since I last looked. What is the current situation there?
> 
> As for Moin 1.9, I have quite a few patches that never made it upstream,
> and I've just spent a couple of hours looking at them again. Some of them
> can be found here:
> 
> https://moinmo.in/PaulBoddie
> 
> (Things like
> https://moinmo.in/FeatureRequests/EnhancedDiffsForRecentChanges are so
> useful that it just annoys me now when I visit a Moin site and have to
> look at individual diffs from a sequence of edits, or have to play with
> controls in the "info" page, when I can instead view the before-after diff
> from a RecentChanges link with that patch.)
> 
> Is there any interest in such patches or any other development for Moin
> 1.9. A while ago, I wondered if a Moin 1.10 would be helpful, but my
> impression was that this would be counterproductive and undermine Moin
> 2.0. So what should we be doing about this?
> 
> With the current fashion of people migrating their own hosted applications
> to dubious cloud providers with their own awful wiki implementations, I
> think that more could be done to demonstrate that Moin is both viable and
> preferable. Things like antispam protection could be usefully enhanced:
> this is probably one of the biggest problems (and most credible arguments
> to migrate away from Moin) that a bit of effort could meaningfully
> address.
> 
> What are other people's thoughts on such matters?
> 
> Paul
> 
> 
------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140





From paul at boddie.org.uk  Wed Mar 23 18:57:52 2016
From: paul at boddie.org.uk (Paul Boddie)
Date: Wed, 23 Mar 2016 23:57:52 +0100
Subject: [Moin-user] MoinMoin Development Activity
In-Reply-To: <ncuvia$unl$1@ger.gmane.org>
References: <201602050032.31692.paul@boddie.org.uk>
	<ncuvia$unl$1@ger.gmane.org>
Message-ID: <201603232357.52601.paul@boddie.org.uk>

On Wednesday 23. March 2016 21.50.18 anton wrote:
> Hi,
> 
> I just looked at moinmoin since a longer time period.
> 
> The last bitbucket comit is about 9 months ago,
> so for me it looks thats its silently dead ...
> as your question has not got an answer since one month...
> 
> Its sad.

Indeed. Looking at the Moin 2.0 repository on Bitbucket...

https://bitbucket.org/thomaswaldmann/moin-2.0

...it appears that there was some kind of activity in February. I guess that 
development of things has drifted over to Bitbucket without any real 
indication of why that happened. And the IRC logs have been even less 
informative than usual. I haven't been on IRC to ask questions, however.

Of course, Moin 1.x (and Moin 2.0) can be as active as we want them to be, 
regardless of what Thomas and others are doing these days [*]. Since people 
are still actively using and deploying Moin, perhaps some efforts should be 
made to push it/them forward in the direction of our choosing.

One thing that I thought about a while ago was to improve the anti-spam 
mechanisms. It seems that a lot of public Moin deployments these days use 
external mechanisms to grant accounts (such as the old-fashioned "ask someone 
to give you an account" approach), but there is some potential for improving 
the basic measures so that spam account creation doesn't happen so easily. 
Having a usable and secure "out of the box" policy for editing is probably the 
highest priority improvement I can think of.

Other than enhancements like that, I can imagine some tidying up of the code 
being useful. I think the argument that we should all be making Moin 2.0 ready 
for wider usage doesn't really hold up so well any more. Ideally, Moin 2.0 
would indeed be ready for people to deploy and would support Moin 1.x features 
so that people would just migrate, but things didn't get that far. Meanwhile, 
people who like Moin still seem to deploy Moin 1.x.

Does anyone else have any ideas for things that could be improved/fixed in 
Moin 1.x? Would a Moin 1.10 be a worthwhile exercise after all?

Paul

[*] https://mail.python.org/pipermail/borgbackup/2016q1/date.html



From ajhurst at me.com  Wed Mar 23 21:06:27 2016
From: ajhurst at me.com (John Hurst)
Date: Thu, 24 Mar 2016 12:06:27 +1100
Subject: [Moin-user] MoinMoin Development Activity
In-Reply-To: <201603232357.52601.paul@boddie.org.uk>
References: <201602050032.31692.paul@boddie.org.uk>
	<ncuvia$unl$1@ger.gmane.org> <201603232357.52601.paul@boddie.org.uk>
Message-ID: <C2350581-5D71-4077-8844-F07B42387D15@me.com>

These are very relevant questions from my perspective.  I have been running a moin 1.9 site for 6 years or so, and having been promising people who comment on its weaker points that "Moin 2 is coming soon".  But I am starting to lose that argument, and there are those who suggest that moving to a more modern wiki would be advantageous.

I have explored how I might help the development of moin 1/2 flavours, but found that I tended to get rather frustrated when I went looking for documentation.  For example, I have had trouble in maintaining various home grown flavours of macros, but short of spending my waking hours reverse engineering code, found it difficult to make much progress (yes, what are the entities in a "request"?).

As a (now retired) academic, I spent years exhorting students to document their code, and trying to set a good example for them to follow (http://www.ajhurst.org/~ajh/teaching/fit2070/2014/labs/index.xml).  And I understand that the moin development is by volunteers, who receive little thanks and many complaints.  But if we can spread the load by encouraging others to join the development, then I would hope emails such as these would no longer be necessary.

So can anyone help me to help you?  Where to I find the sort of documentation that would help a newbie to the inner workings of moin become more engaged?

cheers,
--John Hurst

On 20160324, at 09:57, Paul Boddie wrote:

> On Wednesday 23. March 2016 21.50.18 anton wrote:
>> Hi,
>> 
>> I just looked at moinmoin since a longer time period.
>> 
>> The last bitbucket comit is about 9 months ago,
>> so for me it looks thats its silently dead ...
>> as your question has not got an answer since one month...
>> 
>> Its sad.
> 
> Indeed. Looking at the Moin 2.0 repository on Bitbucket...
> 
> https://bitbucket.org/thomaswaldmann/moin-2.0
> 
> ...it appears that there was some kind of activity in February. I guess that 
> development of things has drifted over to Bitbucket without any real 
> indication of why that happened. And the IRC logs have been even less 
> informative than usual. I haven't been on IRC to ask questions, however.
> 
> Of course, Moin 1.x (and Moin 2.0) can be as active as we want them to be, 
> regardless of what Thomas and others are doing these days [*]. Since people 
> are still actively using and deploying Moin, perhaps some efforts should be 
> made to push it/them forward in the direction of our choosing.
> 
> One thing that I thought about a while ago was to improve the anti-spam 
> mechanisms. It seems that a lot of public Moin deployments these days use 
> external mechanisms to grant accounts (such as the old-fashioned "ask someone 
> to give you an account" approach), but there is some potential for improving 
> the basic measures so that spam account creation doesn't happen so easily. 
> Having a usable and secure "out of the box" policy for editing is probably the 
> highest priority improvement I can think of.
> 
> Other than enhancements like that, I can imagine some tidying up of the code 
> being useful. I think the argument that we should all be making Moin 2.0 ready 
> for wider usage doesn't really hold up so well any more. Ideally, Moin 2.0 
> would indeed be ready for people to deploy and would support Moin 1.x features 
> so that people would just migrate, but things didn't get that far. Meanwhile, 
> people who like Moin still seem to deploy Moin 1.x.
> 
> Does anyone else have any ideas for things that could be improved/fixed in 
> Moin 1.x? Would a Moin 1.10 be a worthwhile exercise after all?
> 
> Paul
> 
> [*] https://mail.python.org/pipermail/borgbackup/2016q1/date.html
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Moin-user mailing list
> Moin-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/moin-user




From paul at boddie.org.uk  Thu Mar 24 07:42:56 2016
From: paul at boddie.org.uk (Paul Boddie)
Date: Thu, 24 Mar 2016 12:42:56 +0100
Subject: [Moin-user] MoinMoin Development Activity
In-Reply-To: <C2350581-5D71-4077-8844-F07B42387D15@me.com>
References: <201602050032.31692.paul@boddie.org.uk>
	<201603232357.52601.paul@boddie.org.uk>
	<C2350581-5D71-4077-8844-F07B42387D15@me.com>
Message-ID: <201603241242.57936.paul@boddie.org.uk>

On Thursday 24. March 2016 02.06.27 John Hurst wrote:
> These are very relevant questions from my perspective.  I have been running
> a moin 1.9 site for 6 years or so, and having been promising people who
> comment on its weaker points that "Moin 2 is coming soon".  But I am
> starting to lose that argument, and there are those who suggest that
> moving to a more modern wiki would be advantageous.

Actually, I'm not particularly convinced by the other wiki solutions. There's 
MediaWiki if you want to go completely mainstream, but I've worked with that 
and it can be very annoying: it's written in PHP, didn't even have proper help 
pages to deploy when I was using it, essential extensions were downloadable 
via *user* pages on the MediaWiki site, and so on.

It seems to me that various more fashionable wikis than MediaWiki (the ones 
that appear to use Git as a storage engine - not necessarily a feature in my 
opinion) either don't provide the same usability as Moin or are often deployed 
so poorly so that the experience is half-broken. There are wikis that try to 
be something else - apparently things like TWiki went off and did this, and 
there's the proprietary Confluence which seems to be all about doing this - 
but again, the usability suffers according to what people have told me about 
them.

So, Moin is still a good choice, but I feel that Moin 2 has drifted away 
without really bringing people with it. I did look at trying it out again 
recently but was put off by the huge number of dependencies and the apparent 
need to use a virtualenv (or whatever) to even try it out. I know that people 
should be using other people's code instead of writing their own, but most of 
that code should be mature and widely available. Otherwise, the effect is the 
same as the project delivering lots of code you don't already have installed 
and making it harder to adopt and deploy.

> I have explored how I might help the development of moin 1/2 flavours, but
> found that I tended to get rather frustrated when I went looking for
> documentation.  For example, I have had trouble in maintaining various
> home grown flavours of macros, but short of spending my waking hours
> reverse engineering code, found it difficult to make much progress (yes,
> what are the entities in a "request"?).

The Moin 1.8 to 1.9 transition introduced various problems with the request 
handling, and I still have to remember which subpackage the request attributes 
are really defined in, as opposed to the boilerplate subpackages which just 
add another abstraction layer. I have no idea what Moin 2 does for this, 
although I seem to remember it being an evolved form of 1.9.

> As a (now retired) academic, I spent years exhorting students to document
> their code, and trying to set a good example for them to follow
> (http://www.ajhurst.org/~ajh/teaching/fit2070/2014/labs/index.xml).

That's an interesting set of resources that I'll have to look at later!

> And I understand that the moin development is by volunteers, who receive
> little thanks and many complaints.  But if we can spread the load by
> encouraging others to join the development, then I would hope emails such as
> these would no longer be necessary.

Indeed.

> So can anyone help me to help you?  Where to I find the sort of
> documentation that would help a newbie to the inner workings of moin
> become more engaged?

I was fortunate enough to get a tour of Moin from Thomas back at a conference 
(ten years ago!), even though I wasn't really looking to do anything with Moin 
at the time, but I'll admit that my knowledge of Moin has been built up over 
time. It's very possible that the developer documentation really needs 
improving to match the changes over the years and to remove material that 
refers to hypothetical enhancements that were never made:

https://moinmo.in/MoinDev

I've written a few extensions over the years [*], and perhaps I should be 
trying to document them a bit more. Practical guidance is usually better than 
just pointing someone at an API reference, after all.

Paul

[*] https://moinmo.in/PaulBoddie



From reuterru at arcor.de  Thu Mar 24 08:59:34 2016
From: reuterru at arcor.de (Rudolf Reuter)
Date: Thu, 24 Mar 2016 13:59:34 +0100
Subject: [Moin-user] MoinMoin Development Activity
In-Reply-To: <ncuvia$unl$1@ger.gmane.org>
References: <201602050032.31692.paul@boddie.org.uk>
	<ncuvia$unl$1@ger.gmane.org>
Message-ID: <56F3E4B6.20805@arcor.de>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20160324/2fddd138/attachment.html>

From moinmoin at picturenow.co.uk  Thu Mar 24 12:44:52 2016
From: moinmoin at picturenow.co.uk (Iain Mac Donald)
Date: Thu, 24 Mar 2016 16:44:52 +0000
Subject: [Moin-user] MoinMoin Development Activity
In-Reply-To: <56F3E4B6.20805@arcor.de>
References: <201602050032.31692.paul@boddie.org.uk>
	<ncuvia$unl$1@ger.gmane.org> <56F3E4B6.20805@arcor.de>
Message-ID: <20160324164452.790b1f69@flora.coachhouse>

On Thu, 24 Mar 2016 13:59:34 +0100
Rudolf Reuter <reuterru at arcor.de> wrote:

> I am very happy with Moin 1.9.
> It is stable, has all the features I need, and the pages are easy to
> backup with rsync. I think stability and reliability are more
> important for a wiki than fancy features.

+1

One feature I use a lot is searching using 3, 4 or 5 characters from a
page name. If there are multiple pages using these characters you get a
search result listing several pages. If there is only one page you get
that one page returned. I find this is very handy and I was sad to hear
it disappear in Moin 2+.

As others have mentioned things they would like to see...

I don't know if this counts as a fancy feature but one thing that
confuses non-technical users is the full text search results. The
results show snippets of text surrounding the search term but this is
displayed as markup not natural language. For people not familiar with
markup that can look odd. 

I don't mind trying applications in virtualenvs as they have become
second nature to me. However, I draw the line at having to download
multi-gigabyte Docker containers. ;-)

Regards,
Iain.



From renato.pontefice at gmail.com  Tue Mar 29 09:35:35 2016
From: renato.pontefice at gmail.com (Renato Pontefice)
Date: Tue, 29 Mar 2016 13:35:35 +0000
Subject: [Moin-user] moin2 when will be released?
Message-ID: <CAF83ECCtiG+bm8Lxo8twq1AQ5QTDae+3D0RK-ydkZz4osN=p_Q@mail.gmail.com>

Hi
I follow the moinmoin wiki, from a while. But, just now I need to start a
project with it.
I know that ver. 2 is quite out.
So, I'm wondering if it better to start a new project (that will end in
about a years) with version 2 or version 1.

TIA

Renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20160329/a535d0aa/attachment.html>

From renato.pontefice at gmail.com  Thu Mar 31 08:57:11 2016
From: renato.pontefice at gmail.com (Renato Pontefice)
Date: Thu, 31 Mar 2016 12:57:11 +0000
Subject: [Moin-user] win 7, moin2, prob to install
Message-ID: <CAF83ECAcHo7jJzOhWS2h6bN+6bLsaeKGUpGKD-fF0ZjkLrhjBQ@mail.gmail.com>

Hi, I would install moinmoin2 on a win7 pc.
Doing that, I obtain an error, that I can't understand:
_____________________________________________________
C:\Users\renatop\moin-2.0>c:\Python27\python wikiconfig.py
Traceback (most recent call last):
  File "wikiconfig.py", line 36, in <module>
    from MoinMoin.config.default import DefaultConfig,
_default_password_checker

  File "C:\Users\renatop\moin-2.0\MoinMoin\config\default.py", line 17, in
<modu
le>
    from babel import parse_locale
ImportError: No module named babel
______________________________________________________

I've already installd (without prob) on a Linux Debian PC (I've just
virtualenv prob).

TIA

Renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20160331/43b1044d/attachment.html>

From crosseyedpenguin at yahoo.com  Thu Mar 31 10:20:14 2016
From: crosseyedpenguin at yahoo.com (Roger Haase)
Date: Thu, 31 Mar 2016 14:20:14 +0000 (UTC)
Subject: [Moin-user] win 7, moin2, prob to install
In-Reply-To: <CAF83ECAcHo7jJzOhWS2h6bN+6bLsaeKGUpGKD-fF0ZjkLrhjBQ@mail.gmail.com>
References: <CAF83ECAcHo7jJzOhWS2h6bN+6bLsaeKGUpGKD-fF0ZjkLrhjBQ@mail.gmail.com>
Message-ID: <780528051.341047.1459434014352.JavaMail.yahoo@mail.yahoo.com>

A guess is you will find some error messages in m-quickinstall.txt saying Babel failed to download. Try running "python quickinstall.py" again (or "m quickinstall").
Roger Haase 

    On Thursday, March 31, 2016 5:58 AM, Renato Pontefice <renato.pontefice at gmail.com> wrote:
 

 Hi, I would install moinmoin2 on a win7 pc.Doing that, I obtain an error, that I can't understand:_____________________________________________________C:\Users\renatop\moin-2.0>c:\Python27\python wikiconfig.pyTraceback (most recent call last):? File "wikiconfig.py", line 36, in <module>? ? from MoinMoin.config.default import DefaultConfig, _default_password_checker
? File "C:\Users\renatop\moin-2.0\MoinMoin\config\default.py", line 17, in <module>? ? from babel import parse_localeImportError: No module named babel______________________________________________________
I've already installd (without prob) on a Linux Debian PC (I've just virtualenv prob).
TIA
Renato
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
Moin-user mailing list
Moin-user at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20160331/bc8d0034/attachment.html>