Chuck Mead <[EMAIL PROTECTED]> wrote:
>>
In my opinion anyone who can pass LPIC2 (if there is not even a single
Windoze question on it) will be able to handle a Windows client better
than 80% of the MCSE's in the field today and I have reason to know.
<<
I fully expect that to be the case. In fact, it demonstrates that even
committed Linux enthusiasts wind up learning more about Microsoft software
than they'd like to know - because 9 times out of 10, that's what's on the
client end of the wire. I rest my case. <g>
>>
Mickey$oft's crap doesn't
interoperate with anything that doesn't go out of its way on its own to
make it so.
<<
Correct. You're making my point for me: A really competent Linux admin
needs to go out of his way to learn something of the Windows world to deal
with it.
>>
Besides what the hell do you worry about nslookup for when
you're talking about Samba? Sounds like a WINS thing-a-ma-jig to me!
NetBIOS name resolution is a far cry from DNS.
<<
Agreed that nslookup and Samba are not related, protocol-wise. I was using
Samba as the most obvious example of a Linux subsystem where MS-related
knowledge and skills are useful. To get a large NetBIOS-over-TCP/IP network
involving Windows clients and Samba servers working, you need to understand
a bit about WINS, domain controllers, primary and backup browsers, browser
elections, the Windows way of doing name resolution, etc. Should this be
included in Linux course materials, and should LPI test for it? There's a
serious issue here.
Microsoft obviously uses the MCSE as a marketing tool; its primary purpose
is to produce an unpaid sales force of Windows evangelists in customer
organizations, and to that end MCSE training and testing includes the
minimum of information about interoperability that they can get away with
and nothing remotely favourable to competitive products. They're never
going to include information about getting Windows clients working with a
Samba server; they can only lose from that. However, the Linux community
has everything to gain from teaching how to configure a Windows client to
interoperate with a Linux server, and how to diagnose interoperability from
the Windows client end as well as at the server. By doing so, we'd be
claiming some moral high ground, and pointing to the fact that
Linux-related education and certification produces people with practical
problem-solving skills.
I'm not really suggesting that a Linux training course ought to teach
people how to configure Control Panel -> Networks -> Protocols -> TCP/IP on
Windows NT, although a comprehensive Samba course might. But we ought not
to shy away from it, and might say things like "If you want to turn off
password encryption, then the relevant Windows registry entry is . . ."
because these things are useful to know. Password encryption has been a
classic trap for young players. Is it a Windows problem? Yes. If a Linux
admin doesn't know about it, does it make him and Linux look bad?
Unfortunately, yes, in the eyes of many MIS managers.
My point remains: nslookup is part of BIND; it's still part of BIND 9.x
although it issues warnings about its being deprecated. If it wasn't there,
I would say "drop it". But it *is* there, in Linux - and a Really Useful
admin will know it. Someone who only knows dig and whines at me that '
"Mickey$oft's crap" doesn't have dig', is Not Useful. I think most
employers will favour Really Useful People Who Get Things Done, and I would
like to think that LPI certification is regarded as reflecting useful
knowledge and not operating system lawyering.
FWIW, it's no big deal. But in my courses, I'll still be making mention of
nslookup. If it never turns up in an LPI test, my students will never
notice. But if someone ever asks them if their DNS is broken, and they grab
a nearby Windows machine and run nslookup to check - well, perhaps they'll
remember what I told them and smile. <g>
Best,
--- Les [http://www.lesbell.com.au]
--
This message was sent from the lpi-examdev mailing list.
Send `unsubscribe lpi-examdev' in the subject to [EMAIL PROTECTED]
to leave the list.
