On 12/15/2011 9:00 PM, Anton Aylward wrote:
Brian K. White said the following on 12/15/2011 08:48 PM:
If you are only trying to debug the immediate situation then ok. As in, if you're just trying to nail down what the automatic process actually did when it came time to do it.
Yes; and much of that is now off-list.
I thought you were suggesting that it's acceptable to expect that config files have nics defined in them for a client to reach a service. That would be unreasonable. For offering services that's different. But a client should not have to know what nic is required to reach a service other than maybe a dhcp client.
In the general, I agree, but not - NEVER - where specifics define it. Many v-for-verySMB and home networks are pretty trivial and strapping them down can avoid other hassles. Such trivial systems don't need their own DHCP or their own DNS server. I imagine most single-machine home system are like that. They simply don't warrant the complexity. Having a defined chain where things absolutely HAVE to be in the set ordering makes phone debugging a lot easier when you're dealing with people who can't tell the difference between a d CD drive and a coffee cup holder.
I would say the opposite. Small customer networks (1 to 50 devices, no dedicated IT staff or even anyone halfway conversant) got 50 thousand times easier to maintain after commodity routers and dhcp became the norm. Making something automatic and dynamic involves more complex code somewhere, but makes the install, use, and administration simpler far more often than it makes it more complex. Only when the automatic protocol is garbage and unreliable does it make things harder. I still configure printers with static IP's because allowing them to dhcp and relying on netbios to resolve their names fails more often than the static config breaks due to the customer changing things. Hard coding things is simply a guaranteed way for them to break sooner or later, and when it does, the unusualness of hard coding something will waste the time of the guy who gets called in to fix it, or simply be beyond them utterly since so many local IT guys are so bad. True a hard coded thing will not ever break all by itself because it itself never changes. Then again it will never fix itself either. And automatic/dynamic things may break sometimes because the extra complexity means more opportunities to break. But they will often fix themselves. Everything is always changing. Very small business owners routinely break everything I ever set up hard coded because they replace printers and workstations, their whole cable/dsl/fios connections, routers, firewalls, everything, willy nilly. And then, after they do it and have sent the grocery bagger slash cable modem installer home, and they finally discover that everyone can get on the internet but no one can get on the local server, then, though I didn't cause this emergency and was not even warned it was going to happen, I still have to drop whatever else I was doing and fix them immediately because they can't work until I do... Only the automatic stuff has any chance to keep working. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org