Simple Comprehensive Config Tools?

Speare asks a question which may be on the tongue of many Linux newbies: "Is there anyone working on a GNOME or X gui front-end that can help organize all of the known device configurators into one comprehensive front-end? Let me point-n-click at /dev/cua2 and see if it's got a modem on it, for example." He also has some valid comments about ways Linux Distributions can improve their configurators. I too feel that a single configurator is better than multiple configuration tools. Linuxconf is a move in the right direction, but it still has room to improve. (More)

"I admit it, I'm a Linux newbie. As I write this, it is Day Two. I've been both impressed and unimpressed with the out-of-box experience. The variety of Linux I've picked up was RedHat 6.1 for my Intel machine. I hate lowlevel hardware tweaking like determining IRQs, and have hated it for 19 years, but I figured I could go through a little more of it.

Impressed:
I was pleased to find that there were gui or text-mode-gui things to help me get many items configured. There were a series of tools on most of the basics like mouse, monitor, graphics card, sound, net card, modem, ppp, and so on. If I knew the name of the tool or could find it (by using the Win32 laptop still attached to the Web), I was able to get my subsystems all working with a little effort. I'm not afraid of vi or bash or emacs, but the gui setup was well-adapted to letting me run around and choose options without having to remember or learn keystrokes like C-x C-s at the same time.

Unimpressed:
Very few things seemed to be organized, either in the online help, or the tools available. Most of the things I found were by searching the support requests on the RedHat page, not in any prepared documentation. Once I found *mention* of setserial(8), I could use it or get the manpage. Once I found the /etc/inittab(5), I could tweak it to get that graphical login that rh6.1 install didn't make. And so on, for problems I faced in an unsupported PnP Sony 17" monitor stuck in 640x480 SVGA, and other problems I've yet to figure out.

If I had a *comprehensive* one-stop-shopping place to go, it would help a lot. It doesn't have to know all the esoteric PnP techniques, it just has to know how to execute the tools that have already been written.

Perhaps it would let you browse all /dev/* entries, click on each one, and it would start the configurator tool that is responsible. Or at least point the user at what /etc/*.conf file was useful. I would hope to see loopback tests and more importantly, what to do or where to look if something's not working resources, even if they're just URLs back to the distro or author of the uberconfig tool."

Comments

graphical config tools

[jetpack]

Disclaimer: this is not a bashing of admintools .. please bare with me :)

I've been kicking around unix systems for some years now, and I've developed a love/hate relationship with admin tools (both GUI and text-based). I tend to lean towards the hate category and edit config files by hand as much as possible.

"Why", you ask? Because if I don't figure out how to do it by hand, when things go south, you either wind up learning to do it by hand, or you often are out of luck. It seems to me that it is better to know all the nasty bits up front, rather than wait for Bad Things to happen later and have to figure things out then (often under pressure from time constraints).

Now, this is not an admintool-bashing argument; I'd love to see the end-all-be-all suite of admin tools. However, what I would *most* like to see in an admin tool is more feedback. Specifically, if I'm going to be using linuxconf (for example), when I hit the apply button, I want it to *tell* me what it's doing, and preferably log all the changes it's making. That way, I have a clue where to look if linuxconf isn't doing the Right Thing. That would go along way towards helping newcomers to linux: they'd have a central place to go for configuration *and* learn what was going on behind the scenes for those times when it really matters.

As a second example, consider the debate about the ease of installing windows vs installing linux. Windows installation is usually described as easier, right? In many ways, I'd say this is true (altho it's the delta is narrowing all the time). However, you've probably had those times when installing windows didn't go so well. And when it goes badly, what happens? You are in a world of hurt. Why is that? Because it doesn't tell you what it's trying to do behind the seens; you can't fix things because you can't even figure out what is supposed to be fixed (at least not without an enormous amount of effort or prior knowledge of windows).

So, in summary, I think anyone developing configuration tools should really consider keeping the tool's users informed about what is going on under the hood, rather than hiding the operations completely. That would help both the user, and the tool's maintainer.

Not Geek enough for Linux?

[Len]

So far, I've seen comments saying: (paraphrased)

• You're an idiot if you don't already know all the magic incantations to configure a Linux system;
• Write your own config tool;
• WINDOZE SUX

It seems that there are quite a few people who think that Linux should not be used by people who don't program; or that Linux is a club for nerds who can rhyme off everything in /etc without drawing breath.

If, on the other hand, Linux is supposed to be an OS that can actually be useful as an OS, shouldn't it be possible to install it properly without having another PC handy for Web queries? Fun's fun, but you shouldn't have to take a "Linux for Geeks" course before you can even boot it up.

I don't think the issue is so much GUI vs. CLI configuration, but rather having some tool available "to execute the tools that have already been written", as the article said.

Or maybe I'm wrong, and I'm just not ready to join the Holy Order of Linux Initiates.
--

cfengine, anyone?

[Christopher B. Brown]

What the world probably needs is for someone to build a "barneyfied" GUI tool for the construction of cfengine scripts.

cfengine is a sort of generic "configuration control" languge. You define things like lines that should be in /etc/hosts , or things that should be mounted, or files that ought to be kept up to date with central repositories, rotating system logs, fixing file permissions, and other similar sorts of things.

A daily/hourly run will go through and "clean up" whatever isn't set according to the instructions.

There's a client/server variation called cfd that allows you to push configuration across a network on demand.

The big point to this is that it treats system set up more like "immunology" than anything else. From a security perspective, this is very good. You get some security rules set up, run them regularly, and fix/prevent holes.

Perhaps more useful, once you set up some common rules for a site, installing a new system becomes real easy: you just need to get as far as installing cfengine, get some config files over, whether via floppy, CD, or NFS mount, and then type # cd /etc/cfengine; cfengine and depending on the sophistication of the rules, you may never need to log on as root again.

For instance, you might set up a location where machines mount a filesystem containing package upgrades or configuration file upgrads, and automagically install them.

The regrettable thing is that cfengine doesn't have the "barneyfication" that naive users may want/need.

On the other hand, it has the major virtue over things like Linuxconf that it is a tool for building configuration systems rather than being a front end that is tightly connected to the back end.

I could see:

• Building a GUI tool that manipulates some combination of templates and data. That allows providing a relatively friendly front end for what could be a bit offputting.
• Using cfengine as the tool for pushing package configuration into place on one's system.

  Thus, rather than merely doing a "cp foo /etc/foo; chmod 774 /etc/foo", the configuration process might include asking the user for input of critical bits of configuration, and constructing a cfengine script that might even be usable to "clean up" if you've done something icky and want to fix the package.

  This would also make it natural to create a little script for a given package that might do security checks, perhaps automagically turning off dangerous options or the like.