Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!longway!std-unix From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.7: System Administration Message-ID: <495@longway.TIC.COM> Date: 6 Jan 90 15:14:45 GMT Sender: std-unix@longway.TIC.COM Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee Lines: 130 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: Jeffrey S. Haemer An Update on UNIX* and C Standards Activities December 1989 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.7: System Administration Update Steven J. McDowall reports on the October 16-20, 1989 meeting in Brussels, Belgium: Background Joe Friday would say, "Just the facts, ma'am." And that's the way I feel. The facts are that I'm sick, it's Thanksgiving, I am going to London for two weeks tomorrow, and 1003.7 is defining a standard way to administer POSIX systems. Now, almost everyone agrees that 1003.7 should deal with networks, not just isolated systems. To wit, it would be nice if I could administer all the machines in a network from a single machine with simple commands. For example, to add a user to all machines in the domain "mn.org", all I should need to do is issue a command like "adduser -d mn.org -options -parameters username". The question is, without any de facto standard already in place to adopt, how can we achieve this? The Approach This is important, so pay attention. Because the major goal of 1003.7 is to create a standard way to manage a set of objects, the group has decided to take an object-oriented approach. Our idea is to begin by creating a list of objects to manage, then to follow that by defining the set of commands to manage each object. This approach is novel for both system administration and POSIX. It will probably require more work on the front end to define the objects, their attributes, and their relationships, than to define the actual command structure to support and manipulate them. Whether this approach will work remains to be seen. __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. December 1989 Standards Update IEEE 1003.7: System Administration - 2 - The Meeting The meeting was boring. To put it bluntly, the week was simply a work week. Objects (and sub-objects) were defined and discussed in detail, then put in the draft. Little got done on the first and last days, due to EEC formalities, which left us with three working days instead of the normal four and a half. Attendance was pretty dramatically reduced, too. About half the normal North Americans showed up, probably because of the location, and only one (yes one...) new European came even though we were meeting in Europe. Oh well, except for my having had my passport stolen, it was a good chance to see Belgium. Concerns 1. The process is taking a long time to move ahead, both because of the difficulty involved and because we seem to attract less manpower than many other groups. Moreover, since we're taking a radical approach, it takes extra time to teach the ideas to anyone new that does come. 2. System administration doesn't have the glamour of some of the other areas being standardized. As the Rodney Dangerfield of POSIX, 1003.7 gets no respect. 3. The notation we're using to define our objects is ASN.1. "Why ASN.1?" you ask. Simply because it's a standardized meta- language to describe abstract data types. The feeling was that this would help make the whole package more suitable for interoperability. I bring this up because there's some movement throughout 1003 to re-do all data structures in a new meta- language created by some of the people working on language- independence. Not only would this require that we go back and re-do our definitions, but I also think ISO will only allow the use of standardized data-languages in their standards. Does anyone out there know if there is such an ISO restriction? If so, it's important for 1003 as a whole, not just for dot seven. 4. Currently, almost all working-committee members are from vendors. IBM, DEC, HP, AT&T, and others are well-represented. A few interested parties, like OSF and /sys/admin. are there as well, but as far as I can tell, there isn't one real user. By "real user" I mean someone who does nothing but administer a system. All of us are connected somehow with creating an administrable system or getting paid to do so. Of course, I should make clear that we all have to administer systems of our own, so we're not simply an ivory tower group with no real December 1989 Standards Update IEEE 1003.7: System Administration - 3 - experience, but representation is still grossly unbalanced. 5. Finally, there's been a loss of focus on interoperability directly attributable to the loss of our X/OPEN representative, Jim Oldroyd. Jim was well respected and made many valuable contributions, but can no longer attend our meetings. As the X/OPEN representative, he was very concerned with multi-vendor environments, and was a major force in helping us focus on and ensure interoperability. I am not saying that no one else on the committee cares about the issue, but it does seem to be being pushed aside in a spirit of, "I think we shouldn't have any interoperability problems if we do this, so let's do it and worry about it later on." Jim had helped provide a more positive, direct approach of determining up front what would be needed for true interoperability. If X/OPEN is still interested in System Administration, and in making sure the 1003.7 standard includes provisions for interoperability, we could still use their help. December 1989 Standards Update IEEE 1003.7: System Administration Volume-Number: Volume 18, Number 5