home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.18 / text0004.txt < prev    next >
Encoding:
Internet Message Format  |  1990-03-18  |  5.7 KB
  1. From: Jeffrey S. Haemer <jsh@usenix.org>
  2.  
  3.  
  4.             An Update on UNIX* and C Standards Activities
  5.  
  6.                             December 1989
  7.  
  8.                  USENIX Standards Watchdog Committee
  9.  
  10.                    Jeffrey S. Haemer, Report Editor
  11.  
  12. IEEE 1003.7: System Administration Update
  13.  
  14. Steven J. McDowall <sjm@mca.mn.org> reports on the October 16-20, 1989
  15. meeting in Brussels, Belgium:
  16.  
  17. Background
  18.  
  19. Joe Friday would say, "Just the facts, ma'am." And that's the way I
  20. feel.  The facts are that I'm sick, it's Thanksgiving, I am going to
  21. London for two weeks tomorrow, and 1003.7 is defining a standard way
  22. to administer POSIX systems.
  23.  
  24. Now, almost everyone agrees that 1003.7 should deal with networks, not
  25. just isolated systems.  To wit, it would be nice if I could administer
  26. all the machines in a network from a single machine with simple
  27. commands.  For example, to add a user to all machines in the domain
  28. "mn.org", all I should need to do is issue a command like "adduser -d
  29. mn.org -options -parameters username". The question is, without any de
  30. facto standard already in place to adopt, how can we achieve this?
  31.  
  32. The Approach
  33.  
  34. This is important, so pay attention.  Because the major goal of 1003.7
  35. is to create a standard way to manage a set of objects, the group has
  36. decided to take an object-oriented approach.  Our idea is to begin by
  37. creating a list of objects to manage, then to follow that by defining
  38. the set of commands to manage each object.  This approach is novel for
  39. both system administration and POSIX.  It will probably require more
  40. work on the front end to define the objects, their attributes, and
  41. their relationships, than to define the actual command structure to
  42. support and manipulate them.  Whether this approach will work remains
  43. to be seen.
  44.  
  45. __________
  46.  
  47.   * UNIX is a registered trademark of AT&T in the U.S. and other
  48.     countries.
  49.  
  50. December 1989 Standards Update      IEEE 1003.7: System Administration
  51.  
  52.  
  53.                                 - 2 -
  54.  
  55. The Meeting
  56.  
  57. The meeting was boring.  To put it bluntly, the week was simply a work
  58. week.  Objects (and sub-objects) were defined and discussed in detail,
  59. then put in the draft.  Little got done on the first and last days,
  60. due to EEC formalities, which left us with three working days instead
  61. of the normal four and a half. Attendance was pretty dramatically
  62. reduced, too.  About half the normal North Americans showed up,
  63. probably because of the location, and only one (yes one...) new
  64. European came even though we were meeting in Europe.  Oh well, except
  65. for my having had my passport stolen, it was a good chance to see
  66. Belgium.
  67.  
  68. Concerns
  69.  
  70.   1.  The process is taking a long time to move ahead, both because of
  71.       the difficulty involved and because we seem to attract less
  72.       manpower than many other groups.  Moreover, since we're taking a
  73.       radical approach, it takes extra time to teach the ideas to
  74.       anyone new that does come.
  75.  
  76.   2.  System administration doesn't have the glamour of some of the
  77.       other areas being standardized.  As the Rodney Dangerfield of
  78.       POSIX, 1003.7 gets no respect.
  79.  
  80.   3.  The notation we're using to define our objects is ASN.1.  "Why
  81.       ASN.1?" you ask.  Simply because it's a standardized meta-
  82.       language to describe abstract data types.  The feeling was that
  83.       this would help make the whole package more suitable for
  84.       interoperability.  I bring this up because there's some movement
  85.       throughout 1003 to re-do all data structures in a new meta-
  86.       language created by some of the people working on language-
  87.       independence.  Not only would this require that we go back and
  88.       re-do our definitions, but I also think ISO will only allow the
  89.       use of standardized data-languages in their standards.  Does
  90.       anyone out there know if there is such an ISO restriction?  If
  91.       so, it's important for 1003 as a whole, not just for dot seven.
  92.  
  93.   4.  Currently, almost all working-committee members are from
  94.       vendors.  IBM, DEC, HP, AT&T, and others are well-represented.
  95.       A few interested parties, like OSF and /sys/admin.  are there as
  96.       well, but as far as I can tell, there isn't one real user.  By
  97.       "real user" I mean someone who does nothing but administer a
  98.       system.  All of us are connected somehow with creating an
  99.       administrable system or getting paid to do so.  Of course, I
  100.       should make clear that we all have to administer systems of our
  101.       own, so we're not simply an ivory tower group with no real
  102.  
  103. December 1989 Standards Update      IEEE 1003.7: System Administration
  104.  
  105.  
  106.                                 - 3 -
  107.  
  108.       experience, but representation is still grossly unbalanced.
  109.  
  110.   5.  Finally, there's been a loss of focus on interoperability
  111.       directly attributable to the loss of our X/OPEN representative,
  112.       Jim Oldroyd.  Jim was well respected and made many valuable
  113.       contributions, but can no longer attend our meetings.  As the
  114.       X/OPEN representative, he was very concerned with multi-vendor
  115.       environments, and was a major force in helping us focus on and
  116.       ensure interoperability.  I am not saying that no one else on
  117.       the committee cares about the issue, but it does seem to be
  118.       being pushed aside in a spirit of, "I think we shouldn't have
  119.       any interoperability problems if we do this, so let's do it and
  120.       worry about it later on." Jim had helped provide a more
  121.       positive, direct approach of determining up front what would be
  122.       needed for true interoperability. If X/OPEN is still interested
  123.       in System Administration, and in making sure the 1003.7 standard
  124.       includes provisions for interoperability, we could still use
  125.       their help.
  126.  
  127. December 1989 Standards Update      IEEE 1003.7: System Administration
  128.  
  129.  
  130. Volume-Number: Volume 18, Number 5
  131.  
  132.