Mediawiki

From HerzbubeWiki
Jump to navigation Jump to search

This page contains information about installing Mediawiki on a Debian system. Various parts of this document may refer to different versions of the Mediawiki package. If no specific version is mentioned, the information hopefully applies to all Mediawiki versions.


References


Packaging history

The packaging of Mediawiki in Debian has a troubled history. Because I find Mediawiki to be such an important piece of software, and I always imagine others also depend on it heavily, I find it astonishing that support for it in the Debian community is so patchy. Here is a short historical overview.

  • In the beginning there was not even a Debian package, which is why parts of this page still contain information about a manual setup.
  • The first packaged release was 1.7 in 2005.
  • Later releases were promptly packaged, but the upgrade handling usually was pretty horrible.
  • The package for release 1.15 in 2009 was the first one that provided a nice and smooth upgrade experience. From then on things became really good for a few years.
  • 1.19 was the last major upstream release to be packaged in June 2012. Package maintenance then dwindled to practically nothing, with only occasional bugfix and security updates.
  • The last package update was a non-maintainer security update in December 2014. This update resulted in package version 1.19.20+dfsg-0+deb7u3. After that the package received no more updates.
  • Even though 1.19 was an LTS release, upstream support for it ceased in mid-2015, roughly 3 years after the initial release. Because of this lack of upstream support the package was finally removed from the Debian stable distribution (jessie) at the beginning of June 2016.
  • An ITP (intent to package) was filed in January 2016, but a couple of months later nothing has come of it.
  • Just a few days before the time of writing this (beginning of July 2016) upstream has released the new version 1.27, which is another LTS version.
  • 5 July 2016: According to the ITP bug report, the new package for 1.25.5-1 has been finally accepted into the Debian archive. In the package changelog the upload is marked with the date 9 August 2015 - if I'm reading this correctly, the package was hanging around in the queue for almost an entire year!
  • Later in 2016: The 1.27.0-1 package has landed. Again, the package changelog has a strange date: 30 June 2016. This is before the last entries in the ITP bug report. I'm not fussing, though, I'm just happy that things seem to be moving again.
  • December 2017: The Jessie backports package has received a more or less steady stream of updates, so that we're now at package version 1.27.4-1~bpo8+1. It seems that Mediawiki has returned to the land of the living - at least for the moment.
  • December 2019: The upstream version 1.31.6 is packaged into the Debian package 1.31.6-1~deb10u1, which is distributed via Debian buster security updates. The last two years have seen a steady stream of package updates. The return to the land of the living has been for good, as it seems.
  • Spring 2024: 5 years later Mediawiki is still supported in Debian 12 (bookworm): The upstream version 1.39.7 is packaged into the Debian package 1.39.7-1~deb12u1.


References


Debian setup

Packages

Install these Debian packages:

mediawiki
mediawiki-classes
php-wikidiff2


Historical notes

  • Up to version 1.10, the Debian meta package mediawiki always pointed to the latest version of Mediawiki. For instance, it pointed to the concrete package mediawiki1.7 or mediawiki1.10.
  • In version 1.12, only the Debian package mediawiki remains, there is no split anymore between a meta package and a concrete package.
  • In version 1.27 the Debian package mediawiki-extensions no longer exists, instead it's now mediawiki-classes. I'm not sure but this may just be a package rename, because mediawiki-classes has a history that goes back to version 1.7.


LocalSettings.php

The settings for the normal operation of the wiki are stored here:

/etc/mediawiki/LocalSettings.php

Settings for extensions or for customizing various aspects of Mediawiki are explained in other sections further down. Here are the most important settings that affect integration with the web server and the database:

$wgSitename = "HerzbubeWiki";
$wgMetaNamespace = "HerzbubeWiki";

$wgScriptPath = "";  # The wiki resides at the base of a Virtual Host, e.g. http://wiki.herzbube.ch/

## The protocol and server name to use in fully-qualified URLs
$wgServer = "https://wiki.herzbube.ch";

## The URL path to static resources (images, scripts, etc.)
$wgResourceBasePath = $wgScriptPath;

$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "mediawikidb";
$wgDBuser = "mediawiki";
$wgDBpassword = "secret";

Because it contains a password, the file should be protected:

cd /etc/mediawiki
chmod 400 LocalSettings.php
chown www-data:www-data LocalSettings.php


Historical note: In older versions the Mediawiki configuration used to be split into two files: AdminSettings.php (settings that are necessary to perform administrative tasks on the command line, typically database upgrade) and LocalSettings.php (settings that are necessary for the normal operation of the wiki). Nowadays everything has been merged into the single file LocalSettings.php.


Web server configuration

This is the Apache vhost configuration:

# --------------------------------------------------------------------------------
# wiki.herzbube.ch
# --------------------------------------------------------------------------------
<VirtualHost *:80>
  ServerName wiki.herzbube.ch
  Redirect permanent "/" "https://wiki.herzbube.ch/"
</VirtualHost>

# --------------------------------------------------------------------------------
# SSL Host
# --------------------------------------------------------------------------------
<VirtualHost *:443>
  ServerName wiki.herzbube.ch
  ServerAdmin webmaster@herzbube.ch
  ErrorLog ${APACHE_LOG_DIR}/wiki.herzbube.ch/error.log
  CustomLog ${APACHE_LOG_DIR}/wiki.herzbube.ch/access.log combined

  DocumentRoot /var/lib/mediawiki
  Alias /robots.txt /var/www/wiki.herzbube.ch/robots.txt

  <Directory /var/lib/mediawiki>
    php_admin_flag engine on
  </Directory>

  <Directory /var/www/wiki.herzbube.ch/>
    Require all granted
  </Directory>

  # Mediawiki 1.39.x: The images folder contains a .htaccess file which already
  # disables PHP script execution. Paradoxically the config file
  # /etc/apache2/conf-available/mediawiki.conf has "AllowOverride None"
  # and then disables PHP script execution on its own, BUT ONLY FOR PHP 7,
  # but the system has PHP 8 installed nowadays. Because we don't want to
  # tamper with the files installed from a package, we disable PHP script
  # execution for PHP 8 (and later) here.
  # Note: Before removing this snippet, make sure that the way how the
  # package disables PHP script execution actually works. Because above we
  # use "php_admin_flag engine on" it may be that "php_flag engine off"
  # does NOT work - here we had to use "php_admin_flag engine off" to
  # make the disable work.
  <Directory /var/lib/mediawiki/images/>
    php_admin_flag engine off
  </Directory>

  Include conf-available/pelargir-herzbube.ch-vhosts-ssl.conf
</VirtualHost>


Upgrade

The general upgrade procedure is this:

  • In aptitude, upgrade the package mediawiki
  • Perform database backup
  • Point browser to https://wiki.herzbube.ch/mw-config, then follow the instructions to perform the database upgrade.
  • Alternatively the upgrade can be performed on the command line. This may be useful if the web browser :
cd /var/lib/mediawiki
php maintenance/update.php
  • Go through all extensions in /var/lib/mediawiki/extensions/ that are custom-installed, i.e. not installed via the Mediawiki package, and upgrade them manually.


This wiki page's history contains information about specific Mediawiki version upgrade paths.


Modifications to Mediawiki

Skin (theme)

Authenticated users can choose their own skin (theme) in their preferences. The default skin (theme) is set with this line in LocalSettings.php:

$wgDefaultSkin = 'vector';

The skin name to use is the internal symbolic name of the skin.

Skins must be loaded for them to be available. This happens in LocalSettings.php, with a series of wfLoadSkin function calls:

wfLoadSkin( 'MinervaNeue' );
wfLoadSkin( 'MonoBook' );
wfLoadSkin( 'Timeless' );
wfLoadSkin( 'Vector' );

Skins are loaded from this filesystem path:

/usr/share/mediawiki/skins


Notes on some skins:

  • The skin "Timeless" is a nice-looking modern skin with a fixed-width layout. I used this for some time but ultimately returned to "Vector" because some of the pages in this wiki have very wide tables that are cut off and become unusable with a fixed-width layout.
  • The skin "Monobook" is the classic skin that Wikipedia used for a long time. It's clean and efficient and doesn't use a lot of space for margins etc. Whenever I'm in doubt and need to test something I use this skin.
  • The skin "Vector" looks quite similar to "Monobook", but feels a bit more modern. It uses spacings more generously so the same amount of content requires more space with this skin than with "Monobook". This is the skin that I'm using currently.


The logo of the site is set with a snippet like this in LocalSettings.php:

$wgLogos = [
        '1x' => "$wgResourceBasePath/images/7/7d/Herzbube.ch-logo.png",
        'icon' => "$wgResourceBasePath/images/7/7d/Herzbube.ch-logo.png",
];

Enable uploads in LocalSettings.php with this setting:

$wgEnableUploads = true

Check out the filesystem to find out where the logo is actually uploaded:

/var/lib/mediawiki/images


Modify navigation bar

You may wish to modify the navigation bar on the left, e.g. remove some unnecessary links such as "Community portal".

For versions >= 1.5:


User groups

Details about user rights and groups can be found on http://www.mediawiki.org/wiki/Manual:User_rights.

You can place users into groups on the Special:Userrights page.

You can assign privileges to a group by editing the file LocalSettings.php in the following way (note that you create groups by simply mentioning them in LocalSettings.php):

$wgGroupPermissions['ninja']['delete'] = true;
$wgGroupPermissions['ninja']['block'] = true;
$wgGroupPermissions['ninja']['bot'] = true;
[...]

The implicit group for anonymous users is '*'. The implicit group for logged in users is 'user'. Therefore, modifying the privileges for these 2 special groups would look like this:

$wgGroupPermissions['*'    ]['createaccount']   = true;
$wgGroupPermissions['user' ]['read']            = true;


The sections below contain information about specific privileges that I'm using.


Searched namespaces

Users who are logged in can change the namespaces that are searched by default in their user preferences. To modify the defaults for anonymous users, edit the file LocalSettings.php to contain the following list:

$wgNamespacesToBeSearchedDefault = array( NS_MAIN => true, NS_USER => true );

In the example above, the User namespace will be searched in addition to the Main namespace (which is the only one searched by default).

Note: Newly created user accounts inherit this setting, but existing user accounts remain unaffected (even if they have not changed their user preferences from the defaults).


No anonymous edits

By default, anonymous (i.e. not logged in) users have permission to edit wiki pages. This can be disabled by placing the following line in LocalSettings.php:

$wgGroupPermissions['*']['edit'] = false;

Note: The "edit" link on top of each page is still shown, but if an anonymous user clicks on the link he will be asked to login.


Disable account registration

By default, account registration for the Mediawiki site is enabled. This can be disabled by placing the following line in LocalSettings.php:

$wgGroupPermissions['*']['createaccount'] = false;

The "log in" link on top of each page is still labelled "log in / create account", but the "create account" link on the login page is no longer visible, and if a user directly goes to the signup page, she will be told that account registration by anonymous users is not possible.


Extensions

Managing extensions

To view a list of installed Mediawiki extensions, go to Special:Version.

The main Debian package mediawiki includes a few useful extensions. Installing the package does not automatically enable those extensions, you still have to manage them by adding a line like this to LocalSettings.php:

wfLoadExtension( 'Cite' );

After enabling an extension you may need to add further extension-specific configuration to LocalSettings.php to make the extension work as desired.


If you want to install a custom extension (i.e. one that is not available via Debian package), then you can drop it into the folder

/usr/share/mediawiki/extensions

This is also the folder where you can see the list of available extensions in the filesystem.


Cite

Cite is an extension which allows a user to create footnotes. For details, see the extension website.

Cite is available through the main Debian package mediawiki. The extension is enabled by adding this to LocalSettings.php:

wfLoadExtension( 'Cite' );

The extension does not require any configuration.


Special:Interwiki

Interwiki links normally must be managed by modifying a database table (details are available on this page). The Special:Interwiki extension exposes the table and the editing process through the page Special:Interwiki. Other extensions for managing Interwiki links can be found here.


The Special:Interwiki extension is available through the main Debian package mediawiki. The extension is enabled by adding this to LocalSettings.php:

wfLoadExtension( 'Interwiki' );


Configure the extension by adding these lines to the end of LocalSettings.php:

# InterWiki extension
$wgGroupPermissions['*']['interwiki'] = false;
$wgGroupPermissions['sysop']['interwiki'] = true;


Interwiki links can now be managed by logging in as an administrator and going to Special:Interwiki.


ParserFunctions

The ParserFunctions extension is available through the main Debian package mediawiki. The extension is enabled by adding this to LocalSettings.php:

wfLoadExtension( 'ParserFunctions' );


The extension does not require any configuration. The extension provides additional parser functions that can be used on pages and in templates, such as

{{#ifexpr ...}}


The extension is enabled because various templates copied from Wikipedia use these expressions. For details, see the extension website.


LDAP Authentication

Several extensions are needed to enable LDAP to be used as an authentication backend. See the LDAP section on this page for more details.


CategoryTree

The CategoryTree extension is available through the main Debian package mediawiki. The extension is enabled by adding this to LocalSettings.php:

wfLoadExtension( 'CategoryTree' );


The extension displays the hierarchy below a category as a tree. When viewing a category page, sub-categories have clickable widgets that allow the user to expand or collapse the tree for that sub-category. The Special:CategoryTree page lets the user specify a category whose tree should be displayed. Last but not least, it is possible to display a category tree inline in a page using the following syntax:

<categorytree mode=pages>Foo</categorytree>

The default clickable widgets are simple "+" and "-" characters. This looks quite ugly, but the widgets can be changed by editing the following pages and specifying a different character. Note that you must have administrator privileges to edit these pages.


To further configure CategoryTree, add the following lines to the end of LocalSettings.php:

# ----------------------------------------------------------------------
# CategoryTree extension
# ----------------------------------------------------------------------
# We want to see pages when we expand a node on a category page
$wgCategoryTreeCategoryPageOptions["mode"] = "pages";
# Allows to display a fully expanded tree with the root category at the base
$wgCategoryTreeMaxDepth = array('CT_MODE_PAGES' => 50, 'CT_MODE_ALL' => 50, 'CT_MODE_CATEGORIES' => 50);


Using the template Template:Category_tree_all it is now possible to show a fully expanded category tree. See the template page for an example.


I have not been able to convince CategoryTree to display a category page, or the special page, with a tree with an initial depth greater than 1. I have tried the following settings, but they did not work:

$wgCategoryTreeSpecialPageOptions["depth"] = 10;
$wgCategoryTreeCategoryPageOptions["depth"] = 10;


At the moment there is also another unresolved issue: When the category tree is expanded, it displays CSS style information.


LDAP

Overview

To enable LDAP to be used as an authentication backend, several extensions are needed:

  • Infrastructure
    • PluggableAuth: This extension provides a framework for creating authentication and authorization extensions.
    • LDAPProvider: This extension provides classes and configuration to query data from LDAP resources.
  • Actual authentication / authorization
  • LDAPAuthentication2: This extension provides the actual authentication. It plugs into PluggableAuth and makes use of LDAPProvider to achieve its goal.
  • LDAPAuthorization: This extension provides authorization. It plugs into PluggableAuth.

A useful overarching resource is the LDAP hub page.

Additional notes:

  • LocalSettings.php now contains another password
  • Users must now be created in LDAP, it is no longer possible to login as a bureaucrat or sysop and create an account
  • Passwords must now be changed in LDAP
  • I formerly logged in as user "Herzbube". This user still exists in the Mediawiki database, but it is no longer possible to login as "Herzbube". Also, I am too lazy to "convert" the account to my new personal account, which means that all edits prior to switching to LDAP authentication are still credited to it.
  • Also see the OpenLDAP page on this wiki


PHP LDAP support

As a prerequisite, PHP must be properly configured as an LDAP client.

  • The Debian package php-ldap must be installed (older Debian versions: php5-ldap)
  • Hash links in /etc/ssl/certs must be set up correctly
  • PHP will query the LDAP server as a local LDAP client. If ldap.herzbube.ch is used for connections, then the server requires TLS and the following line must be present in the system-wide client configuration file /etc/ldap/ldap.conf. The line must refer to the entire CA certificate chain used for verifying the LDAP server certicate.
TLS_CACERT /etc/ssl/certs/ca-certificates.crt

Notes:

  • The line may already be present due to other clients (e.g. ldapsearch) that already need to contact the LDAP directory.
  • The certificate chain used to consist of CAcert certificates (/etc/ssl/certs/cacert.org.certchain), but nowadays I use Let's Encrypt which is supported by Debian off-the-shelf, so the default file shown above is sufficient.


Prepare the LDAP directory

Users

Mediawiki will refer to user entries below ou=users,dc=herzbube,dc=ch. Because I do not plan to store user preferences in LDAP, the current user entries do not need to be modified. All that is required from them is the presence of the uid attribute, and the ability to use them for binding (i.e. the userPassword attribute must be present).


Groups

Mediawiki not only has support for user groups, it actively employs them even even for basic things such as identifying who is an Admin user. For this reason, new groups must be added to the LDAP directory.

Mediawiki will refer to group entries below ou=group,dc=herzbube,dc=ch:

  • Group entries must be of object class groupOfUniqueNames
  • Group entries refer to their members via the attribute uniqueMember
  • uniqueMember requires that its references are full DNs (e.g. cn=admin,ou=users,dc=herzbube,dc=ch)

The following groups are needed:

  • cn=wikiusers,ou=groups,dc=herzbube,dc=ch
    • All users that should be able to login to Mediawiki must be members of this group
    • I use this because I do not want all POSIX accounts (or in fact all user entries below ou=users,dc=herzbube,dc=ch) to be able to login to Mediawiki
    • To ensure this, in other applications I have enhanced user entries with an additional object class in order to mark the entry as an account for that application. For instance, Bugzilla accounts have the additional object class bugzillaAccount
    • Although this group formally is a Mediawiki group, it is not actually required by Mediawiki
  • cn=sysop,ou=groups,dc=herzbube,dc=ch
    • Only contains the "admin" user
  • cn=bureaucrat,ou=groups,dc=herzbube,dc=ch
    • Only contains the "admin" user
  • The page Special:ListGroupRights also lists a group named "Users". No LDAP entry is needed for this group, though, because all users automatically belong to this implicit group. This can be verified by examining the table "user_groups" in Mediawiki's database.


Activate the extensions

The extensions must be installed manually. I'm cloning the respective Git repositories and then checkout the Git tag that corresponds to each required version. Important: You can't just use the latest version of each extension. Instead consult the compatibility matrix that exists on the PluggableAuth website.

cd /var/lib/mediawiki/extensions

git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/PluggableAuth
cd PluggableAuth
git checkout 7.1.0
cd ..

git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/LDAPProvider
cd LDAPProvider
git checkout 2.0.6
cd ..

git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/LDAPAuthentication2
cd LDAPAuthentication2
git checkout 2.0.8
cd ..

git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/LDAPAuthorization
cd LDAPAuthorization
git checkout 2.0.6
cd ..

Next, enable the extensions in LocalSettings.php:

wfLoadExtension( 'LDAPProvider' );
wfLoadExtension( 'PluggableAuth' );
wfLoadExtension( 'LDAPAuthorization' );
wfLoadExtension( 'LDAPAuthentication2' );


Configure the extensions

The extensions are configured by adding code to the end of LocalSettings.php. Note that the following snippets contain comments referring to the obsolete extension LDAPAuthentication which I used before upgrading to Debian bullseye. These comments can safely be ignored and I'll remove them in a future revision of this wiki page.


The extensions LDAPProvider and LDAPAuthorization are configured together like this:

# ---------- LDAPProvider + LDAPAuthorization extension configuration ----------

# Old LDAP Authentication extension config options related to groups, for which there is
# currently no corresponding new config option:
# - $wgLDAPGroupNameAttribute = "cn"  <= The name of the attribute that identifies the group. May be part of "grouprequest"
# - $wgLDAPGroupUseFullDN = true      <= Whether or not the group references the user with a full DN. Had the value "true"
#                                        because the attribute "uniqueMember" requires the reference to be a full DN.

$LDAPProviderDomainConfigProvider = function() {
  $config = [
    # Any string can be used here; this is not a DNS name.
    # Old LDAP Authentication extension config option: $wgLDAPDomainNames
    'wiki.herzbube.ch' => [
      'connection' => [

        # Normally this specifies the DNS name or the IP address of
        # the host that runs the LDAP server. A typical name is
        # "localhost". Because we use a UNIX domain socket (ldapi:///)
        # we must specify "/" here.
        # Old LDAP Authentication extension config option: $wgLDAPServerNames
        "server" => "/",

        # Bind as this user to make searches
        # Old LDAP Authentication extension config option: $wgLDAPProxyAgent
        "user" => "cn=readonly-users,ou=users,dc=herzbube,dc=ch",
        # Old LDAP Authentication extension config option: $wgLDAPProxyAgentPassword
        "pass" => 'eiNg0aQu~oodeit',

        "options" => [
          "LDAP_OPT_DEREF" => 1
        ],

        # The value "ldapi" is used to connect to the server over a UNIX domain
        # socket (ldapi:///). If TLS were required we would specify "tls" here.
        # Old LDAP Authentication extension config option: $wgLDAPEncryptionType
        "enctype" => "ldapi",

        # ---------- Base DNs for searches ----------
        # Since we are defining explicit base DNs for user/group searches,
        # it is unclear how the "basedn" option is going to be used.
        # Old LDAP Authentication extension config option: $wgLDAPBaseDNs
        "basedn" => "dc=herzbube,dc=ch",
        # Old LDAP Authentication extension config option: $wgLDAPGroupBaseDNs
        "groupbasedn" => "ou=groups,dc=herzbube,dc=ch",
        # Old LDAP Authentication extension config option: $wgLDAPUserBaseDNs
        "userbasedn" => "ou=users,dc=herzbube,dc=ch",

        # ---------- Options related to user entries ----------
        # The attribute whose value must match the user name specified at login time.
        # An alternative option to this would be the "searchstring" option.
        # Old LDAP Authentication extension config option: $wgLDAPSearchAttributes
        "searchattribute" => "uid",

        # Attributes that store other information about the user
        "usernameattribute" => "uid",
        "realnameattribute" => "cn",
        "emailattribute" => "mail",

        # Mediawiki always converts the first letter of the user name
        # to upper case, but the LDAP entries for users always use
        # lower case.
        # Old LDAP Authentication extension config option: $wgLDAPLowerCaseUsername = true
        "presearchusernamemodifiers" => [ "lowercase" ],

        # ---------- Options related to group entries ----------
        # Mediawiki groups are not POSIX groups, therefore they are not
        # represented by entries of the posixGroup object class. A useful
        # alternative is the core schema object class groupOfUniqueNames,
        # which is a very generic way to gather a list of unique
        # references to other DNs.
        #
        # If we used the "Configurable" request type we could set a few
        # other options. By using the "GroupUniqueMember" request type
        # we automatically set these options.
        #
        # Option            Value               Old LDAP Authentication extension config option
        # -------------------------------------------------------------------------------------------------------------------------
        # groupobjectclass  groupOfUniqueNames  $wgLDAPGroupObjectclass
        # groupattribute    uniqueMember        $wgLDAPGroupAttribute    The name of the attribute that stores the user references.
        #                                                                uniqueMember is a core schema attribute type.
        #
        # Normally it is expected that groups refer to their members. If it were the other way round
        # and users would refer to their groups via the "memberOf" attribute, we would use the
        # "UserMemberOf" request type.
        # Old LDAP Authentication extension config option: $wgLDAPGroupsUseMemberOf = false => equivalent to "GroupUniqueMember" request type
        #                                                                             true  => equivalent to "UserMemberOf" request type
        "grouprequest" => "MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\GroupUniqueMember::factory",
      ],

      # ---------- Login restrictions ----------
      # Note: This snippet belongs to the LDAPAuthorization extension
      # Login is not allowed if a user is not a member of the groups specified here. In order
      # to use this property, various other group-related options must also be configured.
      # Old LDAP Authentication extension config option: $wgLDAPRequiredGroups
      "authorization" => [
        "rules" => [
          "groups" => [
            "required" => [
              "cn=wikiusers,ou=groups,dc=herzbube,dc=ch"
            ]
          ]
        ]
      ],
    ]
  ];

  return new \MediaWiki\Extension\LDAPProvider\DomainConfigProvider\InlinePHPArray( $config );
};


And here is the snippet for configuring the PluggableAuth and LDAPAuthentication2 extensions.

# ---------- PluggableAuth + LDAPAuthentication2 extension configuration ----------
# Do not allow local Mediawiki users, only allow LDAP users
# Old LDAP Authentication extension config option: $wgLDAPUseLocal
$wgPluggableAuth_EnableLocalLogin = false;    # PluggableAuth
$LDAPAuthentication2AllowLocalLogin = false;  # LDAPAuthentication2 extension

$wgPluggableAuth_EnableLocalProperties = false;

# This works for PluggableAuth v6.0 or later
# The key "Login" is used as the label for the button on the login page
# Note: For PluggableAuth v5.7 or earlier there is no direct correspondence
# to the $wgPluggableAuth_Config option. It is expected that for that version
# LDAPAuthentication2 performs some configuration on its own.
$wgPluggableAuth_Config["Login"] = [
  "plugin" => "LDAPAuthentication2",
  "data" => [
    # Reference to a key in $LDAPProviderDomainConfigProvider
    "domain" => "wiki.herzbube.ch"
  ]
];


Debugging

Add the following lines to LocalSettings.php to write debugging information into a file. Warning: Passwords are written to the file in clear text!

# ---------- Debugging ----------
# https://www.mediawiki.org/wiki/LDAP_hub#Debugging
#$LDAPProviderCacheType = CACHE_NONE;
#$wgDebugLogGroups['PluggableAuth'] =  '/tmp/mediawiki.ldap.debug.log';
#$wgDebugLogGroups['LDAP'] =  '/tmp/mediawiki.ldap.debug.log';
#$wgDebugLogGroups['MediaWiki\\Extension\\LDAPProvider\\Client'] =  '/tmp/mediawiki.ldap.debug.log';
#$wgDebugLogGroups['LDAPProvider'] =  '/tmp/mediawiki.ldap.debug.log';
#$wgDebugLogGroups['LDAPGroups'] =  '/tmp/mediawiki.ldap.debug.log';
#$wgDebugLogGroups['LDAPUserInfo'] =  '/tmp/mediawiki.ldap.debug.log';
#$wgDebugLogGroups['LDAPAuthentication2'] =  '/tmp/mediawiki.ldap.debug.log';
#$wgDebugLogGroups['LDAPAuthorization'] = '/tmp/mediawiki.ldap.debug.log';


Troubleshooting

For general debug output, add the following line to LocalSettings.php:

$wgDebugLogFile = '/tmp/mediawiki.debug.log';

If the debug output of a specific extension is desired, it may be necessary to define other, extension-specific variables. Also, it is possible to redirect debug output to a different log file depending on which group is used by the logging statement. For instance if the logging statement uses the group "foo":

$wgDebugLogGroups = array(
  'foo' => '/tmp/mediawiki.foo.debug.log',
);              


How to clone a Mediawiki installation for local use with MAMP

Overview

This HOWTO explains how I made a clone of HerzbubeWiki so that I could use it locally on my MacBook, together with MAMP, while travelling around the world. The HOWTO is not very generic but rather specific to my installation - you will have to figure out yourself how to adapt the examples to your own needs.


Install the Mediawiki software on the MacBook

cd /Applications/MAMP/htdocs
tar xfvz ~/Downloads/mediawiki-1.12.0.tar.gz
chown -R patrick:patrick mediawiki-1.12.0/
ln -s mediawiki-1.12.0/ mediawiki
cd /Applications/MAMP/htdocs/mediawiki
mv config/LocalSettings.php .
chmod 400 LocalSettings.php


Install the Cite.php extension on the MacBook

cd /Applications/MAMP/htdocs/mediawiki/extensions
tar xfvz ~/Downloads/Cite-MW1.12-r33026.tar.gz
chown -R patrick:patrick Cite/
  • Add the following line to LocalSettings.php:
require_once('extensions/Cite/Cite.php');


Install the database contents on the MacBook

  • On the server, create a database dump
cd /tmp
mysqldump --add-drop-table -u root -p mediawikidb >mediawikidb.sql.dump
gzip mediawikidb.sql.dump
  • Also on the server, create a tar file with the images
cd /var/lib/mediawiki/images
tar cfp /tmp/mediawiki.images.tar *
gzip /tmp/mediawiki.images.tar
  • On the MacBook, restore the database (you will have to enter the password for MAMP's MySQL user root, which is "root" by default)
cd ~/Downloads
scp root@osgiliath:/tmp/mediawikidb.sql.dump.gz .
gunzip mediawikidb.sql.dump.gz
/Applications/MAMP/Library/bin/mysql -u root -p mediawikidb <mediawikidb.sql.dump
  • Also on the MacBook, restore the images
cd ~/Downloads
scp root@osgiliath:/tmp/mediawiki.images.tar.gz .
cd /Applications/MAMP/htdocs/mediawiki/images
tar xfvz ~/Downloads/mediawiki.images.tar.gz


Final configuration

  • Make the following changes to LocalSettings.php to achieve the same configuration as on the server
# enable uploads
$wgEnableUploads       = true;

# new logo (first line only needs to be present because this is not the Debian machine)
$wgUploadPath       = "$wgScriptPath/images";
$wgLogo             = "$wgUploadPath/7/7d/Herzbube.ch-logo.png";

# no anonymous edits
$wgGroupPermissions['*']['edit'] = false;

# new users get the following search settings
$wgNamespacesToBeSearchedDefault = array( NS_MAIN => true, NS_USER => true );


That's it

Point the browser at http://localhost:8888/mediawiki/.