Don't put poll data into webroot

[fonk]

Hi,

it would be great if the poll data wouldn't be in the webroot. With that,

• apache wouldn't need write permissions to the dudle code
• we could backup poll data without backing up program code
• put poll data on external volumes, which will be useful in combination with docker

Best regards,
Frank

[clawoflight]

You could solve most of that with a plain symlink for now, right?

[fonk]

I don't think so, because the folders for the polls in the webroot are named like the poll itself - and because I don't know which polls get created, I can't symlink the folders beforehand :-)

[mhdev90]

+1

@fonk Thx for the Docker Image!

[josch]

@fonk no you have to do the symlinks the other way round. Don't symlink the polls to somewhere else but symlink the cgi and ruby scripts to elsewhere. I did this in the Debian package I created and it works.

Basically, I have the real ruby and cgi files in /usr/share/dudle and permissions are set such that only root can modify files in it. The webserver only has read access. And then in /var/lib/dudle I have symlinks to all the ruby and cgi files living in /usr/share/dudle. The webserver has write access to /var/lib/dudle and can create directories there.

This solves all the things that you mentioned in your initial bug report:

• apache does not have write access to the code (because the files live in /usr/share/dudle in my case)
• you can back up /var/lib/dudle without backing up the program code (your backup would just include dead symlinks to the cgi and ruby files)
• you can put the poll data on external volumes

So maybe this could be documented somewhere but it already works without any modifications to dudle itself.

[kellerben]

do you have a make install target for the setup? I might include that…
(I might as well directly create the symlinks to /usr/share/dudle, i.e. a config param…)

[josch]

We can continue discussion about the install target in pull request #84