NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/std/unix/414

Internet Message Format | 1992-09-09 | 7.8 KB

Path: sparky!uunet!uunet!not-for-mail
From: [e-mail] (Peter Collinson)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.7: System Administration
Date: 9 Sep 1992 14:34:32 -0700
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Lines: 164
Sender: [e-mail]
Approved: [e-mail] (Moderator, Sean Eric Fagan)
Message-ID: <[e-mail]>
NNTP-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]

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

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


Bob Robillard <[e-mail]> reports on the July 13-17, 1992
meeting in Chicago, IL :

Overview of POSIX.7

Since this is the first snitch report on POSIX.7 in quite some time,
I'll start with some background.  (If you already know what POSIX.7's
been up to for the past year or so, you can skip ahead some). POSIX.7
is one of the three POSIX ``Base Standards'' (POSIX.1 and POSIX.2 are
the other two).  It covers the kinds of commands typically found in
section (8) of the man pages - things like fsck and init.

Early on, POSIX.7 decided to address distributed system
administration, rather than just single machine administration, in the
belief that networked computing is the way things are going.  This has
caused a great deal of trouble since distributed system administration
is relatively new and perhaps less ready to be standardized than
stand-alone administration. The hope, however, is that the final
standard will be more useful.

In the last year, POSIX.7 broke its work into several pieces.  Each
area of system administration is getting its own document.  The
current POSIX.7 ``sub-groups'' are:

   - POSIX.7.1 - Printing Administration,

   - POSIX.7.2 - Software Installation and Management, and

   - POSIX.7.3 - User and Group Administration.

POSIX.7.1 - Print Administration

The Printing group is probably the furthest along, since they held a
mock ballot in June.  The base for their document is the Palladium
print system which was originally developed as part of MIT's Project
Athena.  It is now included in the Open Software Foundation's DME
project.  The document specifies print commands, a programming
interface, and a set of managed object definitions. (More on these
later.)

Palladium is the reference implementation of the ISO Document Printing
Application Standard (DPA), currently in international ballot as a
Draft International Standard (DIS) under working group ISO/IEC
JTC1/SC18 (The official name of the ISO document is: Information
technology - Text and office systems - Document printing application
(DPA) - Part 1: Abstract-service definition and procedures, September
1991).  It's a client/server distributed system.

One of the reasons for the mock ballot was to determine whether
Palladium was an acceptable choice for a base.  Since lpr and lp (both
the pre-SVR4 and SVR4 versions) are much more widely used, the group
was concerned that their standard would be voted down on
``not-existing-practice'' grounds.

The people in the mock ballot okayed Palladium.  Eleven (11) said
Palladium would be okay, nine (9) said it would be okay if some
changes were made (changes the POSIX.7.1 group then adopted) and only
five (5) were against it.  Astute readers will note that this a small
mock ballot group, but it was at least a well-rounded one with 6
University people, 10 from computer or operating system vendors (NeXT,
IBM, Sequent, USL, Sun, OSF, Intergraph, Fujitsu), and 4 from user
companies (US West, Bellcore, British Telecom, Boeing).

The No votes on Palladium were particularly strong however, so the
group is still concerned.  If you have an opinion on this either way,
please contact the author.

POSIX.7.2 - Software Management

The Software Management group is not far behind the printing group.
The draft document is stabilizing and should go to mock ballot soon.
It includes commands to install and upgrade software packages.  It
also includes managed object definitions, but no API.

The base of their standard is HP's swinstall tools and USL's pkg
tools.  Currently, the commands look more like the HP commands, but
that is still in flux.

POSIX.7.3 - User and Group Management

The User and Group Management subgroup is still in the early stages.
They have been gathering submissions for their base documents, and
have been trying to determine a course of action.

There has been some debate about whether User/Group Management is a
mature enough area to standardize, and the POSIX Project Management
Committee (PMC) suggested that this group publish a Guide rather than
a standard.  You can expect these issues to be cleared up in the near
future, and a solid direction to form soon.

Managed Objects?

All of the POSIX.7 documents are providing descriptions of ``managed
objects'' for their area.  I'm not an expert on this, but here's
everything I know about it.

Managed objects are hot in distributed management.  UI's Atlas, OSF's
DME, HP's OpenView, the Object Management Group (OMG) - everyone who's
anyone in the field is using them.  I think they come from network
management, where the ``object'' being ``managed'' was a physical
thing (like a router, for example.)

The concept is that there's an object out there, and to do something,
you send it messages.  The Print document, for example, has the
concept of a printer object.  If you want to know what kind of paper a
printer has, you send a message to the printer object and ask for its
``media-supported'' attribute.  There are objects for print jobs,
software packages, etc.

The idea is that these ``managed objects'' work well with distributed
systems because you don't have to know where the printer is - the
message sending mechanism deals with that.  Also, they are an aid to
interoperability, since all POSIX compliant software will have to
support the same set of objects.

Road Blocks

Fair warning: I'm now going to get up on a soap-box.

The next step for the POSIX.7.1 document would seem to be to go to
ballot.  There are, however, two things standing in its way.  First,
all documents need to have test assertions written before entering
ballot.

Test assertions are statements about what a function or command does,
written in such a way that someone could easily write a shell script
or program to check that an implementation actually does the correct
thing.  For example: ``If lpr is given the name of a non-existent file,
it returns the following error....'' (There are formatting details
about test assertions, but that's the basic idea.)

Although having these test assertions is clearly valuable, writting
them is a tedious, time consuming process, and it is likely to delay
ballot by several meetings.  Also, since many details of the commands
and functions are likely to change during ballot, many of the
assertions will need to be thrown away.

Less clearly valuable is the Language Independent Specification (LIS)
of the function calls, which also needs to be written before a draft
goes to ballot.  The functions have to be abstracted from C to an
invented specification format which is free of programming language
dependencies.  The idea of this is to remove any parts of the API that
are implicitly dependent on C syntax, such as return values from
functions, pointer parameters, or the use of structures.  Only the
functionality should remain.

The group then writes a companion ``C thin-binding,'' which doesn't
describe what the functions do, it just talks about how the
functionality described in the LIS is implemented in C.

I believe the goal of the LIS is to make it easier for people
interested in an Ada or Fortran version of POSIX to write the
appropriate language binding for it.  Again, this is tedious and time
consuming, and will likely eat up several meetings of POSIX.7's
limited resources.

Volume-Number: Volume 29, Number 26