deutrino's picture

I'm wondering if there would be any interest in a Tiddlywiki container which serves one or more tiddlywikis with authentication & webdav enabled, so the wiki will save back in place over itself on the server when updated.

Mainly wondering because I just got part of this (minus authentication but that's later) working for myself with Apache on a Turnkey core image. And it seems conceptually pretty simple, and perhaps less complex for a first image than some of the others I still have on my list (LEPP, Pleroma, etc).

I would be doing this by enabling the Apache userdir mod to serve ~/public_html, and modify /etc/apache2/mods-available/userdir.conf to enable WebDAV.

I'm curious if anyone has thoughts about the fact that currently, once a wiki is modified and saved, it lands in ~user/public_html/wikiname.html with user and group both set to www-data. Might be nicer to have it owned by the user.

My thought in doing it all this way is that it takes advantage of basic Linux mechanisms to be multi-user (just create accounts and create ~/public_html, and stick a tiddlywiki copy in... maybe could be done by skel) ... and then backup, sharing, etc of a stable of tiddlywikis (should one ever have such a thing) becomes as easy as using standard utilities to deal with everybody's public_html.

Anyway, Tiddlywiki is great in its niche (a fully functional wiki in a single .html file) but serving & saving changes has always been its Achilles heel due to the browser security model. Anything that helps that (like a Turnkey image which serves up Tiddlywikis) is a good thing.

Forum: 
Jeremy Davis's picture

TBH, I've never used TiddlyWiki, but it looks cool. It sounds like you know it fairly well though, and have some great sounding ideas on making it more useful for people! :)

As you note, it sounds somewhat more straight forward than some of your others (although TBH, I reckon LEPP should be pretty straight forward). Your ideas sound really coll and I'm on board with it in essence.

So here's a bit of a ramble from me about your plans so far. Please excuse the fact that it's a bit of a stream of consciousnesses...


Re your general plan for this, I think putting the wiki html file in /etc/skel is a good one. I assume that it would work around the issue that you noted too? You could make www-data the group owner of these files and set 660/770 (file/dir) permissions so that Apache can read/write. Setting the 'setgid' bit for the directory would ensure that future file will always inherit the www-data group ownership. It does still

Although it will create a new issue as the permissions of the skel contents are modified by adduser/useradd and any pre-configured user/group ownership related permission info will be lost (it does seem to preserve the general octal values; just not the more detailed stuiff). However, there is a workaround. If you add a script named /usr/local/sbin/adduser.local then adduser (and I guess useradd too?) will run this after it's doing it's usual thing. FWIW, I tested to make sure I wasn't leading you astray and here's what I did:

mkdir /etc/skel/public_html
echo "this is a dummy wiki for testing" > /etc/skel/public_html/wikiname.html
chmod 660 /etc/skel/public_html/
chmod 770 /etc/skel/public_html/*

cat > /usr/local/sbin/adduser.local <<EOF
#!/bin/bash -e
# simple script that will be leveraged by 'adduser'.

# 'adduser' passes USERNAME UID GID and HOME:
username=\$1
user_id=\$2
group_id=\$3
user_home=\$4

html_dir=\$user_home/public_html

echo "Tweaking permissions for \\\`\$html_dir' ..."

if [[ -d "\$html_dir" ]]; then
    chgrp -Rh www-data \$html_dir
    chmod g+s \$html_dir
else
    echo "Error - \$html_dir not found."
    exit 1
fi
EOF
chmod +x /usr/local/sbin/adduser.local

adduser tester

(Note it would possibly be better to just add this script to the build code overlay rather than create it like this).

The last command gave me this output:

Adding user `tester' ...
Adding new group `tester' (1001) ...
Adding new user `tester' (1001) with group `tester' ...
Creating home directory `/home/tester' ...
Copying files from `/etc/skel' ...
New password: 
Retype new password: 
passwd: password updated successfully
Changing the user information for tester
Enter the new value, or press ENTER for the default
	Full Name []: 
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
Is the information correct? [Y/n] y
Tweaking permissions for `/home/tester/public_html' ...

And the 'public_html' dir looks like this:

root@tkldev4 ~# ls -la /home/tester/public_html
total 12
drwxrws--- 2 tester www-data 4096 Jan 19 14:34 .
drwxr-xr-x 6 tester tester   4096 Jan 19 14:34 ..
-rw-rw---- 1 tester www-data   33 Jan 19 14:34 wikiname.html

Unfortunately there is still an issue. If you log in as the user and create a new file, it will be readable by www-data, but not writable. I.e.:

tester@tkldev4 ~$ touch public_html/new_wiki.html
tester@tkldev4 ~$ ls -la public_html/
total 12
drwxrws--- 2 tester www-data 4096 Jan 19 14:38 .
drwxr-xr-x 6 tester tester   4096 Jan 19 14:38 ..
-rw-r--r-- 1 tester www-data    0 Jan 19 14:38 new_wiki.html
-rw-rw---- 1 tester www-data   33 Jan 19 14:34 wikiname.html

There are a few ways that we could workaround that last one. One way would be to use ACLs, although that's not really an option as they won't work in all builds (e.g. the Proxmox/LXC builds). Another is to use the umask, that's not a good one either though as it's a user level setting; not a directory setting so it has security implications. Same thing applies to making www-data the default group for the new users.

Although, actually thinking about this some more, perhaps an even better way to go would be for each user to have their own Apache instance(s)? (So rather than run udner www-data, run under each user's account). I've never done it before but the Apache multiuser module is what we'd want?! If we go that way, I suspect that much of what I posted above will be irrelevant...

Regardless, hopefully from all the above bits and pieces we could cobble something together. I'll leave you to research/ponder/test that. Please let me know how you go.

As for the actual TKLDev stuff, starting with core sounds like a great plan. Don't forget that there is a ton of stuff in common (/turnkey/fab/common) which can be leveraged. E.g. to get our common Apache set up, you could use a Makefile like this:

COMMON_CONF = apache-vhost
COMMON_OVERLAYS = apache

include $(FAB_PATH)/common/mk/turnkey.mk

FWIW MoinMoin (see appliance build code) is a wiki written in python which by default stores data in the file system, so whilst you won't need any of the python bits, the fact that it also doesn't have/need a DB nor PHP, etc means that it could be worth a look as something of an inspiration/ideas?!

Anyway, I've rambled enough. Good luck with it and I really look forward to hearing how you go with this one.

Add new comment