Re: [Moin-user] How do I change fonts in Moin 1.9.8

[Paul Boddie]

On Wednesday 8. June 2016 06.10.17 Peter Olsen wrote:
> I’d like to change the font used for text entires in Moin 1.9.8.  Can this
> be done?  If it can how do I do it?

This isn't related to Firefox ESR replacing Iceweasel in Debian, by any 
chance? Today, after that upgrade, Moin's use of "monospace" no longer 
produces a monospace font in the edit box.

At least under the above circumstances, the following bug seems to have 
returned:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388478

As for the more general question, the stylesheets tend to dictate the font 
used. Take a look in screen.css for the theme you are using.

Paul

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] port number prob?

[Paul Boddie]

On Tuesday 31. May 2016 16.07.04 Renato Pontefice wrote:
> Hi,
> I think that my prob could be about port number:
> If I try to access my moin2 wiki from an external browser, I do not receive
> answer from the server.

Did you not start the server as I suggested with the host being something 
else, like 104.155.16.89? You cannot rely on 127.0.0.1 working instead: both 
addresses may be configured to refer to the same (virtual) machine, but they 
do not mean the same thing. And 104.155.16.89 does not magically map to 
127.0.0.1 when traffic arrives at (and enters) the virtual machine.

Starting something that listens on 127.0.0.1 means that it will only respond 
to things using that address, and of course that address is not reachable from 
outside. You have to use an externally-accessible address or you won't solve 
this problem.

You can quite probably test an externally-accessible address inside the 
virtual machine just to make sure that your problem isn't one related to 
routing. So, I advise specifying 104.155.16.89 as the host when starting moin 
and then using lynx (or whatever) inside the virtual machine with that address 
(and whichever port you have chosen) in the URL. Then, if this succeeds, you 
can try again from outside the virtual machine.

> I've tried - from inside the VM - the following command, that, I think,
> explain the following:
> - the VM, answer to a ping with the external addr
> - does not answer neither at port 8081 nor port 8080.
> 
> Could it be a prob of web server?

Ping doesn't take arguments like this (because it operates at a different 
level than one dealing with ports)...

> ping 104.155.16.89:8081
> ping: unknown host 104.155.16.89:8081

You might try something like "telnet 104.155.16.89 8081" and see if it 
connects. But again, your server needs to listen on that external address for 
the service to be reachable.

Paul

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] moin-user migrating to mail.python.org

[Paul Boddie]

On Sunday 29. May 2016 16.41.26 Roger Haase wrote:
> MigratingToGitHub - MoinMoin and on #moin-dev about a year ago. Then it
> seemed most GSOC students were more familiar with GIT and Github than hg
> and Bitbucket. Personally, hg and Bitbucket seem OK, except I wish
> Bitbucket would fix the layout of their bug tracker to show a wider title.

Are there any GSOC projects this year? It seems to me that any development 
taking place on Moin has gone underground.

Paul

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Installed moin2 but unable to access

[Paul Boddie]

On Thursday 26. May 2016 18.43.22 Renato Pontefice wrote:
> Hi,
> I've finaly installed moin2, everything seem to go well, but when I try to
> access it it doesn't answer. This is a log when I run it:

[...]

> 2016-05-26 16:39:40,272 INFO werkzeug:87 * Running on
> http://127.0.0.1:8080/ (Press CTRL+C to quit)

[...]

> it seem to work on port 8080 at the addr of the virtual machine
> but if I try to acces fro a browser: http://104.155.16.89:8080/
> I do not receive any answer
> 
> the traffic for http and https are allowed, why I do not receive any
> answer?

Because the server is listening on 127.0.0.1 in the virtual machine, but you 
are trying to access the server via another address? Maybe you need to tell 
the server to listen on that address as well as on localhost.

Paul

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] moin-user migrating to mail.python.org

[Paul Boddie]

On Thursday 26. May 2016 16.35.35 Roger Haase wrote:
> The migration (including archives and subscriptions) is planned for June
> 15, 2016. If you have any concerns, you may express them here or
> there: https://moinmo.in/MigratingMailToPythonOrg If all goes as planned,
> there is nothing for you to do except update your contact list. A reminder
> will be sent to this list after migration is complete.

This is probably good news, given that the core Moin developers don't really 
seem to read this list any more. I also noticed that Thomas has created a 
project on GitHub for Moin, for at least the 1.x version. Has there been any 
public discussion of this anywhere?

Paul

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

[Moin-user] TimeChanges: an edit-timing extension for MoinMoin

[Paul Boddie]

Hello,

I've been thinking of making an extension like this for a while, but I finally 
got round to it today. The TimeChanges extension measures the time between a 
user viewing a page and then saving it. If the measured time is too short, the 
edit is rejected.

One motivation for this extension is to prevent automated edits of a certain 
kind where a script or robot attempts to rapidly edit pages. There appears to 
be similar extensions for WordPress that attempt to detect robot-like 
behaviour.

I've uploaded the code to a repository in the following location:

http://hgweb.boddie.org.uk/TimeChanges

I think there are probably other interesting techniques that could be applied, 
too. These days, deploying Moin can be a challenge due to the pervasive 
spamming that now takes place on the Web, and it would be interesting to 
explore solutions that make it easier to cultivate trusted communities of wiki 
contributors without the manual effort that is currently needed to do so.

Maybe this, amongst other counter-measures, may be useful to someone.

Paul

P.S. This might also serve as inspiration or as a reference to other potential 
extension authors, especially since it isn't much code at all.

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Creating a static copy of a MoinMoin site

[Paul Boddie]

On Tuesday 12. April 2016 17.03.07 Paul Waring wrote:
> On Tue, Apr 12, 2016 at 02:21:16PM +, Roger Haase wrote:
> >It has been a few years since I have used this, but
> >try: HelpOnMoinCommand/ExportDump - MoinMoin
> >
> > HelpOnMoinCommand/ExportDump - MoinMoin
> 
> I've tried that but there are two big problems with the export dump:
> 
> 1. It adds a .html extension to all pages, meaning that all external
> links (i.e. those linking to the wiki from another site) break.
> 
> 2. It changes a forward slash in URLs to (2f), e.g. About/Contact
> because About(2f)Contact.html (again breaking URLs)

Those don't sound like big problems to me, given that the source code is there 
for potential modification. Admittedly, I haven't looked at that feature in 
recent times, but you're effectively describing encoding issues on the output 
filenames, so there's probably just one place that needs changing.

And you don't even need to make this generic/nice if you're doing this as a 
one-off job for yourself.

Paul

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] try to installing moinmoin2 on win 7

[Paul Boddie]

On Thursday 7. April 2016 15.50.13 Renato Pontefice wrote:
> I think I've installed babel (also Pip, virtualenv) but I still receive
> this error:
> _
> C:\Users\renatop\moin\moin-2.0>wikiconfig.py
> Traceback (most recent call last):
>   File "C:\Users\renatop\moin\moin-2.0\wikiconfig.py", line 36, in 
> from MoinMoin.config.default import DefaultConfig,
> _default_password_checker
> 
>   File "C:\Users\renatop\moin\moin-2.0\MoinMoin\config\default.py", line
> 19, in
> 
> from MoinMoin.i18n import _, L_, N_
>   File "C:\Users\renatop\moin\moin-2.0\MoinMoin\i18n\__init__.py", line 20,
> in <
> module>
> from flask import current_app, request, _request_ctx_stack
> ImportError: No module named flask
> 
> 
> What's the prob now?

You don't have Flask! ;-)

https://pypi.python.org/pypi/Flask

What's happening is that you're chasing down dependencies. I'm not familiar 
with the way that Moin 2 is set up or whether there is supposed to be an 
automated download of dependencies - not that I would trust the Python 
packaging tools to actually manage this successfully - but you might want to 
check the list of dependencies and see what else you might need.

Apparently, setup.py lists the dependencies.

Paul

P.S. I did think about doing a Debian package for Moin 2, but given the amount 
of work involved and the probable need to package various dependencies, I just 
haven't been able to put the time or motivation towards doing so. (Personally, 
I think my time would be better spent on Moin 1.x, but anyway.)

--
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Upgrading from 1.8.1 to 1.9.8

[Paul Boddie]

On Sunday 3. April 2016 09.42.57 Karl Auer wrote:
> On Sun, 2016-04-03 at 16:24 +1000, Karl Auer wrote:
> > The upgrade notes all seem to be about installing 1.9.8 over 1.8.1 -
> > i.e., on the same system.
> 
> I've sort of faked that now: I set up /usr/local/share/moin with the
> 1.8.1 data and overlay directories (and their contents) in it, then
> installed 1.9.8 over the top. Copied moin.wsgi out of the server subdir
> and edited wikiconfig.pi appropriately.
> 
> Now I get a "500 internal error" from Apache for pretty much any page
> except the initial login page, and the final two lines of the Apache2
> error log are:
> 
> [Sun Apr 03 17:14:28.361957 2016] [wsgi:error] [pid 7602:tid
> 139732746934016] [remote 192.168.1.142:48395]   File "Nullarbor", line 2,
> in  [Sun Apr 03 17:14:28.362037 2016] [wsgi:error] [pid 7602:tid
> 139732746934016] [remote 192.168.1.142:48395] TypeError: 'dict' object is
> not callable
> 
> I've set the front page to be a page called "Nullarbor", and that page
> certainly exists in the data.

This looks like a cache-related error. At first it might seem strange that a 
non-Python file might be referenced in a traceback, but Moin effectively 
"compiles" pages to cache entries that are then "run" by Python. (Here, I'm 
relying on my memory of playing around with Moin's caching mechanism.)

> The "upgraded" install does seem to know about the old data at some
> level - if I try to open a page that I know is NOT there, MoinMoin will
> offer to create a new one. If I try to open a page that I know already
> exists, MoinMoin does NOT offer to create a new one; it throws the 500
> error instead.

This sounds like you need to clean the cache using the appropriate moin 
command. Something like this:

moin maint cleancache

You may need to operate as the Web server user (such as www-data) to 
successfully perform the operation:

sudo -u www-data moin maint cleancache

And, of course, the moin command must be in your PATH.

> It also knows about the old accounts - I can log in as the admin
> because I have set that one up new, but I can also log in as one of the
> users from the old system.
> 
> It even seems to be paying attention to the ACLs, saying for various
> pages that I don't have permission to view the page. But it actually
> can't display any pages, even those I have permission to view. The
> error log shows essentially identical errors for every page I try to
> view.
> 
> This may be something to do with caches, but I don't have the skill to
> adapt the script Rick Vandeveer provides with his upgrade notes.

Especially since it appears to be a Windows-centric guide:

https://moinmo.in/RickVanderveer/UpgradingFromMoin18ToMoin19

Most advice around upgrades, whether Moin or Python or both are being 
upgraded, will eventually involve cleaning the cache, either to adapt the 
cache entries to changes in the Moin API that may have occurred (since they 
are effectively programs), or to use the bytecode appropriate for the upgraded 
Python version.

Paul

--
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=/4140
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] moin2 how to create admin user

[Paul Boddie]

On Saturday 2. April 2016 15.45.27 Darren Spruell wrote:
> > On Apr 2, 2016, at 3:08 PM, Renato Pontefice 
> > wrote:
> > 
> > the root user should exist also inside moinmoin2 wiki?
> 
> Yes; the wiki user must be created (needs password, etc.).

I imagine that with Apache or some other suitably-capable Web server, you 
could deploy an authentication module that understands the system 
authentication method, and this would then present an identity to Moin that 
would be handled in Moin itself using the GivenAuth authenticator.

Alternatively, if LDAP were being used to authenticate system users, you could 
get Moin to use LDAPAuth, and I think this would even work with the standalone 
server. However, I don't know how much of this Moin 2 supports.

Paul

--
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=/4140
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] MoinMoin Development Activity

[Paul Boddie]

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

--
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=/4140
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] MoinMoin Development Activity

[Paul Boddie]

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=/4140
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Wiki server ignoring ACLs *followup*

[Paul Boddie]

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

--
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=278785231=/4140
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Wiki server ignoring ACLs *followup*

[Paul Boddie]

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.

--
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=278785111=/4140
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Wiki server ignoring ACLs *followup*

[Paul Boddie]

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

--
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=278785111=/4140
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Wiki server ignoring ACLs *followup*

[Paul Boddie]

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 

Re: [Moin-user] Wiki server ignoring ACLs *followup*

[Paul Boddie]

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

--
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=278785111=/4140
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

[Moin-user] MoinMoin Development Activity

[Paul Boddie]

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=/4140
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] https://moinmo.in/HelpOnVariables , Display variables in fixed font format

[Paul Boddie]

On Friday 4. December 2015 09.52.25 serv...@metamodul.com wrote:
> Hi
> is it possible to display a variable in a fixed font like
> 
> VAR1 = {{{ <> }}}

Have you tried it, and did it work? ;-)

What about this...?

VAR1 = ` <> `

It might be the case that the {{{ and }}} processing is different from the way 
backquotes are interpreted, in that the former may not permit a wide range of 
Moin syntax inside the braces. Used within a paragraph, however, the basic 
formatting of the text should be the same in both cases.

Paul

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Problem with encoding URLS

[Paul Boddie]

On Tuesday 1. December 2015 09.18.52 m...@mherrn.de wrote:
> Hi Paul,
> 
> thanks for your help.

Well, thanks for doing all the hard work investigating the problem! ;-)

[...]

> > Here, I imagine that your locale setting isn't helping. What do you get
> > at the Python prompt if you call sys.getfilesystemencoding() ?
> 
> As the user I running the moin instance, I get:
> 'UTF-8'
> 
> > You may need to look at your system's default locale and/or the user's
> > locale, I guess.
> 
> The users locale is:
> 
> LANG=en_US.UTF-8

Yes, these two things look consistent.

[...]

> So that should all be well.
> I have now done some tests and wrote a minimal WSGI script to print out
> some variables:

If only everyone reporting problems was as thorough. :-)

[...]

> And the output is:
> 
> /
> User: moinuser
> defaultlocale: (None, None)
> prefencoding: ANSI_X3.4-1968
> LANG: C
> LC_ALL: None
> LC_CTYPE: None
> LC_MESSAGES: None
> /
> 
> When running these lines on the console I get:
> 
> /
> User: moinuser
> defaultlocale: ('en_US', 'UTF-8')
> prefencoding: UTF-8
> LANG: en_US.UTF-8
> LC_ALL: None
> LC_CTYPE: None
> LC_MESSAGES: POSIX
> /
> 
> 
> So obviously the locale settings are gone.
> 
> I have googled around a bit and it seems that I have to explicitly set
> the locale settings to WSGIDaemonProcess:
> 
> /
> WSGIDaemonProcess moin user=moinuser group=moinuser processes=5 threads=10
> maximum-requests=1000 umask=0007 lang='de_DE.UTF-8' locale='de_DE.UTF-8'
> /
> 
> and everything is well then!

Here, I almost feel as if I should have asked about CGI or WSGI or whatever. 
This does actually sound familiar now, but I'll admit that I use CGI more 
often than not.

> > I see someone else has experienced this recently, too:
> > 
> > https://moinmo.in/MoinMoinBugs/1.9.8NonAsciiURL-UnicodeEncodeError
> 
> I have added my solution to the Discussion paragraph on that page.
> 
> Thanks for your help!

No problem! You helped yourself, really. Thanks for contributing to the page, 
too! I'm sure the configuration instructions can be improved by someone with a 
bit more familiarity with mod_wsgi.

Paul

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Problem with encoding URLS

[Paul Boddie]

On Monday 30. November 2015 15.33.49 m...@mherrn.de wrote:
> Hi,
> 
> I have just moved my wiki to another server. Unfortunately, URLs with
> special characters (for example german Umlauts) don't work anymore.
> 
> I have a page with the Name "Töst". It contains the german Umlaut "ö".
> The encoded url looks like "https://mywiki.com/T%C3%B6st;

So, that's the page name URL-encoded with the original character values being 
represented using UTF-8. In short...

Töst
-> 84 (T), 195, 182, 115 (s), 116 (t) (decimal values)
   54 (T), C3,  B6,  73 (s), 74 (t) (hex values)
-> T%C3%B6st

Such encoding is perfectly reasonable, since the W3C never got round to 
specifying non-ASCII characters in URLs, or at least not properly.

> When trying to access this page the apache log tells me:
> 
> -/-
> mod_wsgi (pid=31988): Exception occurred processing WSGI script
> '/home/user/www/moin/moin.wsgi'.
> Traceback (most recent call last):
>File "/usr/lib/python2.7/dist-packages/werkzeug/wsgi.py", line 567, in
> __call__
>  cleaned_path = cleaned_path.encode(sys.getfilesystemencoding())
> UnicodeEncodeError: 'ascii' codec can't encode character u'\\xf6' in
> position 2: ordinal not in range(128)
> -/-
> 
> What is going on here? Do I have a misconfiguration in moinmoin? Why is it
> trying to encode it in ASCII?

Here, I imagine that your locale setting isn't helping. What do you get at the 
Python prompt if you call sys.getfilesystemencoding() ?

You may need to look at your system's default locale and/or the user's locale, 
I guess. I see someone else has experienced this recently, too:

https://moinmo.in/MoinMoinBugs/1.9.8NonAsciiURL-UnicodeEncodeError

Paul

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] (no subject)

[Paul Boddie]

On Wednesday 28. October 2015 14.01.12 Alex Vazquez wrote:
> hi All
> 
> I'm migrating my moin wiki to a new server with the same version ( 1.5.7 )
> I have two different wikis. A I can see the content perfectly . But
> the second I get the following error: http://pasted.co/c0a1a349
> 
> Any idea how I can fix?

Were you using Python 2.7 on the old server?

Meanwhile, the error looks as if it is related to ACLs, which might explain 
why one wiki doesn't produce the error but the other one does.

Paul

--
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] HideReferringPage

[Paul Boddie]

On Saturday 24. October 2015 06.52.45 Lars Kruse wrote:
> 
> Am Sat, 24 Oct 2015 01:22:31 +0200
> 
> schrieb Paul Boddie <p...@boddie.org.uk>:
> > Now you just have to write the action. ;-)
> 
> I use the apache config snippet below for redirecting requests via apache's
> "rewrite" module.
> Or did you refer to a moinmoin "action"?

I really meant a Moin action to provide a gateway to external sites, so you 
would start out with a link like this:

http://moinmo.in/

This would get rewritten using the url_mappings (suggested by Marcus) to...

http://yoursite/moin?action=ExternalLinkAction=http%3A%2F%2Fmoinmo.in%2F

And the action would interpret the url argument and perform the redirect.

Paul

--
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] HideReferringPage

[Paul Boddie]

On Saturday 24. October 2015 00.22.23 Marcus Schopen wrote:
> Am Freitag, den 23.10.2015, 23:30 +0200 schrieb Marcus Schopen:
> > Am Freitag, den 23.10.2015, 18:26 +0200 schrieb Marcus Schopen:
> > > Hi,
> > > 
> > > is there something like HideReferringPage for external links for
> > > moinmoin like
> > > 
> > >   https://www.mediawiki.org/wiki/Extension:HideReferringPage
> > 
> > I found this: https://moinmo.in/RedirectingExternalLinks
> > 
> > Any other ways?
> > 
> > Ciao!
> 
> url_mappings = {
>  'https://www.wiki.de/mywiki/': 'https://www.wiki.de/mywiki/',
>  'http://': 'https://www.google.com/url?sa=D=http://',
>  'https://': 'https://www.google.com/url?sa=D=https://'
> }

Well, if you don't mind following all the links via Google...

I think the potentially cleaner way would be to have an action that performs 
such a redirect. According to the Wikipedia page about "Referer", redirects 
should not propagate that header, so an action that performs a similar 
function to that Google service (but without Google soaking up all the data) 
would do the job just as well.

So you'd define some URL mappings pointing to the action using the above 
mechanism, and that would probably do what you want. Now you just have to 
write the action. ;-)

Paul

--
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Migrating wikis from 1.9.3 to 1.9.8

[Paul Boddie]

On Thursday 15. October 2015 15.43.19 Chris Freemesser wrote:
> On 10/15/15 8:49 AM, Steve McIntyre wrote:
> > You'll just need to clean the cache, most likely:
> > 
> > moint maint cleancache
> 
> Thanks for the suggestion, but running the command results in a bunch of
> log lines that concludes with:
> 
> "MoinMoin.error.ConfigurationError: ImportError: No module named
> wikiconfig"

The moin command usually works best (or at all) with some extra options. Try 
this:

moin --config-dir=WIKIDIR maint cleancache

Here, WIKIDIR is the directory containing wikiconfig.py.

Paul

--
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] data_dir does not exists - ConfigurationError

[Paul Boddie]

On Monday 31. August 2015 18.37.24 Ryan L. Raines wrote:
> Disabling SELinux resolved this issue.

The clean way of dealing with this, if you still want to use SELinux, is to 
use semanage and restorecon to tag the files Moin uses. The following page 
might help:

https://moinmo.in/HowTo/FedoraSELinux

Something like this...

semanage fcontext -a -t httpd_sys_content_t \
 "/opt/installs/moin-1.9.8/share/moin/data(/.*)?"

...might be a start. I see that a slightly different "type" value is used on 
the wiki page mentioned above, whereas I used the above command on RHEL a 
while back.

Then, running the following tells SELinux all about what you've done:

restorecon -R -v /opt/installs/moin-1.9.8/share/moin/data

And you get to see what it's tagging.

Paul

--
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Permissions for New Account page

[Paul Boddie]

On Wednesday 29. July 2015 03.37.20 Barry Demchak wrote:
 
 I have inherited a Moin Moin that has an odd behavior:
 
 The new account page (ourdomain.com/cgi-bin/moin.cgi/?action=newaccount)
 displays just fine if I'm already logged in. But if I'm not logged in (as
 would a new user be), I get a permission violation (You are not allowed to
 use this action.).
 
 I think the permission setup is missing the point . a new user can't
 already be logged in. Or . possibly I'm missing the point. (Could this be
 intended to operate this way??)

It could be the case that new users would be added manually by superusers:

https://moinmo.in/FeatureRequests/DisableUserCreation

This is also covered here:

https://moinmo.in/HowTo/ManagingAccountCreation

 Can you help me get this New Account page configured so that new users can
 create accounts?

If your authentication mechanism makes use of existing accounts from other 
systems (the Web server, LDAP, and so on), then new account creation probably 
isn't required anyway. 

Otherwise, it might be useful to allow new account creation, but then it is 
important to introduce additional measures to prevent spam registrations. Off 
the top of my head, I suggest:

Account verification: https://moinmo.in/HowTo/ManagingAccountCreation

Textchas for registration and editing: https://moinmo.in/HelpOnSpam

A trusted editors group (see the ManagingAccountCreation page above)

This is what we used for the Mailman Wiki and it seems to work fairly well. 
Some more details...

Account verification works fairly well, but it doesn't really seem to stop 
spammers. At most, it just filters out some of them, but it also manages to 
slow down registrations, too.

Textchas are effective, but you have to choose a good question: what is 2 + 
2 or similar things are not effective; you need to choose something that a 
random spammer would not be able to find out by just looking at the question. 
Various wikis choose to have the answer to a simple what is the password 
question as a secret that is shared by other means.

Having a trusted editors group may mean that you impose access control on the 
entire wiki insisting that before anyone can edit anything they must be added 
to the trusted editors group. Thus, groupless users may only read things and 
cannot start editing straight away. This effectively adds another hurdle for 
spammers: they may get as far as registering an account, but then their 
account needs to be approved.

Once upon a time, I did make an extension that permitted the review of edits 
so that people could just start editing, but where their edits were queued and 
hidden from site users, but it's arguably better to just put obstacles in the 
path of spammers as early as possible in order to prevent later tidying-up or 
administration effort. For genuine users, the above measures shouldn't really 
be much of a burden.

[...]

 https://sosa.ucsd.edu/confluence/display/~bdemchak/Home

And if your department ever wishes to migrate from Confluence...

https://moinmo.in/ConfluenceConverter

...we may have the solution for that as well. ;-)

Paul

--
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Why multiple user files for individual users?

[Paul Boddie]

On Tuesday 21. July 2015 10.05.38 Philip Colmer wrote:
 Hi
 
 Having cleaned up the data/user directory on my system, I've spotted that
 some users occasionally are still ending up with multiple files for their
 account.
 
 I've diff'ed the files and the only difference is the last_saved field so
 I'm struggling to understand why moin is creating subsequent files ...

Are the permissions different between the old and new files?

Paul

--
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Trying to understand notification behaviour in PageEdit.py

[Paul Boddie]

On Tuesday 3. March 2015 17.47.56 Philip Colmer wrote:
 Thanks, Paul, for your comments.
 
 I've (finally) managed to find a way to get logging working on
 PageEditor.py and I've been able to confirm that notify is, indeed,
 set to False by my code.
 
 Upon further thinking, I suspect that the notifications are *not*
 being caused by my script editing the various pages but, instead, by
 the fact that my script refreshes attachments on each of the pages.

Yes, I was going to suggest the attachments because the attachment mechanisms 
also cause events to be sent.

 The pages are profile pages for each employee and, as such, link to a
 photo of the employee. Since I don't have an easy way of checking
 whether or not the photo has changed, I just updated it every time the
 script runs. Since the attachment code causes notifications, I think
 that is the root cause.

I would think so, too.

 So I've either got to figure out a clean way of extending the
 attachment code so that notifications can be disabled in code, like
 PageEditor allows, or find a better way to handle the photos so that I
 don't have to keep on refreshing the attachments.

It would certainly be nicer to be able to suppress notifications in the 
attachment API, but that would involve enhancing Moin, and I don't really know 
what the situation is with regard to getting patches into upstream Moin 1.x 
these days.

An alternative might involve accessing the stored attachments and comparing a 
checksum of the content with the thing you're considering attaching.

Paul

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] GSoC 2015 aspirant: Validation of Wiki Contents

[Paul Boddie]

On Monday 2. March 2015 18.08.56 Karan Dev wrote:
 Hi Developers,
 
 I am final year computer science engineering student from UPTU. I want to
 contribute to the organization by becoming a part of GSoC 2015. I know
 C/C++, Python, Javascript.
 I went through project ideas of Mailman and found Validation of Wiki
 Contents interesting. Please guide me for the next step.

I see that you're also interested in Mailman, but given that Mailman now uses 
MoinMoin, we should only see that as being a good thing. ;-)

I'm not involved in GSoC, but I would recommend the following things to become 
familiar with Moin development...

Clone the Moin repositories. I'm guessing that the focus is on Moin 2.0, but 
the Wiki Contents appears to refer to the official MoinMoin Wiki (or maybe 
it doesn't - clarification needed!). So, having some familiarity with the Moin 
1.9 code might be useful. See: https://moinmo.in/MoinMoinDownload

Install Moin on your own computer and play around with it. This is easier if 
you've cloned the repositories because you can change the code and see the 
effects immediately, all within a controlled environment.

With some experience with Moin content, you can now start to think about the 
actual GSoC task. The topic seems a bit vague to me, but having been playing 
with wiki content myself recently (for Mailman, in fact), it's possible to get 
a feel for the task by looking at how Moin stores its content, what kind of 
API it provides to access it, and you might get some ideas about extending 
these things.

Anyway, I'll leave it to the mentors to give you some proper advice. :-)

Paul

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Question about underlay pages in 1.9.3

[Paul Boddie]

On Thursday 5. February 2015 00.39.44 Joseph Kang wrote:
 Thanks for the reply, Paul. Your presumption is correct. I'm using the
 tar.gz distributions as downloaded from moinmo.in and I did perform a
 moin maint cleancache as part of the upgrade process.

Good. Sorry not to get back to you quickly about this, by the way!

 I happen to have a test machine that's a clone of the production system. I
 just deleted the underlay directory in my test wiki instance directory;
 copied /usr/share/moin/underlay into my wiki instance subdirectory; went
 through the process of installing the language packs all over again; and
 issued a moin maint cleancache. The packs I chose were
 all_system_pages, all_help_pages, and admin_pages. When I browse to
 this test instance and view the HelpOnFormatting page, it still shows
 the version that says the markup is [[BR]].
 
 I did some digging in the file system and noticed that the
 /usr/share/moin/wiki-instance/data/pages subdirectory has the same
 directories that exists in underlay (with older file mod time/dates) in
 addition to the directories for our wiki's own content. I can only guess
 that it's pulling the outdated HelpOnFormatting page from there. As part
 of my upgrades, I always made sure I issued the moin migration data
 command. As far as I recall, I never saw any errors from them.

I don't remember when the underlay system was introduced, but I think I first 
encountered it having already been using Moin for a while, so perhaps your old 
version didn't employ the underlay for help pages and had them all installed 
in the pages directory. I see that Moin 1.3 featured the underlay, at least:

https://moinmo.in/MoinMoinRelease1.3

Why the pages didn't have their markup converted is a mystery to me, however.

 Should the pages that are in underlay also exist in data? Or is that an
 artifact from running a really old version of MoinMoin and migrating it to
 newer versions?

They only get replicated in the pages directory if they are edited, I think.

 It may be helpful to provide the full list of versions I upgraded
 to/through: 1.187 (as shown on the page footer with show_version=1 set
 in wikiconfig.py), 1.3.5, 1.5.3, 1.5.9, 1.6.0, and finally 1.9.3
 
 Thanks again for your time and assistance. (Sorry about the top reply vs.
 inline. Stuck using Outlook.)

It's probably safe to try running without the duplicated help pages residing 
in the pages directory. Perhaps moving one of the page directories 
(pages/HelpOnFormatting, for example) out of the Moin installation to 
somewhere temporary, then possibly cleaning the Moin cache, and finally 
reloading the page in the browser might provide an insight into what is 
happening.

Paul

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Question about underlay pages in 1.9.3

[Paul Boddie]

On Wednesday 4. February 2015 19.21.50 Joseph Kang wrote:
 Hi, all. I'm new to the list. Our company has been running an internal
 MoinMoin wiki for several years now but it wasn't actively maintained
 until recently. We recently went through a migration from 1.187 to 1.9.3.
 If anyone needs to know the specific versions I upgraded to in-between the
 start and end, I'd be happy to provide that info.

1.187 sounds very old and not particularly Moin-like as a version number, but 
your problem description does seem to confirm that it's certainly an old, 
pre-1.6 version you're using.

 The question I have is about the underlay pages that got installed with
 1.9.3. I noticed that at some point, the markup for inserting a line break
 changed from [[BR]] to BR. However the HelpOnFormatting page that got
 installed through the 1.9.3 LanguageSetup process shows that it's still
 [[BR]]. As far as I can tell, I am running with the underlay pages that
 were installed through 1.9.3. Is this the correct version of
 HelpOnFormatting for this release (mistakes and all)? I noticed that the
 layout and content on https://moinmo.in/HelpOnFormatting is completely
 different. I assume that's from the 1.9.8 version, correct?

The markup changed with Moin 1.6, if I recall correctly, and the 1.9.3 pages 
should describe the modern markup. Maybe the old help pages have been cached, 
although I would have expected a moin maint cleancache to have been executed 
during an upgrade, depending on how the upgrade was done.

 I cannot upgrade to 1.9.8 as our wiki is running on a major Linux
 distribution that, while current in other aspects, is only supporting
 Python 2.4 as the official, supported release.

I would imagine that 1.9.3 with backported security fixes would be good 
enough, although the issue then is who is responsible for backporting those 
fixes. I imagine that the vendor doesn't provide the Moin package for 1.9.3 
that you're intending to use (that is, you're using the source package from 
moinmo.in and not an OS vendor package) and thus isn't providing security 
updates for the code.

Typically, the advice given out in such situations is to try and adopt a later 
Python version to be able to use a later Moin version, which for enterprise 
distributions like RHEL might involve additional semi-official repositories 
like EPEL. Otherwise, you'd need to maintain your own Python installation 
specifically for Moin, too, but you can at least do so in a confined part of 
the system and not try and replace the system Python, which is generally 
regarded as a bad thing to do.

Paul

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Programmatic creating/editing of pages

[Paul Boddie]

On Monday 12. January 2015 11.49.27 Philip Colmer wrote:
 I've written a script that, every night, checks that the organisational
 pages are built from data taken from our LDAP directory.
 
 The code to do the page bit looks like this:
 
 ...
 try:
 editor = PageEditor(request,
 'Internal/meet-the-team/{0}'.format(pnNormalised))
 try:
 text = editor.normalizeText(personMainBody.getvalue())
 try:
 editor.saveText(text, 0)
 ...
 
 It works fine except for two areas that I'd like to overcome if the Moin
 API permits it:
 
 1. I'd prefer NOT to have page history for these pages. It takes up disc
 space and isn't really necessary.

I do wonder whether edits that don't change pages actually produce new 
revisions. I'm fairly sure that when I've imported pages using the page 
package functionality, it hasn't updated unchanged pages, but maybe that's 
something that the page package stuff does.

 2. I'd prefer NOT to have changes to these pages show up in the
 RecentChanges list. The reason for this request is because part of the
 update process requires me to update the photos for each person. Since I
 can't (easily) do a file comparison to see if the photo has changed, I
 replace all of the photos anyway just to be on the safe side. That is 200
 file updates every night which then swamps the RecentChanges list.

Once upon a time, I thought that the trivial edit feature suppressed 
RecentChanges entries, but I don't remember now what the actual effect of that 
is.

 The bit of code that does the photo is:
 
 if (person.photo != ''):

  if person.photo:

;-)

 AttachFile.add_attachment(request,
 'Internal/meet-the-team/{0}'.format(pnNormalised), profile.jpg,
 person.photo, overwrite=1)
 
 Does the API support either of options to reduce noise/files?

Are there any opportunities to make checksums of the images and to detect 
changes that way, perhaps incorporating checksums into filenames so that the 
old checksum is handy? This is just a quick suggestion that may get people 
thinking about better ones. ;-)

I suppose the worst case scenario here is history rewriting, which might not 
be supported by the API. I only ever recall doing operations via the API to 
append to the edit log and to add page revisions.

Paul

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
www.gigenet.com
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Fwd: data_underlay_dir Not being what it's supposed to be

[Paul Boddie]

On Sunday 12. October 2014 17.09.53 Rovanion Luckey wrote:
 Hi,
 I'm trying to set up MoinMoin using the packages in the Ubuntu
 repositories, nginx and uwsgi. I'm having an issue [0] where I get an error
 stating that the underlay directory is not accessible where
 data_underlay_dir is stated to be located in a directory not set in any
 config file.
 
 You see the error [0] says that data_underlay_dir is set to ./underlay
 while the wikiconfig.py clearly sets it to a non-relative url.

The wikiconfig.py file probably isn't used. See below for why I think this is.

 For completeness my site conf [2], uwsgi conf [3] and farmconf [4] is also
 provided in the links below.
 
 I've made sure to restart uwsgi after changing the configurations related
 to moinmoin, even though a reload should suffice. The nginx conf [5] points
 to the socket provided by uwsgi, has been restarted and .. well .. I'm
 running short of ideas.
 
 [0] http://paste.debian.net/125837/
 [1] http://paste.ubuntu.com/8546386/

In this copy of the configuration (wikiconfig.py), I see the following 
lines...

instance_dir = /usr/share/moin/

# Where your own wiki pages are (make regular backups of this directory):
data_dir = os.path.join(instance_dir, 'data', '') # path with trailing /

# Where system and help pages are (you may exclude this from backup):
data_underlay_dir = /usr/share/moin/underlay/ # path with trailing /

Note that neither instance_dir nor data_underlay_dir seem to be set to valid 
strings. Remember that this file is a Python source file and thus these values 
must be valid Python syntax.

Since this file seems to be for a single wiki and not for a farm (or instance 
thereof), I imagine that you aren't using this particular file, however. If 
this file were being used, you'd get a syntax error from Moin, certainly.

Meanwhile...

 [2] http://paste.ubuntu.com/8546401/

...in this file (mywiki.py) you might consider setting something like...

data_underlay_dir = '/usr/share/moin/underlay'

...just to see if it helps.

Paul

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Plugins: recommendations for accessible local directory?

[Paul Boddie]

On Tuesday 26. August 2014 02.01.10 Lars Kruse wrote:
 
 recently I upgraded the VisualSiteMap action [1] for moinmoin v1.9 and
 today I added the HoverCraft action [2].
 In both cases an external application is called in order to create one or
 more files locally:
 * VisualSiteMap: dot/neato/... creates an svg file
 * HoverCraft: a directory containing an html file and some more resource
 files is created
 
 To be of any use, these files need to be accessible via a URL.

If these things really need to create actual files, or if it's easier for them 
to be made to create files instead of just producing data on demand, then you 
could potentially use either the attachment or caching APIs in Moin, and then 
Moin could be made to serve things from the attachment or cache areas in the 
filesystem.

I can think of two things I've had something to do with that uses these APIs:

https://moinmo.in/ParserMarket/graphviz (uses the attachment API)
https://moinmo.in/ActionMarket/ExportPDF (uses the caching API)

Both of these invoke other processes and collect output directly from those 
processes instead of letting them write to files. This is arguably more 
elegant because you don't have to clean up random files generated by tools and 
can choose whether to cache the output or to just send it to the browser 
directly.

 Thus both actions are currently configured with two pieces of information:
 1) a local file path
 2) a URL which is mapped to the above path (via a webserver?)

You can use URLs which invoke actions to get cached or attached content, but 
you'll need to make sure that any URLs embedded in any generated data are 
suitable for subsequently requesting things from Moin. I seem to recall Moin 
supporting a nicer way of requesting attachments than explicitly invoking the 
AttachFile action, so you might even have an easier job ahead of you if you 
use attachments.

 The actions call their respective external application and put their result
 into the above local directory. The URL of these files is
 delivered/embedded to the user.
 
 This approach feels a bit clumsy, since the webserver requires manual
 configuration (mapping the directory to a URL) for each action separately,
 e.g.:
 
   AliasMatch /wikis/([^/]+)/_hovercraft-cache/(.*)$
 /var/cache/moin/HoverCraft/$1/$2
 
 (suitable for the HoverCraft action and for multiple wikis via farmconfig)
 
 Additionally the above approach ignores any ACL restrictions - but I could
 live wih that.

It's always worth remembering ACLs when developing actions to obtain data from 
the cache or associated with a page.

 Since at least the two above actions require this directory/URL mapping
 (separated for each wiki), I could imagine that maybe MoinMoin already
 includes something similar?
 Or is the preferred approach to turn the created files into attachments of
 the respective wiki page? This could work for VisualSiteMap but would be
 quite messy for HoverCraft since it creates multiple files.

I can't remember if there are any nice ways of creating cached bundles of 
files, presumably within their own subdirectories of a cache directory set up 
for this purpose, but even if the API isn't that helpful you could still write 
the necessary code to deal with creating such subdirectories: you'd only be 
getting the appropriate filesystem path from Moin and then appending the 
appropriate details in order to construct a specific path for any given 
purpose. Just be careful to sanitise paths in order to avoid data leakage from 
(or contamination of) the wider filesystem.

Hope this helps!

Paul

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Configuring URL prefix for Moin served via Nginx + Gunicorn

[Paul Boddie]

On Tuesday 27. May 2014 09.27.29 Darren Spruell wrote:
 Greetings,
 
 MoinMoin 1.9.7
 Gunicorn 18.0
 Nginx 1.4.1
 
 I have a single wiki instance that works correctly when served from
 the root of my site (/). I want to migrate it on the site now to be
 served from /wiki/home/ (e.g.
 http://www.example.org/wiki/home/HelpContents). When I configure this
 on Nginx and then set 'url_prefix_static' in the MoinMoin config, wiki
 pages are not served correctly. i.e. attempting to access
 http://www.example.org/wiki/home/ attempts to load a page named
 'wiki/home' and MoinMoin returns 404 with This page does not exist
 yet. You can create a new empty page, or use one of the page
 templates.

So you first need to make sure that Moin is served for that resource and not 
the root resource, and you then need to let Moin know that it is rooted at 
this new resource itself.

 I cannot find a config option to instruct MoinMoin that it is being
 served from a subdirectory of the site and to therefore operate under
 a URL prefix. I understand that 'url_prefix_static' is only for static
 media. I notice that
 http://moinmo.in/HelpOnConfiguration#Configuration_of_multiple_wikis
 documents a config option 'url_prefix' however various references make
 it look as if that setting is no longer used/suggested.

Yes, there's a mention of it in wikiconfig.py files that I've seen, but it 
appears to be obsolete.

 Gunicorn is a WSGI server but as opposed to uwsgi it uses standard
 HTTP as a service protocol; I think this prevents one from passing
 environment settings (such as SCRIPT_NAME) as one would for e.g. FCGI
 or UWSGI, etc. However I notice that placing the following in my
 moin.wsgi seems to fix he path finding:
 
 os.environ['SCRIPT_NAME'] = '/wiki/home'

Well, this should be presented to Moin by the Web server: that's what it is 
for! However, in moin.wsgi, you might be able to set the fix_script_name 
setting instead.

 To me, this seems like more of a hack than a solution.
 
 Current config details:
 
 # Nginx config section
 location /wiki/home {
 try_files   $uri @wiki_home_rewrite;
 }
 location @wiki_home_rewrite {
 proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_headerHost $http_host;
 proxy_redirect  off;
 proxy_pass  http://127.0.0.1:8001;
 }
 
 # wikiconfig.py
 class Config(multiconfig.DefaultConfig):
 ...
 url_prefix_static = '/wiki/home' + url_prefix_static
 ...
 
 Is there a way to configure MoinMoin to understand that it is being
 served from a URL with a prefix path and operate as desired without
 modifying the environment in the WSGI driver script?

If you can get away with fix_script_name, then yes. Otherwise, perhaps not. 
Again, without things like SCRIPT_NAME, scripts know nothing about their 
environment or the way they are deployed.

Paul

--
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Sync'ing 2 pages at different locations

[Paul Boddie]

On Wednesday 12. March 2014 16.51.39 Emmanuel Mayssat wrote:
 Hello,
 
 I am working on a page with several attachments on a personal MoinMoin
 install. I would like to 'sync' that page with the production one.
 
 There are apparently 2 ways of doing this.
 
 1/ An automated 'sync' as described in
 http://moinmo.in/HelpOnSynchronisation
 But I can't understand a thing and because there is no configuration
 example, this page is more confusing than helpful.

I don't have any experience with this.

 2/ A manual procedure which consists in packaging the page (with
 attachments) in a zip file. I can export (i.e. compress) the page +
 attachments in a zip file, but how to import it in another wiki? Where is
 the import utility?

You want to use the package installer:

http://moinmo.in/HelpOnPackageInstaller

I made convenience methods for moinsetup to handle package exporting and 
importing:

http://moinmo.in/ScriptMarket/moinsetup

But I think that you should be able to export a page using the PackagePages 
action in any wiki having it enabled. Then, using the package installer (as 
described in the first reference above) with the resulting zip file should 
permit you to import the packaged page.

Good luck!

Paul

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] still prob with docutil

[Paul Boddie]

On Saturday 22. February 2014 23.22.02 Renato wrote:
 Hi,
 I'm getting crazy :-(
 
 In a moinmoin page that speaks about rest, I read this:
 
 This is a *very* simple example. If you see two asterisks around the
 word very in the previous sentence, then the module docutils is
 improperly installed (or not installed at all). When the module
 docutils is there, the word is displayed in italics and this whole
 block of text is not displayed in a special source-code-like format,
 but like a normal part of the page
 
 I see the two asterisks, so, maybe the docuils module is installed
 improperly.

Is this a built-in page? Does it have the following at the top of the page 
text...?

#FORMAT rst

 I think Docutil are present in my pc.
 I'm wondering if I need to config moinmoin to let him know, where
 Docutil are.
 
 Can someone help me?

Sure. You're using Debian, I think, so try the following first:

dpkg -l python-docutils

The response should include a line that starts like this:

ii  python-docutils   0.8.1-8

Here, the version is the one provided by Wheezy. If you don't see ii at the 
start then you need to try the following using sudo or as root:

apt-get install python-docutils

Alternatively, if you're feeling ambitious or don't have root, you can install 
docutils from source. It isn't too difficult, but then you will need to teach 
Moin about the place it has been installed into.

Meanwhile, when using the system package, you should be able to avoid telling 
Moin about location of docutils, but perhaps only if you're using the system 
Python as well. I recommend using system packages for most things on Debian, 
especially for infrastructure that shouldn't change that often.

Paul

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] render as Rst one step ahead (maybe...)

[Paul Boddie]

On Friday 21. February 2014 19.54.36 Renato wrote:
 ok, From this page
 http://www.merten-home.de/FreeSoftware/moin2rst/manual.html#installation,
 I've found the doc and the file to use, to obtain rst.
 
 - I've downloaded it
 - extracted
 - putted on .../plugin/action and formatter folder
 - restarted apache2
 - login to my wiki
 - create a page
 - went to action menu
 but no action render as restructured text found :-(
 
 the Renderasrestructuredtext.py has root:root right. Could it be this
 the prob?

It depends on the permissions, but it probably has to be at least readable for 
www-data or whoever your Web server user is.

As far as I can see, the files need to be installed into the following places:

 * RenderAsRestructuredtext.py goes into the plugin/action folder
 * text_x-rst.py goes into the plugin/formatter folder
 * moin2rst.py looks as if it is a standalone script

I haven't tried this, but it seems as if it would work with recent Moin 
versions.

Paul

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Getting Introduced with the Community and Looking forward to Contribute to the Project as part of Gsoc 2014

[Paul Boddie]

On Sunday 9. February 2014 17.54.07 Rishabh Raj wrote:
 On Sun, Feb 9, 2014 at 10:05 PM, Nitika nitikaagarwa...@gmail.com wrote:
  
  I had installed the required necessary tools and setup the environment in
  my system needed
  for the contribution to open source software. I had got myself aware of
  the source to some
  extent and had forked on my github account. I had also read the
  contribution, development
 
 I'm pretty sure, we don't have MoinMoin on GitHub.

There's a very similar message on the mailman-developers list from the same 
sender, and I'm pretty sure Mailman doesn't use GitHub, either. Actually I 
think they use Launchpad and Bazaar, so that's two very unlucky guesses. ;-)

Paul

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Moin performance desastrous

[Paul Boddie]

On Saturday 14. December 2013 08.46.31 you wrote:
 Thanks Paul, but there is no Virus checker running on the machine.

Sorry, but I had to mention it: something for the checklist, as I said. The 
other thing I thought about was that a remote filesystem might be involved. 
Could that be the case?

As the Moin sources in MoinMoin.util.filesys say, this is needed for stat, 
rmdir and mkdir on win32, but I couldn't find any explanation of it or any 
experiences others have had. If you could perhaps instrument the failure with 
some kind of call to see if another process has the file open - maybe Windows 
even thinks that the same Moin process still has the file open - using the 
equivalent to the Unix fuser command (or looking in the /proc filesystem), 
then we might get a better idea of what is going on.

Paul

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Moin performance desastrous

[Paul Boddie]

On Friday 13. December 2013 13.39.14 Thomas Waldmann wrote:
 
  Looking into the ACCESS log nothing obvious caught my eye. The ERROR log
  is much more interesting. There are thousands of entries like this:
  
  WARNING MoinMoin.util.filesys:110
  mkdir(('...datacacheaplwikipagegroups__lock__writ
  e_lock',), {}) - access denied. retrying...
 
 Windows?
 
  What is going on here?! Advice is welcome.
 
 If you can find out what exactly is causing the access denied I worked
 around there, I'ld be glad to hear from you (I couldn't).
 
 Only happens on Windows AFAIK.

Virus checking software or similar helpful Windows-only phenomena? Various 
projects recommend excluding their directories from such software's coverage 
tables so that the helpful process that wants to scan files all the time 
doesn't happen to have a file open (and thus on Windows, exclusively locked) 
when the project's software needs to open it.

Maybe this is something different, though, but it's something for the 
troubleshooting checklist whenever Windows is involved.

Paul

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Enable CKEditor in Moin2

[Paul Boddie]

On Monday 9. December 2013 12.53.27 Thomas Waldmann wrote:
 On 12/09/2013 07:13 AM, Tal Hadad wrote:
  OK I saw this, but yet, isn't there a simple conversion from html to
  wiki and so reverse like moin 1.9.7?
 
 As you may have noticed, this stuff is neither simple nor unproblematic,
 it had quite some fundamental issues in moin 1.x.
 
 Also, (f)ckeditor is javascript stuff, so every customization there
 needs work in javascript (and I am not a js developer).

I don't remember the details of (f)ckeditor and how it actually does its 
thing, but I was introduced to the contenteditable support in modern browsers 
and played around with it somewhat. Was there any plan to look at supporting 
contenteditable in Moin? It would have to involve the same Moin-to-HTML round-
trip, and extra JavaScript controls would still be necessary to control 
formatting, and maybe this wouldn't end up offering any benefits over 
(f)ckeditor, but I just wondered if it had been discussed in the recent past.

  I read there is a massive work in conversion many formats to DOM and so
  in reverse, and I wonder if a same page could be edited once in WIKI
  format and once in HTML format.
 
 Theoretically yes, but:
 * there might be roundtrip issues
 * there might be fundamental issues
 * there is a lot of other stuff to do (for me)
 
 So, I won't put effort into implementing that in the foreseeable future.
 
 If you want to help, you can start improving the converters, looking out
 for roundtrip issues.

I'd agree with this: conversion is probably the key issue.

Paul

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] givenauth login

[Paul Boddie]

On Saturday 23. November 2013 19.21.51 r2d2 wrote:
 
 I installed moinmoin1.9.7 to one of my SL6.4 boxes. For authentication I
 want to use the apache web login. Apache login works, but moinmoin
 doesn't seem to get the REMOTE_USER.
 http://moinmo.in/HelpOnAuthentication

Assuming that you've added the GivenAuth instance to the auth setting, the 
usual reason for not getting anything in REMOTE_USER is that Apache is somehow 
letting you access the site without invoking the authentication machinery. Are 
you being prompted for a password? Is your site entirely protected by 
authentication directives?

 Any hints on how to fix this? Otherwise I would like to turn on loglevel
 debug, but I do not know how.

Moin logging is something I rarely use and need to look up every time, but you 
should be able to dig up a suitable config file in the MoinMoin distribution 
and then make sure that it gets loaded by moin.cgi or moin.wsgi. See the 
comments in those scripts for more details.

Paul

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Dynamic page(section) subscriptions

[Paul Boddie]

On Saturday 16. November 2013 22.55.54 Sascha Holzhauer wrote:
 
 I would be grateful if someone could give me some hints on the following
 challenge:
 The wiki has different service pages consisting of a table with
 columns date and user name.
 The aim is to subscribe users to those actions when others edit a row on
 some service page of that date when they are listed on another service
 page.
 
 Example:
 
 Service A
 01.01.   JohnSurname
 02.01.   MariaSurname
 
 Service B
 01.01.PeterSurname
 02.01.SamSurname
 
 For instance, Maria should receive an alert when someone changes Sam at
 02.01. in service B because she is listed for service A at that date.

So what you want to do is this: analyze an edit on a page (Service B), 
extract the date, search for the date in other pages, extract the username, 
and then notify those users?

All of the above is possible but probably not very convenient: use an event 
handler to detect a page edit, parse the change (a regular expression may be 
enough, but you would want the diff to begin with), perform a full-text 
search, parse each page in the search results to get affected users, then 
invoke a notification for each user.

 There is also some kind of overview page for each date named e.g.
 Service_0201 which includes relevant user names. However, these pages
 are filled dynamically with the information by include macros from the
 service pages and are thus probably not helpful regarding the alert
 challenge.

I wonder whether a different way of organising the underlying data might be 
better. Grouping the data by date might eliminate the need to perform a search 
to discover who to notify when the data changes, so that Service_0201 page 
might hold the actual data like this (using a wikidict notation for potential 
convenience):

 Service A:: MariaSurname
 Service B:: SamSurname

Then, any edit to the page could fairly easily cause a scan of the different 
entries and some notifications to be sent. You skip the awkward diff parsing 
and can hopefully just grab everybody's details.

To show the original Service A and Service B pages might then involve more 
work, however, but you could potentially write a macro to do that. This 
actually starts to approach the EventAggregator extension I wrote in some ways 
[1], but that extension only supports notifications in terms of RSS for 
particular event criteria, although you can use Moin search expressions to 
define which events/pages will be selected and thus appear in the RSS feed.

 It may also help to get some summary on how the subscription and alert
 process works (which modules are involved).

I can't provide immediate advice about subscriptions and alerts, but the event 
handler API is something I use in my ApproveChanges plugin [2]. Maybe it can 
provide some inspiration.

Good luck!

Paul

[1] https://moinmo.in/MacroMarket/EventAggregator
[2] https://moinmo.in/ActionMarket/ApproveChanges

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] [Student] Want to start contributing to moinmoin

[Paul Boddie]

On Monday 4. November 2013 15.46.11 Yesha Shah wrote:
 
 I am a computer engineering student. I know Python and I would like to
 start contributing to moinmoin. Can you please suggest how can I get
 started? It would be good if you suggest me some sites to read. I did check
 2 some bugs in the buglist. But then I was at a dead end about how to solve
 them as I don't have complete knowledge about moinmoin.

I imagine that you're a MoinMoin user already, so perhaps one way of getting 
into development is to identify a need you have and then see how you might 
address that need with an extension like a macro, action or parser.

One fairly easy starting point would be to develop a macro, just to gain 
confidence with how these things are written and deployed, and how they 
interact with the rest of the code. See the following page for some guidance:

https://moinmo.in/MoinDev/CreatingMacros

Once you get a macro working and see how it changes the output of a page, you 
will probably be able to write actions and parsers fairly easily, too. After 
that, you'll probably be giving us advice about Moin development. ;-)

Hope this helps!

Paul

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Creating a Wiki-Page

[Paul Boddie]

On Wednesday 30. October 2013 13.30.56 Andreas Kuntzagk wrote:
 Hi,
 
 I want to create a wiki page from a python Program. Following the
 documentation I managed to do that as the user running the webserver.
 However I want to run this program as a different user.
 Whenever I do this I get a permissions error:

[...]

 /share/cc_wiki/moin_cc/share/moin/data exists and is writable by the apache
 user but not by the user running the script.
 
 Version is 1.9.4

I tend to run scripts against a wiki by using sudo with the -u option to 
indicate the Web server user. It is also possible to use filesystem ACLs that 
allow unrelated users to write to the wiki's files (sharing the group assigned 
to files is the low tech equivalent when you don't have ACLs). For example:

setfacl -m u:youruser:rw somefile
setfacl -m u:youruser:rwx somedir

(You can combine this with find to do this to many files, and I generate a 
script to do this in moinsetup.)

However, if files are created by Moin, it can be tricky to get the ACLs to 
stick to these new files, although I'm sure that if I checked the 
documentation I'd find a reasonable solution for that, too.

If anyone has any better ideas, please let us know. ;-)

Paul

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Suggestions sought to how best to implement this request ...

[Paul Boddie]

On Monday 7. October 2013 14.48.19 Philip Colmer wrote:
  The MoinMoin.action.AttachFile module contains functions to work
  with attachments in a nicer way than manipulating the filesystem
  directly.
 
 Is there any documentation on how to programmatically attach a file to a
 page? I can only see documentation for checking if an attachment exists and
 getting the directory path and URL for a page.

Having suggested AttachFile as a way of adding attachments, I just looked at 
some code that I know adds attachments programmatically - the graphviz parser 
[1] - and it appears that it uses AttachFile only to discover the directory of 
attachments for a page. Here's what it does (edited slightly):

# Use the request to create or obtain the directory for a given page.
attach_dir = AttachFile.getAttachDir(request, page_name, create=1)

# Obtain the pathname for the given leafname in the directory.
pathname = join(attach_dir, leafname).encode(config.charset)

After this, the extension just writes to the file with the given pathname (or 
rather it gets graphviz to do so). Looking inside the 
MoinMoin.action.AttachFile module, I see that the add_attachment function does 
more or less the same thing, but it also adds an entry to the history which 
might not be something the graphviz parser would want to do (since it is just 
using the attachments as temporary storage for generated images that can be 
shown conveniently by Moin).

So, maybe add_attachment is what you want unless you don't want to add history 
entries to the edit log, in which case doing only some of what that function 
does (as described above) is probably satisfactory. And if you're doing this 
kind of thing from outside Moin and are just looking to import attachments in 
batch mode, you could instead use the page package infrastructure [2], but 
I'll leave that for another message if you're interested in that.

Paul

[1] http://moinmo.in/ParserMarket/graphviz
[2] http://moinmo.in/HelpOnPackageInstaller

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Suggestions sought to how best to implement this request ...

[Paul Boddie]

On Tuesday 24. September 2013 17.44.05 Philip Colmer wrote:
 Sorry that I couldn't come up with a better subject line ... I've been
 asked to migrate
 
 http://www.linaro.org/linux-on-arm/meet-the-team
 
 onto our internal MoinMoin wiki. The content from that page comes from the
 CMS that sites behind www.linaro.org and I am *not* going to be migrating
 that. Instead, my intention is to use the corporate LDAP directory to store
 the data and use some Python code to pull the data back from LDAP.
 
 I am, however, hitting some mental stumbling blocks and I'd welcome
 thoughts or comments on these:
 
- The way that the lists are arranged into three columns seems to be
some CSS voodoo that I'm trying to unpick. I'm not sure how to mimic
 that in MoinMoin since calling CSS directly is tricky ...

Without actually looking at the CSS, my way of reproducing this would be to 
use float: left on the lists. That might actually do enough, but usage of 
clear: left and clear: right would also help. If you were doing this in 
the source of a normal wiki page, you'd be able to attach CSS to tables using 
tablestyle...

||tablestyle=float:left This table floats left! ||
|| Some content in the page. ||

...but putting lists inside table cells would be awkward: the standard Moin 
tables allow only single line cells/rows, and I think you'd have to use the 
MiniPage macro which doesn't really lend itself to readability:

http://moinmo.in/MacroMarket/MiniPage

You could use my ImprovedTableParser to put lists inside the extended tables 
it supports, since it does allow cells to be defined across multiple lines:

http://moinmo.in/ParserMarket/ImprovedTableParser

I imagine, however, that since you're using content dynamically fetched from 
LDAP, you're probably just going to write your own Moin extension, perhaps a 
macro that you then insert into a page like this...

GetLDAPList(Office of the CEO)

...and then you will have the freedom to generate whatever HTML you like for 
the retrieved content. In your macro, you'd probably use the formatter API to 
make the lists like this:

def execute(macro, args):
fmt = macro.formatter
...
output = []; append = output.append
...
append(fmt.bullet_list(on=1, attr={class : stafflist}))
...
append(fmt.listitem(on=1))
...
append(fmt.listitem(on=0))
...
append(fmt.bullet_list(on=0))
...
return u.join(output)

If you can re-use the CSS from before, you could name the CSS class for each 
list as above. Otherwise, I think you can define a style attribute. If not, I 
probably have a patch against Moin that lets you define one. ;-)

See the MacroMarket for examples of macros:

http://moinmo.in/MacroMarket

There is some sort of guide to writing macros, but just looking at existing 
simple ones in the MoinMoin.macro package can be just as informative:

http://moinmo.in/MoinDev/CreatingMacros

- Clicking on an individual (e.g.
http://www.linaro.org/linux-on-arm/meet-the-team/philip-colmer/) results

I thought I recognised your name from the Acorn era! :-)

in more normal layout although, again, the HTML seems to have some
interesting CSS references but I might be able to ignore more of that
 and use a table instead to try to get to a similar look. My thinking here
 is that a script running directly on the server would run regularly and
 build static wiki pages based off LDAP data. For the person's photo, my
 research into MoinMoin seems to suggest that an attachment would seem to
 be the best solution as I can transfer the JPEG data from the LDAP server
 and store it inside the attachments directory for that page. Is there an
 API for storing attachments or should I just write directly to the page's
 directory structure?

You could certainly have a special homepage template and populate it from 
backend data, either generating the entire page every time something changes 
or generating an initial page that then uses macros to fetch backend data 
(maybe caching it if you're worried about performance).

Meanwhile, if you're looking to store images inside the wiki instead of just 
referencing them in some conventional Web space, attachments are probably the 
way to go. The MoinMoin.action.AttachFile module contains functions to work 
with attachments in a nicer way than manipulating the filesystem directly. I'd 
be inclined to serve images from a vanilla Web directory unless you need the 
possibility for people to change them in the wiki itself, however.

- Similarly with the lists of people in a group (e.g.
http://www.linaro.org/linux-on-arm/meet-the-team/office-of-the-coo), my
intention is to build a wiki page for each group. However, if I've gone
 for the aforementioned approach of storing the images as an attachment for
 an individual page, can I reference that from another page? If not, I
 guess the better solution would be to store all of the staff images in a
 central directory and then consistently link to 

Re: [Moin-user] Spam on Moin wikis and anti-spam best practices

[Paul Boddie]

On Tuesday 3. September 2013 14.41.16 Steve McIntyre wrote:
 On Tue, Sep 03, 2013 at 11:04:28AM +0200, Thomas Waldmann wrote:
  perhaps we need safer defaults
 
 I don't think we should change defaults within a stable release series.
 
 But we can change how example configs look like and document stuff better.

Actually, this is what I was really suggesting. Although I think that Moin 
should be more secure out of the box, it is impossible to deliver something 
acceptable for every audience.

One of my aims with moinsetup (http://moinmo.in/ScriptMarket/moinsetup) is to 
be able to help people configure Moin for different kinds of audience. People 
should be in the habit of reviewing their configuration before exposing their 
site in whichever environment they have chosen.

  Really control registration: for extra control over registration,
  perhaps use the
  http://www.moinmo.in/MoinMoinPatch/VerifyAccountCreationByEmail patch
  to require e-mail verification of account registration.
 
 I wouldn't recommend this patch until someone cleans it up (see my
 comments there), does more testing and reviews the code again.
 
 Ah, bugger. Sorry, I hadn't seen the comments there. I'm subscribed to
 the page, but it looks like maybe my spam filter ate it or
 something.
 
 I'm in the middle of cleaning up and re-targetting my patches against
 1.9.7 right now anyway. I'll update the page shortly.

As another layer of defence, I think that this extension would be a valuable 
addition to Moin.

  Does anyone have any opinions about the above?
 
 Good writeup, should be supplemented with a modified default wiki/farm
 config.

I may add this and put the writeup on the Moin Wiki.

 One can add to regularly review logs, esp. after spam gets in. So one
 can sometimes identify static IP addrs only used for spamming (put them
 in moin's hosts_deny or handle via web server) and also textchas that
 have been broken and should be replaced.
 
 I've also added support for calling out to an external program at
 account creation time to see if a new account should be created, based
 on email/IP/account name. I've got quite a few extra scripts written
 locally to help with monitoring account signups and managing the
 blacklists too.
 
 More helpful things here would include:
 
  * better support for network addressing for blacklisting (something
that understands CIDR rather than just .startswith)
 
  * support for moderation - new account holder should need to have
their first few edits approved by existing users

There are tricks that other systems like WordPress (and its plugins) use to 
detect and filter out spam. I have indicated an interest to look into this, 
but all this stuff takes time, and I don't currently feel that I am in a 
position to be spending my time on developing such things.

Still, increased adoption of the tools we do have available would probably 
help many people, in my opinion.

Paul

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

[Moin-user] Spam on Moin wikis and anti-spam best practices

[Paul Boddie]

Hello,

I've noticed a lot of spam on various Moin-based wikis recently, and I think 
that this is giving various users and admins reason to reconsider their use of 
Moin, rightly or wrongly. Although there are guides to anti-spam measures, 
Moin isn't really set up to resist the ills of the Internet by default, and 
perhaps we need safer defaults and a coherent guide to the techniques 
available to defeat spam.

My suggestions, which I will gladly write up in more detail, are as follows:

Control access: decide on whether anyone can use or contribute to your wiki 
and thus who your users are; if you would prefer some form of identification 
or if you feel that it would help you identify good or bad contributions at a 
glance (an IP address or hostname in RecentChanges doesn't say a lot), 
restrict access using the acl_rights_default setting.

Control registration: if your users are a predefined set controlled by other 
means, register them separately and disable the newaccount action using the 
actions_excluded setting. If you need users to be able to request 
registration, consider enabling textchas to make sure that only suitable users 
can register.

Really control registration: for extra control over registration, perhaps use 
the http://www.moinmo.in/MoinMoinPatch/VerifyAccountCreationByEmail patch to 
require e-mail verification of account registration.

Control editing: where the set of users is not limited and where people may be 
able to register and become eligible for editing, enable textchas to make sure 
that only suitable users can make edits. If you feel that users should be able 
to edit without textcha questions upon being registered, add them to the group 
specified in the textchas_disabled_group setting as soon as you can.

Challenge editors properly: it should be said that if spammers have guessed 
the answer to a textcha question in order to register, they will be able to 
guess the answer to that question should it be asked upon editing, so it is 
vital to have high-quality textcha questions. The existing HelpOnSpam page 
provides plenty of advice on such matters.

Really control editing: one action that puts edits in approval queues is 
http://www.moinmo.in/ActionMarket/ApproveChanges which effectively hides spam 
edits from most wiki users, although wiki reviewers will still be faced with 
these edits, albeit tucked away in subpages that can be deleted in their 
entirety if it all becomes too much work.

Does anyone have any opinions about the above? I suspect that some wikis are 
let down by poor textcha questions or missing access control policy, so I'd 
like to be able to have something to show to the admins before they give up on 
Moin or on wikis in general.

Paul

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] moinmoin and xapian unindexable object

[Paul Boddie]

On Thursday 25. July 2013 13.22.49 Thomas Waldmann wrote:
  I am using MoinMoin 1.8 and ...
 
 Is there some special reason you use an outdated / unmaintained version?
 
 See also: http://moinmo.in/SecurityFixes

Not speaking on behalf of the inquirer here, but I have various wikis on my 
own machine which still run 1.8. Since they aren't meant to be exposed to the 
Internet, I'm not going to upgrade them because it would be a distraction, and 
upgrading my OS distribution (and discovering the incompatibility mentioned 
earlier) was already enough of a distraction. I suppose that performing a Moin 
upgrade would have been only a bit more work, but you never really know.

I agree that people should be moving to 1.9, especially after the hardening it 
has received in recent months.

Paul

P.S. Now that I've upgraded my distro, I might conceivably get to spend a bit 
more time on Moin 2, especially since it provides Python 2.7 as the default 
and this appears to be what Moin 2 prefers.

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] moinmoin and xapian unindexable object

[Paul Boddie]

On Wednesday 24. July 2013 04.51.10 Robert Pitt wrote:
 Hello,
 I am using MoinMoin 1.8 and trying to set up the xapian indexer (v1.2.5-1).
  Those pages that contain FullSearchCached(category:CategoryXXX)
 are displaying an unindexable object error message. Any ideas on how to
 fix this?

I recently upgraded my system to a distribution where the Xapian packages 
cause this problem. It turns out that an API change occurred in the Xapian 
Python bindings, and it looks like Moin 1.8's code uses the deprecated and now 
unsupported way of referring to various things within Xapian.

I've uploaded a patch to the following place:

http://www.moinmo.in/MoinMoinBugs/1.8XapianSearchingFailsWithUnindexableObject

Let us know if this fixes the problem for you!

Paul

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Anchor from included files ... not included

[Paul Boddie]

On Monday 22 July 2013 01:52:19 Emmanuel Mayssat wrote:
 I have a parent wiki page which consists of a series of Include
 directives/macros. Although the text is included correctly, the anchor
 links are not. Is that a feature or a bug?

The Include macro should cause the anchors in the included page to 
be qualified so that they do not conflict with anchors in the parent page 
or other included pages. This happens for headings which are assigned anchors 
by Moin automatically, and you can see the result in any page with a table of 
contents that is including other pages. For example:

http://mercurial.selenic.com/wiki/FAQ

See how links are qualified, here for How does merging work? on the 
GeneralUsage page:

http://mercurial.selenic.com/wiki/FAQ#FAQ.2FGeneralUsage.How_does_merging_work.3F

When the GeneralUsage page is displayed normally, there is an 
anchor How_does_merging_work.3F for the same content.

I would expect to see explicitly defined anchors modified in the same way on 
pages that include other pages containing such anchors. Are you certain that 
the HTML source has no anchors whatsoever as opposed to qualified anchors?

Paul

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Inject CSS for a particular page

[Paul Boddie]

On Sunday 21 July 2013 06:36:01 Emmanuel Mayssat wrote:
 I would like to change the style of headers for a subset of pages.
 How can I inject my css stylesheet in a particular page?

For all pages, you can obviously change the stylesheets configuration 
setting like this (not tested):

  stylesheets = [(screen, /css/mystyles.css)]

This augments the stylesheets mentioned in the theme class. See the ThemeBase 
class in MoinMoin/theme/__init__.py for the default definitions.

To affect only some pages, it might be necessary to change the theme code or 
to override a theme with extra code to insert references to styles and 
scripts (with regard to your other question). The html_head method in a theme 
(see the ThemeBase class for details) invokes various other methods to do 
this work and either those methods or html_head itself could be customised to 
insert extra stylesheet and script references in a more flexible fashion.

You might test the page name and insert extra stuff in html_head like this:

  html = ...
  if d[page].page_name in (SpecialPage, ...):
  # Refer to .../common/js/special.js
  html.append(self.externalScript(special))
  # Refer to .../theme/css/mystyles.css
  # (you have to install mystyles.css in the theme's css directory)
  html.append(self._stylesheet_link(True, screen, mystyles.css))
  return '\n'.join(html)

You could make a new theme and override html_head, adding your own stylesheet 
and script references to the string that comes back from the superclass's 
html_head, or you could change the existing themes. I can't think of a nice 
and quick way of doing this for all themes at the moment, but maybe there are 
some tricks that can be used. (You could change html_stylesheets in 
ThemeBase, for example, but that would leave you with local modifications to 
Moin itself, which isn't always desirable.)

Paul

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Immutable pages

[Paul Boddie]

On Saturday 06 July 2013 14:24:14 Frank Becker wrote:
 Hi all,

 the summer starts and the computers get mad.

 Every page in my Wiki is immutable now. A few days ago there were no
 problems with the wiki and every page was editable. And I can write:  I
 didn't do anything !! hands up :-)

But has anything else changed? Have any system updates been applied recently?

 I have two copies of the wiki on two different computers and on every
 computer all the pages are immutable.

With two different computers involved, one could also suspect system updates 
if they both run the same operating system distribution. What about your 
browser? Are you still authenticated when you try and access the wiki?

 Really: There were neither chances in the acl nor in the configuration
 or in the python setup.

What does your ACL configuration look like? I imagine that you do have some 
rule in place to prevent unauthorised editing, so we might need to see why it 
is that you are no longer considered to be authorised.

 Ok the question is: What can I do to get every page editable?

Let's look at the configuration first and consider any changes that may have 
taken place in the environment.

Paul

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Cracked...advice sought on how to proceed

[Paul Boddie]

On Sunday 16 June 2013 19:09:36 Desmond Rivet wrote:
 Hi all,

 I'm running a personal MoinMoin wiki.  I've recently discovered that I've
 been cracked.  I'm finding lots of entries in the data/pages directory that
 look like:

 zupeginwuxi397/edit-log
 6pm_Offer_Coupon_Codes/edit-log

 All the edit-log files (that I've checked) appear to be empty.  The file
 also appears to be the only contents of these bogus pages/directories.  As
 I said, I have a ton of these in my data/pages folder.  And it's been going
 on for a while, judging by the backup I've looked at.

These are attempts to create pages, and I think that a bug was reported 
recently about such denied attempts still creating files, even though the 
pages will not be created:

http://comments.gmane.org/gmane.comp.web.wiki.moin.general/8998

The following fix was described:

http://hg.moinmo.in/moin/1.9/rev/6489ec33874d

 I'm not sure how it happened or what the intent was.  I'm not sure what
 exactly has been compromised.  Can I just change my login password and get
 a better SSL certificate? (I always logged in via https, but maybe the
 certificate was compromised).

Provided that you're running a fixed version of Moin that isn't subject to 
vulnerabilities, I rather suspect that you're seeing the effect of the 
problem mentioned above.

 That being said, all is not lost. It's fairly easy for me to pick out my
 own pages from the mess - looking for folders that have a revisions
 subfolder seems to do the trick.

 So I'm seeking some advice on how to proceed.  Can I simply rm -rf the
 bogus directories from the file system?  If I do this, will I have to
 update some other cache file?

I don't want to give concrete advice here, but I imagine that you could remove 
the bogus directories. If Moin has a record of the pages elsewhere, it will 
probably just ignore them if it comes across something like a log entry 
referencing them. Maybe the despam action helps in this situation, but I 
wouldn't know.

 Should I re-install MoinMoin?  If I do, is there a way to re-import all my
 original pages into the new wiki (assuming I pulled out all the pages from
 my old wiki) ?

I wouldn't immediately re-install Moin. It might be interesting to know what 
kind of authentication measures you provide, whether you have a restrictive 
ACL policy, and whether the newaccount action is enabled. Generally, to 
prevent bogus edits you can require users to be registered in order to make 
edits, you can thereby require authentication, and you can forbid new 
accounts by putting the following in the class in your configuration file:

actions_excluded = [newaccount] # plus any others you exclude

At that point, maybe the only new files that get created are session files and 
cache files, as far as I can tell.

Paul

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] convert moin moin to OSQA format

[Paul Boddie]

On Wednesday 12 June 2013 16:41:08 Kamal Ahmed wrote:
 Hi,
 Is it possible to convert moin moin to OSQA (http://www.osqa.net/) ?

It's amusing that the OSQA Wiki is using Atlassian Confluence:

http://wiki.osqa.net/display/docs/Home

 If so is there a tool available ? has any one tried it ?

How would you convert general content into the QA format?

According to the user guide [*], the individual contributions/fragments use 
the largely awful Markdown syntax [**].

[*] http://wiki.osqa.net/display/docs/OSQA+User%27s+Guide
[**] http://daringfireball.net/projects/markdown/syntax

From my experiences converting between markup languages [*] and also parsing 
Moin syntax for various Moin extension purposes, I would anticipate a lot of 
problems in getting Markdown to faithfully reproduce the output of 
non-trivial Moin markup.

[*] http://moinmo.in/ConfluenceConverter

Paul

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] TypeError after upgrading to 1.9.6

[Paul Boddie]

On Thursday 07 February 2013 12:05:19 Nico Zanferrari wrote:
 Forget it, it was my fault (just a file access problem ;-).

[...]

File /usr/lib/python2.6/site-packages/MoinMoin/Page.py, line 917, in
  parse_processing_instructions
  if args in i18n.wikiLanguages():
  TypeError: argument of type 'NoneType' is not iterable

Could you share with us which permissions were wrong? I encounter this bug 
occasionally and it's written up here:

http://moinmo.in/MoinMoinBugs/argument%20of%20type%20%27NoneType%27%20is%20not%20iterable

It would be good to identify it and get rid of it for good. That would mean 
producing a better error for permissions problems.

Paul

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Installing Help in 1.9.6

[Paul Boddie]

On Monday 28 January 2013 00:08:21 Peter Olsen wrote:
 Ladies and Gentlemen,

 Unless I'm reading the LanguageSetup page incorrectly (certainly possible)
 I believe I should be able to install the Help and System pages using some
 combination of Install links at the bottom of the LanguageSetup.  I can't
 find them  I've seen them in other installations, but not in mine.  clearly
 I'm missing something.   My question is whether it's the ability to
 understand the instructions or the missing links to which those
 instructions refer.

You have to be superuser to use those links, I think, but I can't remember if 
you also have to be superuser to see them. I guess you already are superuser, 
but I thought I ought to mention it just in case.

Paul

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Lost Moin-Moin central wiki

[Paul Boddie]

On Saturday 01 December 2012 13:41:10 Thomas Waldmann wrote:
  Recently I upgraded to version 1.9.5 after many happy years with
  1.8.*.  When I did so  I lost all my personal modifications (page
  layout, etc)

 If you are speaking of a custom theme, you likely need to update it for
 1.9. Same is true for some other extensions, esp. if they access stuff
 in the request object (as moin 1.9 is using werkzeug/wsgi there, which
 is different from the custom stuff we had before).

   but, worst of all, I lost connectivity to the central wiki on which
  most of the documentation can be found.  For example, a title search
  on format comes up empty.  A text search returns only pages from my
  local wiki.

 This is way too unspecific and lacking important information to post any
 really helpful answer.

Is this not a reference to the help pages? Depending on how the upgrade was 
done, it's possible that the inquirer has a Wiki without various underlay 
pages which then have to be installed separately in 1.9 as page packages from 
the SystemPagesSetup page.

Similarly, any custom theme would go away if the upgrade was more like a fresh 
install and a migration of the old data. But I'm just guessing here.

Paul

--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Problem with GivenAuth configuration, through Apache digest?

[Paul Boddie]

On Tuesday 06 November 2012 21:13:31 fero14041 wrote:

 [Wishes]
 As there could be other services provided by the server,
 such as Mercurial's repositories, an instance of Trac, etc.
 I'd like the users to log themselves to each with same shared account
 across them (one per user), ideally managed by Apache's digest
 authentication. MoinMoin's doc clearly points how this could be possible,
 with ``GivenAuth`` authentication method.
 This seems to not be sufficient::

 auth = [GivenAuth(autocreate=True)], MoinAuth()]
 auth_methods_trusted = ['given']

I'm not familiar with the auth_methods_trusted setting, but I think this only 
affects the Trusted ACL group.

 [Problem and tries]
 I did not succeed in letting Apache give
 authentication to MoinMoin. I tried:
 - different installs (with packages provided by server's distribution,
 or from source);
 - carefully reading the documentation (many times, perhaps not enough ?-);
 - testing different configuration variants;
 - searching for similar report in bugs and mailing list archives
 (Google Groups) or
 - through the web (found few:
 http://blog.nyaruka.com/apache2-http-digest-auth-and-moinmoin, also
 https://gist.github.com/498124).
 So I highly suspected remaining problem simply occurs in a bad
 configuration.

You have certainly done a lot of preparation. :-)

 [Tech. context]
 This server runs on Debian Squeeze (up to date),
 web pages are served by Apache (2.2.16-6+squeeze8), mod_wsgi (3.3-2)
 and Python 2.6.6

 [Demonstration]
 In order to give you most informations,
 configuration template files used are provided at:
 http://moin.poeulfs.org/hg/pb_apache_digest_auth/file/tip/
 and specially ``etc/wikiconfig.py`` for Moin instance config.,
 and ``etc/httpd.conf`` for Apache's one.
 I also put two instances of Moin from different version, and same config,
 one at version 1.9.4 provided by Debian package (in current Squeeze
 backports), and the other in a dedicated virtualenv with latest stable
 release 1.9.5.: http://moin.poeulfs.org/test/moin194/
 http://moin.poeulfs.org/test/moin195/

I tried these with the user account and found that after selecting Login by 
Apache and logging in, only the login page is given the credentials: 
navigating to another page shows Login instead of user as the username in 
the navigation bar.

 For each instance, there are:
 - following users and groups:
   - one superuser (``fero14041admin``),
   - one ``AdminGroup`` with one admin user (``admin``, password like
 login), - one ``TestGroup`` with two regular users (``user`` (pwd id.) and
 ``fero14041``);
   - all default rights are defined in config by::

 acl_rights_default = (uAdminGroup:read,write,delete,revert 
   uTestGroup:read,write 
   uAll:)

 - a theme derived from `modernized`, putting in page's header an additional
   link to ``login`` page and requiring Apache authentication.

 Finally, those instances' logs, and specially that related to login,
 are readable at:
  http://moin.poeulfs.org/test/viewlogs/logs

I suppose I'm seeing successful authentication in the logs, but I think your 
problem is actually in your Web server configuration:

Location /wiki/login
Require valid-user
/Location

This only enforces authentication for the login resource, meaning that you 
only ever activate authentication for that resource, and the credentials 
never get passed to the Wiki for anything else, such as /wiki/FrontPage and 
so on.

HTTP authentication can be infuriating in cases like this. If you change the 
above to this...

Location /wiki
Require valid-user
/Location

...then you won't be able to let users in without authenticating with Apache. 
Thus, logging in using Apache becomes all or nothing.

Of course, you could publish the same Wiki at multiple locations and protect 
one of them, so that you would have the above for authenticated users and 
something else for people who are anonymous or who might log in via MoinMoin 
itself, exposed at /wiki-public or whatever. That's not very elegant, I know.

Maybe there's a way of having a separate login resource that performs some 
kind of authentication, sets some kind of authentication token, and then Moin 
can be made to read that token and authenticate people. That sounds a bit 
like OpenID, but I'm thinking of something much less complicated.

 So, I would appreciate any help your could provide, to understand
 what I am doing wrong ^^;) (or if it's a bug and requires a report)...
 and of course share with my users all the power of MoinMoin!
 And thank you for reading this long message.

 Cheers,

 -- fero14041


 PS: Please excuse strange wordings and/or phrasings, as English is not
 my mother language.

It would take me a long time to write a response in French, but your message 
is very clear and comprehensible. I hope at least some of what I've written 
makes as much sense and is somewhat helpful. :-)

Paul

Re: [Moin-user] Moin CGI script permissions on RedHat RHEL6.3 and CentOS6.3

[Paul Boddie]

On Monday 16 July 2012 19:51:59 Reimar Bauer wrote:
 Just a question

 is there no mod_wsgi on sel linux?

I haven't really looked at mod_wsgi on RHEL. There might be complications 
involved with defining a SELinux policy since I understand that mod_wsgi 
deploys a daemon and that kind of activity has to be explicitly enabled. I 
think I had to do something similar to this for PHP and MediaWiki so that 
Apache processes could talk to MySQL.

See here for more of this kind of thing:

http://selinuxproject.org/page/ApacheRecipes

 Or why do you use CGI?

Actually, I often use CGI because it is very easy to deploy and because I 
haven't bothered to set up mod_wsgi. The principal pitfall with CGI occurs 
with Moin 1.9 because Moin wants to serve static content itself, rather than 
leave it to Apache, and doing so using CGI really affects performance. A few 
configuration changes to use Apache for static content, just as is done with 
Moin 1.8, and performance is reasonable again.

Some people find setting Apache up to be too much work, but defining a 
ScriptAlias and an Alias is pretty easy - probably easier than 
troubleshooting mod_wsgi if that is causing trouble - and I have my moinsetup 
tool to handle the pathname calculus that usually causes problems when 
configuring Apache to serve content.

I do aim to use mod_wsgi a bit more, though.

Paul

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Starting the Test Editor

[Paul Boddie]

On Tuesday 12 June 2012 00:15:19 Dave Hellewell wrote:
 I'm unaware of any shortcuts I can use to start the text editor in raw
 text (or any other mode). To get around this, where pages are long, I
 periodically embed a link similar to:

 [[http://myurl/wiki/SomeLenghtyPage?action=editeditor=text|Edit this
 page]]

 This lessens the tedium of having to scroll to the top of the page in
 order to click the Edit Text link when maintaining pages.

 Are any list members aware of a better way of doing this? Is there a
 shorthand version for the link I'm using, or are there any mechanisms
 that allow shortcuts (key combos etc.) to open the editor?

For long pages, I tend to use Ctrl-Home or Ctrl-End to respectively navigate 
to the start or end of the page, and then click on the edit link I expect to 
find there. ;-)

You can, of course, split your page into sections (perhaps subpages), include 
them in another page (perhaps a parent page), and configure the sections' 
Include macros to show edit links for those section pages. See the following 
for some ideas:

http://moinmo.in/HelpOnMacros/Include (see editlink)
http://moinmo.in/Bounty/SectionEditing (see the end of the page)

Paul

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Developer Introduction

[Paul Boddie]

On Saturday 26 May 2012 06:53:28 Rashad Tatum wrote:
 MoinMoin Developers,

 My name is Rashad Tatum. John Sullivan recently contacted me and requested
 that I introduce myself to the MoinMoin community. I am currently a senior
 student at Southern Polytechnic State University studying Computer Science
 and Mathematics. I have expressed interest in helping with the MoinMoin
 project. I am particularly interested in helping convert wiki pages to
 MoinMoin.

 Please let me know how I may help.

Thomas already replied and wondered whether the Wiki conversion you're 
thinking of has something to do with the Confluence converter:

http://moinmo.in/ConfluenceConverter

As I noted in a message sent to the mailing list for that project...

http://lists.bjdean.id.au/pipermail/mmwiki/2012q2/92.html

...I've written some code that produces a basic Moin conversion of a 
Confluence Wiki (links, headings, lists, parsed regions) but still needs to 
support user profile migration and more advanced syntax. See this plain 
non-https link for details:

http://hgweb.boddie.org.uk/ConfluenceConverter/

Currently, the effort seems to be stalled, partly because I haven't had time 
to work on it, and partly because there doesn't seem to be much activity 
around the project in general. If you want to lend a hand, you could download 
the necessary code (see above) and the data...

https://gitorious.org/confluence2moinmoin/main/trees/master/data/import/20110621

...and then see if you can generate the page packages. Doing conversion 
round-trips can be tedious (setup a Wiki, import the pages, verify the 
content, repeat...), and I recommend moinsetup if you're not completely 
familiar with Moin (see the README.txt file for details).

Feel free to contact me or the mmwiki list if this is what you're interested 
in working on:

http://lists.bjdean.id.au/cgi-bin/mailman/listinfo/mmwiki

Sorry to everyone who isn't interested in migrating Confluence Wiki data to 
Moin!

Paul

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Diagnose and fix performance problems?

[Paul Boddie]

On Thursday 03 May 2012 00:15:31 Thomas Waldmann wrote:
   Did you use apache/mod-wsgi or cgi? cgi is slow.
 
  Our servers do not offer mod_wsgi, so I think we're currently using
  some sort of WSGI-- Fast CGI wrapper. Could this be a major cause of
  the problems?

 Well, I can't tell much about the layers below moin (esp. not for
 software I do not use myself), but in principle, fastcgi should be of
 almost same performance as mod-wsgi. A little more software (likely
 flup) in between moin and web server, but still fast.

 Plain CGI (not fastcgi) means loading and initializing all the code for
 each request and terminating after that one request is processed.

Although Thomas wrote that CGI is slow, it isn't necessarily super-slow, just 
slow compared to WSGI. Even then, there are lots of things that can overwhelm 
the overhead of CGI in terms of performance costs, even if you've switched to 
WSGI and are convinced that everything should be much faster.

The classic example of this is any functionality that makes use of page 
searching: perhaps long-running processes may be fortunate when scanning 
pages for, say, category information if it gets cached over time (although 
the filesystem cache would help for CGI processes, too), but enabling Xapian 
for Moin 1.x provides significant benefits regardless of the means of 
deployment.

 FastCGI as well as mod-wsgi means long-running processes which are only
 rarely terminated and restarted and thus is much faster and less
 overhead.

Agreed. Still, if things are taking 10 seconds and there isn't some kind of 
pathological script reloading going on, it may be something other than the 
deployment technology.

I have in the past enabled the timing information to spot bottlenecks, 
although this merely indicated that searches were slow and that I should 
enable Xapian support. On your site, the only unusual stuff looks like some 
banner-related JavaScript and the delightful Google Analytics code. Nothing 
like fancy but expensive Moin macros as far as I can tell.

Paul

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Print a page in moinmoin

[Paul Boddie]

On Thursday 26 April 2012 14:28:26 Manfred Lotz wrote:
 Hi there,
 After happily converting my existing wiki to Moinmoin I wanted to print
 a page (unfortunately I didn't test it before).

 The problem I'm facing is that the print looks like a print of a
 presentation page. Instead of a single A4 page I got 4 pages in
 landscape.

What are your print settings in your browser?

 I want the text to appear on paper as normal text in A4
 portrait.

The print stylesheets - what the browser uses to format pages for printing - 
depend on which theme is being used, but generally they just remove all the 
navigation and furniture that you usually see around the page content and 
only preserve the page text, so you should get a fairly plain printout by 
default, but the paper size and orientation are things your browser will be 
in control of, not the stylesheet.

 Anything, I can do to get it like I want?

I recommend checking your print settings and verifying that the paper size is 
A4, that the output is scaled to 100%, and that you have one page per side. 
Firefox is a bit confusing in this respect as you have the print preview 
settings and then the actual printer settings. I recommend tuning the preview 
to look more or less correct and then verifying that, when choosing to 
actually print, you aren't putting more than one page per side or anything 
like that.

Paul

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Very slow page saving caused by notifications

[Paul Boddie]

On Monday 23 April 2012 15:11:47 Steve McIntyre wrote:
 On Sun, Apr 22, 2012 at 02:27:16PM +0200, Thomas Waldmann wrote:

 caching
 ===
 sometimes stuff can be accelerated by adding a cache. but if you have a
 cache, you always have to make sure it is consistent with the real data.
 
 i had a quick look at the subscribed users caching patch and I suspect
 that might not be the case there.

 Hmmm. It seems to work fine for me in testing, but it's possible that
 testing hasn't exercised all paths yet. Any suggestions on where to
 check?

I had the impression that the cache was updated when a user saves their 
profile but not when the user subscribes or unsubscribes using the 
appropriate action, but I may have missed something.

Paul

P.S. My note about Xapian (that Thomas responded to) was more about general 
content indexing, of which caching can be regarded as something of a special 
case, than Xapian specifically - it just happens to be the only serious Moin 
1.x option in this area beyond the built-in Moin functionality - although 
there certainly are a lot of applications of caching once you start looking 
for them.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Very slow page saving caused by notifications

[Paul Boddie]

On Sunday 15 April 2012 21:44:34 Steve McIntyre wrote:

 I've posted a bug at

   http://moinmo.in/MoinMoinBugs/SubscribedPagesPerformanceProblem

 Quick summary:

 On a site with a large number of registered users
 (e.g. wiki.debian.org), saving a page taks a very long time. With a
 large number of users, the design of the page subscription system
 doesn't scale well. Saving a page works well, but moin then scans all
 the user data files looking for the subscribed_pages data. With
 thousands of users registered, this can take a very long time; we're
 seeing  90 seconds on a wiki with more than 10,000 users.

I can see that the offending code is in MoinMoin/Page.py, specifically the 
getSubscribers method of the Page class. This looks like a classic case of 
needing to invert the way the data is stored so that it can be queried more 
efficiently - it's a bit like comparing the standard text search 
functionality with Xapian-based searching, where the former relies on 
scanning pages sequentially (pages yield terms), whereas the latter employs 
such inverted storage of queryable information (terms yield pages).

 This area needs fixing in some way - maybe add a cache in front of the
 user lookup here, or store the subscribed_pages information
 differently. I might be able to help with coding this, but I'd want to
 see what other people think first in terms of a design.

 What do people think?

I'd be inclined to index the subscription information so that there's a more 
efficiently queryable structure (pages yielding subscribers) that can be used 
in preference to the existing approach. Having subscriptions amend the index 
when created would eliminate any need for periodic reindexing, and I think 
you could implement this by having an event handler that can handle the 
SubscribedToPageEvent type of event.

There are probably other areas of Moin that could benefit from Xapian-based 
indexing, but this certainly looks like a good application of it.

Paul

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Very slow page saving caused by notifications

[Paul Boddie]

On Sunday 15 April 2012 23:12:18 Steve McIntyre wrote:
 Ah, I see there's a similar bug already (with a patch) in

 http://moinmo.in/MoinMoinBugs/GetSubscribersSlow

 which adds a cache.

I suppose that a cache would perform just as well as a more sophisticated 
approach, given that one would effectively be storing the same correspondence 
of page to subscriber list in the cache. I think that the patch to user.py is 
perhaps less than desirable, though, given that an event handler could 
probably do the same work handling UserCreatedEvent and SubscribedToPageEvent 
instances. Then again, if you're already patching Page.py, patching another 
core module probably isn't too disruptive.

Paul

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] BackLinks Slow

[Paul Boddie]

On Tuesday 06 March 2012 20:29:21 Dave Clements wrote:
 Hello all,

 Clicking on BackLinks (the page title) to see what links to this page, is
 slow i my 1.9 wiki, often timing out after 5 minutes.  It looks like this
 is not searching the cache.  Is there any way to speed this up?

I would imagine that having Xapian enabled would make a big difference if a 
full search needed to be performed; the HelpOnXapian page has the details. If 
you already have Xapian enabled then something else is going wrong, and I 
guess we'd need to look more deeply into what is happening to fix it.

Paul

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] integrated authentication (Moin, Bugzilla, Gitosis, etc)

[Paul Boddie]

On Saturday 25 February 2012 11:31:12 Daniel Pocock wrote:
 On 24/02/12 23:34, Paul Boddie wrote:
  On Friday 24 February 2012 21:22:37 Daniel Pocock wrote:
  Could ACLs and everything else in Moin use the email address in place of
  the name value?  Or could the email address be safely used in the name
  field?
 
  On one Moin deployment, I use each user's e-mail address as their
  username. If this doesn't work with ACLs for some reason, I'd be
  interested in making a patch that makes it work.

 Did you have to make any hacks or patches to support that?

I haven't used ACLs on that deployment until now, but setting an ACL with an 
e-mail address as username doesn't cause an error, at least.

 The email address shows up on screen, e.g. where it shows the user who
 last changed a particular page?

Yes.

 And the email address is valid in the name of the user's own page, e.g.:

 http://moin-wiki.example.org/wiki/u...@example.org

 or is anything likely to choke on the @ symbol?

I don't see why it would on a page name, and it seems to work - I can create a 
page and access it - but for things like ACLs I suppose it would depend on 
the parser, which also seems to work.

[...]

 So maybe the solution for my own Moin deployment would involve:
 - user logs in with email address
 - user chooses a display name on the first login or it looks up the name
 on subsequent logins (the system would not be able to translate
 email-display name with a regex)
 - the display name appears on any pages they edit, etc

I notice that the alias name (see the user settings/preferences) doesn't seem 
to appear in place of the username generally when testing under MoinMoin 
1.8.8 and 1.9.3. You can get the username to be replaced by an alias under 
certain circumstances, but not on pages like RecentChanges, so it is possible 
that the mapping doesn't occur generally. (The code would need to use 
request.user.aliasname instead of request.user.name throughout, at least 
where it doesn't affect the functionality in some way.)

That said, I know that an explicit mapping exists for OpenID-authenticated 
users: you don't see their login URLs all over the place because they choose 
a username when visiting for the first time. Maybe a solution might involve a 
similar identity mapping exercise using REMOTE_USER as the starting point, 
but it would arguably be a lot cleaner to make aliases ubiquitous in Moin 
where user details are displayed instead.

Paul

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] integrated authentication (Moin, Bugzilla, Gitosis, etc)

[Paul Boddie]

On Friday 24 February 2012 21:22:37 Daniel Pocock wrote:

 Could ACLs and everything else in Moin use the email address in place of
 the name value?  Or could the email address be safely used in the name
 field?

On one Moin deployment, I use each user's e-mail address as their username. If 
this doesn't work with ACLs for some reason, I'd be interested in making a 
patch that makes it work.

[...]

 You save the best bit for last: letting the user log in with the email
 address would make it work just like Bugzilla and Mailman

Having to use an e-mail address as a username is something of a limitation 
with Bugzilla, which I also use together with Wiki installations, but you can 
certainly adopt that scheme with Moin, too. In effect, you can delegate the 
authentication to Apache, use GivenAuth to access the REMOTE_USER details (as 
Thomas pointed out), and then you're mostly avoiding any registration process 
within Moin.

Paul

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] no space left on device but plenty of disk space.

[Paul Boddie]

On Tuesday 10 January 2012 17:43:55 Michał Lenart wrote:

 I am running a MoinMoin wikifarm. When I try to upload big attachment (1GB)
 I get Internal server error and I see no space left on device error in
 moin.log. However `df -h /usr/share/moin` says there is about 100GB of free
 space on the disk. What is the problem?

A quick unresearched guess is that you're actually running out of space in 
your /tmp partition. File uploads with most Python Web frameworks typically 
involve creating a temporary file inside the preferred temporary storage 
location (usually /tmp), and on some systems this partition is configured to 
be rather small.

Paul

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Can I block people from creating accounts if they don't verify their address?

[Paul Boddie]

On Thursday 08 December 2011 16:05:31 Steven W. Orr wrote:

 This is not really what I want. I don't want other people to not be allowed
 to create accounts. What I want is to prevent people from creating accounts
 whose email address matches a pattern. In my case (today) the interlopers
 are all on the .info TLD

Are they all providing .info e-mail addresses or are their requests 
originating from addresses resolving to .info domains? It seems to me that 
spammers could easily work around restrictions on e-mail addresses. 
Nevertheless, you could just change the newaccount action to check the e-mail 
address. Something like this, after checking for the address's presence for 
an existing user and just before saving the new user...

  blocked_pattern = getattr(request.cfg, blocked_email_addresses)
  if blocked_pattern:
  blocked_regexp = re.compile(blocked_pattern)
  if blocked_regexp.match(theuser.email):
  return _(Couldn't register you!)

Feel free to use this, play around with it, use multiple patterns or whatever. 
I guess you'd set the pattern up like this:

  blocked_email_addresses = r.*?\.info$

You could use the | operator and brackets to add more possibilities.

 Another thing that would be wonderful would be if the account creation
 could be completed only by responding to a confirmation email, the same as
 if you were signing up for a mailing list.

I saw the following e-mail confirmation patch when searching the Moin site 
for account creation:

http://moinmo.in/RussellStuart/EmailActivation

The discussion is a bit weird because a lot of the timestamps give the current 
time instead of the time of each message, but it seems that people have been 
looking at this code and the problem in general fairly recently.

 But, I don't want to disallow everyone from signing up as a default.

 BTW, I should mention that all of the spam that I'm getting is not only
 coming from the .info TLD, it's also coming in despite TextCha being
 enabled. That never used to be the case.

It's possible that determined people could target a site using TextCha and 
defeat it, but that goes somewhat beyond what TextCha is designed to handle.

With regard to general frameworks around the mechanisms discussed here, the 
new account action doesn't seem to utilise any event mechanisms that you find 
elsewhere in Moin, so you can't write a plug-in that performs a 
post-registration check. I experimented with an event handler that performs 
authorisation checks on edits:

http://moinmo.in/ActionMarket/ApproveChanges

This is a potentially large sledgehammer to crack the nut of spam, however, 
but it effectively queues all edits from anyone you haven't explicitly 
nominated as being trustworthy. Spammers shouldn't see any of their edits 
published unless you approve them.

Paul

--
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of 
discussion for anyone considering optimizing the pricing and packaging model 
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Caching generated content from a parser

[Paul Boddie]

On Friday 02 December 2011 21:45:35 Paul Moore wrote:
 I'm writing a parser which generates content (an image) based on the
 text provided to the parser - something like the Google Chart or
 Graphviz parsers. I'm trying to decide where would be the best place
 to store the generated content. The Google Chart parser uses the
 cache, which feels like the best option to me. (The Graphviz parser's
 use of attachments feels like it exposes too many of the gory details
 to the user for me).

This is precisely the dilemma I had recently: I was/am writing a chart data 
parser that uses SVG as output. I've chosen to go with attachments, however, 
just like the Graphviz parser (the simpler one of the two, at least) because 
the caching behaviour was driving me up the wall, whereas you can always 
delete attachments manually and guarantee that the parser will regenerate the 
output. Another benefit is that if you ever need to export the page, it might 
be sufficient to just write a script to grab the page and attachments.

Paul

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] Occupy Moin Street!

[Paul Boddie]

On Monday 21 November 2011 08:55:04 Radomir Dopieralski wrote:
 Incidentally, anybody with the necessary skills is already using those
 skills in their day job and possibly a dozen of side projects. Sure,
 it would be great to have a dedicated contributor with some design
 skills who cares about the looks and usability, and loads of free time
 to spare (making themes is a really time- and attention-consuming
 task). Any project would love to have such a person. It's probably not
 going to happen.

Having done some themes for Moin, I agree that it's a lot of work, but taking 
what Thomas wrote about getting all the details right, I think that Kai has a 
point about testing. One thing I did find better about Moin than, say, 
MediaWiki was that covering the special cases in the theme is easier with 
Moin: with MediaWiki, there are a bunch of special pages with their own 
layout that you have to check, whereas Moin re-uses a lot of the same styles 
and also doesn't tend to invent so many special pages for things. The problem 
then is the stylesheets for extensions, but that's another matter.

 From my own experience with MoinMoin themes I can say it is a very fun
 and rewarding work, but it takes a lot of time and some concentration
 -- you cannot really do it after work. I was lucky enough to organize
 things so that I could work on MoinMoin during my day work at the
 university -- I made them use MoinMoin. Unfortunately, that changed
 when I changed jobs, and currently it's hard to convince my boss that
 I need to work on a project that is not ready to be used and it is not
 sure if it's any better than the paid tools we already use. That's all
 about a moderately-skilled programmer with some basic experience in
 design. A real pro would be completely impossible to get (they often
 even have to choose between important projects inside the company).

I've been fortunate in that the suggested designs in my workplace (for 
MediaWiki) did not appeal to my boss, and after people thinking that they 
were looking at Wikipedia instead of our department's site, I managed to do a 
quick design that my boss liked which was inspired by some older site designs 
for the organisation's pages. With some refinements, I think I've been able 
to make the case for keeping the theme as it is, and making a Moin version 
was not too much work once the stylesheets were done. But yes, it's tricky to 
justify spending time on such stuff, although people are often happy after 
it's done.

 So, unless you will improve something yourself, there is little chance
 of a miracle happening.

I don't want to criticise Web designers, and I certainly don't want to claim 
that I'm any good at it - it's a frustrating exercise most of the time, and I 
actually try and re-use existing designs wherever possible, maintaining 
whatever coherent font, colour, spacing rules that those designs mandate - 
but a lot of products of Web designers can actually be quite poor, too, or at 
least the ones I see regularly: layout requiring JavaScript, ultra-narrow 
content regions, distracting dynamic effects, and so on. So I don't think 
people should shy away from trying to make nice themes, but the case for 
maintainability is very important: there are plenty of themes already 
available that need fixing up for recent Moin versions; someone has to do 
that work.

Paul

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

Re: [Moin-user] BlueHost complaining my Moin site has too many files

[Paul Boddie]

On Friday 29 April 2011 00:17:04 John Hurst wrote:

 Are there any hidden gotchas?  I mean, is there documentation on how
 revisions are maintained?  I tried deleting some old revisions, and
 got internal system error when I went to view the page.

One thing I regularly get caught out by when running the moin script is any 
difference in permissions or ownership between the Web server user and the 
user running the script. That might be the cause of your internal system 
(server?) error.

Paul

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user

[Moin-user] Moin's OpenID support and identifier_select

[Paul Boddie]

Hello,

I've been trying to make sure that I haven't been breaking OpenID in Moin 
while applying some patches, and I noticed that putting more than one 
provider in openidrp_allowed_op puts Moin into the identifier select mode 
of authentication where the following occurs:

1. The relying party or RP (in this case, Moin offering an OpenID login) 
shows a list of providers of the form http://example.com/ (rather than 
specific identifiers like http://me.example.com/).

2. The RP does discovery using the selected provider, finds out where the 
OpenID provider endpoint is.

3. The RP, indicating an association handle for future use, redirects the 
end-user to the provider endpoint and lets them authorise the authentication 
request.

4. The provider redirects the end-user back to the RP using a specially formed 
URL which includes the OpenID provider endpoint and the association handle 
which should have been provided in step 3.

5. The RP attempts to verify the details provided.

Here's the problem: when the provider is another Moin instance, the OpenID 
endpoint mentioned in the specially formed URL is different from the one that 
was mentioned in discovery. Since the OpenID library (python-openid) 
concerned uses the endpoint together with the association handle when 
preparing the request in step 3, it cannot verify the details from step 4 
using a new endpoint returned by Moin-as-provider.

So, I'm trying to find out whether anyone uses Moin in this way. I'm also 
trying to figure out whether returning a different endpoint is a valid thing 
to do and/or whether using an initial endpoint to record authentication state 
is sensible, although that's more of an issue for the python-openid 
maintainers, I would imagine.

Does anyone have any ideas or experiences with this?

Paul

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user