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.

Concerning secure, self-contained static website generation, the more powerful online-editable solutions (lektor with support for custom data structures) have already been mentioned…

But this seems really nice for very simple, plain small websites as in ~/public_html:

2 Likes

Not sure though, if yellow.php is like WordPress or its

…ecosystem of badness. With other web apps - like Wordpress for example - you can also have themes which can be made independently. But if themes can include arbitrary CSS and Javascript then this means it’s possible to create themes which exfiltrate data or attack users, and a black market then develops around such themes, which is comparable to the market for zero day exploits and other “cyberweapons”. In the presence of such threats, projects then usually create an official store or approved site for downloading themes, and once again you start to get gatekeeping and centralization. Points of control.
(https://blog.freedombone.net/tackling-the-ecosystem-of-badness)

1 Like