Re: Packaging questions (cricket)
On Mon, Aug 23, 1999 at 11:43:43AM +0200, Raphael Hertzog wrote:
> Le Sun, Aug 22, 1999 at 07:00:37PM -0400, Matt Zimmerman écrivait:
> > cricket-0.70
> > [...]
> > |-- images (used by the CGI)
>
> An already used solution was to put them in /usr/doc/<package>/ and then
> the images were available as /doc/<package>/<image> in the web tree.
>
> But this is likely to fail now that we're going to change /usr/doc with
> /usr/share/doc.
>
> Therefore the best solution is propbably to install them directly under
> /var/www I think. Or install them in /usr/share and put symlink in
> /var/www/
Do the default web server configurations allow symlinks like this?
> > `-- util (auxiliary and example programs called to do data collection)
> You should decide whether they are only examples or not. :)
They are pretty generally useful, so I am going to install them with the
library modules in /usr/share/cricket
> > - 'compile' (a program to convert the ASCII configuration into a database
> > format for use internally) in /usr/sbin as 'cricket-compile'
> if the user is not intented to call it directly, then simply put it in
> /usr/lib/cricket/compile and call it where necessary. :)
This is the only portion that will be called by the user; it will be run
each time the configuration is updated to compile it into a database
format (a la sendmail and the aliases database).
> > I have not yet decided what to do with the images...policy states that
> > packages should avoid touching the web server document root. Should
> > I install them under /usr/share/cricket and tell the user to Alias that
> > directory to /cricket/images with the web server or some such?
> No, the package should we working when installed. Install the images in
> /usr/share/cricket/images and symlink /var/www/cricket/images =>
> /usr/share/cricket/images ...
I am fine with this, as long as all available web servers have the equivalent
of Apache's 'SymlinksIfOwnerMatch' enabled per default. I don't see
anything in policy about this; is it a reasonable assumption?
> > the desired username is being used for local purposes, in which case I imagine
> > that Squid would break badly. Should I try to detect this situation (that is,
> > whether the user was created by my package or by the local admin, and act
> > appropriately), or is squid doing the right thing?
> I don't take care of this problem. It is not likely to happen ...
Hmm...I don't like the sound of that. The postinst will have to chown
directories to this user, which might be bad if there is already a real,
supposedly-unprivileged user with that name. Would it be reasonable to
check whether the user's UID is in the designated 'system' range?
> > To find where they are installed, so as to locate the 'lib' directory
> > immediately beneath. This actually works OK for the collector (in
> > /usr/share/cricket), as it will find the correct 'lib'. For 'compile',
> > I manually edited it to use /usr/share/cricket as its 'root'. This part
> > is kind of a mess.
> I also had similar problems, I simply wrote a patch which does allow to
> decide at install time where everything is installed and asked the author
> to include it.
The installation script already provides a mechanism for substituting the
location of the perl interpreter; it could probably be extended to do this
as well. Thanks for the suggestion.
> > - Have the collector write its logfile to /var/log/cricket
>
> With /var/log/cricket a directory. The log file beeing
> /var/log/cricket/cricket.log. This way you are sure that you have write
> permission to the log file. :)
OK, I'll do that. Thanks.
--
- Matt
Reply to: