Re: Bug reporting script
> > > I think that information could be quite useful. I think that user,
> > > group, and mode information would be very useful, as well. (Word-Perfect
> > > 5.x for Unix has "wpperm -[c|s]" that uses such a database to reset those
> > > attributes; it's quite handy for solving all kinds of permissions problems.)
> >
> > Ownership and permissions information only becomes useful for (typically)
> > a few files in each package - setuid binaries, for example. I expect this
>
> Maybe we're talking about different things - maybe we just disagree.
> I've seen wpperm fix problems in .../wp/shlib which is full of non-
> executable shared files. I've also seen Unix support Reps. indiscriminately
> run 'chmod 777 *' on large parts of a file system. I've seen the after-
> math of overworked, under-trained sys-admins changing owner:group as well
> as the file's mode. I've got examples on this system where file permissions
> aren't what they should be. We've had posts to debian-user and debian-bugs
> that were file permission problems. The list goes on and on.
I suppose there's no reason why my program shouldn't check stored
permissions/etc information if it's there. I guess that makes it a dpkg
issue rather than a repair issue.
(My first thought here was: just how much braindamage can we be expected
to cope with? There comes a point when the way to fix these problems is
just to reinstall the package and not make the mistakes again. But I
think this feature could be supported as an option without too much
trouble.)
> Sure, many of these things are preventable, but they happen nonetheless.
> It'd be nice to have a tool that checked/corrected these changes. Adding
> user:group and permissions information to /var/lib/dpkg/info/*.list is
> one way of providing the default information.
>
> My question is: "What level of functionality justifies added overhead and
> complexity?"
>
> > kind of thing is going to be sufficiently rare that it would be acceptable
> > for the 'bug' scripts I proposed earlier to check for themselves.
>
> Please, don't get me wrong, I like the idea of having a 'bug' script!
> I believe file permission problems are quite prevalent and can potentially
> affect any file. If this is true, then we should provide a mechanism to
> correct those errors. This function could prove useful as part of the
> base system, or dpkg. How consistent do the bug scripts need to be from
> package to package?
I think repair-0.1 is still in Incoming. I may upload version 0.2
tomorrow, depending what state it is in. Precisely how things work is
subject to change, especially if someone has a better idea, but:
Repair calls bug scripts with one option argument, which may be --sanity
or --user, and a filename. The --sanity option is supposed just to check
for the packages own configuration files being present, readable by the
right user, etc; the --user option checks for more user-dependent errors
(e.g. repair.bug checks that there is a /usr/sbin/sendmail; this is
potentially a user error if they have --forced dpkg to do something odd)
and engages the user in a dialog to try and extract more information about
the problem - e.g pointing them at /usr/doc/<the right thing> if
necessary.
In both cases a report of all this is written to the file specified, to
be included in the mail message that eventually gets sent (this will
contain things like 'user is sure it's not a bug with the MTA')
Support for automatically fixing permissions, etc, would probably be
through a --repair option.
There's a bunch of perl functions (currently living in /usr/lib/repair.pl)
which simplify doing all this; but if package maintainers prefer to use sh
or whatever for writing these scripts that'll work too.
Bug scripts probably shouldn't need to call dpkg, as repair should be
able to do that itself, though 0.1 isn't too hot here ;-)
ttfn/rjk
Reply to: