Subject: Re: The new rc.d stuff... [now rc.conf]
To: Robert Elz <kre@munnari.OZ.AU>
From: John Nemeth <>
List: current-users
Date: 05/11/2000 03:10:50
On Aug 29,  4:31pm, Robert Elz wrote:
}     Date:        Sat, 8 Apr 2000 01:24:38 -0700
}     From: (John Nemeth)
}   | That's nice.  However, there are a bunch of us that want it to
}   | stay, because removing it would make our lives as administrator's far
}   | more difficult.
} I actually doubt that, once you got a little used to it.

     It would be nice if you would stop trying to convince us of this.
I (and I assume others such as Greywolf) have used enough systems that
I know what works for me and what doesn't.

}   | Why should your needs and/or desires take precedence
}   | over other peoples?
} Of themselves, they shouldn't, nor should yours.

     However, you have been makeing demands, "rc.conf must go."  I may
have expressed my opinion rather strongly, but they still boil down to
if NetBSD makes certain changes, then it may no longer meet my needs.

}   |      Says who?  As of this moment, you're not even on the list of
}   | contributors (although you are listed as contributing to CSRG) much
}   | less being listed as having any kind of authority.  I just checked at
}   | .
} You're right, I have no authority in NetBSD at all.   You can take some
} heart at that if you like (that is, it isn't likely, or even possible,

     The problem I have is more to do with the way you expressed your
opinion then what it is.  You've said things like "rc.conf must go"
which sounds like a demand, and "rc.conf will go" which sounds like a
statement of authority.

}   | ssh, apache, amanda, and Xserver are all
}   | applications, not part of the OS.  Their configs don't belong in rc.conf
}   | which is an OS config file.  Nobody is arguing for a "Registry".
} rc.conf is an OS config file?   My OS config file, last time I looked,
} was in /sys/arch/`uname -m`/conf/NAME

     This isn't the L* camp (an OS consists of more then just a kernel)...

} Or is it that you're saying that syslog, cron, named, ntp, sendmail,
} xdm, gated ... are all "part of the OS" ?

     syslog and cron can certainly be considered to be part of the OS.
named, ntp, and sendmail are debatable.  I wouldn't consider xdm and
gated to be part of the OS (note that gated isn't supplied with NetBSD).

} And if so, why aren't you wanting their config files to be merged into
} rc.conf ?   They all have separate config files that you have to manage
} separately from rc.conf, and they're all also listed in rc.conf as well.

     As I said, I really don't want an M$ registry.  Perhaps, I should
have said OS startup configuration.  That should narrow things down to
just the subject at hand.

}   |      As long as the file keeps a defined format, this isn't true.  If
}   | somebody violates the defined format, then they probably don't care
}   | about automated tools.
} The "defined format" for rc.conf is that it's a shell script that
} contains only variable settings and comments.   Aside from that, it
} looks as if almost anything goes, just consider this fragment...

     I've already suggested that for people that want to treat the file
as a general shell script, they should put a line like
"#@NO_AUTOMATION" at the top which would tell any automated tools to
not touch it.  If that line isn't there then the "defined format"
should be restricted to simple variable settings and comments.

} # NFS daemons and parameters
} nfs_client=NO                                   # enable client daemons
}                         nfsiod_flags="-n 4"
} nfs_server=NO                                   # enable server daemons
}                         mountd_flags=""
}                         nfsd_flags="-tun 4"
} lockd=NO                lockd_flags=""
} statd=NO                statd_flags=""
} amd=NO                  amd_flags="-l syslog -x error,noinfo,nostats"
}                         amd_dir=/amd                    # mount dir
}                         amd_master=/etc/amd/master      # master map
} While I guess you could write something that can figure out what is
} going on there, parse it, and re-create it, I think I'd prefer not
} to have to.

     That wouldn't be very hard, and several people have stepped
forward offering to do just that.  Some have even suggested that the
tool have a configuration file that lists accounts that can change
certain variables.  This should solve everybody's complaints.

     I really don't understand the reluctance to have a large text file
that can be either maintained by hand or programmatically.  There are
several examples of this already.  One that everybody knows would be
/etc/passwd.  A somewhat more freeform example (variable definitions
and comments seperated into subsections) would be the M$ Windows 3.x
*.ini files.  These files are very similar to *.conf and are usually
maintained programmatically, but you could modify them by hand if you
wish (and I have).  In other words, this is a solved problem.

} And all this is ignoring the possibility of actually allowing both
} options to continue to exist - letting you keep all your settings in
} rc.conf if you like, but also allowing them to be in individual files.

    This could make for a maintenance nightmare.

} And even the latter is "all in one place" really for those who claim
} that is what they need - it's just that the "place" is a directory
} rather than a file.

     A directory barely qualifies as "all in one place" and handling a
directory full of files as opposed to just one file is a major pain in
the neck.

}-- End of excerpt from Robert Elz