Hi Bryan, > > It looks to me you view technology per se, so you want to join > > everything related to auth/dir/naming. I view not technology, but common > > tasks network admins need to do. That's why I prefer to keep all > > samba-related stuff like winbind separate from a more general > > auth/dir/naming exam. And that's why I think strong ldap skills are not > > required for LPIC-3-Samba. > > Sigh, I have _never_ said "strong" LDAP skills were needed. I only said > _basic_ object synchronization across an enterprise is needed, and one > that doesn't merely rely on native Windows servers.
Ok, so I guess we agree there could be a "core" auth/naming/dir exam, which touches LDAP, and a specific LDAP exam. And so the specifc Samba exam would have a foundation if we choose to include samba-ldap integration. But I don't think winbind would be part of the core exam. First, because it asks for specific Windows networking concepts and so it would be better in the samba exam which is the one who really needs those. Second, I can't imagine anyone using winbind outside a scenario of Windows integration. If someone uses winbind for apache or squid or whatever auth he does that because he already has the windows integration need and has to master samba for that. So this professional would need the samba certification anyway, and if the core auth/dir/naming exam does the job of making sure we can work with those concepts we'll be able to extrapolate his LPIC-3-Samba to solve the apache auth problem. We cannot test for ech possible combination and permutation of services, but we can test for essencial concepts and the more common specifc scenarios. By the way, I like your "Availability and Redunancy" proposal, and even think this could be another core LPIC-3 exam, or at least part of it. I don't thing we'll be able to build a successfull LPIC-3 without a core exam, required for all certification tracks. > As far as "technology" -- I though that's what UNIX/Linux is. It is a > set of services to implement a set of services in an enterprise. Not > only is Samba on its own _not_ such, but it relies on _other_ services > as well. Linux is technology, which serves to solve specific user and business problems. I guess exam development starts with identifying those needs, and them a specific technoloy becomes the focus of the solution. Of course Samba uses lots of other services to do its work, but anyway the sysadmin will find samba is the core of the solution and all other services will be used as "accessories" to samba. The core exam would build the foundation to those "accessory" technologies, and the other exams would test for specific ways those accessories need to be used with the main technology which is the focus of each exam. > I have tried my best to _simplify_ and _streamline_ the program with my > suggestions. You'all are looking at it as "oh, we can't do all that" > but you're looking at it from the standpoint of doing "all that" on > _each_ exam. No I don't. If I were I'd not be proposing a "core" exam as pre-requisite. My point is that not everything related to auth (like winbind) should go to the core. Thanks to PAM and NSS winbind can be used as a general auth tool for any Linux service, but this is not the common scenario. Whoever wants a general, central auth infrastructure will look into NIS or LDAP. And managing a set of LDAP server is complex enough to have its own exam. > I'm just saying take the common stuff -- the network-wide > synchronization of objects, authententication and resource information > -- and put it in a single exam. It's *NOT* a full-up LDAP exam, just an > _elementary_ one. But it would not be just an elementary LDAP exam, right? > P.S. A few questions to reflect on this "peer" review ... > > How many here have worked outside of the ISP world? Here in Brazil most Linux use is in either the ISP world or as intranets. Maybe that's the reason you center all on LDAP and I think this should be an option. But ISPs are not my focus at work. My consulting focus is development infrastructure: databases, application servers and development managenet (like revision control systems and bug tracking). I do a lot of heterogeneus network integration because few pros have both unix/windows/novell knowledge > On an enterprise network where you have to synchronize basic objects on > UNIX/Linux systems? NIS and NFS can do a good job there, but most people seem to be frozen in the time you could not integrate those with gsssec and kerberos. > And the Linux systems are doing more than just serving files to Windows > systems? Actually here Linux is not very popular as a file server, except for small companies. Big companies here tend to use Linux as web, e-mail , app or database server. Most of the time because they don't know how to use Posix ACLs. And the current state of many tools and distributions still looks to me as not very friendly for ACLs. And when it's used as a file server, it's essentially for Windows clients. You build file server to serve user workstations, and very few of them are Linux. :-( > Such as what my peers at HP, IBM, Red Hat and others are doing at their > clients, and I'm doing at mine as well, and have been for a decade. It looks to me as if you want to target only the high end of the professional market. But if this is the LPI target for LPI-3 that's fine. > And even then, legacy NIS/NFS died over 5 years ago, and we really have > to "get current" or I will still professionally recommend MCSEs or RHCAs > because they at least know a solution with a basic, distributed > authentication/object system that can service UNIX/Linux clients as well > as Windows ones. I think "getting current" also means properly configuring NIS and NFS. You don't have to use them in the insecure way it was done 10 years ago. And they are way easier to understand and setup than LDAP. I think Linux would be more used as the core enterprise infrastructure if the latest releases of NIS and LDAP were in common use. Going to LDAP is too big a step for many companies and professionals, at least in the current state of affairs, where configuring each service to use LDAP takes a lot of time. []s, Fernando Lozano _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/mailman/listinfo/lpi-examdev
