Lab46 Wiki

My notes for doing an mth-approved installation and configuration of dokuwiki.

Obtain the latest version of dokuwiki (2009-12-25 at time of writing, substitute as appropriate).

www:/var/www$ wget http://www.splitbrain.org/_media/projects/dokuwiki/dokuwiki-2009-12-25.tgz

Extract it, and set a more sane directory name.

www:/var/www$ tar -zxf dokuwiki-2009-12-25.tgz
www:/var/www$ mv dokuwiki-2009-12-25 wikiname

Prior to running the install, we need to ensure all permissions are as they should be.

www:/var/www$ chown -R wedge:www-data wikiname
www:/var/www$ chmod -R 640 wikiname
www:/var/www$ chmod -R ug+X wikiname   # make only directories searchable
www:/var/www$ cd wikiname
www:/var/www/wikiname$ chmod -R g+w data/ conf/ lib/plugins/

To install, point your web browser at: http://www/wikiname/install.php

Fill in the fields as appropriate. I make sure to set up an 'admin' user, to have in existence should LDAP be inaccessible and I need to convert back to local authentication.

When done, it will instruct you to delete the 'install.php' file residing in the wiki base directory. Be sure to do so:

www:/var/www/wikiname$ rm -f install.php

I tend to like to make changes to the template, so instead of messing up the default one beyond all repair, I simply make a copy and switch over to it:

www:/var/www/wikiname/lib/tpl$ cp -a default newtpl

Under “newtpl/” will be files that define the template. Some things I like to change immediately include newtpl/footer.html … I remove the “donate” button, and the “RSS” button as well.

Under the “Admin” → “Configuration Settings” page, some settings I like to change:

• (Basic) Wiki title: Customize as appropriate
• (Basic) Start page name: Customize as appropriate
• (Basic) Template: set the “newtpl” one you just created
• (Authentication) Disable Dokuwiki Actions: Register (prevent people from making accounts)
• (Advanced) Use Nice URLs: .htaccess (second option– URL rewriting in apache)

Following will be information on various pieces of functionality that may or may not be needed, depending on the purpose of the wiki.

They are provided for centralized completeness.

If you would like for this wiki to allow Lab46 users to log in and edit wiki content, it would need to be hooked up to do LDAP authentication against the LAIR LDAP server.

The following configuration is added to /var/www/notes/conf/local.php to enable this to happen:

$conf['authtype']                       = 'ldap';
$conf['passcrypt']                      = 'ssha';
$conf['auth']['ldap']['server']         = 'ldap://auth:389';                              
$conf['auth']['ldap']['usertree']       = 'ou=People,dc=lair,dc=lan';
$conf['auth']['ldap']['grouptree']      = 'ou=Group,dc=lair,dc=lan';
$conf['auth']['ldap']['userfilter']     = '(&(uid=%{user})(objectClass=posixAccount))';
$conf['auth']['ldap']['groupfilter']    = '(&(objectClass=posixGroup)(|(gidNumber=%{gid})(memberUID=%{user})))';
$conf['auth']['ldap']['version']        = 3;

After this is saved, refresh the page, and you should be good to go.

I referenced http://www.dokuwiki.org/auth:ldap_openldap in setting this functionality up.

After enabling LDAP authentication, the 'admin' user no longer worked. So I needed to force-enable an existing user to be the admin… a quick google search dug up:

$conf['superuser'] = 'wedge,squirrel,ian';

There is also a setting for wiki managers… this could be used to delegate to students put in charge of maintaining some content.

To make things look extra pretty in the address bar, I looked up how to enable URL rewriting… the best way, it would seem is to enable it on the web server proper– this means apache.

As a result of exploring this, I ended up switching www over to using apache2 instead of apache1, as getting things like the rewrite module working were just so much quicker.

On the web server side, in the case of notes and content, I had to add directory stanzas to /etc/apache2/httpd.conf:

<Directory /var/www/haas/content>
    AllowOverride AuthConfig FileInfo Limit
</Directory>
 
<Directory /var/www/notes>
    AllowOverride AuthConfig FileInfo Limit
</Directory>

which enable the use of .htaccess files in those directories.

In the case of the lab46web wiki, because it is the primary serving point for www now, I had to perform the configuration change under the /etc/apache2/sites-available/default config file, under the primary VirtualHost entry. The specific directory stanza looks something like this:

    <Directory /var/www/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride AuthConfig FileInfo Limit
        Order allow,deny
        allow from all
        # This directive allows us to have apache2's default start page
                # in /apache2-default/, but still have / go to the right place
                RedirectMatch ^/$ /lab46web/
    </Directory>

The big trick here is the “AllowOverride AuthConfig FileInfo Limit” in all cases.

Next, back in the base directory of each dokuwiki install, I copied the .htaccess.dist file to .htaccess, edited it, and enabled the following options:

RewriteEngine on
RewriteBase /notes     # or "/lab46web" or "/haas/content"
RewriteRule ^_media/(.*)              lib/exe/fetch.php?media=$1  [QSA,L]
RewriteRule ^_detail/(.*)             lib/exe/detail.php?media=$1  [QSA,L]
RewriteRule ^_export/([^/]+)/(.*)     doku.php?do=export_$1&id=$2  [QSA,L]
RewriteRule ^$                        doku.php  [L] 
RewriteCond %{REQUEST_FILENAME}       !-f 
RewriteCond %{REQUEST_FILENAME}       !-d 
RewriteRule (.*)                      doku.php?id=$1  [QSA,L]
RewriteRule ^index.php$               doku.php                                            

When all is said and done, restart apache2 and all should be working.

I adapted the dokuwiki 'wikicalendar' plugin to output months in a more sane format (ie Sunday being the leftmost day listed, with Saturday being the rightmost).

Default behavior is to have Monday be the left-most. So, to make it align its output with that of the 'cal' command, I made the following changes.

First up:

  // (CURRENT) wikicalendar/lang/en/lang.php:
 
  $lang['days'][7]    = 'Sunday';
  $lang['days'][1]    = 'Monday';
  $lang['days'][2]    = 'Tuesday';
  $lang['days'][3]    = 'Wednesday';
  $lang['days'][4]    = 'Thursday';
  $lang['days'][5]    = 'Friday';
  $lang['days'][6]    = 'Saturday';

  // (ORIGINAL) wikicalendar/lang/en/lang.php:
 
  $lang['days'][1]    = 'Monday';
  $lang['days'][2]    = 'Tuesday';
  $lang['days'][3]    = 'Wednesday';
  $lang['days'][4]    = 'Thursday';
  $lang['days'][5]    = 'Friday';
  $lang['days'][6]    = 'Saturday';
  $lang['days'][7]    = 'Sunday';

Basically, I physically put Sunday first in the array order. Notice the array element is still 7… this is so I would not have to go through and redo the logic… it was used to having Sunday have a value of 7, so I kept it. Since all we're interested in is output, that's a very minor thing indeed.

The next change:

(CURRENT) wikicalendar/syntax.php:

219: if($wd == 7) $out .= '<tr>';
...
223:     while($wd < ($this->MonthStart)) {

(ORIGINAL) wikicalendar/syntax.php:

219: if($wd == 0) $out .= '<tr>';
...
223:     while($wd < ($this->MonthStart-1)) {

And here, changing where the calendar row begins (changed to '7' – Sunday), and also to make sure initial blank days are filled in appropriately, $this→MonthStart instead of $this→MonthStart-1.

All in all, a relatively minor change, and only affecting the output… internal logic remains the same.