David Hiers wrote:
Acme is a victim of their own success on this one. It's so easy to manage the SDs over the CLI for a handful of boxes, and it plugs into our overall monitoring strategy so well that I've never thought of what I'm missing with the EMS. Size matters, so if we had a oodles of them it might be a different story.
Aside from that, there is a generally pointless and misguided preoccupation throughout all departments of IT and communications with GUI administration tools and abstraction layers for everything. GUI tools are appropriate if - and only if - (1) they simplify a task so that lower-skilled people can be hired to do it as part of business processes replicated at decreasing marginal cost, or (2) if they make a task more efficient to perform. The latter is usually predicated on there being some level of unnecessarily granular detail that can be encapsulated in most common use cases. Anything truly complicated and granular at once will require a GUI that is equally complicated and granular, which is a waste of time and resources for both the vendor in producing it (and keeping it synchronised with the core product) and for the user in having to attain proficiency in learning the roundabout ways of the GUI. At that point, it's simpler to just use the CLI or other some-such allegedly "crude" interface. This obsessive fixation with GUIs, GUIs, GUIs for everything reminds me of many a misguided, disastrous "business process language" undertaking in the enterprise world, where an obsessive methodological preoccupation with divesting "programming" from "business logic" and/or the "business layer" leads to complicated domain-specific input with fat specifications, all in the name of supposedly protecting "business people" from having to write any actual code, per se. The end-result ends up being more obfuscated, conceptually elaborate, and intellectually demanding than just sitting down and writing code, and, in fact, the skills required turn out to be suspiciously similar to programming. The sort of thing that is BPEL and business-XML-such-and-such are good examples, and by far not the worst. Only now, it operates through an obese, lumbering interpreted mediation layer, requires expensive and time-consuming care and feeding (maintenance), and creates a hard bound on flexibility limited by that subset of the original programmatic options that are exposed by the new "interface."
Along these lines, has anyone ever cooked up a decent perl module to work with the selecting and such needed to modify the config? It'd be pretty sweet to can some module that can work with their CLI paradigm as well as expect or net::telnet.
I've written a number of such Perl scripts in the past to accomplish specific goals, but nothing in the way of a generic interface or general-purpose interaction layer. -- Alex -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671