This is a place for questions and discussions that don't have a Discussion page fitting enough. Users of ikiwiki can ask questions here.

This is a bold experiment by me, since I have exactly such a question. This overrides the default content/discussion dichotomy, feel free to refactor and discuss! --ulrik

Current topics

Hi All;

I'm trying to use a filter hook as part of making wikilinks work in tex4ht. It seems that filter is called for every page. For my application I just want it to be called for ".tex" files, but right now I have to have a look at the content, which I don't like so much.

Is there a better hook to use for this? I need to transform the input before preprocessing.

DavidBremner

Posted Fri Sep 12 14:01:56 2008

Dear developers and users,

Problem

I am trying to set up ikiwiki for a website. Users should be able to edit pages using the webbrowser (ikiwiki.cgi) and a few should be able to edit it using versioning control and in this case Git.

I have ikiwiki working for a single user (me), but I do not get the permissions right for multiple users and commiters. The wiki admin does not own the Git repository in this case. And I do not understand everything yet (especially concerning wrappers).

Programs

I am running Debian Etch with gitosis (0.2+20080626-2) installed from etch-backports, Apache2 (apache2.2-common 2.2.3-4+etch5) and ikiwiki (2.63) from Sid.

Goal

  • The website (run by ikiwiki) should be accessable via http://www.example.org/
  • Users can edit pages using the webbrowser.
  • Git is used as the backend.
  • The Git repository should be publicaly browsable via http://git.example.org/git/project.git (gitweb).
  • The Git repository can be accessed with git clone git://git.example.org/git/project.git (git-daemon).
  • Some manually set up users can push their changes over SSH to the repository and the post-update hook updates the wiki.

Directory Layout and permissions.

Website

The website is stored in /srv/www/www.example.org/htdocs/ (destdir in ikiwiki.setup) and is owned by www-data:root with rights 755.

Git repository

The package gitosis creates an user gitosis with the home directory /srv/gitosis/ and the repository are stored in /srv/gitosis/repository/project.git owned by gitosis:gitosis and permissions 750. I can setup the permissions who is allowed to access this repository and if it should be published using git-daemon or gitweb in the configuration file gitosis.conf.

My efforts without results

I could not come up with a working set of users which are put into different groups to create a good result with ikiwiki. The main problem is that under Debian umask is set to 022 which means that the members of a group are not allowed to write. I did not want to change this.

You can set the umask for ikiwiki itself, without changing the system umask, via the usmask setting in the setup file. --Joey

In the end, I did the following. I created a directory /srv/ikiwiki/ which is owned by gitosis. The setup file is also located there (/srv/ikiwiki/project.setup). I put the srcdir there too (srcdir => '/srv/ikiwiki/project/'). So now sudo -u gitosis ikiwiki --project.setup is able to create the post-update hook (git_wrapper => '/srv/gitosis/repositories/project.git/hooks/post-update'). Since this hook is called every time something is checked in over SSH, it is run by gitosis, so I did not set it suid. Or do I have to, because ikiwiki.cgi will be run as www-data?

Generally, ikiwiki.cgi is run as the user who owns the wiki and repository, in this case, gitosis. The ikwiiki.cgi needs to be able to write to source files in the wiki; it needs to be able to commit changes, and it needs to be able to generate and write the html files. If you don't want ikiwiki.cgi to run as gitosis, you will need to put gitosis and www-data in a group and give them both write access, with appropriate umask, etc. --Joey

cgi_wrapper

I do not understand those wrappers completely. The cgi is a script, which can be called by a webserver, e. g. Apache 2. But www-data is normally not allowed to write to the source directory (which is owned by gitosis or push to the repository). Therefore it should be run as the user gitosis. And because cgi scripts can not be made suid, I wrapper (in this case a C program) is created (cgi_wrapper) which can be made suid and therefore be run as the user gitosis. Is this correct?

It seems to me like you understand the wrapper pretty well. It's main reson to exist is to safely be suid, yes.

So where is good place to save this wrapper? cgi_wrapper => '/srv/ikiwiki/project-wrapper'? Then /srv/ikiwiki/project-wrapper is created from a temporary C file prject-wrapper.c?

No sudo -u gitosis ikikwiki --setup project.setup is still not able to put the compilation result into /srv/www/www.project.org/htdocs because this is owned by www-data. I just came up with two things.

  1. Set destdir => '/srv/ikiwiki/html-project', do ln -s /srv/ikiwiki/html-project /srv/www/www.example.org/htdocs and adduser www-data gitosis. But I am not sure about the security implications of using symbolic links.

  2. Since the webserver (Apache 2) has just to read the html files (is that true for static and dynamic (PHP) pages) sudo chown -R gitosis:www-data /srv/www/www.example.org/ should do it. But it is per default www-data:root under Debian, so I do not know if this should be changed.

Could you please enlighten me. It should be possible seeing for example this site.

www-data is not really intended to own files. So that if the web server is compromised, it cannot rewrite your web site. So make the site's destdir be owned by the same user that ikiwiki runs as. /srv/www is not shipped by debian; it is a bug in debian for any package to make files owned by www-data; so it seems to me that your /srv/www www-data ownership is something you must have configured yourself. --Joey

Thanks in advance,

--PaulePanter

Posted Thu Sep 11 15:31:34 2008

I don't know if I'm doing this right... I'm using a server provider that doesn't allow me to install into standard perl locations, so I used PREFIX to install things in my home dir. The problem is that when the wrapper is run by the CGI server, it can't find the perl modules I installed. There didn't seem to be a way to set the PERL5LIB from the standard config, so I added one. Patch attached. Or did I miss something and this was already possible?

The standard way to do it is to set INSTALL_BASE=$HOME when running Makefile.PL. If you do this, ikiwiki will be built with a special use lib $HOME line inserted, that will make it look in the specified directory for perl modules.

The nearlyfreespeech tip has an example of doing this. --Joey

Thanks! I found that page, but didn't recognise the importance of INSTALL_BASE.

It looks like INSTALL_BASE only appeared in version 6.31 of the Perl MakeMaker. My provider is still running version 6.30. Looks like I'll be keeping my patches for the moment... sigh.

Posted Mon Sep 8 12:30:11 2008

[[!teximg code="{}pFq(a1,...,ap;c1,...,cq;z) = \sum{n=0}^\infty \frac{(a1)n\cdot\cdot\cdot(ap)n}{(c1)n\cdot\cdot\cdot(cq)_n} \frac{z^n}{n!}"]]

JAJAJA, the teximg is not loaded... :-(

Bye.

This wiki does not have teximg enabled. --Joey

Posted Mon Sep 8 12:30:11 2008

Greetings.

I am put this code in one page: [[!teximg code="\frac{1}{5}" alt="1/5"]]

this is the configuration file ikiwiki.info:

add_plugins => [qw{sidebar goodstuff textile html htmlscrubber table pagetemplate teximg map meta anonok img version textile txt}]

Here the log

This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) (format=latex 2008.8.4) 5 AUG 2008 10:01 entering extended mode %&-line parsing enabled. **/tmp/fb7742f8dd0c66473643ba40592e2be2.SBQfJo94ii/fb7742f8dd0c66473643ba40592e 2be2.tex

(/tmp/fb7742f8dd0c66473643ba40592e2be2.SBQfJo94ii/fb7742f8dd0c66473643ba40592e2 be2.tex

[...]

Package scrkbase Info: You've used the obsolete option `12pt'. (scrkbase) \KOMAoptions{fontsize=12pt} will be used instead. (scrkbase) You should do this change too on input line 594.

[...]

! LaTeX Error: File `mhchem.sty' not found.

Type X to quit or to proceed, or enter new name. (Default extension: sty)

Enter file name: ! Emergency stop.

l.1 ...l}\usepackage[version=3]{mhchem}\usepackage

                                              {amsmath}\usepackage{amsfo...

(cannot \read from terminal in nonstop modes)

Here is how much of TeX's memory you used: 761 strings out of 94074 10268 string characters out of 1167096 66007 words of memory out of 1500000 4120 multiletter control sequences out of 10000+50000 3938 words of font info for 15 fonts, out of 1200000 for 2000 645 hyphenation exceptions out of 8191 30i,1n,28p,410b,45s stack positions out of 5000i,500n,6000p,200000b,10000s No pages of output.

Some idea ?.

It looks like teximg uses some less standard LaTeX packages. (see line 100 of Ikiwiki/Plugin/teximg.pm in the Ikiwiki source.) A quick work-around for an end-user would be to install the 'mhchem' LaTeX package (look in CTAN ). A medium-term workaround would be to replace 'scrartcl' on line 100 with 'article', and delete line 101 in the teximg source. Longer term it would be nice to give teximg a configurable preamble. Hrm - maybe that configurable preamble should be a todo? -- Will

Yes it works. Thanks. I am writing some code for examples.

Posted Mon Sep 8 12:30:11 2008

Hello. My ikiwiki is at an unreliable and unprofessional host, that still has many advantages. It's my university. One thing making sure I tolerate this is that it is free and I have ssh access. Now I have two location onto which I would like to put my website, both are of the form of http://users.university.top/user/wiki/, where "user" is different for each host. This is a problem for some of my wiki pages:

I have some pages in the wiki (content) and some files in a directory parallel to the wiki directory called publicfiles/, and some images in images/. Now I want to link to files in publicfiles/ and images/ from the wiki, and I can't use absolute paths, since the "user" part is different in each URL (and will be different for each host I choose). I could use relative paths, that has worked before, so I type ../../publicfiles/file.tar.gz; but I've run into a problem again: inline pages. For inline pages where you include pages from a different level, it doesn't work.

I've tried a middle ground with pages relative to the wiki top, that is the link index/../publicfiles/file.tar.gz. I think ikiwiki doesn't allow this, doing index/../ doesn't take you out of the wiki root.

I found one solution, and that was to put a symlink called publicfiles into the wiki/ directory. This has to be put in place on the server I think, I don't know how this will do with ikiwiki or my remote sync. --ulrik Thu, 20 Dec 2007 22:07:05 +0100

But not even the symlink solution works, since I have only two choices, specify relative to the ikiwiki page, or relative to the absolute webdomain root. I need to specify from wiki root :( for example the link publicfiles/ will not as I thought link always to wikiroot/publicfiles , but rather link to publicfiles in the level of the wiki you are at right now.

--ulrik

If you put the publicfiles/ into the srcdir that ikiwiki builds the wiki from, then it'll know about them and wikilinks to the files will work same as wikilinks to any other files ikiwiki knows about. Perhaps there's a reason you can't do that, such as the files being too large, or not being available on the host you build on, I don't know. --Joey

Yes, that would solve it. A part of me wanted though that it should be possible to put a symlink called publicfiles that basically points to wikiroot/../publicfiles, and have the ability to link to files with wikisyntax anyway. But it doesn't work since symlinks are dangerous, and.. how would ikiwiki know how to interpret a relative link, relative to source dir or dest dir (etc..)? I'll have to put all my images and publicfiles into the wiki; it is principally wrong since publicfiles are tar.gz (and a few .deb files) for software, but it is practically ok since the individual files are not more than 150K and I don't have anything against archiving them. --ulrik

You know, you don't need to check the files into revision control, they can just be put in the srcdir of the wiki outside revision control.

To try to formalize and clarify my first proposal: An administrator would be able for each wiki to create a list of off-wiki "places" that are accessed via certain items in the wiki root (or could be under a subpage too of course). The example is illustrated by publicfiles and the symlink, but a non-symlink solution would probably be better. A natural way to specify off-wiki places are absolute URLs, but also relative to the wiki root, since that would fit to my case. Just like you can't go out of the wiki root, you should not be able to go up from such an external resource. This should all be done in some plugin of course. I'll have to learn Perl before I write the plugin though :) --ulrik

Posted Mon Sep 8 12:30:11 2008