Hi Bryan,
And why having winbind as part of the samba exam and not as part
of the auth exam would prevent this?
Because Winbindd on the Samba exam will take away from SMB and other
network file service concepts such as access controls and authorization.
And winbondd outside samba will require covering NetBIOS concepts that
have nothing to do with other auth and naming services. If winbindd is a
specific incarnation of a general concept, it should be tested together
where it has the bigger change of being used, and not artifially as part
of it's "general' category of tools. This way you actually loose focus.
It may look like a better focus for you who already maters the
technology and has years of expertize, but it wont't be the best focus
for LPICP candidates. It's a big mistake to suppose LPICP-3 will already
be enterprise network admins; those who already are won't look after
LPIC except if they need the paper to fulfill some bureucratic
requirement, in which case they will do the test the next day and pass.
Else LPIC missed its goals.
LPIC-3 candidates will have a specifc work focus: manage file services
for windows workstations; manage file services for linux workstations;
manage directory services for whatever service rely on then; manage
network security; and so on. We have to provide a minimum set of tests
and objectives for each professional focus, and not try to create a
certification for the guru who masters it all.
"Common denominators" to object authentication and naming go on the
auth/dir/name exam.
Otherwise we'll quickly find ourselves covering, recovering and even
more recovering the same "common denominators" and more and more exams.
Your proposal has nothing to do with "common denominators". You want to
join all services that are somewhat related to authentication, user
management and naming in the same test. This is nice in theory but not
practical, because you end up with a too big foundation that in the end
allows candidates to implement nothing, just infrastructure for the
services users demand.
And in the real world, how many companies use winbind without other
samba services?
ISP/ASPs do! Seen it many times for Apache!
And didn't those companies required people with other samba skills
besides winbindd? Didn't those companies had other servers who provided
file acess using either samba or Windows? Would those companies have
choosen winbind if they were a true linux-unix-only shop?
If I put winbind together with other auth services on the same tests,
passing becomes harder for pros who do not want windows integration. And
pros who need only the windows integration or just the windows file
services will miss a tool they'll probably need.
Put in another way, which scenario is more common:
1. a samba admin that adds winbind because his company centralizes user
accounts in MS ADS; or
2. an apache admin that uses winbind as a way to replicate users among a
group of internet servers, and has no file servers elsewhere that serve
windows clients?
I've also seen UNIX/Linux file servers that used it for authentication
against an ADS domain, but did _not_ provide SMB (only NFS or AFS)
Every time I seen that there were also other servers that provided SMB.
At
the same time, I've seen ADS integration _without_ Winbindd. They used
PassSync or other synchronization tool instead, and keep the objects
local to the UNIX/Linux network.
Will LPI certify PassSync and other proprietary tools you can use for a
Linux network, like Novell eDirectory? I think LPI will ask only for
software commonly bundled with Linux distros, if not only open source
software. So there's no point arguing you could do ADS integration
without winbind. Whoever does ADS integraton will most of the time use
winbind, and that's what LPI certifies: common scenarios.
I consider the "standalone" and "local-only" focus to have nothing to do
with "enterprise."
I don't think LPI customers agree with your definition of what
"enterprise" means. You see only the extremes, local/standalone systems
and the perfectly integrated network. Reality presents more options, and
won't help to say a customer he made a bad choice.
I'm not suggesting that. You keep thinking that I'm suggesting that.
Why? Because you're designing the Samba-only exam for 1-2 auth/dir/name
scenarios. And then every other exam for 1-2 auth/dir/name.
I don't know from where you took that conclusion. Just because I don't
think all possible auth/dir/etc scenarios should be together in just one
core exam I won't have duplication. I see nothing wrong with having an
apache administrator that needs to use NTLM or ADS-based authenticatoin
and tell him "take the samba exam".
I'm trying to _avoid_ "scenarios" all-together!
You want no certificatoin at all, because it's all about "scenarios",
that is, real tasks real admins need to perform in real networks.
I'm trying to say things like ...
- "Here's how you configure Kerberos' KDC, setup principles, etc..."
Nice for core
- "Here's how you configure NTLM authentication with Winbindd."
Nice for samba -- does all Linux sysadmin have to understand what NTLM
is? Don't you think someone can be a very good
apache/squid/nfs/procmail/mysql/imapd/ldap/cups sysadmin, and having
very few or even no knowledge about windows networking?
- "Here's how you map to native SAM objects."
Again nice for samba, not for the general linux sysadmin
- "Here's how you can store native SAM objects in TDB, LDAP, etc..."
Samba specific, it doesn't make sense to test for this outside of the
samba exam.
- "Here's how you leverage native UNIX/Linux network objects."
Good for core
- "Here's how you can configure local UNIX/Linux name switch."
Core, no doubt.
That _removes_ scenarios entirely! We don't want to be testing
"scenarios." We do _not_ want to be testing "cookbook" methods. We
want to be testing _tasks_ -- tasks that, when put together as a whole,
"do something" _across_ an "enterprise."
Where are the "tasks" when you put together all authentication services
without any service that makes use of them? One thing is factoring out
common concepts and practices, like PAM and NSS, another entirelly
differnent thing is creating a category like "auth" and forgetting about
real-world uses of the technology in that category.
If you say Kerberos could be on core, I concede, because understanding
Kerberos operation requires much less concepts than understanding
Windows authentication, and Kerberos has nuch broader use than nmbd and
winbindd without smbd.
On the other side, how could someone manage a winbind server and not
knowing the remaining samba stuff?
Quite easily!
You authenticate the system into the native SAM (Windows) domain.
And you know nothing about that a SAM is and what a Windows domain is.
Nothing about domains memberships and how you find the DC. Too much
windows-specific stuff for a general core exam.
You configure your smb.conf for only Winbindd components.
Will you be able to touch smb.conf and not knowing smbd and nmbd?
You start the service without smbd!
You do _not_ have to run smbd!
Hell, you can even run nmbd _without_ smbd too!
Just because you *can* run nmbd and winbindd without running smbd you
will *force( everyone to understand nmbd and winbindd, while very few
will do that and not have smbd running elsewhere?
And vice-versa in _all_ cases.
Just because smbd, nmbd and winbindd are not mutually exclusive doesn't
mean they have _any_ dependency on each other what-so-ever! ;->
Yes, they have lots of common dependencies, that no other services share
with them. If not the Samba team would provide them as separate,
isolated packages just like they provide rsync outside of samba. They
are the only one Linux services that require understanding NetBIOS, SAM,
ADS, the Network Browser and MS-RPC.
[]s, Fernando Lozano
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/mailman/listinfo/lpi-examdev
