John Summerfield wrote: > Andrew Hecox wrote: >> Dag Wieers wrote: >>> On Tue, 13 Nov 2007, todd w. wrote: >>> >>>> Dag Weers stated: >>>> >>>>> What is missing to me is something more similar to smit or smitty on >>>> AIX. >>>>> A modular interface to drive scripts with a well-structured menu. >>>>> Such an Open-Source project with the right spirit will no doubt >>>>> attract >>>>> lost of people to write modules and new features. >>>> Ack, no.... (please). Smit is clunky at best. Maybe I'm biased - but I >>>> expect my admins to know commands and to execute them. >>> Right, let's use highly expensive sysadmins for stupid operational >>> procedures and support. >>> >> >> But are they best off learning a framework executing commands or writing >> simple scripts, shell functions, and alaises to execute commands? >> Clearly at some point a framework is helpful and at some point it's >> overkill. > > How can it be overkill? > > Every sysadmin is a beginner at some time. If you want a new email > account set up, would you prefer your beginner sysadmin to spend five > minutes filling in a form on the screen, one that prompts for the full > set of information, one that ensures he does a complete job all in five > minutes, or do you think his time's better spent reading manuals and > howtos for an hour or so, coming up with an different answer from last > time? > > Okay, so you've spend big bucks and she's trained, so it only takes 15 > minutes. Probably she'd take three minutes with the form. >
I would rather that she read the 10 line shell script so that she understood unambiguously what it means to our site to "add" a user, even if it took an hour. If we're going to have an admin for 3-5 years, I'm happy to take 3 full months of training so that they can understand the breadth of what we do and how we do it. In other words, I place a lower priority on getting them doing a full range of work soon, and a higher priority on getting them to understand what it is we do and why. We tend to use these 10 line shell scripts as inline documentation for why do add users this way, any relevant history for that policy, etc. Our experience has been that if that meta information is kept with the implementation details, admins and programmers are more likely to get the meta-info up to date. >> >> Eg, @uchicago we wrap the useradd command to do arbitrarily different >> things on different boxes, depending on both our general "template" and >> any additions our overrides for that host. Our "framework" is a 10 line >> shell script with a 5 line helper function for finding any overrides. >> Any "highly expensive" sysadmin can understand, debug, or extend the >> script very quickly and easily. > > Assuming it's properly documented and easily found. The best > documentation is on-screen forms, part of an integrated administration > tool. > I'm not sure I follow how that is the case, or even what you mean. > >> >> I think the interesting question is not if there's value in a general >> system management tool but at what point does it's value v. cost exceed >> simple homegrown solutions. And at that point, where your scale or >> problem is large enough that you've exceeded homegrown solutions, is >> there all much value in which one RHAT happened to include in the distro? > > Home-grown solutions are always expensive, more so in small shops. In > small shops they tend to be basic, undocumented and hard for the next > sysadmin to find. > I don't quite understand how they are always expensive. Certainly, home grown solutions /can/ be awful, awful stuff but so can third-party solutions. Rather than be definitively awful or awesome, I'd submit both have different characteristics and are appropriate under different circumstances. There also is clearly an issue of scale, maturity, complexity, and interface. For example, our script for adding users calls useradd even though we could easily have modified the relevant files ourselves. However useradd presents a stable, well-documented, and easily scripted interface. Each new major version of EL we verify that things like useradd continue to do what we expect and if they don't, we wrap those changes into our code. Verifying that useradd's -m, -G, -u, and -p and options still do the same thing is a very quick process. >> >> Our scale here is a couple hundred systems with low-to-moderate levels >> of customization. My experience has been that this was easier to >> hand-roll that than use someone else's tool. > > I'm sceptical. > > That does _not_ mean I disbelieve you, but if I needed to decide one way > or the other I'd want to verify your view of the facts. > > OK. -Ah _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
