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
Attachment:
pgp5z7aepHI8g.pgp
Description: PGP signature