From stevegt@TerraLuna.Org Wed Feb 1 05:57:48 2006 From: stevegt@TerraLuna.Org (Steve Traugott) Date: Tue, 31 Jan 2006 21:57:48 -0800 (PST) Subject: [Infrastructures] ISconf 4.2.8.220: protocol fixes, large file support Message-ID: <20060201055748.0DDDA241C2@spirit.terraluna.org> Hi All, I'm pleased to announce the release of ISconf 4.2.8.220: http://trac.t7a.org/isconf/pub/isconf-4.2.8.220.tar.gz This maintenance release makes several performance and reliability improvements, allows for 'snap' of large files, and fixes a potential UDP flood condition. You'll want to upgrade to this version. See http://trac.t7a.org/isconf/timeline for change history. More on large file support: By "large files" I mean several hundred megabytes -- yes, you could 'isconf snap' an entire .iso image now, if you were so possessed. We're not doing any chunking or starvation inside the cache yet, so *all* of your hosts need to have plenty of free space if you try that; consider yourself warned. There are still known bugs in the 4.2.8 series that aren't fixed. As I receive feedback I'll continue to balance 4.2.8 maintenance against the 4.3 series -- some of the remaining bugs are in code which 4.3 deprecates. Feel free to let me know what you would prioritize, and I'll factor that in. The 4.3.1 work, continuing, focuses on the TCP mesh code. This will give us the ability to retire UDP, simplify firewall rules, and provides the foundation we'll need later for reporting, asset management, authentication, authorization, and monitoring. Look for 4.3.2 as the stable release of this next version, and see http://trac.t7a.org/isconf/roadmap for details. Take Care, Steve --- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com -- http://Infrastructures.Org From mlkb@x-tend.be Wed Feb 1 08:23:57 2006 From: mlkb@x-tend.be (Kris Buytaert) Date: Wed, 01 Feb 2006 09:23:57 +0100 Subject: [Infrastructures] openQRM Message-ID: <1138782237.2574.14.camel@mine2.x-tend.be> Anyone already looked at openQRM ? What do you people gernerally think about it's concept ? Do you want to deploy machines or do you want them to boot from a central storage server ? greetings -- Kris Buytaert From brendan@cs.uchicago.edu Wed Feb 1 18:18:57 2006 From: brendan@cs.uchicago.edu (Brendan Strejcek) Date: Wed, 1 Feb 2006 12:18:57 -0600 Subject: [Infrastructures] openQRM In-Reply-To: <1138782237.2574.14.camel@mine2.x-tend.be> References: <1138782237.2574.14.camel@mine2.x-tend.be> Message-ID: <20060201181857.GQ14205@classes.cs.uchicago.edu> Kris Buytaert wrote: > Anyone already looked at openQRM ? > > What do you people gernerally think about it's concept ? > > Do you want to deploy machines or do you want them to boot from a > central storage server ? I had not heard of it before, but it looks interesting. I am having a hard time finding a high level architectural description of the system, so I guess I will have to piece it together from the reference and howto documentation. It reminds me of ControlTier (http://www.controltier.com/) but maybe that is just because of the corporate-style web design. :-) Best, Brendan -- Senior System Administrator The University of Chicago Department of Computer Science http://www.cs.uchicago.edu/people/brendan http://praksys.blogspot.com/ From stevegt@TerraLuna.Org Mon Feb 13 07:53:56 2006 From: stevegt@TerraLuna.Org (Steve Traugott) Date: Sun, 12 Feb 2006 23:53:56 -0800 (PST) Subject: [Infrastructures] ISconf 4.2.8.222: python2.4 fix Message-ID: <20060213075356.2463A24758@spirit.terraluna.org> Hi All, I'm pleased to announce the release of ISconf 4.2.8.222: http://trac.t7a.org/isconf/pub/isconf-4.2.8.222.tar.gz This maintenance release fixes a python 2.4 socket select incompatibility (the 'fileno' bug). If you're running python 2.4, you'll need this fix. See http://trac.t7a.org/isconf/timeline for detailed change history. There are still known bugs in the 4.2.8 series that aren't fixed. As I receive feedback I'll continue to balance 4.2.8 maintenance against the 4.3 series -- some of the remaining bugs are in code which 4.3 deprecates. Feel free to let me know what you would prioritize, and I'll factor that in. The 4.3.1 work, continuing, focuses on the TCP mesh code. This will give us the ability to retire UDP, simplify firewall rules, and provides the foundation we'll need later for reporting, asset management, authentication, authorization, and monitoring. Look for 4.3.2 as the stable release of this next version, and see http://trac.t7a.org/isconf/roadmap for details. Take Care, Steve --- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com -- http://Infrastructures.Org From avbidder@fortytwo.ch Tue Feb 14 07:52:04 2006 From: avbidder@fortytwo.ch (Adrian von Bidder) Date: Tue, 14 Feb 2006 08:52:04 +0100 Subject: [Infrastructures] fai vs. ZENworks vs. m23 Message-ID: <200602140852.10800.avbidder@fortytwo.ch> --nextPart2126991.AkYdYmZJP5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Yo all! We're (finally) ending our historically grown each-machine-is-unique=20 approach to maintaining our 80 Linux PCs and looking at some management=20 tools. We're evaluating m23, zenworks and fai - any users of these tools=20 here? fai and m23 would imply using Debian (or derivative), while ZENworks would= =20 imply SuSE (we're not looking at RH)- we are confident that both are=20 absolutely viable choices, and since I'm more a Debian guy, while my=20 collegue has more SuSE experience we thought that we'll decide on the=20 software distribution tool first and base our distribution choice on that. As mentioned, there are ca. 80 clients. Some of them are on ADSL (700k,=20 soon 2Mbps), some of them on VDSL (12Mbps) so upgrade by re-installing=20 complete images is probably not a good idea. Also, many of these clients=20 are only powered on when people want to work, so the update process needs=20 to cope with that: * needs to happen in the background * needs to cope with being aborted a few times during download * needs to be client-driven, as we don't know and don't want to know when= =20 each client will be powered on. Wake on LAN might be possible except for=20 the DSL clients. Otherwise, the environment is relatively simple. Uniform x86 Linux=20 environment, even more or less uniform hardware (wrt net, graphics=20 chipsets). The only problem will be the local printers, where we'll need=20 to properly handle all the configuration differencies. LDAP as auth=20 service, $HOME on NFS, KDE partly locked down with KIOSK. Comments? cheers =2D- vbi =2D-=20 Today is Setting Orange, the 45th day of Chaos in the YOLD 3172 --nextPart2126991.AkYdYmZJP5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEABECAGcFAkPxjCpgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6yWMAn0O4i2wgYlj4oXof0+WN/uxQ +zShAJ9KiA6k5XzrigIG1b2Dk5imhhfVfA== =P/aD -----END PGP SIGNATURE----- --nextPart2126991.AkYdYmZJP5-- From tsnyder@shoppersdrugmart.ca Tue Feb 14 14:57:12 2006 From: tsnyder@shoppersdrugmart.ca (Todd Snyder) Date: Tue, 14 Feb 2006 09:57:12 -0500 Subject: [Infrastructures] fai vs. ZENworks vs. m23 Message-ID: <278FF45ECEEC9047BF088C218BFF0C448DCCAE@CORPEX04.sdmnet.ca> If you go with Zenworks (which we're also looking at doing), I believe you need to use eDirectory (or link in with AD) which will probably mess with your LDAP Authentication. I'd suggest talking to Novell directly, talk to a sales drone or an SE and see what they have to say about implementing Zenworks in an existing environment. We haven't gotten to that level of detail with them yet, so I can't help you. Give me a couple weeks and we might have more information. Other than the constant harassment that happens after you talk to the sales drone, theres really nothing to lose. Cheers. T. -----Original Message----- From: infrastructures-admin@terraluna.org [mailto:infrastructures-admin@terraluna.org] On Behalf Of Adrian von Bidder Sent: Tuesday, February 14, 2006 2:52 AM To: infrastructures@terraluna.org Subject: [Infrastructures] fai vs. ZENworks vs. m23 Yo all! We're (finally) ending our historically grown each-machine-is-unique approach to maintaining our 80 Linux PCs and looking at some management tools. We're evaluating m23, zenworks and fai - any users of these tools here? fai and m23 would imply using Debian (or derivative), while ZENworks would imply SuSE (we're not looking at RH)- we are confident that both are absolutely viable choices, and since I'm more a Debian guy, while my collegue has more SuSE experience we thought that we'll decide on the software distribution tool first and base our distribution choice on that. As mentioned, there are ca. 80 clients. Some of them are on ADSL (700k, soon 2Mbps), some of them on VDSL (12Mbps) so upgrade by re-installing complete images is probably not a good idea. Also, many of these clients are only powered on when people want to work, so the update process needs to cope with that: * needs to happen in the background * needs to cope with being aborted a few times during download * needs to be client-driven, as we don't know and don't want to know when each client will be powered on. Wake on LAN might be possible except for the DSL clients. Otherwise, the environment is relatively simple. Uniform x86 Linux environment, even more or less uniform hardware (wrt net, graphics chipsets). The only problem will be the local printers, where we'll need to properly handle all the configuration differencies. LDAP as auth service, $HOME on NFS, KDE partly locked down with KIOSK. Comments? cheers -- vbi -- Today is Setting Orange, the 45th day of Chaos in the YOLD 3172 From tubaman@fattuba.com Fri Feb 17 17:08:41 2006 From: tubaman@fattuba.com (Ryan Nowakowski) Date: Fri, 17 Feb 2006 11:08:41 -0600 Subject: [Infrastructures] fai vs. ZENworks vs. m23 In-Reply-To: <200602140852.10800.avbidder@fortytwo.ch> References: <200602140852.10800.avbidder@fortytwo.ch> Message-ID: <20060217170841.GE28676@polishwonder.homeip.net> --NtwzykIc2mflq5ck Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 14, 2006 at 08:52:04AM +0100, Adrian von Bidder wrote: > Yo all! >=20 > We're (finally) ending our historically grown each-machine-is-unique=20 > approach to maintaining our 80 Linux PCs and looking at some management= =20 > tools. We're evaluating m23, zenworks and fai - any users of these tools= =20 > here? >=20 > fai and m23 would imply using Debian (or derivative), while ZENworks woul= d=20 > imply SuSE (we're not looking at RH)- we are confident that both are=20 > absolutely viable choices, and since I'm more a Debian guy, while my=20 > collegue has more SuSE experience we thought that we'll decide on the=20 > software distribution tool first and base our distribution choice on that. >=20 > As mentioned, there are ca. 80 clients. Some of them are on ADSL (700k,= =20 > soon 2Mbps), some of them on VDSL (12Mbps) so upgrade by re-installing=20 > complete images is probably not a good idea. Also, many of these clients= =20 > are only powered on when people want to work, so the update process needs= =20 > to cope with that: > * needs to happen in the background > * needs to cope with being aborted a few times during download > * needs to be client-driven, as we don't know and don't want to know whe= n=20 > each client will be powered on. Wake on LAN might be possible except for= =20 > the DSL clients. >=20 > Otherwise, the environment is relatively simple. Uniform x86 Linux=20 > environment, even more or less uniform hardware (wrt net, graphics=20 > chipsets). The only problem will be the local printers, where we'll need= =20 > to properly handle all the configuration differencies. LDAP as auth=20 > service, $HOME on NFS, KDE partly locked down with KIOSK. >=20 > Comments? >=20 > cheers > -- vbi I'm using FAI and isconf 2.X to manage about 20 Debian Sarge machines for a manufacturing test environment. It has worked well for us. For the next infrastructure I will definitely be using isconf 4.X. I just have too much knowledge stored in makefiles right now to switch. - Ryan --NtwzykIc2mflq5ck Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD9gMZ6ZA8+1/wXqMRAifHAJ9q5LvS5FaGlCmqWkHs6eskkHEyvgCcCmbu 74mM3gplWR+cVS+p3LeMSwI= =LEAJ -----END PGP SIGNATURE----- --NtwzykIc2mflq5ck-- From oetiker@ee.ethz.ch Fri Feb 17 22:00:14 2006 From: oetiker@ee.ethz.ch (Tobias Oetiker) Date: Fri, 17 Feb 2006 23:00:14 +0100 (MET) Subject: check out template tree II ... Re: [Infrastructures] fai vs. ZENworks vs. m23 In-Reply-To: <20060217170841.GE28676@polishwonder.homeip.net> References: <200602140852.10800.avbidder@fortytwo.ch> <20060217170841.GE28676@polishwonder.homeip.net> Message-ID: Hi, this makes me want to promote template tree again ... > I'm using FAI and isconf 2.X to manage about 20 Debian Sarge machines > for a manufacturing test environment. It has worked well for us. For > the next infrastructure I will definitely be using isconf 4.X. I just > have too much knowledge stored in makefiles right now to switch. Here at ETH Zurich (EE-Department) we run 196 Debian 3.1 ia32 18 Debian 3.1 amd64 148 Solaris 8 10 Solaris 9 59 Mac OS X 10.3 amongst these are 343 diskless clients. We run Desktop Workstations, Server, Compute Clusters and Student Labs. All configured from one high-level configuration file of 2395 lines ... this file is well structured and pulls together 359 configurable feature modules that make up the actual configuration code. Each feature can exhibit an API that makes it possible to use the same module in different configurations. The configuration info gets converted to a cfengine.conf file for application to the machines ... if we have the system create a single cfengine.conf file describing all the config we apply then the file has 1.2 million lines of cfengine code (this could be optimized). A config for one server still comes in at 4979 lines of cfengine code. A client is about 2864 lines. The system we developed and use is called template tree II. You can read all about it on http://isg.ee.ethz.ch/tools/isgtc/index.cgi?page=module_pod;module=tetre2;pod=docs/overview.pod currently you can get all the code but we have not yet published a set of sample configuration files since it all tends to be rather site specific (we wouldn't need configuration management otherwise). I mentioned diskless clients above. The creation of diskless clients is fully automated too. It takes about 45 Seconds to build a diskless client image. Images are built offline under a separate mount point. Once an image is built the DHCP config gets adjusted such that when the client boots the next time, it will automatically pick up the new image. This makes down-times for 'upgrades' a matter of seconds ... We don't actually ever patch diskless clients, since we just rebuild them from scratch whenever a new kernel is deployed or we add in some more Solaris patches ... Currently we do diskless Solaris and Debian, but OSX 10.4 looks very promising. http://isg.ee.ethz.ch/tools/isgtc/index.cgi?page=module_pod;module=disklessmgr2;pod=disklessmgr2 cheers tobi -- ______ __ _ /_ __/_ / / (_) Oetiker @ ISG.EE, ETL F24.2, ETH, CH-8092 Zurich / // _ \/ _ \/ / System Manager, Time Lord, Coder, Designer, Coach /_/ \.__/_.__/_/ http://people.ee.ethz.ch/oetiker +41(0)44-632-5286 From stevegt@TerraLuna.Org Wed Feb 22 20:43:07 2006 From: stevegt@TerraLuna.Org (Steve Traugott) Date: Wed, 22 Feb 2006 12:43:07 -0800 Subject: [Infrastructures] Infrastructures.Org rework In-Reply-To: <20021011171624.GB24325@trinity.acomp.usf.edu> References: <20021011171624.GB24325@trinity.acomp.usf.edu> Message-ID: <20060222204307.GA7091@terraluna.org> Hi Kevin, Joel, All, Kevin, a few years ago you posted the Infrastructure Design Patterns idea below. Developments at a current client tell me that, maybe now more than ever we (1) need a pattern library, and (2) now have enough material to populate it. The case I'm encountering right now is one in which lack of generally available and concise patterns, a library to refer to, is causing a great deal of semantic difficulty. There is still not a general understanding, even among senior UNIX folks who should know better, that use of a given pattern in an infrastructure implies certain behaviors, costs, and compatibility (or not) with other patterns. I'm watching yet another case of an organization spending a great deal of time and money, and enjoying some pretty painful internal conflict, while trying to re-invent things that at least half the members of this list already learned the hard way. Joel, you and I have spoken 1:1 several times about the idea of moving the current contents of infrastructures.org into a wiki, so that it can be expanded on and updated, getting us out of being the editorial bottleneck, and so on. We have the beginnings of a good pattern and standards library, but it is showing its age. You and I seem to have agreed that we can do this move without messing up our copyright and preventing us from publishing print versions; there is probably precedent in blogs, other wikis, creative commons licenses, etc. I think we decided we can do this, but just in case, I'm asking again, formally and in public, so that we know our i's are dotted: Joel, can I rework infrastructures.org into a community-edited site, provided that you and I reserve the right to publish the resulting text without having to go back and later get individual authorization from each contributor? Everyone else; the question I have for you is this: Would you be willing to contribute to a wiki or other community-edited repository of documents which serve as design patterns and RFC-like standards documents, in which, by contributing, you might be listed in a "contributors" section, but would not retain copyright in your contribution? I hate doing it that way, but it's the only way we'd be able to easily print the result. I'm not doing this for profit motive -- bog knows very few technical book authors make significant income from the proceeds, and this is such a niche that we may never be able to get it published except via e.g. lulu.com. The only reason for publishing on paper at all is to try to get wider dissemination and make all of our jobs easier. An example to emulate, for instance, might be the Python Cookbook; recipes drawn from the web site are published in an O'Reilly book, and the primary contributors are credited with each recipe. A portion of proceeds can be fed back into the community in some way, etc. There are probably several ways of doing this, and I'm sure there are people out there who would already have in mind how this should be licensed; please feel free to provide suggestions. We've all talked sporadically over the years about variations of this, have wished for RFC-like documents, and have even discussed document file formats. I think we're finally now at the point where I have the incentive, the time, and the tools to actually do something about it, and I think we need to take advantage of the opportunity while it's here. Take Care (and let me know what you think), Steve On Fri, Oct 11, 2002 at 01:16:24PM -0400, Kevin M. Counts wrote: > > I thought it might be fun to come up with some > Infrastructure Design Patterns and I have taken > a stab at one entitled "BootHook". > > For anyone not familiar with design patterns, > a good start might be: > > http://www.enteract.com/~bradapp/docs/patterns-intro.html > > In a nutshell, they are a named solution to a recurring > problem in a particular context. They don't say exactly > how to do something but instead provide a general > architectural discussion of one or more solutions to > the problem. > > By developing a set of patterns for a domain > a "Pattern Language" emerges which provides a > common ground to communicate the architectural > concepts with others without having to cover > as many "low-level" implementation details. > > > -- Kevin > > .___________________________________. > | Kevin Counts kcounts@usf.edu | > | 813.974.1466 (w) 727.460.9522 (c) | > | http://www.digicat.org | > `-----------------------------------' > > > > #------------------------------------------------------------------------- > # Pattern Name > #------------------------------------------------------------------------- > > BootHook > > #------------------------------------------------------------------------- > # Also Known As > #------------------------------------------------------------------------- > > -nil- > > #------------------------------------------------------------------------- > # Intent > #------------------------------------------------------------------------- > > Deploy software with functionality to update itself via a > configuration repository and invoke configuration actions on the host's > local environment. > > > #------------------------------------------------------------------------- > # Motivation > #------------------------------------------------------------------------- > > Centralized management is a key design in infrastructure implementation. > > A popular implementation of this design is establishing a central server > which is responsible for initiating distribution of software and > modifications on the infrastructure hosts' local environment. > > Although this meets the fundamental requirements, it has several > consequences: > > - Distributions must be synchronized with the availability of the > infrastructure hosts. Unavailable hosts and missed updates may > establish a need for complex, fault tolerant logic. > > - As the infrastructure scales, performance requirements may require > a more complex implementation of multi-threaded distribution. > > In contrast, the BootHook pattern enables each infrastructure host as > a self-modifying entity. Host synchronization and multi-threaded > distribution are handled implicitly through this passive, delegated design. > > The configuration repository retains control of the resources and rules > for the infrastructure but delegates the timing of the actions to the host. > > > #------------------------------------------------------------------------- > # Applicability > #------------------------------------------------------------------------- > > Use this pattern when: > > - You want to configure an infrastructure host with a small initial > software footprint. > > - You want to avoid pushing out changes and allow the infrastructure > hosts to control their update schedule. > > > #------------------------------------------------------------------------- > # Structure > #------------------------------------------------------------------------- > > |---------------------------------| > | Infrastructure Host | > | | > | | > | (3)configuration | > | actions |(1)request update |---------------| > | <----------------*|----------|*---------------------->| | > | | BootHook | | | Configuration | > | | Software | |(2)updated software | Repository | > | |----------|<----------------------*| | > | | |---------------| > |---------------------------------| > > > #------------------------------------------------------------------------- > # Participants > #------------------------------------------------------------------------- > > BootHook Software > A minimal set of software with self-contained functionality to > contact the Configuration Repository, update itself, and invoke > configuration actions on the Infrastructure Host. > > Configuration Repository (a.k.a. Gold Server) > The central repository where infrastructure software and configuration > resources are stored. > > Infrastructure Host > Any host machine managed by the infrastructure configuration management > system. > > > #------------------------------------------------------------------------- > # Collaborations > #------------------------------------------------------------------------- > > The BootHook Software will always contact the Configuration Respository > to obtain the latest copy of its own environment and configuration > information. It then invokes software housed in its environment which > performs configuration actions on the Infrastructure host. > > > #------------------------------------------------------------------------- > # Consequences > #------------------------------------------------------------------------- > > The BootHook pattern has the following benefits and liabilities: > > - It gives the host control of when updates occur. > The passive nature of the pattern makes synchronizing a series of > updates and reboots a trivial task. > > - Because it is a passive update model, updates may not propogate > in an acceptable time frame. > > > > #------------------------------------------------------------------------- > # Implementation > #------------------------------------------------------------------------- > > The BootHook software is often initiated by a start-up script on > the Infrastructure Host. At boot, the latest copy of the environment > is updated from the Configuration Repository and actions can be > performed before the host goes into service. > > In addition, a scheduler is usually configured initiate the BootHook > on a schedule for periodic updates. > > One caveat of the BootHook pattern is the passive design may not meet > certain update time-window requirements. A solution is to employ a > push model to trigger the passive update when required. > > > > #------------------------------------------------------------------------- > # Sample Code > #------------------------------------------------------------------------- > > > #!/bin/sh > > #-- Download the latest copy of this script from the Configuration > #-- Repository and if it has changed, execute the new version. > > ${RSYNC} ${REPOSITORY}/${BOOKHOOK_ROOT}/sbin/boothook.sh /tmp > > if cmp -s ${LOCAL_BOOTHOOK_ROOT}/sbin/bookhook.sh /tmp/boothook.sh ; then > . > else > cp /tmp/bookhook.sh ${LOCAL_BOOTHOOK_ROOT}/sbin/boothook.sh > exec ${LOCAL_BOOTHOOK_ROOT}/sbin/boothook.sh > fi > > #-- At this point we have the latest copy of boothook.sh. > #-- Now update the entire BookHook environment and run the > #-- the program to invoke configuration actions on the > #-- local Infrastructure Host. > > ${RSYNC} ${CONFIG_REPOSITORY}/${BOOTHOOK_ROOT}/ ${LOCAL_BOOKHOOK_ROOT} > > ${LOCAL_BOOTHOOK_ROOT}/start_config_actions.sh > > > > #------------------------------------------------------------------------- > # Known Uses > #------------------------------------------------------------------------- > > The BootHook pattern is used in the ISConf (Infrastructure Configuration > Engine) framework. (http://www.infrastructures.org) > > > #------------------------------------------------------------------------- > # Related Patterns > #------------------------------------------------------------------------- > > -nil- > > > > > ========================================================================== > # Below are the descriptions of the sections of a design pattern for > # reference or if you would like to fill it in and post a new one :-) > ========================================================================== > > > #------------------------------------------------------------------------- > # Pattern Name - The pattern's name conveys the essence of the pattern > # succinctly. A good name is vital, because it will > # become part of your design vocabulary. > #------------------------------------------------------------------------- > > > #------------------------------------------------------------------------- > # Also Known As - Other well-known names for the pattern, if any. > #------------------------------------------------------------------------- > > > > #------------------------------------------------------------------------- > # Intent - A short statement that answers the following questions: > # What does the design pattern do? What is its rationale and > # intent? What particular design issue or problem does it address? > #------------------------------------------------------------------------- > > > #------------------------------------------------------------------------- > # Motivation - A scenario that illustrates a design problem and how the > # class and object structures in the pattern solve the > # problem. The scenario will help you understand the more > # abstract description of the pattern that follows. > #------------------------------------------------------------------------- > > > #------------------------------------------------------------------------- > # Applicability - What are the situations in which the design pattern can > # be applied? What are examples of poor designs that the > # pattern can address? How can you recognize these > # situations? > #------------------------------------------------------------------------- > > > #------------------------------------------------------------------------- > # Structure - A graphical representation of the patttern. > #------------------------------------------------------------------------- > > > #------------------------------------------------------------------------- > # Participants - The classes and/or objects participating in the design > # pattern and their responsibilities. > #------------------------------------------------------------------------- > > > #------------------------------------------------------------------------- > # Collaborations - How the participants collaborate to carry out their > # responsibilities. > #------------------------------------------------------------------------- > > > #------------------------------------------------------------------------- > # Consequences - How does the pattern support its objectives? What are > # the trade-offs and results of using the pattern? What > # aspect of system structure does it let you vary > # independently? > #------------------------------------------------------------------------- > > > #------------------------------------------------------------------------- > # Implementation - What pitfalls, hints, or techniques should you be aware > # of when implementing the pattern? Are there language- > # specific issues? > #------------------------------------------------------------------------- > > > > #------------------------------------------------------------------------- > # Sample Code - Code fragments that illustrate how you might implement > # the pattern. > #------------------------------------------------------------------------- > > > > #------------------------------------------------------------------------- > # Known Uses - Examples of the pattern found in real systems. > #------------------------------------------------------------------------- > > > > #------------------------------------------------------------------------- > # Related Patterns - What design patterns are closely related to this one? > # What are the important differences? With which other > # patterns should this one be used? > #------------------------------------------------------------------------- > > > > _______________________________________________ > Infrastructures mailing list > Infrastructures@mailman.terraluna.org > http://mailman.terraluna.org/mailman/listinfo/infrastructures > -- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com -- http://Infrastructures.Org From Devdas Bhagat Wed Feb 22 21:25:06 2006 From: Devdas Bhagat (Devdas Bhagat) Date: Thu, 23 Feb 2006 02:55:06 +0530 Subject: [Infrastructures] Infrastructures.Org rework In-Reply-To: <20060222204307.GA7091@terraluna.org> References: <20021011171624.GB24325@trinity.acomp.usf.edu> <20060222204307.GA7091@terraluna.org> Message-ID: <20060222212506.GA1632@dvb> On 22/02/06 12:43 -0800, Steve Traugott wrote: > Hi Kevin, Joel, All, > > Kevin, a few years ago you posted the Infrastructure Design Patterns > idea below. Developments at a current client tell me that, maybe now And I have been STFW for this for the past few hours. > more than ever we (1) need a pattern library, and (2) now have enough > material to populate it. The case I'm encountering right now is one > in which lack of generally available and concise patterns, a library > to refer to, is causing a great deal of semantic difficulty. There is We need both patterns, and anti-patterns [1]. > still not a general understanding, even among senior UNIX folks who > should know better, that use of a given pattern in an infrastructure > implies certain behaviors, costs, and compatibility (or not) with > other patterns. I'm watching yet another case of an organization > spending a great deal of time and money, and enjoying some pretty > painful internal conflict, while trying to re-invent things that at > least half the members of this list already learned the hard way. > Everyone else; the question I have for you is this: Would you be > willing to contribute to a wiki or other community-edited repository > of documents which serve as design patterns and RFC-like standards > documents, in which, by contributing, you might be listed in a > "contributors" section, but would not retain copyright in your Choose a creative commons license. Or offer a choice of two or three possible ones you find acceptable, and we can then choose one of those on the list. I don't know how much I can contribute (still have a lot to learn), but I will try and write as much as I can. > contribution? I hate doing it that way, but it's the only way we'd be Alternatively authors could retain copyright, but grant anyone the right to publish the text (including for profit). > able to easily print the result. I'm not doing this for profit motive > -- bog knows very few technical book authors make significant income > from the proceeds, and this is such a niche that we may never be able > to get it published except via e.g. lulu.com. The only reason for > publishing on paper at all is to try to get wider dissemination and > make all of our jobs easier. > I hope it does work out well. Devdas Bhagat [1] The Anti-patterns book describes the way software development fails, and gives common illustrations (and solutions). A similar toolkit for administrative tasks is called for. From counts@digicat.org Thu Feb 23 15:51:57 2006 From: counts@digicat.org (counts@digicat.org) Date: Thu, 23 Feb 2006 10:51:57 -0500 Subject: [Infrastructures] Infrastructures.Org rework In-Reply-To: <20060222204307.GA7091@terraluna.org> References: <20021011171624.GB24325@trinity.acomp.usf.edu> <20060222204307.GA7091@terraluna.org> Message-ID: <20060223155157.GA18564@leto.moffitt.usf.edu> On 2006-02-22, Steve Traugott wrote: > Kevin, a few years ago you posted the Infrastructure Design Patterns > idea below. Developments at a current client tell me that, maybe now > more than ever we (1) need a pattern library, and (2) now have enough > material to populate it. I agree. It seems as if we are seeing more and more infrastructure implementations popping up lately (just look at the Feb 2006 issue of Usenix ";login"). The concepts developed in Isconf and other related systems should provide enough raw material to flesh out a solid collection of patterns (and as Devdas mentioned perhaps anti-patterns). > Everyone else; the question I have for you is this: Would you be > willing to contribute to a wiki or other community-edited repository > of documents which serve as design patterns and RFC-like standards > documents, in which, by contributing, you might be listed in a > "contributors" section, but would not retain copyright in your > contribution? I think a wiki would be great! After all it was Design Patterns that really started the whole wiki thing (http://en.wikipedia.org/wiki/Wiki#History). > An example to emulate, for instance, might be the Python Cookbook; > recipes drawn from the web site are published in an O'Reilly book, and > the primary contributors are credited with each recipe. Great idea. So what animal would you think appropriate? ;-) Regards, Kevin -- ._____________________________________________________. | Kevin Counts | | UNIX Systems Analyst | | UNIX Systems Group | | H. Lee Moffitt Cancer Center and Research Institute | | 813.745.1832(w) counts@digicat.org | | http://www.digicat.org/ | '-----------------------------------------------------' From Devdas Bhagat Thu Feb 23 17:06:05 2006 From: Devdas Bhagat (Devdas Bhagat) Date: Thu, 23 Feb 2006 22:36:05 +0530 Subject: [Infrastructures] Infrastructures.Org rework In-Reply-To: <20060223155157.GA18564@leto.moffitt.usf.edu> References: <20021011171624.GB24325@trinity.acomp.usf.edu> <20060222204307.GA7091@terraluna.org> <20060223155157.GA18564@leto.moffitt.usf.edu> Message-ID: <20060223170605.GA17535@dvb> On 23/02/06 10:51 -0500, counts@digicat.org wrote: > > Great idea. So what animal would you think appropriate? ;-) > http://www.venganza.org/ That one, of course. After all, we are speaking about intelligent design of system administration techniques. Devdas Bhagat From asoudure@kuala-lumpur.oilfield.slb.com Fri Feb 24 01:27:22 2006 From: asoudure@kuala-lumpur.oilfield.slb.com (Adam Soudure) Date: Fri, 24 Feb 2006 09:27:22 +0800 Subject: [Infrastructures] Re: Infrastructures.Org rework In-Reply-To: <200602232001.k1NK1HJ17174@roton.TerraLuna.Org> References: <200602232001.k1NK1HJ17174@roton.TerraLuna.Org> Message-ID: <6.2.1.2.2.20060224092117.09e8ea38@sg0040-pop3.mail.slb.com> Steve, >Hi Kevin, Joel, All, > >Kevin, a few years ago you posted the Infrastructure Design Patterns >idea below. Developments at a current client tell me that, maybe now >more than ever we (1) need a pattern library, and (2) now have enough >material to populate it. The case I'm encountering right now is one >in which lack of generally available and concise patterns, a library >to refer to, is causing a great deal of semantic difficulty. There is >still not a general understanding, even among senior UNIX folks who >should know better, that use of a given pattern in an infrastructure >implies certain behaviors, costs, and compatibility (or not) with >other patterns. I'm watching yet another case of an organization >spending a great deal of time and money, and enjoying some pretty >painful internal conflict, while trying to re-invent things that at >least half the members of this list already learned the hard way. I am but a lurker, but apply and build on the lessons in Infrastructures.org on a daily basis. I think a patterns library would be a great idea. I would even be happy to contribute in whatever way you would see fit. >Everyone else; the question I have for you is this: Would you be >willing to contribute to a wiki or other community-edited repository >of documents which serve as design patterns and RFC-like standards >documents, in which, by contributing, you might be listed in a >"contributors" section, but would not retain copyright in your >contribution? I hate doing it that way, but it's the only way we'd be >able to easily print the result. I'm not doing this for profit motive >-- bog knows very few technical book authors make significant income >from the proceeds, and this is such a niche that we may never be able >to get it published except via e.g. lulu.com. The only reason for >publishing on paper at all is to try to get wider dissemination and >make all of our jobs easier. Yes, absolutely. >An example to emulate, for instance, might be the Python Cookbook; >recipes drawn from the web site are published in an O'Reilly book, and >the primary contributors are credited with each recipe. A portion of >proceeds can be fed back into the community in some way, etc. There >are probably several ways of doing this, and I'm sure there are people >out there who would already have in mind how this should be licensed; >please feel free to provide suggestions. How about some Creative Commons style thing? I think folks ought to be able to profit from their work or simply give it to the community and still receive their due credit. Like another poster, I think an O'Reilly animal would be way cool ;-) So, in summary, your idea gets my vote. Cheers Adam -- =============================================== Adam Soudure - DCS Systems Manager Schlumberger, Kuala Lumpur, Malaysia Mobile: 60 12 231 2729 email: asoudure@slb.com ===============================================