This page explains how to quickly set up a MoinMoin wiki on one of your domains, and also how to migrate old MoinMoin wiki instances to work with the current MoinMoin release.

New wiki

We already have MoinMoin installed on our system. All you need to do is run a script, add some DomTool configuration, and edit your wikiconfig.py file.

Making a new MoinMoin instance

All you have to do is figure out which directory you want to use to store the wiki (we refer to it as $INSTANCE below), and then run:

moinmoin-install $INSTANCE

For the curious, the moinmoin-install script may be viewed here (FIXME: broken link).

Adding to your Domtool configuration

The easiest thing is to set up a dedicated web site for serving a MoinMoin wiki, like so:

moinMoin "mymoin" where
  Script = home "$INSTANCE/moin.cgi"
with
end

When this is done within $YOURDOMAIN, you get a new web virtual host mymoin.$YOURDOMAIN which expects your moin.cgi script to be in the base of your home directory. Change the Script parameter to alter this expectation. The static moin files are served out of http://mymoin.$YOURDOMAIN/moin$VERSION/..., and the wiki pages themselves are accessed at URLs like http://mymoin.$YOURDOMAIN/PageName.

You can also add a MoinMoin wiki within a larger virtual host. For example:

web "other" where
  alias "/something" "/something_else";

  addMoinMoin where
    Htdocs = "/wikidata";
    Script = home "$INSTANCE/moin.cgi";
    Prefix = "/mywiki"
  end
end

Here, we add a wiki to a vhost other.$YOURDOMAIN that also has some other config. We ask to serve the static files with the URL prefix wikidata instead of moin$VERSION, we say that moin.cgi file is found in the other subdirectory of our home directory, and we ask to serve wiki pages at http://other.$YOURDOMAIN/mywiki/PageName. If you want to use the default HtDocs (recommended), set it to moin_default_htdocs which will use the appropriate versioned static files path for the current MoinMoin release.

Modifying wikiconfig.py

As the final step, you will want to edit wikiconfig.py, which resides in your $INSTANCE folder. You must at least set sitename, and will want to configure the superuser and acl_rights_before settings to be able to administer your wiki.

Your new wiki's local HelpOnConfiguration page or HelpOnConfiguration should explain the rest.

If you customized the HtDocs location, you must edit the url_prefix_static. This is almost always a bad idea, however, since the default will result in the best cache policy and avoid problems with loading incorrect static files when we upgrade the shared files.

At this point, check out the rest of that file to set, for example, your site name. When done, tell domtool to update your configuration, and point a browser at your new wiki installation.

Setting the Default Access Control List

See HelpOnAccessControlLists for detailed instructions on setting access control lists.

As of MoinMoin 1.9.10, the default ACL only allows Trusted users to edit pages (acl_rights_default = u"Trusted:read,write,delete,revert Known:read All:read"). Earlier versions allowed users with accounts (Known) and without accounts (All) to edit by default, but would show a TextCHA (if enabled) to Known/All members.

If you'd like all users with accounts to edit, and anyone without an account to be able to read pages you can override the default acl: acl_rights_default = u"Trusted:read,write,delete,revert Known:read,write,revert All:read". If you decide to allow users without accounts to edit pages, it is recommended to only grant All:read,write and not grant anonymous users delete or revert permissions (delete in particular can do irreversible damage). Only allowing trusted users to delete pages is recommended, especially if you allow open account registration.

Allowing Account Creation

Starting with MoinMoin 1.9.10, the newaccount action is disabled by default, and users will need to manually request accounts to be created by a wiki superuser. It is recommended to leave newaccount disabled, and document how to request an account on your WelcomePage. Users will need to provide you with their requested WikiName and email address. A superuser then creates the account by using Settings -> Switch User, and entering the new username and email address. The user that requested the account can then claim the account by using the recoverpass action and setting a password.

If your wiki is for internal use only, or if you will be enabling a TextCHA for newaccount on a public wiki, you can enable public account creation by overriding actions_superuser in your configuration. For a wiki using multiconfig (default at HCoop):

    actions_superuser = multiconfig.DefaultConfig.actions_superuser[:]
    actions_superuser.remove('newaccount')

If you have set up a wiki farm, the configuration suggested by MoinMoin will work:

   actions_superuser = FarmConfig.actions_superuser[:]
   actions_superuser.remove('newaccount')

If you allow the newaccount action, you must set a TextCHA on the action, or spammers will inundate your wiki with fake accounts.

Anti-Spam

If you override the defaults and allow new account creation on your wiki, you must enable TextCHAs on your login form or your wiki will eventually grind to a halt

Unfortunately, spammers have figured out how to register MoinMoin accounts, and, even if you only allow editing by a trusted group, will register hundreds of accounts per month on your wiki after they've found it. Over time, you will notice the wiki slowing down since moin stores account information in individual files (finding a file in a UNIX directory becomes linearly more expensive as the number of files increases).

See HelpOnSpam for details on configuring TextCHA. Enabling TextCHAs will automatically place one onto the user registration form; if you choose a reasonable question/answer this will prevent shotgun spammers from silently slowing down your wiki.

Migrating old MoinMoin wikis

Depending on the last version of MoinMoin you used, this could be tricky. The good news is that once you migrate your wiki instance to the version of MoinMoin that we have installed, migration should be a lot easier in the future.

If you know what version of MoinMoin you used previously, then skip to the appropriate section. Otherwise read on, and we will try to help you figure it out.

We will call your MoinMoin data directory $DATA.

Before MoinMoin 1.2

Good luck. You'll have to download MoinMoin 1.2.4 yourself, upgrade to it first, and then remove MoinMoin 1.2.4 and proceed with the next sections. If you have hosted a MoinMoin on an old HCoop server, you almost certainly had a later version of MoinMoin than this.

MoinMoin 1.2 through 1.3.4

If you want to know whether you have at least MoinMoin 1.3.4, check for the existence of the $DATA/plugin/__init__.py file. If you have it, skip this section. Otherwise, continue on.

First, back up your data by making a copy of it.

Then, change to the directory where the migration scripts are located:

$ cd /usr/share/python-support/python-moinmoin/MoinMoin/script/old/migration/

Then, consult /usr/share/doc/moinmoin-common/README.Migration.gz, and figure out which scripts you need to run. Unfortunately, you'll have to either know exactly which version of MoinMoin you were last using, or do some detective work by looking at the migration scripts themselves.

To run an individual script (in this example, the 12_to_13_mig11.py script), do:

$ ./12_to_13_mig11.py $DATA

This brings you up to MoinMoin 1.3.5.

MoinMoin 1.3.5

If you have previously used an old HCoop server, this is most likely the version you last used.

First, change to the directory where the migration scripts are located:

$ cd /usr/share/python-support/python-moinmoin/MoinMoin/script/old/migration/

Then, run just this one migration script:

$ ./152_to_1050300.py $DATA

This brings you up to MoinMoin 1.5.3.

MoinMoin 1.5.3

You have it easy. Just run the following, from any directory.

$CONFIGDIR is the full path to the directory that has your wikidata.py file, without any "~" characters. We will call your Wiki URL (example: wiki.DOMAIN.TLD/) $WIKIURL.

$ cd $CONFIGDIR
$ moin --wiki-url=$WIKIURL migration data

Moin 1.7.x

Remember to make a backup. The 1.7 to 1.9 update is slightly more intrusive than previous updates, and you cannot go back if you screw up!

If you installed moin using moinmoin-install on mire, this is the version you are using. The next version we offer is 1.9.5. To make things easier in the future, we moved the moin install from the local machine to afs. Upgrading your data is similar to previous version, where $CONFIGDIR is the directory containing your wikiconfig.py.

cd $CONFIGDIR
/afs/hcoop.net/common/bin/moin --config-dir=`pwd` --wiki-url=$WIKIURL maint cleancache
/afs/hcoop.net/common/bin/moin --config-dir=`pwd` --wiki-url=$WIKIURL migration data

MoinMoin made a number of changes to their module hiearchy in 1.9, so you'll also need to replace your copy of moin.cgi with the latest version:

cp /afs/hcoop.net/common/app/moin/installed/moin19/share/moin/server/moin.cgi $LOCATION-OF-YOUR-MOIN.CGI

For this release, it is recommended that you copy a new version of the system-wide wikiconfig.py from /afs/hcoop.net/common/app/moin/installed/moin19/share/moin/config/wikiconfig.py and merge the minimal settings needed from your current config. Things to look out for:

• url_static_prefix is now automatically generated, so you should unset it

• You really ought to use a TextCHA, at the very least to prevent account registration spam

Tips and Tricks

The moin command line program is installed at /afs/hcoop.net/common/bin (which is in the default path for bash users). It is quite useful for managing your wiki; see HelpOnMoinCommand for its documentation. You will need to provide at least --config-dir and --wiki-url as arguments (represented by ... in our examples).

Managing Inactive Users

You may find yourself with a large number of inactive users; a likely cause is registration spam if you have a wiki relying on a trusted editors group instead of TextCHA. Moin handily provides a command to list and remove inactive users.

The process of removing inactive users occurs in two steps. First you gather the list of active and inactive users in a file (substitute $KEEP with a name of your choosing)

moin ... acount inactive --py-append=$KEEP

$FILE will contain the set of users that are to be kept. If you see any bogus accounts in the file, remove the line containing them. Next, using the file of users to keep, review which members would be deleted were you to proceed:

moin ... account inactive --py-exec=$KEEP --show

This will result in output like:

1239843008.83.54402     u'FooBar'    u'email@domain.tld'        0
...

You probably want to redirect this to a file to analyze in a text editor since there will likely be at least a few users you do not want to prune. When you encounter a user you do not want to delete, note the uid (the first field in a line, e.g. 1239843008.83.54402 in the example above). You will need to add a new line to $KEEP in the format:

editlog_uids.add(u'$UID') 

If you copy all of the lines from the list you want to keep into a new file, you can pipe it through cut -f1 to extract the UID.

FIXME: Trivial script to take list of lines from $KEEP and generate editlog commands to keep additional users

FIXME: document actually removing inactive users

Removing stale editor backups

If you want to remove the "MoinEditorBackup" files from your wiki instance, then do the following.

for i in $(find $DATA/pages -type d \
  -name '*(2f)MoinEditorBackup'); do
    rm -fr $i
done

Unlock locked files

If your wiki instance still isn't working, then you might have a stale lock file or two. Do the following to remove stale lockfiles.

for i in $(find $DATA/pages -type f -name current-locked); do
    echo "Removing stale lockfile in $(dirname $i) ..."
    mv $i $(dirname $i)/current
done

500 Server Error

If you get a 500 server error when running your wiki, one likely cause is permissions on your $INSTANCE directory. The directory which contains moin.cgi needs to have permissions 755, because suexec will refuse to run the cgi if its parent directory is writeable by others. Note that the directory permissions do not actually affect anything (since we're using AndrewFileSystem), but modifying the suexec code to skip the checks is considered too risky.

Installing Themes

You can install most plugins with no problem, but themes at least require that you place files into the shared htdocs. You have two options:

1. Request that we install the static files site-wide (no problem for things in the theme market)

2. Copy the static files into your own directory, and change HtDocs (this requires that you keep up to date with upgrades)

We are serving the css and images for at least the following themes:

• Moniker

---

CategoryMemberManual