################################################ # # # ## ## ###### ####### ## ## ## ## ## # # ## ## ## ## ## ### ## ## ## ## # # ## ## ## ## #### ## ## ## ## # # ## ## ###### ###### ## ## ## ## ### # # ## ## ## ## ## #### ## ## ## # # ## ## ## ## ## ## ### ## ## ## # # ####### ###### ####### ## ## ## ## ## # # # ################################################ The following paper was originally presented at the Seventh System Administration Conference (LISA '93) Monterey, California, November 1-5, 1993 It was published by USENIX Association in the Conference Proceedings of the Seventh System Administration Conference For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: office@usenix.org 4. WWW URL: https://www.usenix.org Towards a POSIX Standard for Software Administration Barrie Archer - ICL ABSTRACT The POSIX draft standard for Software Administration is about to go to ballot for acceptance as a formal POSIX standard. Since this standard is likely to form the basis of future Software Administration products it will have a profound effect on the facilities available to administrators and the way they manage software. This paper explains how the standard came about, gives a summary of the features and explains how systems administrations can, via the balloting process, have an influence on the final standard. Introduction structure and the background The distribution, installation to what is there, than and control of software is an expounding the detail. By important and time consuming doing this it is hoped that task for administrators. Most reviewers will appreciate the vendors supply tools for their conflicts that were addressed own systems, but, especially and the process that led to in a network of heterogeneous their resolution. They will systems, administrators have then be in a better position often had to resort to invent- to understand what the draft ing their own methods. Previ- standard is trying to achieve ous papers at LISA have and will be able to contribute reported on some of these to maintaining a coherent efforts. To address this prob- standard. lem the POSIX Systems Adminis- This paper was prepared tration Group (P1003.7) set up whilst the draft standard was a subgroup to propose a stan- still under development and so dard for software administra- anything stated here should be tion. Working from the specif- taken as a guide only - refer ications of existing tools to the standard itself for this subgroup produced a draft definitive information. Also, standard that will shortly be for the sake of readability, balloted for acceptance as a some simpler terms have been POSIX standard used in this description in place of the formally defined The purpose of this paper terms in the draft standard. is to bring to the notice of a Objectives wide audience the impending The subgroup defined three ballot of the draft standard objectives that the standard and to encourage participation should address. in the ballot as well as to Administrator Portability explain what is in the draft By providing an interface for standard and why. In describ- software administration that ing the draft standard more was consistent on all confor- emphasis is put on the overall mant implementations, 1993 LISA - November 1-5, 1993 - Monterey, CA 1 Towards a POSIX Standard for Software Administration Archer administrators would be able limitations, however, and can- to use any such system without not substitute for the kind of retraining. overview being presented here. Standard Packaging format Scope A common packaging format Another important considera- would enable software to be tion in defining a standard is processed on any conformant to limit its scope to some- system. This does not imply a thing that can be achieved in architecture independent for- a reasonable time. There is a mat, although it does not pre- trade off here between what clude it. Software can only be one would like to do and the run on an architecture it is least one can do for a usable designed for. It does allow, standard. In the section on however, for discless clients the history of this standard to be catered for. there are some comments on how Distributed Administration the scope changed over the The provision of interopera- definition life cycle. An aim bility interfaces enables dis- of this paper is to give some tributed software administra- information about how the tion across systems. This can standard came about and why it be done either through the covers some things but not command line interface or others. It is hoped that this through a management applica- will enable those who join the tion specifically written for balloting group to be in a the purpose. better position to make com- Standards ments. In order to be useful, a stan- POSIX Standards dard must define interfaces or formats in a sufficiently POSIX Standards have to be rigorous way that there should approved by the Project Moni- be no ambiguities that could toring Committee who will seek result in incompatibilities to assure that the standard is between implementations. How reasonable, that it is based this applies to POSIX stan- on existing practice and that dards is discussed in a later there is sufficient support to section. However, attaining enable the work to be done. this necessary rigour does not Once such approval is obtained lead to a readable document. a group (or sub-group as in For example, any particular the case of Software Adminis- aspect should only be defined tration) can be formed which once in a standard, whereas will meet at the quarterly for readability a summary of POSIX meetings to progress the the aspect might appear in development of the draft stan- several places. dard. At the end of the Rationale development process a draft In order to try to address the will be produced which will be problem of readability POSIX balloted standards contain sections of Balloting rationale. These sections are To ballot a draft standard a intended to explain what parts balloting group is formed. The of the standard mean, how they IEEE uses appropriate means to are expected to be used and advertise that the group is why they are there. Even the being formed. Any individual addition of rationale has its may join, but comments from 2 1993 LISA - November 1-5, 1993 - Monterey, CA Archer Towards a POSIX Standard for Software Administration those who are not members of evolved. This is useful infor- IEEE or the Computer Society mation for understanding why are for information only. To the draft standard contains pass the ballot 75% of the what it does and why the balloting group must respond facilities are defined in the and 75% of those responding way they are. must agree to the standard. Participation Agreement can be the result of One of the conditions of comments being taken into starting out on the process of account - the process known as producing a POSIX standard is ballot resolution. Of, course that there should be suffi- if there are too many comments cient commitment to enable the requiring material changes it work to be done. The subgroup would be necessary to ballot was fortunate that there were again. was a high level of commitment Mock Ballot by several companies and indi- It is customary for groups to viduals. Most major vendors engage in a mock ballot prior were represented as were to the ballot described above. users, in the form of The intention is to address living/breathing systems the same audience and to find administrators. The subgroup out if there are any fundamen- was also able to get work done tal problems before going to between meeting by the use of ballot. For Software Adminis- a mail reflector. In this way tration the mock ballot showed even those who were not able that Configuration, Recovery to attend a particular meeting and Software Service (patch- could continue to contribute. ing) would have to be Existing Practice addressed in the draft to go One condition for a POSIX to ballot. standard is that it should be ISO Standards based on existing practice and Once standards have been not be a invention of the approved through the balloting group, hence indicating that process they go forward to ISO the standard can be imple- for ratification as interna- mented. One of the first tional standards. This is han- actions taken by the subgroup, dled by Working Group 15 of therefore, was to examine the SC22. There are certain agree- existing practice, and this ments in place between IEEE was done by inviting submis- and ISO designed to smooth sions, either or both of a this process by ensuring that paper submission or a presen- the POSIX standards will be tation. The companies that acceptable to ISO without made such submissions are alteration. One area where this affects the work is that a POSIX standard can only reference other formal stan- dards. It cannot reference or rely on an implementation or de facto standard. History This section covers the way in which the draft standard 1993 LISA - November 1-5, 1993 - Monterey, CA 3 Towards a POSIX Standard for Software Administration Archer given in table 1. Base Document _______________________________ In order to start work on the | | text of the draft standard, | IBM | the subgroup decided to adopt | ICL | one of the submitted papers as | Digital Equipment Corporation| a base document. The one | Hewlett Packard | chosen was the SDU utilities | SNI | submitted by Hewlett Packard | SCO | (also the basis of OSF DME | UNIX Systems Laboratories | software distribution). Having |______________________________| adopted this base document the group then proceeded to modify Table 1: itsso that it was more generic The subgroup found that all and also covered important the submissions had many features not found in the SDU features in common and that utilities but which existed in there was a good deal of other submissions or identi- agreement in the facilities fied as needed by the mock that should be provided. Obvi- ballot. ously, some features were only Mock Ballot found in some submissions and The document that was distri- there were some misalignments. buted for the Mock Ballot was Nevertheless, the subgroup was Draft 8. It was recognised encouraged by this to proceed, that a lot of work needed to in the belief that there was a be done on it before it could good chance that the become a formal standard but interested parties could come it was felt that the time was to an agreement on a draft appropriate to get a wider standard. opinion of the work so far. 67 people took part in the Mock It should be noted that the Ballot, sending in almost 1000 requirement for existing prac- comments. Three of these tice brings its own complica- responses were classed as tions. These can arise because votes against the proposed existing practices in dif- draft standard, the rest being ferent areas being addressed qualified approvals. Many by the draft standard do not respondents identified the fit together well, or because lack of rigour, but there were there is no one existing prac- also many comments that tice that gives all the facil- pointed out problems that ities identified as necessary might not otherwise have been for the draft standard. corrected before the formal Comparison ballot. In addition it became The subgroup drew up comparis- very clear that Configuration, ons of the documents submitted Recovery and Software Service in order to determine the core (patching) would have to be facilities and to examine the addressed to make the draft addition aspects of particular standard acceptable. In get- submissions. Part of this work ting to draft 8 these items appeared in the rationale of had been considered and the draft that was basis of dropped due to a lack of the Mock Ballot. existing practice and in an attempt to simplify the task of producing the draft 4 1993 LISA - November 1-5, 1993 - Monterey, CA Archer Towards a POSIX Standard for Software Administration standard. What the Mock Ballot any conformant system an clearly showed was that many administrator will hence have people saw them as vital parts a consistent way way of deal- of the standard. ing with software. Overview Management Information The draft standard defines the This section gives a high information which describes level description of the draft the software being managed. standard, the details of which The draft standard does not are filled out in later sec- define how this information is tions. stored for software that has Components been installed, although it The draft standard can be con- does define the way in which sidered as consisting of three the tasks use the information. key components, which are The management information is required to achieve the objec- sometimes referred to as the tives. Management Information Base Packaging Layout (MIB) by analogy with Network The draft standard defines the Management standards, although information that is held about this term will not appear in software on a distribution the draft standard. medium, as well as the way Roles this information is In order to provide a frame- represented on the medium. work for producing the draft This definition enables the standard the concept of roles use of different media to dis- was used, although it is not tribute software (including in the normative part of the electronic transfer), optimis- draft standard (although it is ing the use of each type of in the rationale). The concept media according to its partic- of roles helps in the explana- ular attributes. The draft tion of the tasks but it is standard does not define an not rigorously defined and so architectural neutral format could not be included in the but does not preclude it. How- normative part of the draft ever, it does allow for the standard. This is just one architecture of a product to example where the rigour of a be identified and for variants draft standard conflicts with of the product for several making it readable. Figure 1, architectures to be present shows the relationship of simultaneously. Hence, an these roles, which are further appropriate variant may be discussed below. Note that chosen from several on a this diagram is a simplified medium. version of the one that Figure 1: Roles in Software appears in the rationale of Administration the draft standard. The dif- ferent roles may each take Commands place on separate systems or The draft standard defines combinations of roles may take commands for performing the place on one system. various tasks that are needed Package Role in order to perform software In the package role developed administration. The definition software is taken and put in a of these commands is based on distribution. How the the submissions received. On developed software got into a 1993 LISA - November 1-5, 1993 - Monterey, CA 5 Towards a POSIX Standard for Software Administration Archer state to be packaged is out- configuration was outside the side the scope of the draft scope of the standard because standard - the standard is not it was believed to be in the intended to cover the area of scope of another subgroup. software development and However, many responses to the source control. the mock ballot indicated that Source Role without configuration the In the source role a distribu- draft standard would be incom- tion, or one or more com- plete and of significantly ponents of it, is transferred less use. Since the other sub- to where it is to be group had not progressed their installed. The transfer may work, configuration has been also be to another source role added. - a staging operation. This Manager Role transfer may take the form of Having the manager role pro- electronic transmission or vides for distributed control transfer on some medium. The of the software administration concept of the source role process. The functions per- came from some of the submis- formed in the other roles can sions which had very extensive be controlled by the manager functionality associated with role. The manager role may be this area. However, other performed by the command line implementations provided much interface provided in the less functionality and allowed draft standard or by a manage- for the role to effectively ment application. It is worth null in some circumstances. stressing again that the Target Role manager role can be on the It is in the target role that same system as any (or all) of the software is installed, the other roles. that is it is deployed and Developer Role manipulated to put it in a This role is specifically out- form that will enable it, side the scope of the stan- eventually, to be run. One dard. In the developer role important aspect of the target software is constructed and role is that it may take place placed into the form known as on a system which has a dif- developed software which is ferent architecture from that the form in which it can be on which the software will accepted by the package role. run. Where there are discless Typically this will involve clients the target role is activities such as compila- taken by the server. tion, source control, etc. Client Role Structure of Packaging In the client role the The draft standard defines software is configured so that very precisely the format into it will be in a state to be which the software is pack- run. Configuration takes place aged, this being the form that on the architecture on which the source role transfers. The the software is to run. draft standard also defines Installed software may be sub- the format for developed ject to being configured software, particularly the several times, for example steering information which comms software may be config- defines how to do the packag- ured to serve several dif- ing. The draft standard does ferent paths. At mock ballot not define the format for 6 1993 LISA - November 1-5, 1993 - Monterey, CA Archer Towards a POSIX Standard for Software Administration installed or configured bundles within distributions. software (this being specific Products to particular architectures). Although products were common The rest of this section gives to all submissions it took the high level structure of some effort to tightly define the packaging format. what they were since there History were significant differences Although the various submis- in the detail between the sub- sions showed considerable com- missions. A late addition to monality in the fundamental the draft standard is the con- concepts of the packaging for- cept of bundles to group mat, this area of the draft together products. These are standard caused significant explained below. Products are problems, undergoing substan- defined in the draft standard tial changes before and after to have attributes like a mock ballot. The problem lay name, a revision number, with how many levels of struc- architecture, etc. One area of ture there should be in the concern was that two software packaging format. Products vendors might produce products containing filesets containing with the same name. The draft files was an obvious and sim- standard already incorporated ple format but one which all a mechanism to permit dif- submitters had found to be ferent versions of software to inadequate. At one point (the co-exist in a distribution and first Santa Clara meeting) a in installed software. How- recursive structure was pro- ever, in order for administra- posed whereby a product could tors to correctly identify a contain a product, and this product, a vendor tag was could be to any depth. How- added as an attribute that ever, this was not what is could be used to select a pro- commonly understood by the duct. The group realised that term "product". The group there could still be a con- hence looked for some other flict if vendors used the same (unloaded) word but ended up tag but felt it was beyond adopting, temporarily, the their remit to solve this term RNC - for Recursive Nota- problem. However, the adminis- tional Convenience! trator can also display the However, although the vendor description attribute recursive structure had many where a vendor can put addi- attractions, it was an unknown tional information, such as quantity, having no known address, support telephone existing practice. It was also number, etc. There is probably felt that when work progressed little chance of this not to the detail, let alone being unique! implementation, there would be Products contain filesets significant problems caused by and subproducts. Products can this structure. An example have dependencies on other might be dependencies (q.v.). products (see section on Dependencies). After many discussions over Filesets many meetings, the structure A fileset is a collection of illustrated in figure 2 has files that are logically been adopted. This has subpro- related. The important point ducts within products and about a fileset is that it is 1993 LISA - November 1-5, 1993 - Monterey, CA 7 Towards a POSIX Standard for Software Administration Archer Figure 2: Structure of Packaging Layout the smallest unit that can be their attributes and the specified for the tasks extent to which they still defined in the draft standard. exist in installed software. Filesets have many of the Packaging Information attributes of a product, such The packaging format defines as name, version, architec- two types of information, the ture, etc. Filesets can have data that is the actual dependencies on other software (code, data, filesets, as well as bundles, resources, etc.) and the con- products and subproducts (see trol information that enables section on Dependencies). the installation process to Sub-Products take place. It is this con- Subproducts are contained in trol information that actually products and are a method of supplies the structure dis- addressing a group of filesets cussed in the preceding sec- or subproducts. Hence a tions. In order to make ins- fileset (or subproduct) may be tallation efficient from a referred to from more than one serial medium this information subproduct. Hence subproducts is required to be at the start do not contain anything and of such a medium. are not the recursive struc- Tasks ture mentioned above. Subpro- ducts are very simple and have In this section the tasks that few attributes (no revision or are provided by the draft architecture, for example). A standard are described. These use of subproducts might be to tasks are invoked using the group together the man pages, CLI commands defined in the thus allowing an administrator draft standard or by applica- to load a product, or pro- tions. ducts, but not the man pages Phases for them. Tasks are implemented in three Bundles phases, the selection phase, Bundles enable several pro- the analysis phase and the ducts to be grouped and execution phase. managed together. A major Selection Phase example of this was the In the selection phase the operating system, which is a filesets that are to be the collection of products distri- subject of the task are deter- buted as a whole. Bundles mined. A fileset may be refer to products or other included because is has been bundles in a similar manner to specified individually or subproducts. They share many because it is part of a higher attributes in common with pro- level component (e.g. a pro- ducts. Products exist in a duct). The way in which a distribution in their own selection is specified on the right; they do not have to be command line is covered in a referred to from bundles. Some later section. In addition a details of the operation of fileset may be included bundles is still being worked because it (or a component it out by the group. There are is a part of) is needed to discussions taking place about satisfy a dependency. In this 8 1993 LISA - November 1-5, 1993 - Monterey, CA Archer Towards a POSIX Standard for Software Administration case the fileset may be parts of them. Where parts of included without being speci- distributions are to be fied to the task. copied, the selection mechan- Analysis Phase ism is used to define the com- Analysis phase determines if ponents to be copied. Where the task is likely to succeed. the destination already This involves evaluating if exists, copying involves there are enough resources, adding to the distribution. whether dependencies are Copying may take place to or satisfied, etc. Success in from different storage forms, this phase does not guarantee for example copying to a that the task will succeed but serial medium. failure should only occur if It is envisaged that copy- the task would certainly fail. ing will be a common task per- A key aspect of this phase is formed by administrators. It that no change is made to the might involve taking several system so that if the phase distributions, received from fails part way through no the implementors or a software recovery is necessary to distributor, and constructing revert to the initial state. one or more further distribu- The analysis phase is run for tions from them. These new all selected products and distributions may contain only filesets before proceeding to parts of the original distri- the next phase. butions, with only some pro- Execution Phase ducts from bundles being In the execution phase the copied or some subproducts actual work of the task takes from products. The latter place, using the information case may occur where, for from the selection phase. example, it was decided not to Packaging distribute the tutorial com- The task of packaging takes ponents of a product. place in the packaging role and involves collecting the Figure 3 shows an example components of the software, of creating two distributions, together with control informa- A and B. Distribution A is tion, and making this into a created by selecting 4 pro- distribution. The draft stan- ducts from 3 distributions. dard defines the way the Distribution B is created by steering information is sup- selecting one product from a plied to the task as well as distribution and a second pro- the way in which the component duct is also copied because files are supplied. The infor- the selected product has a mation supplied to this task dependency on it. A similar involves a detailed knowledge example could show filesets or of the software and how it is subproducts being selected constructed. It is envisaged from within products or pro- that this task will be per- ducts from within bundles. formed by the implementors of Installing the software, either directly Installation takes place in or as part of a make(1). the target role and involves Copying transforming software from the Copying takes place in the distribution format to the source role and involves copy- installed form in which the ing complete distributions or software can configured to be 1993 LISA - November 1-5, 1993 - Monterey, CA 9 Towards a POSIX Standard for Software Administration Archer Figure 3: Example of Copy Tasks run. This involves operations well as the management infor- such as creating directories, mation relating to the pro- copying files, setting permis- duct. There are some elements sions, running scripts, etc. that are not removed, these The installation process is being information that users explained in more detail in a would wish to have left. later section. Input to the Examples of this would be the installation process may be a files that make up a database distribution in filestore or the postbox in a Message (possibly copied from a serial Transfer Agent. These are medium) or directly from a identified specifically in the serial medium. control information when the Configuring product is packaged. Configuring software is the Figure 4: Request Task final step before software is actually made operational and, Request unlike installation, always The installation and confi- takes place in the client role guration tasks can involve the and on the client architec- running of scripts defined ture. The definition of confi- during the packaging task. guration depends on the These scripts may need to software but it is expected obtain information to custom- that it will normally be an ise the work they do. If the operation that can be per- scripts were to interrogate formed in significantly less the administrator at the time time than the installation the information was required, task. An example might be the the installation or configura- installation of a new revision tion task would be running of a Message Transfer Agent. interactively. To avoid this Configuring would specialise undesirable situation a script the software for the particu- is defined during the packag- lar situation and make it the ing task which asks the ques- revision actually in use. tions. This script is run by Software may be configured the request task and the more than once, each giving responses stored in a response rise to a different configured file. When the installation or instance. Taking the example configuration task is taking of the MTA again, it may be place the scripts can use the that the software is config- information from the response ured for several different file. The request task can be services. The parameters to run entirely independently of configuration are specific to the installation or configura- the software being configured, tion task and the response and are hence not part of the files distributed with the draft standard. They are sup- products to which they apply. plied via the request task. If this is not done, the Removing request task will be run at Removing a product involves the start of the installation deletion of the filestore ele- or configuration task. Figure ments that were created during 4 illustrates the use of the the installation process as request script and response 10 1993 LISA - November 1-5, 1993 - Monterey, CA Archer Towards a POSIX Standard for Software Administration file. The Installation Process Verifying One of the major items of that Verification of a distribution draft standard is how the ins- or installed software can be tallation of a product (or run in the source, target or group of products) takes client roles. It establishes place. Installation of the integrity of the informa- software involves those tion by checking the file activities needed to transform attributes and checksum it from the distribution to a against the control informa- state in which it can be run tion. Files that might change, once it is configured. and therefore should not be Files verified, are marked as such A fairly straightforward in the control information. If aspect of installation is the a customisation script creation of directories to (described in a later section) hold filesets and the copying changes the contents of a of files from the distribution file, the modification task into the installed software. should be used by the script It is also possible to create to ensure that the management links. The following sections information is updated. discusses some of the more Listing complex aspects of installa- Listing can take place in the tion. source, target or client roles Dependencies and gives information about Dependencies provide an impor- distributions and installed tant way to ensure that software. The selection pro- software is correctly cess determines the items to installed, configured, copied be listed. The depth of infor- or removed. During the selec- mation is given by an option. tion phase of a task a check Modification is made for dependent Modification takes place in software. If dependencies are the source, target or client not satisfied the task will roles and is the process by fail (this can be overriden). which the management informa- A dependency is an attribute tion is changed to reflect the of a fileset that refers to a information it refers to. This bundle, product, subproduct or may be necessary because a other fileset. A dependency customisation script has modi- may also be an attribute of a fied a file or because some of product, which means that it the management information applies to all filesets within associated with a product is the product. inapplicable in a particular situation. Systems administra- Consideration was given to tors who worked on the draft allowing dependences as attri- standard emphasised the impor- butes of subproducts but this tance of being able to correct was dropped because subpro- the information, when (not if) ducts are references not "con- it got out of step with real- tainers" and the rules would ity. Since the way in which have been too complex. the management information is The following sections stored is implementation describe the three types of dependent it is necessary to dependency defined in the provide a task to change it. draft standard. 1993 LISA - November 1-5, 1993 - Monterey, CA 11 Towards a POSIX Standard for Software Administration Archer Prerequisites filesets. In principle each A prerequisite must already different fileset in a product have been installed before the could have a different script. software that depends on it is Existing practice indicates installed or it must be that such a situation would be installed as part of the same unusual and that product installation task. During the scripts are likely to be the selection phase of a task, most common. A exception to products may be added to the this might be filesets that selected set in order to make up the operating system. satisfy prerequisite dependen- Check Script cies. The check script is run during Corequisites the analysis phase of the task In the case of a corequisite, to supplement the checks done the software that is depended automatically. For example, on must be installed and con- the automatic check for suffi- figured in order for the cient disc space could be sup- dependency to be satisfied. plemented by a disc space Dependencies such as this check that is dependent on might occur for parts of the some customisation of the ins- operating system. tallation specified in the Exrequisites response file. Since the In this case installation can- scripts are executed during not take place if the exre- the analysis phase, they are quisite has already been not allowed to make any modif- installed or has previously ications to the target role. been selected during the Installation scripts install task. Dependencies There are two installation such as this might occur where scripts, the pre- and post- versions of a product cannot installation scripts run co-exist on a system. before and after the files are Customisation Scripts copied from the distribution. A common feature of all sub- These scripts are run in the missions was the use of environment of the target scripts to allow installation role, not the client role. and configuration to be cus- Examples of such scripts are tomised. These scripts are the production of a new ver- defined during the packaging sion of a product by applying task. The scripts (apart from changes to a previous revision the configuration script) are and the transformation of data run in the Target Role and into a new format for a new thus not necessarily in the revision of the product. Vir- environment or on the archi- tually the only constraint on tecture on which the software these scripts is that if they will be run. Environment vari- modify the installed software ables for the scripts define a call to change the manage- the final environment. The ment information must be made method of returning informa- (modification task). These tion from scripts is also a extensive possibilities raise problem and a totally satis- problems for the draft stan- factory solution has yet to be dard since it is difficult to found. ensure that the rules given Scripts may be associated are sufficient to guarantee with products and with interoperability. It is 12 1993 LISA - November 1-5, 1993 - Monterey, CA Archer Towards a POSIX Standard for Software Administration probably for this reason that Product Location so much discussion within the The packaging layout specifies group concerned this aspect of a default location in the the draft standard. To enable filestore where a product will recovery to take place there be installed. This can be are also undo scripts for pre- overridden by an option to the and post-install. task. Removal Scripts Simultaneous Versions Like the installation scripts It is possible to install dif- there are pre- and post- ferent versions of a product removal scripts. The draft simultaneously, provided the standard does not define what product can be installed any- the removal scripts should do where in the filestore hierar- except that they should chy (i.e. it is relocatable). reverse any changes that the The version of a product installation scripts have made includes its revision and the and which have not, or could architecture it is to run on. not, be reflected in the Hence, it is possible to have management information. Hence simultaneous installation of if an installation script multiple revisions of a pro- creates a file and adds this duct as well as installing to the management information versions for different archi- such a file will be deleted tectures (important for automatically. However, if a servers of discless clients). data file needs to be Depending on the product, it transformed into a different may or may not be possible to format that will have to be configure multiple revisions handled by the removal script. simultaneously. Configuration Script Overlaying These scripts perform func- Only one product can exist at tions that must take place on one location. If an attempt is the architecture on which the made to install another pro- software will run or which are duct (or another version of associated with the configura- the same product) at the same tion of a particular instance location it will either be of the software. Since the rejected as an error or the only substantive action original product will be defined in the draft standard deleted. The action to be for the configuration task is taken can be selected by an the running of the configura- option to the task. It is tion script, a product can expected that all products only effectively be configured will be relocatable and the if such a script is supplied. installation of a new version The parameters to the confi- of a product will not be done guration task are supplied to by overlaying. the configuration script by Recovery means of the request task. Recovery is the process of Examples of configuration undoing the effect of a failed scripts are a compilation to task, addressed here in terms the architecture of the client of installation but also role or the definition of par- applying to copying and, to a ticular services. lesser extent, packaging and configuring. Recovery is only significant when a product has 1993 LISA - November 1-5, 1993 - Monterey, CA 13 Towards a POSIX Standard for Software Administration Archer been overlaid. Where a new between phases). Any facili- version is installed simul- ties in the draft standard taneously with an old version, must therefore cover the recovery merely involves requirements of the command removing the partially line as well as administrative installed new version. As has applications. been stated, recovery was not Level of recovery addressed in the draft that The components selected for was circulated for mock bal- installation may be the result lot. This was because the dis- of a high level definition cussions up to that point had ("install this bundle") or a not produced a consensus on low level definition ("install what should be done. However, these filesets"). It might be responses to the mock ballot deemed necessary for the showed that recovery would recovery action to be dif- have to be addressed in the ferent in the two cases - and final balloting draft. In the all the cases in between and event of a failure there are combinations. However, this basically two choices, to seems to imply that the draft delete what has already been standard should contain a very installed or to leave what has complex definition, detailing been done so that a subsequent what should happen in each installation does not have to case, and providing equally re-install parts already suc- complex overrides for the cessfully installed. The default actions. choice of these could be an Scripts installation option. The fol- When an installation fails it lowing sections discuss some is necessary to run scripts to of issues involved. undo the changes made by the Overlaid Products installation script(s). How- Information was provided to ever, it would be difficult the group about implementa- for an implementor to ensure tions that provided recovery that such scripts would work by roll-back or by copying and irrespective of the the type deletion of the old version. or position of the failure. Whatever the implementation Current Situation there are implications in The current proposal being terms of storage required, worked on in the draft stan- already a potential problem dard provides a fairly area if both the distribution straightforward recovery and installed software were mechanism. It is applicable to present on a system. the situation where a product Administrative Applications is overlaid and requires that, Applications that provide an in the event of a failure, the advanced interface to Software product is restored to its Administration would handle original state. Two new recovery in their own style. scripts are proposed, the In order to enable this to unpre-install and the unpost- happen the distributed inter- install scripts which undo any face would provide detailed changes made by the control over the phases of the corresponding install scripts. installation process (events Interactions During Tasks on completion of a phase and One area where there was not control over the transition commonality in the submissions 14 1993 LISA - November 1-5, 1993 - Monterey, CA Archer Towards a POSIX Standard for Software Administration was the facility for the ins- available as an attribute of tallation scripts to ask ques- the modified product. However, tions of the task submitter. this does not answer the ques- Since making the installation tion of how a task could check process interactive is that a new modification was undesirable some submissions appropriate for the existing effectively forbade any such modification level of a pro- questions whereas others duct. Various schemes were in enabled the questions to be current use, from those that answered at the start of the re-issued all previous modifi- installation task and even cations with each new modifi- allowed the answers to be dis- cation to those that left it tributed with the software. up to the administrator to The draft standard adopts this select the modifications to be latter approach - see the applied, handling any depen- request task. dencies or exclusions between Software Service them. Software Service is the term Reversion adopted to describe modifica- It is obviously necessary to tions made to product other be able to remove a modifica- than replacement by a dif- tion from a product and in the ferent version of the product. general case this would either This includes replacement of require a roll forward from one or more files and in situ the original, unmodified, modification of the data instance of the product or within a file, the classic would need roll back informa- form of "patching". When this tion to be kept. was initially considered many Management Information different methods of achieving Modification of part of a pro- it were described. However, duct requires that the manage- there was no common core that ment information be updated. could be discerned in these This would then enable the methods and the submitters verify task to operate were frequently not enthusias- correctly and not report an tic about their own methods. error with respect to a modi- It was therefore difficult for fied product. With a roll back the group to select an exist- provision for reversion (see ing practice to standardise above) the modified management and for this reason it was information would have to form omitted entirely from the mock part of the roll back log. ballot version of the draft Current State of Standard standard. The rest of this The current state of the draft section describes some of the standard is that there will be issues and the current state no additional facilities pro- of the draft standard. vided specifically for Level Identification software service, although the One of the major topics for rationale will explain how it Software Service was the iden- can be achieved. This involves tification of the modifica- the overlaying of one fileset tions that had been applied. with a new version that has In the completely general case one or more of the files each modification would be changed. The installation separately identified and the scripts can be used to provide list of modifications would be roll back, identification and 1993 LISA - November 1-5, 1993 - Monterey, CA 15 Towards a POSIX Standard for Software Administration Archer dependency checking. This is software administration tasks. the only solution that seemed Nevertheless, it was recog- capable of accommodating the nised that the interface to diverse schemes currently in software administration, and use. particularly distributed Installing the Operating Sys- software administration, would tem increasingly be the province While the draft standard does of an integrated interface, not address all aspects of particularly one based on a operating system update and Graphical User Interface. Such initial installation, it does an interface would have a sig- provide the basic functional- nificant advantage where ity so that it can be used as software was being distributed a fundamental part of these to, and installed on multiple processes. Facilities provided machines simultaneously, a include marking files as being task which is inherently asyn- part of the operating system chronous. Several of the sub- and indicating that a product missions indicated that such or fileset will not become implementations already effective until a re-boot existed. occurs. Excluded, however, are The Command Line Format the final stages of switching All submissions provided com- from the old to the new ver- mands to invoke the tasks and sion of the operating system, the draft standard was based which would take place during on these. The basic form of a the configuration stage. The command is initial installation of the command [options...] selections [@ target ...] operating system on an empty meaning the the command system requires special tech- operates on the software iden- niques since services that are tified by selections and the normally assumed to be present tasks take place on the hosts (e.g. the filestore) are not specified by target. The for- available. The draft standard mat of the options and target only deals with installation is covered in the rest of this of software when a POSIX com- section. The selections, being pliant operating system is a significant issue in their present and so is not applica- own right, are covered in ble to the initial installa- another section. The commands tion of the operating system implement the tasks already until this is true. This does defined. not, of course, preclude a Options vendor from providing such An important issue that had to facilities but they would be be addressed was the sheer extensions to the standard. number of options that had to Tasks using the CLI be accommodated. Not all options from all submissions One of the objectives for the were included but there was an draft standard has been stated inclination to accept that if as Operator Portability, mean- a facility had been found ing that, on any system that necessary or useful it should complies with the draft stan- be included. This issue of the dard, an administrator would number of options had already find a well known set of Com- been addressed by the sub- mands with which to perform group working on the Print 16 1993 LISA - November 1-5, 1993 - Monterey, CA Archer Towards a POSIX Standard for Software Administration standard, P1003.7.1, and com- there was a struggle to patible approach was adopted. achieve the necessary flexi- This involved specifying bility without a grossly com- options in a quoted string plex syntax. The following given as the -x option to the sections describe the details command, or in a file, the of the selection and the pathname of which is specified objectives that were being in the -X option. Within the addressed. quoted string, or file, an Depth option would consist of an A selection can specify bun- identifier and a value. The dles, products, subproducts or identifier consists of lower filesets and so can be as case letters and underscores. specific or general as These identifiers are not required. The implication is localisable to other always that all the components languages. of the item specified are Host Definitions selected. The format for specifying the Versions machine on which the task is In the draft standard, the performed is version of a product is an @ target... attribute that defines its and this was generally liked intended architecture, identi- as being intuitive although it fies the vendor and provides does not have any applicable the revision of the product precedence as a separator of itself. Hence there can be operands (its use in mail several versions of the same aliases and Berkeley commands revision of a product, each is different). This syntax for a different combination of does not appear in POSIX.2 but hardware and operating system. is legal according to the The specification of the utility guidelines of that architecture in the selection standard. As distributed util- provides wild cards and the ities extend the problem space comparison of the revision that POSIX.2 addresses, avoid- takes into account the common ing extensions was not deemed dot format, e.g. 2.03. to be essential. In the end, Locations the decision of the working A selection may also specify group was that the use of @ the location where the product was acceptable, and indeed is to be located as a result desirable over alternatives of the operation, overriding such as moving the operand to the default in the product. the options. For example, for the install Selections task the location would define A selection defines the items where the product is to be that are the subject of an installed. This feature of a operation, for example a selection is a bit of an selection might define the oddity because the rest of the software product that are to selection is concerned with be installed from a distribu- the source of the operation tion. At the simplest level whereas the location is con- this would just be the name of cerned with the destination. a product. However, there were However, it is necessary several areas where the selec- because there may be several tion got more complex and selections each needing to be 1993 LISA - November 1-5, 1993 - Monterey, CA 17 Towards a POSIX Standard for Software Administration Archer located in a different place. is the control information, Dependencies which is actually very similar Selections are also used for between the two. The differ- dependencies, that is for ence is that the format of a references from a product or distribution is defined by the fileset to a bundle, product, draft standard whereas the subproduct or fileset, but in format for the catalog for this case the location cannot installed software is not. In be specified. this latter case it is imple- Customisation mentation defined how the The systems administrators who catalog is stored although the had participated in the draft standard does define development of the draft stan- standard ways of accessing it. dard had emphasised the impor- For example, the list task tance of avoiding fixed res- reads it and the modify task trictions whilst at the same changes it. time enabling defaults and Contents of a Catalogue limits to be set for any par- Information in the catalogue ticular installation. The defines the contents (bundle, existing practice supported product, etc.) of a distribu- this concept and and so this tion or installed software, facility was built into the giving the attributes of the draft standard. components (name, revision and System Wide Defaults dependencies for example). On any system there will be Multiple Catalogues one defaults file which gives A valuable contribution from the defaults for about 25 Systems Administrators in the aspects of software adminis- group was the need for multi- tration. In addition different ple catalogues, for example defaults can be specified for corresponding to development different tasks. So, for exam- software, software under test ple, the default for whether and production software. The to try to automatically draft standard hence allows resolve dependencies could be for the catalogue to be speci- set to true for installation fied as part of the syntax of but false for copying a dis- the commands. This does how- tribution. ever raise the question of how Local Defaults one might be able to find all The system wide defaults can the catalogues on a particular be over-ridden by the options system. It would be a distinct file to a particular command, advantage if this could be a file which is in a similar achieved in some way but so format to the system wide far this has not been incor- defaults file. These in their porated in the draft standard. turn can be over-ridden by Filestore Structure what is specified on the com- mand line. The draft standard is based on The Software Catalogue a POSIX compliant filestore structure but does not specify The term catalogue applies to any other detail about how a distribution or to a collec- installed software should be tion of installed software. mapped other than that there Most of what the draft stan- must be a node under which the dard defines about a catalogue product files are installed. 18 1993 LISA - November 1-5, 1993 - Monterey, CA Archer Towards a POSIX Standard for Software Administration This requirement does not obviously important, particu- exclude the possibility of larly for the operating sys- some files being located else- tem. Installation of other where although this is software only requires that discouraged. the correct location in the Software Layout (server) filestore is chosen Software should be constructed for the software to be visible so that it can be installed to the client. However, if relative to any point in the the management information is filestore hierarchy. This is to be visible to the client it particularly important for the is important that this too is simultaneous installation of located in the correct place. multiple versions of the same The provision of multiple product. However there are catalogues is hence an impor- some types of software for tant facility for discless which this is not possible, clients. particularly the operating Heterogeneous Management system itself. In such cir- cumstances the software will The group would very much have to be constructed to pro- liked to have made the stan- vide some other method of han- dard yield implementations dling simultaneous versions, that were interoperable at the possibly by some special task level. That is to say action as part of configura- that the manager role could tion. manage any of the other roles Alternative Root irrespective of the systems on Sometimes it is necessary to which the roles were imple- install software relative to a mented provided they conformed virtual (or alternative) root. to the standard. This would This means that absolute provide not only the capabil- references in the installation ity of heterogeneous manage- to the filestore hierarchy are ment using the commands taken to be relative to the defined in the standard but alternative root. This is par- also a mechanism for enabling ticularly useful for instal- management applications to be ling operating system software written which could manage for a discless client or on a conformant systems. Unfor- disc unit that will be tunately this would require installed in another system the standard to refer to some (preloaded software). The mechanism for performing dis- discless client example is tributed tasks and no such illustrated in figure 5 in mechanism is available as a which software is installed on formal standard. However, the the target with node D as the group did receive several sub- alternative root. For the missions specifying how this client J is the root, node K could be achieved using de is node E, etc. and so it facto standards. In addition appears to the client as if some work was done on the for- the software had been mal definition of Managed installed with the actual root Objects that corresponded to as J. the definitions in the stan- Discless Clients dard. An agreement has been For discless clients the reached with the X/Open Sys- alternative root facility is tems Management Working Group 1993 LISA - November 1-5, 1993 - Monterey, CA 19 Towards a POSIX Standard for Software Administration Archer Figure 5: Filestore Structure for Discless Clients that they would progress this Lovelace Road, BRACKNELL aspect of the standard, to be Berks, RG12 8SN, UK and elec- published in due course as an tronically at X/Open Specification. barcher@oasis.icl.co.uk. How to Participate in the Bal- lot When the ballot is about to take place the IEEE will advertise for participants. Anyone can submit comments but only those from members of the IEEE (or the Computer Society of the IEEE) are counted for the ballot; comments from oth- ers are "for information only". To ensure that you are notified of the ballot send your details to the author or the chair of the group, Jay Ashford at ashford@austin.ibm.com. Acknowledgements A lot of people have contri- buted to the draft standard, too many to be mentioned here. However, particular thanks are due to Jay Ashford, Matt Wicks and George Williams who have reviewed this paper to ensure that it reflects what the draft standard actually says rather than my own prejudices. Author Information Barrie Archer is a Systems Designer working in ICL Client-Server Systems. He works on the strategy of ICL's Systems Management products and participated in the development of ICL's OPEN- framework Architecture for Systems Management. He is the ICL representative on the X/Open Systems Management Working Group and POSIX 1003.7 Working Group. He can be reached by mail on ICL 20 1993 LISA - November 1-5, 1993 - Monterey, CA