Re: System administration with GNOME.




On 29-Mar-00 Sri Ramkrishna wrote:
> On Mon, 27 Mar 2000, Lauris Kaplinski wrote:
>> 1. Specify universal config file syntax (xml?). It should also specify
>> in-memory interface (DOM?), CORBA bindings etc.
> 
> Definitely a good idea.  This is what I believe Apple is doing with their
> system.  What might be a good idea is to be able to describe a particular
> OS in terms of an XML file.  For instance, you could do something like
> this:
> 
> <nis>
>         </etc/yp.conf>
> </nis>

        Sorry to be jumping on this thread so late, but I just got
back to my e-mail system. 

        I view tasks like this from the perspective of someone who
has many different operating systems and platforms to take care of.
I also am sometimes required to duplicate existing system configurations
on other platforms, or to create a repeatable build system that will
work on more than one platform. Using things like autoconf and RPM,
this is generally possible now for software applications, but for
the systems themselves, it is not.

        Anyhow, here's how I'd summarize my desires for such a system:

        1. It must have some sort of configuration file/fileset that
contains all the information necessary to duplicate an installation
on a new system. Note that this does not mean it will actually have
the ability to do so in all circumstances, but it ought to at least
have enough information to know what it can do and be able to 
identify anything it can't (much as RPM can do this for packages).

        2. It should be human-readable, and preferably editable as
well. This seems to be the thought behind both the XML suggestion
and Miguel's insistence on using scripts. Anyhow, I think it's a
good idea. There are no performance issues here that I'm aware of,
so compiled code shouldn't be necessary, except perhaps in the rare
case of something that can't be done via scripts.

        3. It should have some provision for being portable between
operating systems and CPUs. This could probably be accomplished in
a number of ways, such as include files for Perl or shell scripts.
I doubt that it could be done solely using config files that have
simple "VARIABLE=value" tokens, and this seems to be the consensus.
Lauris and Sri seemed to like XML as a possibility.

        4. It should be able to add new modules/packages/plugins to
itself. I don't think anyone mentioned this before, but it seems 
necessary to me. IOW, there should be a bare minimum package that
you can add first, perhaps using an RPM or a Deb or SunOS package,
then it can add other features to itself somehow, preferably in a
way that is standard across all systems. Why? Because otherwise you
need a different installation package for every possible 
plugin/architecture combination out there. It don't think this would
have to be a complex installation system, probably just the ability
to write a set of files into a directory with a particular name or
location.

        5. It should be able to be run in batch mode, as well as
via GUI. I assume that this is what is meant by "kickstart" mode.
Anyhow, to me it means that I should be able to install the basic
operating system, GNOME and its support software, and this package,
and then run a script to have it install everything like it should
be.

        What I hope you're aiming for is something that allows a
system administrator to set up his user interface, e-mail config-
uration, and anything else that's present on most Unix systems, 
then save that configuation. He can then duplicate that config-
uration on other Unix systems, even if they are running different
flavors of Unix on different platforms. One of the most frustrating
things about doing system admin in Unix is that knowing how to do
the job on one architecture, Hewlett-Packard 9000 series, say, gives
you only the barest idea how to do it on another architecture. IOW,
you know the issues, but the tools are totally different, right
down to those little command line utilities like 'ls'.

        Here are some of the tasks that could be done, in what has
proven to be no particular order. It should be possible to either
set up or duplicate these configuration items:

        1. GNOME configuration (of course). This would include:
           a. Default user configuration
           b. Individual user setups
           c. Window manager configuration
           d. Adding themes for GTK and window managers
           e. Standard and user foot menus, drawers
           f. Standard panel configurations
        2. X-window configuration
           a. Basically, all the stuff that's in the Xconfigurator
              program, like screen resolution, drivers, etc.
           b. Installation or configuration of fonts or font
              managers
           c. Login manager configuration (i.e. gdm/xdm/kdm)
        3. E-mail configuration
           a. Configurations for delivery agents (say, a
              sendmail.cf configuration for a large internal
              network).
           b. Default user configuration for mail user agents
           c. Any lists of e-mail aliases, e-mail directories,
              etc.
        4. User and Group configuration
           a. Install users and groups on system, possibly duplicating
              user and group ID numbers
           b. User configurations (.cshrc,.profile, etc.)
           c. Levels of password checking, user capabilities
        5. Printer configuration
           a. Replicate lists of available printers, and install
              appropriate filters, ghostscript configurations.
        6. Network configuration
           a. Network numbers
           b. DHCP/RARP/BOOTP configurations
           c. DNS/NIS configurations
           d. NFS export information
           e. Samba configuration (note that this ties in with
              printer configuration tasks)
        7. Database configuration
           a. Install databases, add users for PostgreSQL
        8. OS/device configuration
           a. Kernel configuration and build
           b. Detect new devices (where possible)
           c. Install new devices
        9. Web administration
           a. Duplicate configuration of web server (across
              different web servers??)
           b. Set up and check security levels
           c. Add/delete web users, including admin types
           d. Install web sites, servers

        Having these functions in a standard administration system
would take care of most of the things I do when installing new
systems. There are certainly other things that could be done, and
we probably ought to name as many as we can think of up front. If
there are some that can't be done, OK, but listing what we want up
front will make it less likely that we paint ourselves into a 
corner.

        Someone was starting to create a GNOME-aware TCL interpreter
awhile back. It's too bad this project isn't further along, because
TCL seems like an ideal language to build a GUI for system administration
software. It's available in one form or another on just about every
Unix platform that has X-windows, and is fairly easy to learn. SCO
built their Open Whatever 5 sysadmin software using Visual TCl, and
it seemed to work pretty well. Is it worth considering using TCL
anyway?

        I'd like to help with this effort. I can help with requirements
definition and clarification, and am pretty familiar with both HPUX and
Linux system administration. I can program in TCL, sh, C, HTML, among
others, and I'm sure I could learn XML or Perl if needed.

        Well, after typing all this I noticed that there's now a list
for gnome sysadmin stuff, so I'll try to post this there as well as
on the main list.

----------------------------------
Date: 03-Apr-00  Time: 12:54:11

Craig Orsinger                  (email: <orsingerc@epg-gw1.lewis.army.mil>)
Logicon RDA
Bldg. 8B28                      "Just another megalomaniac with ideas above his
6th & F Streets                 station. The Universe is full of them."
Ft. Lewis, WA   98433                   - The Doctor
----------------------------------



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]