Ikiwiki and WordPress

I’m hoping to understand better the issues with Ikiwiki that were raised during the last Summit - and the considerations underlying the decision to work on adding WordPress to FreedomBox’s Apps rather than(?) to work on resolving issues with Ikiwiki. Any suggestions where I might start looking?

Thank you.

Paul Allen

I think the discussion started with this thread…

which lead to this comment in the RFC for agenda items.

There are multiple ways of setting up websites in FreedomBox:

  1. Use a wiki like Ikiwiki or MediaWiki as a website (with some customization)
  2. Place the website files under /var/www/html and use Apache to serve them
  3. Create a user website using Apache mod_userdir

We also discussed adding static website generators like Hugo and Lektor.

The above options need the user to be able to use the command line, change file permissions, write Apache configuration etc. which not all FreedomBox users might be able to do.

WordPress was suggested as a way of creating websites in a WYSIWYG manner without much technical skills. We discussed adding WordPress about 2 years ago since the Debian package was already available, but we couldn’t go ahead because of security concerns. Now, we believe it is safe to add WordPress with our current systemd sandboxing which acts as a bulkhead limiting damage in case of a security compromise. The WordPress package itself comes from Debian, but plugins are third-party scripts which contain unknown security issues. So, we’ll try to keep plugins disabled by default if possible with an option to enable it if the admin knows what they’re doing.

WordPress is still not a full/only solution to this problem. We can still try to improve and make the other ways of hosting websites to be more user-friendly, e.g. by providing an easy way to upload files to /var/www/html and setting the correct file permissions automatically, providing a way to upload a local.css file to Ikiwiki etc.

1 Like

That’s why I don’t understand why my contributions to work out a general solution seem to get ignored, or not understood. (User-private-groups, group-directories in a central /home data directory tree, etc. for all apps to use and benefit from (allowing for easy to use preconfigurable defaults).

For “old fashioned” apps like ikiwiki it would also become trivial to “upload” and “permission adjust” files, if they were located in a set-group-id directory of the admin. Simply copy a file or edit the file using a local network browser using an admin account, or a plinth/web filebrowser.

All multi-user file permission problems solved, at once, and for all other cases as well.

Thank you - this background gives me a much better understanding of the initial concerns about Ikiwiki - and some things to check out for myself.

The lightweight options that I have found most user-friendly are

  • Branchable which is ikiwiki running on git. Joey H., who wrote branchable, also wrote the Debian Installer and git-annex. The nice thing about it is that you can build your wiki in a browser, from git (if you know git), or with other command line tools. This means that people who have a relevant workflow can just use it, and people building new skills are building skills that are useful and transferable. The documentation is great, too. If ikiwiki on freedombox could be augmented by emulating branchable, people who know git would be less likely to blunder with less familiar terms.
  • SDF, a public access unix since 1987, has a little script called mkhomepg that users run to set up their new website in their www directory. Once the website is running just fine (pages handwritten HTML, converted from markdown with pandoc, or produced with a static site generator), permissions inevitably end up broken at some point. The solution to almost every problem users on SDF have with their websites is to tell them to run mkhomepg -p, which fixes the permissions. Voila, your pages are accessible again.

I point these solutions out not in opposition to adding wordpress, but as examples of ways to make ikiwiki or static sites more user friendly that are proven to work in the wild. Neither of these are perfectly vanilla Debian solutions, but Debian does have ikiwiki and git of course, and the SDF mkhomepg script, while written for NetBSD, is just a shell script afaik.

EDITED to fix previous statement “ikiwiki on freedombox could be augmented by emulating git-annex” (which was not what I meant) with “by emulating branchable” (which was what I meant). Sorry for the confusion.

1 Like

I’ve only vaguely heard about git-annex. If it’s an essential part of Branchable, maybe we can consider adding it as part of our Ikiwiki installation as well. I’m interested in finding out more about the differences between Branchable and the basic Ikiwiki installation provided in Debian/FreedomBox.

This is very interesting. Though in case of FreedomBox our solution is more likely to be web-based than command line, the idea is still relevant. There should be some way of automatically setting the correct file permissions.

Adding WordPress is a decision already made. But there is still scope for discussion on how to improve Ikiwiki and make static websites more user-friendly.
Thanks for pointing out these existing solutions.

The output of mkhomepg -h on sdf, (when run by user hobnail) is as follows:

usage:  mkhomepg            (initial setup)
        mkhomepg -p         (set appropriate file permissions)
        mkhomepg -a         (set or unset your custom URL)
        mkhomepg -d         (set or unset http://sdf.org/~hobnail)
        mkhomepg -t         (toggles SDF cluster/MetaArray hosting)

The default url mkhomepg would setup for user hobnail is hobnail.sdf.org. Run with the -d flag, it toggles the url to sdf.org/~hobnail. The -a flag lets you set a custom url, like hobnail.com. The -p flag (as used by user hobnail) invokes chmod 644 or chmod 640, I think on the whole /www/hobnail directory, which is symlinked to the html folder in $HOME. It might do more. The -t flag is used for moving the site to a different host.

There is a short tutorial on building a website on SDF with mkhomepg. I think smj@sdf.org is the author of mkhomepg. He might be willing to share its source code. It’s a delightful little utility. SDF uses .htaccess to allow per-user configuration of the Apache server by normal users without admin access.

Gopher on SDF is similarly managed by the mkgopher command, written by smj in 2003. It allows help, creation, and maintenence of a gopherhole in the $HOME/gopher directory, which it symlinks (for user hobnail) to /ftp/pub/users/hobnail, and serves from gopher://sdf.org:70/1/users/hobnail/.

I think the branchable codebase is just ikiwiki plus ikiwiki-hosting. It seems like ikiwiki may run on git or svn by default. I only became aware I could manage my wiki by git when I started using branchable, thanks to branchable’s good documentation of how to use it via git.

Apache mod_userdir

That link actually contains different security advisories.

First thing mentioned is freedombox should probably rather serve the user websites on subdomains for example.

If somebody is using, or would like to use, the freedombox “user websites” feature, you could test the brush-up-groupdirs.sh script.

Among other dirs it also creates a ~/public_html SGID “group” directory. (And intends to fix permission problems that may have crept up.)

Would be good if somebody could test if it already allows for the user to seamlessly “collaborate” with the apache and web-apps on new and modified files.