Slashdot Mirror
Simple Comprehensive Config Tools?
"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."
Webmin is an excellent configuration tool that everyone should check out once. It's particularly good at configuring server processes such as sendmail and DNS.
http://www.webmin.com
I don't really have an answer here, more of an expansion to the question, I guess. Since tools like linuxconf can be so dangerous (big gaping security hole waiting to be exploited in the machine isn't properly configed, and who is going to be most likely to not know what config is dangerous? First time users. Not to mention breaking things that you don't understand...), is that really the best answer? I think that a better solution to this would be a very detailed set of installation and/or config documents. For some things, this isn't that big a deal - if you can't get quake3 running in the first 20 minutes the machine was booted into *nix/BSD, you'll live. But if you don't know how to deal with basic config and setup, you can leave yourself open to being rooted, and that is a danger not only to yourself, but to everyone who has a computer that is network accessible from yours. Not a problem for the home box with nothing but loopback, but a serious problem for someone installing linux in their office, or on a college campus, or attaching to a DSL or cable modem. Personally, the way I first did this was by looking for man pages associated with everything in /etc. But that's time consuming, and there's plenty of stuff you don't learn that way. I suppose that for a given item you want to setup, that might not be that bad a method, for the moment. Still, I like the notion of a big pile of documentation. IIRC, red hat used to sell a package where you got these two immense reference manuals along with the distro cd and some other cds of software. Something like that would be good for a first time install, I think. Although it would have to be done just right - easily cross referenced, available in text or digital form, and up to date. Having meandered about this notion, I think it'll never happen, because it is that most feared and hated part of the programming project - documentation. Bummer, dude.
Now, in an attempt at answering, I would say that YaST is a really good tool for this, although I don't know if it can be shoehorned onto anything other that suse. YaST is fun and fabulous, although it doesn't do everything. But what it does, it does nice.
itachi
The impression that everything is not organized comes from someone who knows nothing about Unix; I mean, "once I found
I understand the need the GUI generation (and most of non-geeks) have for easy to use tools, especially if Linux wants to take over the desktops (which I'm not sure is a good idea anyway), but I really worry about it turning Linux into something it's not, which is difficult to use for the experienced user.
Please be careful with automated tools. To try to put all the Unix miriad configuration files under ONE tool has a huge potential for chaos. It's almost inevitable the thing is going to get out of sync as already happens with linuxconf, unless you refrain from doing any kind of configuration by hand.
My feeling is that half the problems of the Windows family are caused just by that - the GUI and the need to make everything easy.
Maybe if Linux would split into 2 things, one of them being what already exists and the other some distribution for the masses. If something like this does happen, I'll bet anyone the version for the masses will not be nearly as stable and flexible as the original design.
Please, guys, make your install/config tools, but be careful!
I think we can start of with a sem-apropriate quote from Brian Behlendorf:
The point I'm trying to make here is that traditionaly under unix configuration has been quite a complex thing. Practicly everything under wintel has been designed with a cutsie little 'properties' dialogue in mind. Most of the time under unix the system and tools are vastly more configurable. Just look at the network thingy in a windows control panel, it's unwealdy, obease and not entirely effective at getting the job done, now imagine what it might look like under linux with the 10 fold greater flexibility the architechture lends to configuration. It may well be possible to design simple dialogues to hland the simple stuff like ip address, dialup and the like (effectively just the definitions at the top of all the config scripts and a few enable dissables). What you are unlikely to see however is an 'apply' button that asks you to 'please wait while I recompile the kernal', it's just plain silly. A certain degree of configuration can be hidden from the user by dialogues but until some big changes under the hood are implemented sooner or latter your going to have to roll your sleaves up. The question you then need to ask is how much flexibility are we willing to sacrifice for user friendliness?Although I can appreciate many people's desire to
have GUI config tools to help with configuration
in linux (devices, xwindows, daemons, startup, etc), I'd like to point out the following:
most GUI tools of this ilk are linux-specific.
One thing I always tell friends (esp. when configuring apache, bind, sendmail, etc) is that
they should go straight to the config files. One
of the strengths of linux is that configuring it
gives you an introduction to other unices as well.
If you can configure apache's httpd.conf on linux,
then you can also configure it on freebsd, solaris, aix, and just about any other UNIX it will port to. That's a valuable skill to learn --
and one that the GUI tool won't help you with.
By all means, play around with GUI configurators,
but learn what they actually configure and where.
Look at the config files. Learn to configure these
things with vi and you'll go a long way towards a
wider world.
(one thing I did like about AIX Smit is that it
displayed the CLI syntax once it kicked off a
configuration task -- not bad).
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.
- 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 inIf, 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.
--
To an extent, yes. A bimodal tool (addressing needs of the expert user and the new to the system) would be of value to the WHOLE Linux market. I realize that many folks have a bias that makes them feel that Linux would be best served by keeping it highly complex, but you restrict the usability of the OS by doing so. Consider something like Jakob Nielsen's usability heuristics, one of which states that you should support the new user with comprehensive assistance and an obvious interface, but also provide shortcuts to the advanced user. I beieve that there is room for both in the Linux community. Perhaps the resource for the new user could be an agent that could be a module to be compiled if selected, so that the new user has the help, and the experienced user could merely not install it. Just my 2 cents (Canadian, so that's about 1.6 cents US). Cadfael
-- The Hollow Man
Non illegitimati carborundum
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:
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.
If you're not part of the solution, you're part of the precipitate.
gecco, on sourceforge, looks interesting. It has a way to go, but it has a cool plugin architecture that should make it easy for various people to contribute to it, and make it a good all-around tool...
----
The viewpoints are extreme oversimplifications, but the point is made. What we're seeing is a split both over how Linux should be used, and I think, how it will be used. And it says a lot about what Linux needs. Linux's install base is diversifying so much that one solution is not going to fit everyone. On the one hand I say, "Yes, a comprehensive graphical system manager would be fantastic!" On the other, "But you're not learning system administration, which is what Linux is all about."
Linux is too complex for the newbie. It's just a fact, and it's going to have to be accepted. Steps have already been taken to change that, but in large part, these efforts have been controlled by people who aren't newbies and don't understand all of the troubles. Microsoft does this sort of testing, and the Linux community does not. When we need something like this, something that targets an audience that's "not us", we copy Microsoft, and since our systems weren't designed like Microsoft's, it's a kludge. It works, but not necessarily very well, and it's certainly not cohesive, and probably never will be, simply because it's being done by many separate people, not one overarching company. It's one of the downfalls of open-source software, a minor one for anyone who doesn't use corporate software.
Someone can very easily develop a fully comprehensive system manager. Parts have already been started. The end result is something that really bastardizes the idea of what Linux is, a server OS that is very complex and very loosely organized, but it does work for the newbie, because it hides all that. The end result is really two different versions of Linux, which is really what Microsoft has with its Windows line. The Windows schism isn't necessarily a bad thing, except that they are two different implementations. With Linux, the community has a chance to produce that seeming "schism" in one implementation. If done right, security, which config files can of course break, can be set at install time, and the system manager will never touch it. A more advanced user, of course, would take care of all that on his own, and probably never need the manager. It's the same OS. The implementation is even the same. On one hand, though, you are setting the security at install time, and in the other, the user's taking care of it.
I don't want one of these 'system managers'. My Linux doesn't need one of these 'system managers'. But Linux as a community does, if it's ever going to be viewed as having its act together. Webmind and Linuxconf don't cut it. Newbies need a manager that can act just like we do when we manage our systems. Can a community that produces so many things separately do that as one? Who knows.
Graphical all-in-1 configuration tool is a great idea - but it is ahead of its time. Here's why:
First, configuration file formats changes from one version of the same software to the next. It is unlikely that the team who writes the config utilities catch up soon enough with the team who makes the programs to be configured.
Second, different programs have different configuration files. It makes it hard for a single configuration utility to recognize them all.
Third, the existing tools seem to be too tree-structured, taking away the simplicity advantage they first try to provide. (anyone besides me who hates linuxconf?)
INI files is one of the few things about Windows that I like. I'd love to know if anyone has started to unify the format of all the configuration files into, say, XML?
Another possibility is to have the author of each program write its own configuration cgi script,
Then some project can be started to make a configuration server to gobble them all up at an HTTP port (ala SWAT)
As of now, the closest thing I can get is to have a text editor that support projects. Put a bunch of config files into a project....I prefer this to linuxconf. You get the idea.
That's my biggest beef with Linuxconf - when I resort to using it because I don't know how to do it by hand, I would *really* like to have it tell me which file it's editing...
linuxconf offers you the option of previewing your changes before it applies them. When you quit the program, choose "Preview what has to be done".
This is on Red Hat 6.1, linuxconf 1.16r3.2-2, but I'm pretty sure it has done this for a long time.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
You can have your cake and eat it too. The existence of easy to use graphical tools does not necessarily mean that text-based tools are going out the window (no pun intended).
Face it, some things are just a nightmare in linux. For example, making it so that you can have decent good-looking fonts in X requires a brilliantly written 20+ page how-to. Things just HAVE TO get better than this. Very few people have the time to read dozens of pages of information to change each little aspect of their computing experience.
Graphical front-ends are a good idea, epecially for administrative tasks that are done once per installation or that are changed infrequently or on machines that are administered by someone that is not a professional administrator. It is very hard to remember the details of commands like mount, for example. The man page is very long and complex for this command and it creates a feeling of dread in someone that just wants to get some work done.
What's needed is a declarative, as opposed to procedural, way to specify what "installed" means for a device or a software package. The problem with procedural representations is that it's hard to do much with them except run them. Given the specification of something in this form, along with specification of previously installed things, it should be possible to perform all the following operations:
The key idea here is to get away from procedural scripts and to move toward a declarative representation that can be used for multiple purposes.
This is kind of abstract. To be more concrete, you want a description of a component that contains lots of information like:
Package XXX requires file YYY with checksum ZZZ installed in directory DDD.
This provides information that an installer or an uninstaller needs, but more important, it allows you to find conflicts between components. That's the part of configuration and installation that usually gives trouble.
"cfengine" is a step in the right direction, but they don't quite have it right. A popular package that got this right, one that let you do all four operations listed from the same description, would be a major advance.
You can/should/have to standardize... even win16 had a consistent *.ini file syntax that made sense even if you had never seen the application before. Why can't Unix standardize? why not Linux?
/etc/* and their siblings. Not only the original software which gets fed said files, but other software as well. Changing things would break huge amounts of software. Ironically, some of these programs are automation tools design to make admins' jobs easier.
.INI files; others will want XML; others still will want something based on their favorite scripting syntax. Who gets to be king of the world and decide the standard?
Mainly because of that beast that causes engineers to shudder and admins to dive for cover: Backwards compatibility.
There is a huge installed base of software that reads and/or writes the countless configuration files that live in
There are other problems as well. For one, what format do you pick? Some will want Windows style
There is also the legitimate technical complaint that no one format fits all possible uses. The sendmail configuration file format is a programming language all its own; it would be tough to reduce it to a universal format that would work for all software.
In short, changing things around to use a single standard format would be akin to getting all the people of world to settle on one language: Really nice idea, but impossible to execute.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
The biggest problem with all these configureing programs is that you the user are limited to what the programmers have built in. Also these programs make a mess of the files. I gave mandrake a try a while back and for me it was the hardest thing to use because the config program didn't have anything in it for configureing ip_masq and more that one nic. The rc files are a mess and imposible to trace.
I started out using slackware and I found most of the config files were easy to edit manualy and any special setups wasn't that hard to configure.
One of the biggest problems I have when I sit down at a windows 9x machine to fix something for a friend is that I have no way of knowing what the box is trying to do or what has been done. And then theres the rebooting *shudder*.
What we need is a stadard layout for config files. That are both easy to read by humans and programs alike.
God, root, what is the difference?
Here's another little story.
I owned a Toyota MR2 a few years back, which is a mid-engine car. That is to say, the engine is not in front of the front axle, it's in front of the back axle, behind the driver.
I drove a long highway trip, visiting relatives in a small town, just when it was due for oil. I didn't have the option of going to a Toyota dealership to get the service done. I went to a professional looking establishment a relative recommended. I drove up, and girl waived me into the garage stall. She must have been the mechanic's girlfriend, just killing time and helping him on a slow Wednesday. She made a hand gesture for me to "open the front hood."
I smiled, and shook my head no. When she came to the window, I explained, the oil's behind me. Her boyfriend assured her that I wasn't pulling her leg... the engine compartment really wasn't up in the front of the car. She couldn't get over that... a car with the engine in the back!
Sure, if you *know* the architecture of MSDOS and Windows starts with a kernel that reads AutoExec.bat, while the architecture of Unix starts with a kernel that reads /etc/inittab, you should be able to find your way around.
The last time I used Unix, there was no X login shell. Why would I look into something that was named /etc (as in, miscellaneous afterthoughts) for the core, key, central file that controlled all run levels? It's all a matter of context.
There's a difference between being stupid, and being ignorant. One can be cured.
[
I have a rabid hatred of XML. It's just such a hideously ugly language that I could never stand to use it. Markup languages seem more or less acceptable for text formatting, though they aren't much fun to write by hand, but they are just about my last choice for configuration (or for general data description, or programming). They're also hideously verbose, wasting keystrokes and network bandwidth alike.
I still don't see any advantage to XML. Standardizing on a completely general language is about as useful as standardizing on "an ordered list of bits." If you're going to extend it you still need code somewhere that actually understands the data. Parsing a configuration language is trivial compared to actually deciding what the content and structure should be.
Yes, I know, you can make a GUI editor that understands the format of your XML-based language, and gives the user options, but I really don't think this is more than a superficial benefit. People should get used to editing plain text; it's the basic skill of running Unix systems, and a damn good thing to standardize on. Text editors have been tuned for a long time, and they can be used very efficiently with a little practice - much more so than a configuration GUI.
A more useful thing might be to start having a standard script for each plain text configuration file, which interleaves it with a man file, putting all the relevant entries right beside where they'd be used, allows the user to edit the file in this way, then removes the man comments (for efficiency in reading the config file) when he is done. This way you could get what is IMHO the main benefit of GUIs: having configuration options laid out in front of the user to select, with all of the traditional benefits of plain text (or rather, unique syntax) config files.