objectrepository and odme (was Re: 3002 update breaks uucico

[Jerry Heyman]

In article <663467505.4708 at mindcraft.com> karish at mindcraft.com (Chuck Karish) writes:
>In article <4704 at awdprime.UUCP> jerry at heyman.austin.ibm.com
>(Jerry Heyman) writes:
>>In article <27 at softpro.stgt.sub.org> cmo at softpro.stgt.sub.org
>>(Christian Motz) writes:
>
[... discussion about why objrepos/odm was created ...]
>
>Given the presence of a tool like smit that knows where the
>configuration files are, this argument doesn't explain why the ODM
>database is needed.  'most' isn't adequate; the sys admin has no way to
>know when the traditional approach will work and when it won't.
>

This raises some questions as to exactly what SMIT is.  SMIT is nothing more
than a command builder that saves an administrator from knowing all the nitty
gritty little commands that are required to do configuration and other mgmt
type operations.  

When I said 'most' configuration could still be done in stanza files (and I 
gave the example of inet.conf) this lead to the above comments.  If you use 
SMIT and ODM for all your configuration information, then you should be ok.
Some people might not want to have all their information in an ODM database,
so we have given the option of starting some of the commands (again I'll use
inetd) by telling it NOT to use ODM and to use the stanza files.  As for which
commands do and don't use ODM, all the new configuration information for the
RISC System/6000 use the ODM.  Some of the older commands can use the databases
but don't have to.

>
>As far as I can tell from playing with odme, all it knows how to do is to
>load a prepared stanza into the database.  When I found the entry for it
>in the info database, I expected to be able to browse the database and
>find out what features of the different components were configurable.
>Instead, I found no way to determine the names of the objects in
>the database, so I couldn't call them up and look at them.  I also
>discovered that odme always screwed up the colors in my aixterm
>windows.
>

Without proper documentation (and I agree that we haven't provided enough for
any of the databases - let alone for odme) all the fields actually make sense.
I just used odme on /etc/objrepos/CuAt.  In it you will find three columns,
the first being the object name, the second being an attribute of the object,
and the third being the value for the attribute.  You can modify any of these
values (though I won't guarantee that you can reboot after doing so).  And yes,
odme DOES screw up the colors and we are aware of the problem.

>As a system manager, I have yet to find a real use for odme.
>

I'm not real sure that as a system manager I would want to use odme.

[... deletions...]
>
>I like smit.  It embodies a lot of system administration
>knowledge and calling syntax that I don't have to learn myself.
>I like the fact that it documents what it's done.
>
>Several quibbles, though:
>
>- How do I know when the traditional system administration
>  approaches are equivalent to smit choices, and when things have to be
>  done some special way?  It's fine to provide a maintenance tool that
>  hides complication from the naive user, but it's not fine to wrap
>  administrative tasks in magic that hinders expert users.  Especially
>  when the high-level tools are less than perfect and less than
>  complete.
>

A thing to note when using smit.  It always modifies the appropriate odm
database, but doesn't update a stanza file that has the same information in
it.  This is a shortcoming of the tool and is being addressed.

>- Where's the documentation for the special utilities that smit calls?
>  smit by itself is not a complete system administration interface.
>  Especially in large installations, it's necessary to write
>  non-interactive programs to do maintenance on multiple machines.
>  This is difficult when there's no specification for the behavior of
>  the support programs.  Some of the documented interfaces (in the
>  paper manuals, anyway) don't seem to exist, and many of the existing
>  ones aren't documented.  I want to know how to call what smit calls,
>  and I want some assurance that those utilities won't be arbitrarily
>  changed or replaced and make my scripts worthless.
>

SMIT doesn't call any special utilities.  The best way to envision what smit
does is by imagining it is a large shell script.  Each menu is in turn another
shell script that will create the appropriate system command when you have 
completed all the information that is required for the command to execute.
That means that all the proper options will be filled out and the proper syntax
is guaranteed.  The most interesting thing about smit is that the screens are
stored in several odm databases.

>- Why does smit write smit.log and smit.script in my home directory?
>  There's only one system being maintained; there should be exactly one
>  trace of the maintenance process.
>
Have you actually looked at either of these two files?  smit.log shows the 
output once the commands in smit.script are executed.  once you have a
smit.script that you are happy with, you can use it rather than going into
smit to do the same things over and over.  It should be possible to take a
smit.script from one machine and use it to help configure a different S/6000
machine.

>- The menu choices are not adequately explained.  They need, at the
>  very least, specific references to the info database.
>

This is probably true.  I haven't seen what each menu looks like and most were
done by the developers of the particular lpp so they may have taken for granted
knowledge that someone else doesn't have.

>- Where's a list of the 'fast path' keywords for jumping to a
>  particular smit menu from the command line?
>-- 

A fast path would be to say 'smit commandname' and you will be jumped directly
to the menu that deals with that particular command.  For example you could
start smit up and go through the various screens until you get to the screen
where you set the hostname, or you can say 'smit hostname' and get there
directly.

>
>	Chuck Karish		karish at mindcraft.com
>	Mindcraft, Inc.		(415) 323-9000		

jerry heyman
-- 
Jerry Heyman                     IBM T-R: jerry at heyman.austin.ibm.com
AWD Tools Development            VNET   : HEYMAN at AUSVMQ
AWD Austin                       T/L    : 793-3962
*** All opinions expressed are exactly that - my opinions and NOT IBM's