On Jun 1, Jeffrey S. Dutky wrote regarding "Re: SEUL: admin tools GUI": > > firstname.lastname@example.org wrote: > > > > On 29-May-97 Jeffrey S. Dutky wrote: > > > > >I would like to add: > > > > > > 11) graphical administration apps > > > > > > > I think this is the most important point. What people fear most > > in Linux is the administration. It's fairly easy to preconfigure > > the WM so that it's easy to use, but IMHO we should make admini- > > stration as easy as possible. _and_ add some graphical frontend the the .*wmrc - not every user will want to live with /etc/skel/* for all eternity, but only a rather smallish proportion will be prepared to learn the formats of the config files. i suspect fvwm, fvwm2 and fvwm2-95 are the most widely-spread; personally i prefer the former, but that's mainly because i couldn't be bothered to convert my rc to the fvwm2 format and i sincerely hate the window appearance of *95. > One of the big problems with graphical admin tools is that they > might require a more restrictive format for the config files than > a human would normally like. which config files are you thinking of here? shell- or perlscripts and friends are certainly unparseable by a config-tool once an editor has been at it, but _all_ rc-files are machine-understandable. after all, a machine eventually understands them... <g> for shell/perl/similar scripts, the debian install approach (mapped to some tcl/tk-frontend w/ appropriate buttons) is probably best: "the configuration file foo has been edited and is no longer readable by the bar-tool. do you wish to: [stick with the existing file] [overwrite with parseable version] [open the files both options would return in an editor to assess the situation]" ... or something similar. flexibility with the _option_ to let the system handle it in a way that returns something if not ideal, known to work. > This can cause the admin tool to erase changes made by a hardy > sysadmin when the changes are outside of the limited understanding > written into the GUI tool. as mentioned, provide the _option_. do not ignore the human, for down that road lieth winblows... [...] > I think the first tools should only manage admin tasks that involve > simple table structured files [...] not only, but definitely start there. > As far as putting a nicer face on the configuration scripts, [...] > I think we should consider creating a new initialization process > that would replace the classic BSD style init or the newer SysV > style init. gnaaaaa!!!! you're definitely moving too far. an intelligently managed system if scripts to begin with is easily manageable via any tool as long as it's the only one editing any of them - if any editing whatsoever is actually needed. i'll expand a little on this. imagine your sysv-init, with the relevant dirs/files being: 0. /etc/inittab 1. /etc/init.d/* 2. /etc/rc.d/* 3. /etc/rc?.d/[SK][0-9][0-9]* the inittab is easy to parse; the possibilities are, after all, restricted to a restricted set (*getty, the scripts, xdm et.al.). one of (1) or (2) should be the basis for any overwrites the script does, the other the directory where _all_ relevant scripts are. (3) are then symlinks the the actual scripts. so far, the ideas are known; if any daemons installed have appropriate startup scripts automatically placed in (1) or (2), selecting whether or not to start them is reduced to the presence or absence of the corresponding symlinks. this part, too, is known. for an administrative tool to know about how to deal with this, one possibly two, file(s) is/are needed: - one containing the daemon's name, description, and related script (if the latter doesn't correspond to the name - sshd started from /etc/rc.d/sshd etc.) - one containing the daemon's name and runlevels it might make sense in - when running w/o network, sendmail needn't run as daemon, httpd makes no real sense etc. if a daemon is not found in the latter or the config file doesn't exist, no need to panic, just ask the power that be, at the same time stating what the runlevels are for (_and_, of course, show the number; there are those that know what to do with that but not with the description <g>). > I think that the daemons should be launched based on their > placement in some specific directory or directories. I think > that it is easier to tell the user "Any programs you put in > directory X will be run when the machine starts up" rather than > telling them that there are some shell scripts that can do just > about anything... that'd certainly be easier to tell the user, but it'd be a major catastrophe on the clue scale to do that with the daemons themselves. think about the symlink-idea; it's basically what you said and one of the very good reasons for living w/ sysv-style init as opposed to the idea of having only a very few scripts that attempt to manage everything - bsd-stylish. those parameters that absolutely must be changed in one place could easily be deposited in a config-script that sets appropriate environment values and is sourced by the actual startup scripts. yes, all of this can easily be script-managed, just make sure that a) you have some sane state somewhere to revert to if such is asked for, and b) the scripts contain relevant and detailed comments, in order to dissuade the clueless and give the clued a hint on how to hand-edit without breaking the (probably gui) tools. two more comments: - none of this is mine or somehow original, it's a quick sum up of good ideas implemented in some distrib or other i've come across - a gui is most likely necessary, i agree; in order to have both a wider base of people that can work on any tools developed and give those willing to learn and interested, i suggest to do without c and the associated x libraries, instead relying on tcl/tk and/or perl/tk. greetinx, Gabriel -- Don't diet, download linux to remove the FAT. email will be posted as i see fit.