Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.24/text0019.txt

Text File | 1991-09-03 | 8.0 KB | 204 lines

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
1003.7: System Administration


Martin Kirk <[e-mail]> reports on the April 15-19,
1991 meeting in Chicago, IL:

Summary

POSIX.7 is getting back on its feet again, having come through a rocky
period in its history. The Project Management Committee (PMC) has
reviewed the project and recommended that it be split into a number of
sub-projects, organized by POSIX.7. Likely candidates are print
management, software management and user environment management.

Report

The April 1991 POSIX meeting in Chicago may turn out to be the final
step in the rehabilitation of the POSIX.7 Systems Administration
working group.

Probably as a result of its occasionally controversial past, POSIX.7
was among the first batch of working groups to be reviewed by the
newly created Project Management Committee (PMC).

It is possible to speculate on whether POSIX.7 would have met the
PMC's project approval criteria had it been in existence two years
ago.  One of the most pertinent criteria would probably have been the
existence of a suitable base document.  A likely candidate would have
been the NIST proposed draft System Administration document, though it
might have been difficult to demonstrate the right kind of consensus
around it!

Anyway, the PMC was not in existence then and POSIX.7 was duly
created.  The first couple of meetings were spent investigating the
possibility of standardising the existing systems administration
commands that we all know and love.  The working group decided that
there was little benefit to be gained from solving the single machine
problem in a world that was rapidly moving towards a norm of
heterogeneous networks, and set off on its trek into the rather more
esoteric realms of object-oriented systems management for networks of
heterogeneous machines.

Inevitably this change of direction led to charges that the group was
inventing hand-over-fist, rather than following the ``traditional''
standards model of codifying existing practice.  (No-one ever argued
that the group had gone beyond its scope, which was cunningly worded
to allow the group to do almost anything).

Moving into the world of distributed systems management opened up
various cans of wriggling things with labels like ``interoperability''
and ``frameworks.'' (This was when I discovered that ratholes were
full of worms).  It was at this point that an over-enthusiastic
embracing of object- oriented concepts led to the promulgation of a
command line interface that was tremendously orthogonal, but completely
different to all known existing practice.

Interoperability proved to be a particularly thorny problem.
Everybody could agree that it was essential, but there was no emerging
consensus as to how it would be achieved.

In hindsight, this was the lowest point of POSIX.7's fortunes.  From
this point the rehabilitation commenced.  The first stage was an
agreement among the group to limit the scope of its activities (but
not its objectives).  The group decided to concentrate on two
particular aspects, the definition of the managed objects required for
systems management, and the definition of management tasks - the
administrator's view of the job in hand.  This decision allowed the
group to close the door on the ratholes and concentrate on areas where
it was able to make progress.

Part of the motivation for this decision was recognition that the
problem space is vast and that trying to attack it over too large a
front was a suicidal manoeuvre.  There was also an increased awareness
of the related work of other organizations, such as the OSI Network
Management Forum, the OSI Implementer's Workshop Network Management
SIG, and X/Open.  As this other work comes to fruition, it will be
available for use by POSIX.7 and will likely solve some of the
thornier problems, such as interoperability.

So what happened in Chicago to raise hopes that the rehabilitation is
almost complete?  For some time the group had been aware that some
functional areas were much closer to reaching a consensus than others,
and it had been considering how it might better organize the work in
order to ``get something out of the door.'' The result of the PMC
review of POSIX.7 was a recommendation that the existing project
should be split into a series of sub-projects, each representing a
functional area within the overall problem space, and each leading to
a separately balloted document.  The existing project would be
retained as an ``umbrella'' to handle the co-ordination issues arising
from the split.

This is necessary if the parts are to form a coherent whole.  New
projects would be raised to cover a first set of functional areas.  No
more than two or three of these functional sub-projects would be
active at any time. This would keep the group focussed on a set of
limited and achievable goals.  New projects would be instantiated as
existing ones move into the balloting phase.

One of the benefits of this approach is that each of the new
sub-projects must pass the PMC's project approval criteria before it
is recommended.  The proposal will be properly scrutinized to ensure
that the project is likely to succeed within reasonable timeframes.  A
result of the earlier decision to concentrate on managed objects and
management tasks will be to relate the new projects much more closely
to existing interfaces, thus removing one of the rods which the group
had fashioned for others to beat it with.  An obvious source of
candidate management tasks can be found in the existing administrative
command set on the systems around us, and it would be a perverse
decision indeed to introduce gratuitous changes to the style of that
interface.

The first set of sub-projects are likely to be Print Management,
Software Management, and User Environment Management.  These three
represent areas where the work of the group is well advanced and where
there is strong commitment of energies.

The Print Management work is based on the MIT Palladium printing
system, which has the benefit of being well-aligned with the emerging
ISO distributed printing standard, DIS 10164.  The Print Management
sub-group within POSIX.7 has been working with the Palladium documents
for over a year and this work is probably the closest to being
complete.

Software Management has enjoyed a resurgence of interest within
POSIX.7 over the last 6 months, with source material being drawn from
DEC, HP, AT&T and Siemens-Nixdorf.  The small group that has been
working in this area has been comparing the various technologies and
(not surprisingly?)  finding a great deal of commonality between then
in terms of their underlying concepts and functionality.  The task of
identifying a common model and a common set of functions is well
advanced and bodes well for the future.  (Indeed, the rate of progress
is positively alarming!)

The third area, User Environment Management is a logical candidate for
inclusion in the initial set of sub-projects.  Much of systems
management is concerned with the management of users and their
interactions with other components of the system.  Many management
tasks need to be able to refer to users and it seems to be appropriate
to tackle this area at an early stage.  (For some inexplicable reason,
the ``add user'' operation seems to be the universal example always
brought up when talking about some aspect of systems administration -
another motivating factor.)

Looking beyond the confines of POSIX.7 into the wider world, the
original decision to adopt an object-oriented approach to the problem
of systems administration is at last being vindicated.
Object-oriented concepts lie at the heart of the OSF Distributed
Management Environment request for technology (RFT), the UI Systems
Management SIG and the X/Open Systems Management working group.  It
looks as if history will show POSIX.7's decision to have been a far-
sighted move rather than turning up a blind alley.

[The above opinions do not necessarily represent those of the IEEE, my
employers, or even myself!].











































Volume-Number: Volume 24, Number 22