On Sun, Mar 09, 2003 at 06:38:30PM +0000, Colin Watson wrote: > It doesn't do any harm to have one if you have some bright ideas for > what should go in there, but I don't think it's necessary, no.
okay, i just put a little something like "this is a cgi script for
foo package, documentation for this package can be found in /usr/share/doc/foo"
in a manpage.
> > - is it a policy violation to ship an empty logfile?
>
> I doubt it's covered by policy (although I haven't checked), but I think
> it's a bad idea. You don't want to have the log file zeroed when the
> package is upgraded. It would be better to touch it in the postinst with
> the appropriate permissions, and possibly have logrotate deal with it
> appropriately.
yeah, that's a good point. also, logging's turned off by default, so
i figure just not touch it at all, and let the user create it if
he/she wants logging (and give instructions how to do so in various
places)
> (Doesn't the stderr from CGI scripts go to the web server's error log
> file anyway? I don't recall seeing a CGI script with its own log file
> before, but I suppose it could make sense if a lot of data is being
> logged.)
yeah, stderr does, but i didn't write the package, i'm just trying to
debianize it, and that's how the author has written it.
> Tricky. What happens if the admin has chosen to run the web server under
> some different uid/gid? Maybe the CGI script should be setgid to a
> special-purpose group and drop that gid for everything other than
> writing to the log file (which could be in /var/log/sugarplum writeable
> by the appropriate group so that you wouldn't have to worry about
> touching log files in the postinst). I'm not sure whether that's a good
> idea or not though.
that's a good point. one more reason not to ship/touch the file.
thanks for all the input,
sean
pgpXW4o0658U3.pgp
Description: PGP signature
