Re: SEUL: admin tools GUI

["Jeffrey S. Dutky" <dutky@BellAtlantic.net>]

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.
> 

I've been giving this a lot of thought ever since I began reading
"Essential System Administration" by AEleen Frisch. I've gotten a
few ideas from the NeXTSTEP admin tools. Here are some of thoughts:

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. 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.

In order to prevent this I think the first tools should only
manage admin tasks that involve simple table structured files
(passwd, groups, hosts, fstab, mtab). Table structured files
just don't get so complicated that the tools should ever be
baboozled by a syntactically correct file. (A syntactically
incorrect file is asking to be erased, in my book)

Working from this assumption we can make a preliminary list
of the admin tools we will need:

PROGRAM                     FILES
-------------------------------------------------------------
Users&Groups                passwd, groups, shells
Hosts&Network               hosts, host.conf
Import&Export               fstab, exports, mtab
Periodic Events             crontab
Linux Loader                lilo.conf
System Startup              inittab, fstab, mtab
Remote Access               ftp*, securetty
Network Services            services, hosts.allow, hosts.deny
Network Config              inetd.conf, (running ifconfig)

As far as putting a nicer face on the configuration scripts,
I don't think that can be done so easily. So long as the system
runs a bunch of shell scripts at startup, the only way to manage
them effectively is to have someone who can understand the scripts
and rewrite them: I don't think a graphical front end would be a
good way to try to do this and I sure as hell wouldn't want to
write the part that tries to interpret a script somone else wrote.

I think we should consider creating a new initialization process
that would replace the classic BSD style init or the newer SysV
style init. I realize that there will be some resistance to this
idea but I think that the SysV style, at least, is extremely
confusing until you have had it explained several times. This is
not good for the average user who doesn't have a guru on hand
to explain things.

I have some ideas about how the startup process could be made
easier to understand but (I say, cowwering behind my chair) they
come from my experience with MacOS (cringe, cowwer, tremble).
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...

- Jeff Dutky
----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------