pc@hillside.co.uk (Peter Collinson) (06/26/91)
Submitted-by: pc@hillside.co.uk (Peter Collinson) USENIX Standards Watchdog Committee Stephen R. Walli <stephe@usenix.org>, Report Editor 1003.7: System Administration Martin Kirk <m.kirk@xopen.co.uk> 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
henry@zoo.toronto.edu (Henry Spencer) (06/26/91)
Submitted-by: henry@zoo.toronto.edu (Henry Spencer) In article <1991Jun25.214723.7644@uunet.uu.net> pc@hillside.co.uk (Peter Collinson) writes: >... 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. Why does it worry me that this list of related organizations does not mention the IETF and the SNMP/MIB work -- the network-management protocols and facilities that are in far wider use than any of the above, with a far greater level of demonstrated interoperability? -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry Volume-Number: Volume 24, Number 24
randall@Virginia.EDU (Randall Atkinson) (06/26/91)
Submitted-by: randall@Virginia.EDU (Randall Atkinson) In article <1991Jun25.214723.7644@uunet.uu.net>, Peter Collinson <pc@hillside.co.uk> writes: >Submitted-by: pc@hillside.co.uk (Peter Collinson) > >USENIX Standards Watchdog Committee >Stephen R. Walli <stephe@usenix.org>, Report Editor >1003.7: System Administration > >Martin Kirk <m.kirk@xopen.co.uk> reports on the April 15-19, >1991 meeting in Chicago, IL: >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. Judging from comments below, they are still ignoring existing practice in historical UNIX-derived systems in some cases. If true, this is A Bad Thing. >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. One would certainly hope that they are also tracking and taking advantage of the good sized installed base that is already using SNMP regularly. With the draft security extensions now published by the IETF, SNMP has a good body of real-world experience. It would be best if the POSIX.7 group tried to use that leverage to devise a good standard. This isn't an OSI vs. TCP/IP thing; they should take advantage of the experience of both groups. While network management is becoming better understood, it isn't entirely a solved problem yet and I hope the POSIX.7 folks will be careful in what they choose to standardise. > 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. Not only the style but also the content. Standardise what already is historical practice and try to avoid inventing new features without actual implementation and user experience. >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. Palladium reportedly has an interface unlike those on historical systems. I'd much rather see lp/lpr and lprm/lpstat be standardised as user interfaces than something unfamiliar to virtually all of the existing users. >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. But is it based on historical systems ? What kinds of tools are being standardised here ? >The third area, User Environment Management is a logical candidate for >inclusion in the initial set of sub-projects. What is being managed here besides user-addition ? Could someone give examples maybe ? Randall Atkinson randall@Virginia.EDU Volume-Number: Volume 24, Number 25