/etc/sysconfig/harddisks deprecated?

[Jeff Spaleta]

On 8/16/05, Paul Howarth <paul at city-fan.org> wrote:
> Try using /etc/sysconfig/modules/hdparm.modules instead.

Is /etc/sysconfig/modules  mentioned anywhere outside of the rc.sysinit itself?

I'm not seeing it mentioned in
/usr/share/doc/initscripts-8.11.1/sysconfig.txt nor anything higher
level that a novice admin would reach for.  This was introduced in fc4
and was not shipped as part of fc3. I'm just wondering how exactly are
admins suppose to be discovering these sorts of additions? Are admins
really expected to be reading over the logic in rc.sysinit script with
every iteration?

The only reference I see to how to use this outside of rc.sysinit is a
terse changelog line.. which doesn't indicate anything about the
naming constraints for filenames nor anything with regard to when in
the linear init process these files will be activated so an admin
would still have to read rc.sysinit directly to figure out what to do
and whether it fits their needs.
<quote>
/usr/share/doc/initscripts-8.11.1/ChangeLog:    
load user-defined module scripts from /etc/sysconfig/modules at boot
</quote>
Thats it.. thats the only reference I see on my system and its of
course duplicated in the rpm package changelog.

Now reading over rc.sysinit isn't particular difficult for an
experienced unix administrator.. but a dare say that there is a
significant segment of the userbase who are cutting their teeth on the
experience of being an 'admin' while running fedora at home are going
to be significantly confused when trying to read through rc.sysinit
unless they are explicitly told that they need to learn full bash
logic syntax before working with admin only level items on a fedora
system.  You need to know much less about bash scripting to write a
short hdparm.modules file that just has the hdparm commands you need
in it than it is to follow rc.sysinit.  Making the modules file
feature syntax only discoverable via rc.sysinit review seems backwards
to me.

I'm just asking to get a better feel of the learning curve
expectations being set for people who are going to admin boxes.  I'm
not looking to expose this graphically so people can clicky-click
their way through esoteric hardware setup.. I just want to make sure
that there is a clear understanding as to what admins should "know"
before touching the system and to make sure features are exposed in
such a way that admins can start from that baseline amount of
knowledge and work from that starting point with "reasonable"
on-system documentation and references to additional documentation.

I have a pretty good idea as to where the expectations lie for the
casual user functionality and its clear there is a long term plan to
get tools out for that audience that are commiserate with the learning
curve expectations for casual users.. but I don't think there is any
plan floating about on how to make it easier for a novice admin to
work efficiently with the system...especially when new functionality
is exposed.  For new admin accessible features ( like the addition of
sysconfig/modules/ ) that fall outside the casual user audience
definition,  I don't have any real sense as to what the consensous
expectation on what admins need to do to discover new features and
what they should do learn how to configure new features.  Nor do I see
an effort to identify baseline level(s) of knowledge assumed for
"admins" when exposing a new feature.    In this case it seems rather
counterproductive to require an admin to read through the logic in
rc.sysinit to discover that files need to be named
/etc/sysconfig/modules/*.modules and be executable.  The details need
to be explained in /usr/share/doc/initscripts-X.Y  at the very very
least.

-jef