On Fri, 2006-06-16 at 18:01 -0300, Fernando Lozano wrote:
> I think we agree on the most part but didn't choose well the words.
Maybe that's the case.
Listen, call the exams whatever you want. Maybe it's a matter of
pooling all of the objectives for now, then piecing off the objects and
the resulting tasks later to each exam.
> I don't think all authentication should be a pre-requisite because a
> Samba-based network (with mostly windows clients) would not need to use
> NIS and LDAP, but would be enough with winbind.
Understand winbindd _is_ a _key_ part of authentication/directory
services. It ties into NTLM and ADS -- as well as object mapping. And
it _can_ work for _other_ services too -- even NFS, Apache, etc...
Also understand that Samba can and does rely on other capabilities in
the system -- local, PAM/NSS, etc... I think people get so caught up on
"discrete" services and service names they miss the "bigger picture"
when it comes to how these services inter-operate.
> I agree that using LDAP and integrating samba with it would be
> preferable,
Doesn't have to be LDAP per-se. Remember, Samba can use any LDAP store
for various capabilities, or it can tie into ADS' LDAP store (namely its
SAM and other schema) for interoperability. I think you're making this
more complicated than it needs to be.
But I think the enterprise Linux administrator _does_ need to understand
_basic_ network-wide authentication, directory/resource listing and
elementary network object names. If we are going to sell this as the
Linux "equivalent" of MCSA and/or MCSE, you can't ignore these basic
concepts.
> but I also thing mastering LDAP is still very very hard
Whoa whoa whoa! "Very, very hard"??? No, I only think familiarity is
the only issue here -- and ignoring the general concept of network-wide
authentication, directory/resource listings and basic object naming is
the problem.
People keep thinking Samba is a "separate" and "discrete" service on its
own. It's not. It _never_ has been. Furthermore, people think
OpenLDAP and MS Kerberos tie-in is the _only_ way you can synchronize
with ADS. It is very much _not_.
Again, if we are going to sell this as the Linux "equivalent" of MCSA
and/or MCSE, you can't ignore these basic concepts.
> and it should not be a requisite for a level-3 samba or unix admin.
> Maybe LDAP should be another certification track per se.
I don't think people are understanding that even LDAP is not a
"discrete" service, much less Samba.
Systems _always_ use basic naming to find a network object.
Systems _always_ authenticate on a network.
Users _always_ authenticate on a network.
Systems _always_ use some directory/resource listing to find resources.
Users _always_ use network resources.
These are _elementary_ concepts that need to be _broken_down_ into
practical tasks and _real_world_ objectives.
If you think LDAP is "hard," fine, we'll write up some objectives and
then leave them out if you think so. But it doesn't the reality that
network resources _are_ published in _some_ directory or resource list.
But understand that relying on broadcast or legacy WINS services is
really _not_ modern, real-world enterprise networking.
> I don't think the lines should be drawn around authentication and file
> services.
Understand what I said. I said a line needs to be drawn as some point
between auth/dir/name services and file/print services because at some
point, the auth/dir/name services are _independent_ of the file/print
services. They are applicable to _other_ services like Internet/web,
database, etc...
Winbindd can be and _is_ often used for other services -- including NFS
and Apache if you wish. Or Winbindd doesn't have to be used at all, and
other mechanisms can used to map UNIX-Windows groups, handle password
synchronization, etc...
> Maybe my understanding about Level-3 objectives is wrong, please correct
> me if I am wrong, but a LPIC-3-Samba should have value per se and not
> just as part of an "enterprise certification".
I'm sorry, but I strongly believe we are now talking about LPIC-3 as an
"enterprise" certification program. Exams should be built on this, and
the foundation of _any_ "enterprise" program is network-wide mechanisms
for _basic_ services.
That's authentication, directory/resource lists and elementary object
naming. This is how many other programs do it too.
> If this is right, the LPIC-3-Samba should not require things from NFS
> and NIS (and whatever) but should require aything you need to build
> reliable samba servers.
Stop putting it in terms of NIS and NFS.
First off, NIS is _no_different_ than _local_ UNIX authentication and
resource lists. It has _nothing_ to do with anything but augmentation
of _local_ UNIX features.
Secondly, NFS is just about multi-client interoperability. That _only_
affects the network filesystem interoperability for multiple clients.
So fine, let's make a network filesystem exam on SMB-only and then
another exam for everything else like it's "not important." To get
everyone off of worrying about NFS, I'll say that for now -- *INGORE*
the fact I even brought up NFS and it's left to this "other, less
important" exam.
So, third, getting back to authentication -- winbindd _can_ be used to
authenticate Apache, Squid, etc... as well as other things (like NFS).
It can be used for things _outside_ of Samba. At the same time, Samba
authentication and user/group synchronization _can_ be done _without_
winbindd. In fact, in many enterprises, it is!
Sigh, at this point, I honest don't think people don't know the first
thing about how authentication, directory and naming works for Samba.
Or they are used to implementing Samba with legacy broadcast and/or
maybe WINS (or DNS proxy if we're lucky). You've read a cookbook and
don't understand what it does, except for the fact that it seemingly
"works."
And you have your Windows and UNIX and Linux all separate from one
another. No integration. No enterprise services. No federation. No
"Enterprise Linux" in your backbone, just separate.
> So I propose a "general" exam for naming and authentication, that would
> be a prerequisite for both Security, Samba and NFS/AFS tracks. And LDAP
> would be either a fourth track or an add-on ("level 4") to the Samba and
> NFS tracks.
Okay, that's tolerable.
But I think you're going to find you can't ignore the fact that
"resource lists" exists -- unless you're just going to stick with
NetBIOS and other broadcast protocols (SAP anyone?) to advertise
resources. You have to have centralized, "published" resource lists.
> So just take both tracks. Just like you can be both a MCSE and a MCSD.
Huh? That's a _poor_ analogy.
MCSD is a _developer_ track.
MCSE is an _administrator_ track.
MCSE covers _many_ things, not just ActiveDirectory Services (ADS).
In fact, Microsoft complements the ADS portion with network services.
> I don't think there's enough issues relating to sharing using both
> services at the same time to justify testing for this on the exams.
Do you know the #1 reason why I get consulting work? Totally screwed up
Samba permissions on directories that are already NFS exported. Totally
screwed up UNIX-Windows mappings. Totally screwed up DAC security.
HP, IBM, Red Hat, others -- ask them -- they aren't getting most of
their consulting work on "Windows integration." They are getting most
of their consulting work on augmenting or replacing UNIX, often with
UNIX/Linux clients as much or even more than Windows.
You can't have this "oh, well, we won't test on this" attitude.
Enterprises that are screaming for an authority on interoperability will
consider it a _joke_. Or they will just go CDE/CLE or RHCA.
> I like this idea, but it would be abother certification track and not a
> pre-requisite for a Samba or NFS admin.
The _only_ pre-requisite is authentication, directory and naming.
Everything else is _separate_.
But I think if you take the authentication, directory and naming aspects
out of the Samba exam, you might just have plenty of room for _other_
network filesystem questions like those for NFS. And, gasp, you might
even start talking about access control lists on files that are both
exported via NFS and shared via SMB -- because they must share
authentication and authorization info.
Any directory that can be shared by any network file service should be
covered on that exam -- because they can cause issues with each other,
and often _do_ in enterprise configurations. That means about the
_only_ network file service that shouldn't be covered in AFS -- which
uses virtualized filesystems and cannot be shared with any other.
--
Bryan J. Smith Professional, technical annoyance
mailto:[EMAIL PROTECTED] http://thebs413.blogspot.com
----------------------------------------------------------
The existence of Linux has far more to do with the breakup
of AT&T's monopoly than anything Microsoft has ever done.
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/mailman/listinfo/lpi-examdev
