Bug#533571: [checks/init.d] multiple corrections and enhancements
Russ Allbery wrote:
> Raphael Geissert writes:
>> Russ Allbery wrote:
>
>>> Init scripts are not randomly run before /usr is mounted.
>>
>> Unless they have a broken or incorrect LSB header (which... happens, and
>> hence my urgency on implementing the other check), or they play with the
>> default order values (not that often).
>
> Yeah, I'd be more comfortable keeping it if we suppressed it if the init
> script declared a dependency on the appropriate fs thing and it was
> using Perl. I agree with the idea for anything that isn't essential
> (because of the removal of dependencies problem) -- that *is* a Policy
> violation, since Policy says that init scripts must cope with still
> being installed when the package has been removed. If we exclude Perl
> and anything else that's essential, I think it might even be serious as
> you had it originally, the more I think about it, since scripts cannot
> deal with their interpreter missing.
Okay, agreed.
>
>> The init.d-related checks I still plant to write are:
>> * init.d-script-is-foo.sh-but-not-bin-sh
>> Basically making sure *.sh scripts use /bin/sh. This would have been of
>> more use when Policy still stated that script might be sourced.
>> Maybe with a severity/certainty of minor/certain?
>
> My instinct says minor/certain with a willingness to downgrade to
> wishlist or pedantic if anyone complains. There are enough reasons why
> writing an init script in something other than sh are a bad idea that
> I'd like to try it as a warning.
I think minor should be fine, since having a foo*.sh* init script with a
bash shebang is kind-of confusing; wishlist at worst, IMHO.
>
>> * init.d-uses-usr-binary-but-no-dependency-on-remote_fs
>> serious/certain?
>
> What we're going to run into with this is that in practice /usr is
> almost always mounted, which makes me wonder if this is RC. But
> supporting NFS-mounted /usr is something that Debian tries to do, so
> maybe it is. It's either serious or important, at least.
I saw a number of people saying they used encrypted partitions in the -devel
thread, which could also lead to the "/usr over NFS" effect/catastrophe.
>
> I'm not sure we're going to get enough accuracy on the file scan to be
> able to say we're certain, though. I'm thinking of init scripts that
> have optional actions that aren't one of the ones run during the build,
> possibly implemented with shell functions.
Hmm, indeed; I was thinking about using $LEADIN (which reminds me I need to
find a way to reduce the code duplication that this would lead to between
checks/scripts and init.d) to extract the names of the commands being used.
>
>> * default-file-contains-not-only-variables-and-comments
>> A check for anything that doesn't match:
>> m/^\s*(?:#|[A-Za-z0-9_]+=|$)/
>> serious/certain?
>
> Huh, I didn't even know that was in Policy. But there it is, so yes.
> (I suspect that will prompt a call to change Policy, but we can deal
> with that when it happens.)
After a quick scan on a set of packages I only found htdig to be using
a 'foo = bar' format, and tor calling ulimit from there. In general I agree
with the current requirements, as it ensures that any logic is performed
directly on the init script and not in the configuration file (not to
mention that the init script is supposed to be able to live and behave
decently without it).
Cheers,
--
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net
Reply to: