DokuWiki Installer


This page assists in the first time installation and configuration of Dokuwiki. More info on this installer is available on it's own documentation page.

DokuWiki uses ordinary files for the storage of wiki pages and other information associated with those pages (e.g. images, search indexes, old revisions, etc). In order to operate successfully DokuWiki must have write access to the directories that hold those files. This installer is not capable of setting up directory permissions. That normally needs to be done directly on a command shell or if you are using hosting, through FTP or your hosting control panel (e.g. cPanel).

This installer will setup your DokuWiki configuration for ACL, which in turn allows administrator login and access to DokuWiki's admin menu for installing plugins, managing users, managing access to wiki pages and alteration of configuration settings. It isn't required for DokuWiki to operate, however it will make Dokuwiki easier to administer.

Experienced users or users with special setup requirements should use these links for details concerning installation instructions and configuration settings.

For security reasons this script will only work with a new and unmodified Dokuwiki installation. You should either re-extract the files from the downloaded package or consult the complete Dokuwiki installation instructions

driven by DokuWiki powered by PHP
Packagers [Mantis Bug Tracker Wiki]

User Tools

Site Tools



Author: Victor Boctor


  • Typically they have experience in packaging products or are the packagers for Mantis for one or more distributions. [giallu: I think it is very unlikely to be the packager on more of one distro, not a big deal though…]
  • The packaging team will have CVS commit access (same access level as Mantis developers and globalization team).

Ownership of Packaging Code

  • Focus on streamlining the Mantis packaging process.
  • Responsible for maintaining unattended install / upgrade for Mantis.

Communication with Linux Distributions

  • Maintain a list of Linux distributions that include Mantis.
  • Maintain a list of Linux distributions that we should approach to include Mantis. [giallu: do we really want to actively do this? ]
  • Keep close communication with Mantis packagers and Linux distributions.
  • Responsible for integrating patches supplied to them by Mantis packagers.
  • Work with Linux Distributions that provide a list of issues that need to be done for them to include Mantis.
  • Communicate to packagers and Linux distributions that only Mantis stable releases should be included in their distributions (whether stable or unstable). [giallu: this is not easy for all distros. For example, anyone feel free to correct me if I am wrong, debian stable is “stable” in the sense it will not change much overtime, and that only critical fixes are applied to packages, usually by backporting the patch]
  • Packagers can also use the “Contact Us” page to send emails to myself (vboctor) directly, then I can address or re-direct them to the appropriate news group or individuals.

Security Bugs and Advisories

[giallu: this whole section seems quite orthogonal to the packaging issue; of course distro packagers are interested in security issues/patches, but this list seems more suited for a security team, not a packaging one]

  • Manage the process of porting security bugs to the latest stable branch and make sure there are bugs to track such porting work (with summary starting with “Port:” prefix and adding a relationship of type “related”).
  • Make sure that security fixes have the required level of documentation to support the process of creating security advisories.
  • Maintain a list of sites on which we would like to submit our new advisories.
  • Decide and maintain the format of the security advisory.
  • Author and publish security advisories.
  • Make sure security bugs cross references security advisories (e.g. include CVE in summary).
  • Make sure security bugs are reported as private and are changed to public once a stable release is released.
  • Make sure the security category is used “wisely” in the bug tracker.
    • Duplicate security issues should be marked as such.
    • If there are N security issues that indirectly refer to the same issue, then they a parent issue should be created and that is the one that should be documented, fixed, included in the change log, and published as a security advisory.
  • Security fixes should include a description of the fix. It can be explanation of how to apply the fix, a patch, etc. This should allow packagers to apply the fix, users who are not ready to upgrade to also do the same.
  • Advisories that are hosted on the Mantis website will be hosted on the wiki and will be all linked from an index page. The index page should include a table with information like: date, CVE, bug #s, versions affected, and summary.
mantisbt/role_packager.txt · Last modified: 2011/11/16 07:35 by atrol