Re: SEUL: admin tools GUI

[Gabriel Krabbe <satan@bofh.studfb.unibw-muenchen.de>]

On Jun 1, Jeffrey S. Dutky wrote regarding "Re: SEUL: admin tools GUI": 
>
> jfm2@club-internet.fr 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.

PGP signature