On Tue, 2006-06-20 at 18:20 -0300, Fernando Lozano wrote: > And winbondd outside samba will require covering NetBIOS concepts that > have nothing to do with other auth and naming services.
NetBIOS is object naming, nothing more. You have to deal with it if you use certain Windows authentication or object naming facilities. > 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. There's no "loss of focus." In fact, the naming issues of NetBIOS or even LDAP v. X.500, are _important_ aspects to enterprise object authentication and naming. > 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. Is it not the purpose of certification and training to further the knowledge of the professional, based on the mastery of those more experienced? > 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, You're kidding me here, right? > in which case they will do the test the next day and pass. > Else LPIC missed its goals. If you "water it down" to the point where anyone can pass without knowing 50-75% of the material, then it doesn't matter what you do. If you are not "rounded" enough to pass 50-75% of the material, you should _not_ pass. It's not about what you know, it's about knowing at least 50-75% of what you _should_ know. People are experts in one area, but there are _huge_gaps_ in other knowledge -- things that they _may_ run into in many other, but similar, roles. If this was LPIC-1 or even LPIC-2, to a lesser extent, I'd say it's not as big of a deal. But now we're talking enterprise-level, and that means you do *NOT* test standalone or departmental-concepts. You're testing _enterprise-wide_ details. > 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. I have a network resource. How do I get to _any_ major OS client? That's enterprise networking -- PERIOD. > Your proposal has nothing to do with "common denominators". It has _everything_ to do with "common denominators"! You mentioned NetBIOS. That's a _major_ constraint with Windows clients, even if you're _not_ sharing SMB services. Things _break_ on a network with Windows clients when certain NetBIOS constraints are not adhered to. Even with ADS. Even with Windows XP. Even when you're not connecting to a SMB resource. There are LDAP v. X.500 naming issues too. There are legacy UNIX limitations. These should be understood when you are integrating such things. > You want to join all services that are somewhat related to > authentication, user management and naming in the same test. Yes. > This is nice in theory but not practical, because you end up with > a too big foundation Really? So you'd rather cover only a limited number of auth/object for Samba, then another for Apache, and then another for database, etc...? And what you'll get is either simple, standalone/departmental setups that have _no_ integration with one another *OR* you'll redundantly cover many things over and over again on each exam to be more complete. Why should I recover how to authenticate Apache against ADS when some of the setup is shared by Samba or even NFS against ADS? > that in the end allows candidates to implement nothing, just > infrastructure for the services users demand. That's _exactly_ what I propose is the LPI 301 is! It's the _foundation_ for everything else! > And didn't those companies required people with other samba skills > besides winbindd? Nope. We didn't use network filesystems on that network at that ISP/ASP. > Didn't those companies had other servers who provided file acess > using either samba or Windows? Nope. ADS was the Kerberos and LDAP store. There was very limited NFS access via tunnels. Windows access was via SSH/SCP/SFTP using Kerberos as authentication. > Would those companies have choosen winbind if they were a true > linux-unix-only shop? They were Linux, MacOS X and Windows. I've yet to see a "true" Linux-UNIX only enterprise myself. > If I put winbind together with other auth services on the same tests, > passing becomes harder for pros who do not want windows integration. I'm sorry, but at some point, you can't avoid enterprise-wide authentication, object naming and storage services to a variety of clients. This is _not_ LPIC-1/2, and I consider LPIC-3 "enterprise" level. > And pros who need only the windows integration or just the windows file > services will miss a tool they'll probably need. Need for what? I'm taking the authentication and mapping portion _out_ of local and network filesystem details. I'm moving it to an exam that actually does it justice and doesn't cater to limited, local UNIX concepts. > 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? For the last time, _avoid_ scenarios! Avoid them completely! What you continue to advocate is that we _only_ focus on _fixed_, _segmented_ and _standalone_ network integration. > Every time I seen that there were also other servers that provided SMB. Oh ... so you are saying that you've seen NFS with SMB, eh? So how can you keep advocating separation of concepts and integration? > Will LPI certify PassSync and other proprietary tools BUZ! *WRONG*! PassSync is MPL dude. > 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. BUZ! *WRONG*! > Whoever does ADS integraton will most of the time use winbind, Not enterprises I work in. > and that's what LPI certifies: common scenarios. Listen, I'm used to being the 10% minority of viewpoints. It doesn't mean I'm any less incorrect. In fact, I get most of my work because of it. I pull companies out of the clusterfsck hole their IT departments and other consultants left them in. I don't pigeon-hole them with a "house of cards" solution but a stable, open enterprise. Even if part of the enterprise is ADS-controlled, there is also an open, UNIX/Linux-based infrastructure too. > 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. Don't speak for LPI customers unless you _really_ know. I'm going off of my consulting work, several of which are core LPI partners. > Reality presents more options, and won't help to say a customer he > made a bad choice. A customer _never_ makes a "bad choice." A customer only "poorly integrates" that choice. If you pick any solution, you had better integrate it proper. That means when we are testing on open source services, we had better test how you integrate it proper! I don't want to test people on a HOWTO or "Cookbook" solution. I don't want to test what someone can do at home or in a standalone department. We need to be testing what an enterprise installation should be capable of. And that begins with my vision of LPI 301 -- 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". But now you've gotta have links from the Apache exam to _both_ the Samba exam _and_ the Directory Service exam for the _same_concepts_. And you're quickly going to build a mesh across exams of redundant questions on multiple exams. > You want no certificatoin at all, because it's all about "scenarios", > that is, real tasks real admins need to perform in real networks. Huh? I'm 100% about tasks! You're the one limiting yourself with "scenarios." > Nice for core > Nice for samba -- does all Linux sysadmin have to understand what NTLM > is? Yes! Because an Enterprise Linux administrator _will_ run into it. > 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? They will _have_ to understand auth/dir/name in general. Winbindd is not much to add in that mix. > Again nice for samba, not for the general linux sysadmin Disagree entirely. > Samba specific, it doesn't make sense to test for this outside of the > samba exam. Disagree entirely. Especially if you're providing SAM-based store for non-SMB services. > Good for core > Core, no doubt. But Samba uses those as well! > Where are the "tasks" when you put together all authentication services > without any service that makes use of them? Authentication *IS* a set of services. Mapping objects *IS* a set of services. > 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. What do you think PAM and NSS are?!?!?! What do you think Winbindd primarily does?! And even nbmd too?! Authentication, basic computer/user/group objects/mapping and naming services! > 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. Huh? Kerberos ticketing is far more complex than you reality. You might think it's "simple" because you have been leveraging ADS as your KDC, and merely setting up Samba for it, but it's not. > And you know nothing about that a SAM is and what a Windows domain is. A Windows domain is 2 things: - Browser (system and resource naming) - Controller (computer/user/group principal store and authentication) The "Controller" is the System Accounts Manager (SAM). In a nutshell, its the portion of the Windows registry that is made network-wide by the first Domain Controller (DC) in a Windows domain. That's how it's been since NT 3.1 and still is in NT 5.1 (2003) ADS. Nothing damn special. You still have to deal with the SAM -- whether it's a Windows client or server. And there are services to do that, one being winbindd. The browser component is nmbd, although it's useless on its own for little more than broadcast, WINS or WINS-to-DNS proxy. > Nothing about domains memberships and how you find the DC. Domain membership is merely adding your computer to the SAM as just another principal. > Too much windows-specific stuff for a general core exam. BS. It's breaking down the commonalities of Windows credentials with UNIX credentials and integrating the two with services. > Will you be able to touch smb.conf and not knowing smbd and nmbd? Yes. Draw the line around the facilities, not the project that provides them. > 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? Yes. Draw the line around the facilities, not the project that provides them. Many different projects and their services require you to modify the same configuration files. No difference here. > Yes, they have lots of common dependencies, that no other services share > with them. Huh? Last time I checked, nmbd has a heavy dependency on DNS and other network services -- unless you're doing 100% broadcast/WINS which does _not_ work for peer UNIX/Linux services. Winbindd also has many other dependencies, including PAM and NSS, which are also heavily integrated into other UNIX/Linux facilities. Draw the line around the facilities, not the project that provides them. > If not the Samba team would provide them as separate, isolated packages If you read the Samba docs, that has not only been considered, but some people *HAVE* done it in various projects because they have _nothing_ to do with SMB! The Samba team even considered 10 separate daemons for Samba 3.0. > just like they provide rsync outside of samba. Where does Rsync bridge to Windows facilities at all? It's Tridgell's service that has _nothing_ to do with Windows integration. > They are the only one Linux services that require understanding > NetBIOS, SAM, ADS, the Network Browser and MS-RPC. If you take MS-RPC out of it, that's _not_ true at all! They first 4 also affect _everything_ on an enterprise network! What you advocate is that you _never_ integrate Windows credentials and naming with UNIX/Linux or other "open systems" credentials and naming -- *EXCEPT* when deploying SMB file services. You don't see any reason *EXCEPT* when SMB file services are in use on a node. Again, "standalone" attitude, not "enterprise." -- 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
