On Thu, 15 Nov 2007, Tom Sightler wrote: > On Thu, 2007-11-15 at 12:07 +0100, Dag Wieers wrote: > > > I also believe smit is owned by IBM. I haven't heard that it would be > > > open sourced. ;) > > > > I don't want smitty per se, I don't like every aspect of smitty. But a > > framework where modules and scripts can be structured and improved in a > > community fashion looks very interesting to me. > > Isn't that pretty much what linuxconf was? Perhaps it didn't have a > good community spirit but it seemed pretty close to what you are asking > for. It described itself as a framework for writing modules and it had > a text menu interface, a GUI, a web interface, and a CLI interface. My > memory was that linuxconf was nearly universally despised, similar to my > experience with smitty.
linuxconf had a few problems, so yes that isn't pretty much what I meant. I specifically talked about smitty because smitty does it better in many ways (but still does some things wrong). Problems with linuxconf (iirc): - perl framework was a mess (bad quality, too complicated) - one person driven - configuration files got screwed (much like yast) - no 'view source' mode - no real community spirit (and a liability to Red Hat) > In the end I'll admit to disliking almost all of these types of tools. > They invariably destroy my nicely commented config files, turning a > perfectly crafted and commented dhcpd.conf or named.conf (just as an > example) into a completely unrecognizable mess. Some of the junior > admins use them minimally for things lie viewing logs, print job > administration, and user administration, but very little if anything > else. Sure, and maybe some of it cannot be done differently and you can opt out on those. (Maybe lock them so people cannot use them) The new system would: - work on the config-files directly (no secondary system like yast) - make backups of changes to files - is modular and easy to write entries for (or adapt entries) - hopefully written in python (or at least not c, java or perl :)) - has a 'view source' mode so you can see what happens (or what didn't happen) - offer a framework that puts a lot of the logic centrally (so that modules are straightforward and consistent) - have ACLs to allow certain users to do certain things - mainly ncurses (until the framework is done, then maybe gui/web ?) with the aim being that people can customize procedures and policies to adapt to their own corporate environment and share those improvements tht are more generic. Of course, since a lot of distributions are different, those modules would have different versions for different distributions. Communities would work horizontally around modules or vertically around distributions. Well, those are my ideas, but I have no time to pull something like this off unfortunately :( -- -- dag wieers, [EMAIL PROTECTED], http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
