On Thu, Jan 6, 2011 at 08:05, Jesse Trucks <[email protected]> wrote: > On Thu, Jan 06, 2011 at 06:37:44AM -0500, Michael C Tiernan wrote: >> >> Would it be wrong to also develop a list of "expectations" or core >> competencies (or groups of competencies) that a "System Administrator" >> (Jouinor, Mid-level, Senior) should have or aspire to? >> > > This would be incredibly valuable. However, this is a non-trivial list > to generate in any sort of either cross-platform or categorized way. > This is a project on LOPSA's wish list, but it's such a major > undertaking to even remotely do in a useful way that we've not had > resources (mostly volunteers) to do it. > > If we got ten people suddenly excited about doing this AND that had a > wide range of experiences in different technologies and types of > organizations those ten people could make some great progress on this. > Yet, finding a variety of experience among people that want to do the > project make it quite difficult. > > I would not want to see a great effort in one area, say Linux (though > even that has enough variety it would be difficult to do without having > sub-categories for each of the major distrubition types), and then have > no effort whatsoever in any other area. That would mean we not only > failed the project, but we, once aain, look like we are not > platform/technology agnostic/neutral.
This dove-tails into an idea that has been kicking around my cranium for a while. Instead of trying to put together a large laundry list of things that must be configured on Redhat Linux, SuSE Linux, Windows, and $platform...I think it would be better to abstract this out to "System Administration Design Patterns". For instance, "Single Sign-On" could be one such pattern...or possibly a compound pattern. Each required component for implementing SSO would be represented as a unique "object class" within the pattern, and the basic, commonly required configuration information would comprise the properties and interface of each "object class". Just as Object-Oriented Programming Design Patterns can be implemented in practically any object-oriented programming language, System Administration Design Patterns should be able to be implemented on any system. For instance, a system monitoring pattern that requires a some manner of sending alerts to designated actors (be they people or other components), should be abstracted beyond the details of whether that communication system is Exchange, Postfix, Sendmail, AOL, Jabber, SMS, or even smoke signals. Distill that detail down to the absolute basics that are needed for transmitting the message, while maintaining as much flexibility for implementation as is possible, e.g.: default messaging preferences, a list of recipients, messaging addresses for each of those recipients, messaging _preferences_ for each of those recipients, connection details for method of transmission (command line? phone number for paging service? Originating mail/IM account? Connection details to the LEGO MindStorm controller that holds the blanket over the fire?...etc.), and perhaps a scheduling/throttling system so that messages are sent based on priority. That's just an off-the-cuff example. And there might be more details needed for that component of a system monitoring pattern. In fact, there would probably be several patterns for system monitoring. But a design pattern necessarily must not be _too_ complicated, in order to preserve it's utility and accessibility to all consumers be they students, implementers, managers, etc. We could start with the system administration design patterns, determine which of those are an integral part of any system adminstration role, and then determine curriculum recommendations (perhaps require that labs implement of these patterns within at least two platforms...bonus points for heterogeneous platform implementations) to ensure sufficient competency for any graduate to be successful in an entry-level position. By focusing on design patterns, and not specific platforms, technologies, file system implementations, network standards or vendor product offerings, we also provide a better foundation of knowledge that can improve any system administrators understanding of what they are doing. This is sometimes lost when a "computer guy" only learns how to configure one product, but doesn't understand which of those configured services are common to _any_ product that implements some or all of the same functionality. This _also_ would provide a resource for those who have to combine heterogeneous platforms into a single, _cleanly_ integrated system. "I know that both platforms, at a minimum, have to have a way of implementing this set of service components to provide the same functionality. So these services/platforms should integrate or overlap in such-and-such manner, minimizing the amount of 'middle-ware' needed to get it $desired_services to work throughout the whole environment." _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
