Re: etc scripts
David,
I suspect we're in over-violent agreement, but (as always)
it's the exceptions that are interesting.
> On Fri, Jun 11, 1999 at 11:42:55AM -0700, Nathan Myers wrote:
> > David Hinds wrote:
> > > This seems to require a proliferation of integration packages.
> >
> > That's the nature of integration.
>
> No, that is not the *nature* of integration, because as far as I know,
> you're just proposing a new (more general) solution to the problem,
> and it isn't one that anyone else uses.
I meant in general. Modularity is good, but it implies a need for
integration somewhere. When integration isn't done well enough,
people complain (incorrectly) about the modularity, and start asking
for violations of modularity.
> > *Somebody, somewhere* has to know
> > about the relationship. Either it doesn't get done (status quo),
> > it gets done in the wrong place (maintenance nightmare) or it gets
> > done in a seperable bit.
>
> Well, it has generally been done by having a central configuration
> facility that has a usually fixed range of services that can be coped
> with. The fixed range isn't ideal, but it handles 95% of the problem,
> which has made most people happy.
Yes. /etc/init.d (or /etc/rc.d/init.d, feh!) is such a facility.
> > > What if you also want to reconfigure ftpd, tcp-wrappers, and on and on?
> > > Why should PCMCIA be the central clearing house for network config
> > > scripts?
> >
> > It seems to be, now. I'd like it not to be.
>
> The PCMCIA network script is pretty simple, and while it can handle
> the basics, was never intended to be the end-all of network setup
> tools.
Right. It tries to do a little bit, and may even succeed. But
it sets a poor example. Scanning a directory, and providing little
scripts as examples to put in the directory, would set a better
example. In a robust distro those scripts would be replaced with
references to the more-general hot-plug apparatus, but your own
script wouldn't need to change.
> > It's the package that knows when cards are plugged and unplugged.
> > It doesn't have to know about ftpd etc.; it just needs to report
> > an event to somebody else (e.g. the network subsystem).
>
> So set up the Debian network subsystem so that there is a facility for
> handling adding or removing interfaces. PCMCIA is just one of various
> possible hardware arrangements that could support hot plugging. And
> everything that needs to be done for a hot plugged interface, needs to
> be done for a permanently attached interface at boot time. Thus the
> problem reduces to one that (should be) already solved. There is no
> need for creating a new init script heirarchy specific to PCMCIA
> network devices.
I agree, there are lots of hot-plugging interfaces coming, and PCMCIA
is among the better-behaved of them. USB and Firewire will be
"interesting". It would certainly be best to have a common framework
for them all. That's best done by setting them a good example.
As the grand-daddy of hot-pluggable interfaces, PCMCIA is a natural
to set that example.
> > But your scripts have distribution dependencies anyway, because they
> > try to do more than they have enough knowledge to do correctly. The
> > dhcpcd version problem was just an example of that.
>
> That is not what I'd call a distribution dependency. dhcpcd is used
> across all distributions, and the same (trivial) version check works
> in all cases.
There are several DHCP clients, all with differing interfaces and
semantics.
> > It doesn't matter. What is there now has all kinds of fragile (thus
> > probably wrong) knowledge about the rest of the system.
>
> Like what? As far as I can tell, it depends only on Linux standards,
> like finding network tools in /sbin, and use of /etc/resolv.conf. I
> have no reports of the script not working for certain distributions.
Mine was one. Generally your script doesn't do anything unless one
turns things on, and one doesn't turn things on unless it looks like
it will work. Scarcity of reports can be interpreted many ways.
> > > I don't really buy your argument that PCMCIA is the place where this
> > > sort of integration should get done. The integration of, say, dhcp
> > > with sendmail is not a PCMCIA issue, it is a general networking issue.
> > > If you solve the general problem, then PCMCIA can just make use of
> > > whatever your solution turned out to be.
> >
> > Exactly. All you want in the pcmcia scripts is something that will
> > use the integration solutions defined elsewhere.
>
> Right, and I want those solutions to be *elsewhere*. Red Hat did do
> this right: they've got "ifup" and "ifdown" scripts for configuring
> individual network devices. Their standard network scripts call
> these, and PCMCIA calls these. And if other types of hot plug network
> devices arrive in the future, they'll work fine, too.
RH made a good first effort, but their approach requires the
base installation to know too much about interfaces, and leaves
packages too little flexibility.
> > > If you like, you're welcome to implement the Debian network.opts file
> > > to farm out work to dhcp, bootp, sendmail, etc scripts just as you
> > > describe. That gives you everything you want, and doesn't require
> > > other distributions to conform to your system.
> >
> > That sounds fine, except for all the cruft in between ". network.opts"
> > and "start_fn" -- which are easily left turned off, _assuming_ that
> > nobody has defined environment variables that _happen_ to match your
> > choices.
>
> Come on, this is a non-problem. If you like, I can make the network
> script a bit more robust here, but it has never been an issue. And I
> can think of cases where inheriting those environment variables would
> actually be useful.
It's a non-problem as long as everything called from your script
is written with an eye on your script. To make your script call
general-purpose setup scripts would violate that proviso. More-robust
variable naming (e.g. PCMCIA_CS_DHCP instead of DHCP) would make it
a non-problem.
Nathan Myers
ncm@cantrip.org
Reply to: